Б. Страуструп - Язык программирования С++. Специальное издание, 3-изд. Бином. 2004 (1160791), страница 180
Текст из файла (страница 180)
Можно разработать список проверок для гарантии того, что методики придерживаются, нли выработать механизмы для обязательного соблюдения процедур и условных обозначений. Далее, глядя на приведенную в э 24.3 классификацию зависимостей, можно объявить, что одни зависимости хороши, а другие плохи, и обеспечить механизм анализа, гарантирующий, что этн соображения применяются во всем проекте, Чтобы завершить это «укрепление дисциплины» в процессе производства программного продукта, нужно определить стандарты документации (включая орфографические и грамматические правила, а также способ набора) и унифицировать облик программы (включая спецификации на то, какие особенности языка можно применять, а какие нельзя, какими видами библиотек можно пользоваться, а какими нельзя, какие лелать отступы, как называть функции, перемениь|е, типы и т, д.). Многое из этого может способствовать успеху проекта.
Во всяком случае, было бы безрассудно, не. имея более или менее определенной и ловольно жесткой всесторонне продуманной схемы, браться за проектирование системы, которая в конечном итоге будет иметь десять миллионов строк кода, в разработке которой будут заняты сотни людей, а лет через десять тысячи людей будут заниматься сопровождением и поддержкой. К счастью, болыиинство систем не попадает в эту категорию. Однако, как только принята идея, что такой-то метод проектирования, кодирования и ведения дойумен- Глава 23. Разработка и проектирование 788 тацин «правилен», возникает желание применять его повсеместно и неукоснительно.
В небольших проектах это может привести к нелепым ограничениям и бессмысленным затратам. В частности, такой подход ведет к тому, что в качестве оценки успеха будет рассматриваться передвижение бумаг и заполнение форм, а не продуктивная работа. Бели это произошло, настоящие программисты и проектировщики покинут проект, и их заменят бюрократы. Поскольку в программистском сообществе уже имели место такие смешные ошибки в приложении метода проектирования (надо надеяться, вполне обоснованные), подобные неудачи порой служат оправданием для несоблюдения никаких формальностей в процессе разработки. Это, в свою очередь, ведет к неразберихе и неудачам, которые стремился предотвратить предыдущий метод.
Действительная проблема заключается в том, чтобы для разработки конкретного проекта выбрать соответствующую степень формальности. Не думайте, что вы легко найдете решение этой проблемы. Для маленького проекта годится по сути дела лю бой подход. Хуже того, похоже, что и для болыпих проектов годится по сути дела любой подход — как бы плохо он ни был задуман и как бы жестоко ни относился к вовлеченным в него людям — если вы готовы потратить на разработку неограниченное количество времени н денег. Ключевая проблема при любой разработке заключается в том, как сохранить целостность проекта. Эта проблема растет в нелинейной зависимости от масштаба. Только отдельная личность или неболыпая группа может сохранять понимание обШих задач всего проекта. Большинство же должно затрачивать столько времени на его составные части, технические детали, повседневное администрирование и т. п., что задачи проекта в целом легко забываются или подчиняются более локальным и непосредственно важным целям.
Отсутствие личности или группы с явно поставленной задачей поддерживать целостность проекта часто означает неудачу. Вше один рецепт неудачи — не дать возможности этой личности или группе повлиять на проект в целом. Отсутствие согласованной долговременной цели приносит проекту и организации больше вреда, чем каков-либо частный недостаток. Работа несколысих личностей должна заключаться в формулировании такой общей цели, в постоянном размышлении о ней, в написании ключевых документов по проекту в пелом н в том, чтобы помочь дру гнм держать эту цель в голове. 23.5.3.
Личности Описанный здесь метод проектирования выводит на первое место умелых проектировщиков и программистов. Таким образом, выбор проектировщиков и программистов имеет критическое значение для успеха организации. Руководители часто забывают, что организация состоит из личностей. Распространено мнение о том, что все программисты одинаковы и взаимозаменяемы. Подобное заблуждение может развалить организацию, приведя к изгнанию самых эффективных личностей, и обрекая оставшихся на работу гораздо ниже своих способностей. Личности взаимозаменяемы, только если им не давать воспользоваться своими способностями выше того абсолютного минимума, которого требует данная задача.
Таким образом, миф о взаимозаменяемости негум анен и по сути своей расточителен. 23.5. Менеджмент 789 Большинство способов измерения производительности труда программиста поощряет расточительную практику и не принимает в расчет решающего индивидуального вклада. Самый наглядный пример — относительно широко распространенная практика подсчета производительности труда по числу строк кода, страниц документации, проведенных тестов и т. и. Такие графики хороши на картинках, но имеют весьма отдаленное отношение к реальности. Например, если продуктивность измеряется числом строк кода, успепшое повторное использование оказывает отрицательное влияние на показатели продуктивности программиста.
Успешное применение лучших принципов для перепроектирования большого фрагмента программы, как правило, производит тот же эффект. Измерить качество произведенной работы гораздо труднее, чем валовое количество, и все же отдельных личностей и группы нужно награждать, основываясь на качестве их результатов, а не на грубых количественных показателях. К сожалению, разработка практических способов измерить качество — насколько я понимаю — едва ли ведется Кроме того, показатели, описывающие состояние проекта не полностью, имеют тенденцию искажать действительность.
Люди приспосабливаются к установленным промежуточным срокам и привыкают улучшать индивидуальную и коллективную производительность, определяемую показателями. Прямой результат этого состоит в уменьшении целостности системы и производительности труда.
Например, если определяегся, сколько ошибок должно быть ликвидировано в срок (или сколько должно остаться), мы увидим, что в срок укладываются за счет понижения быстродействия или увеличения требований к аппаратуре, необходимой для работы системы. И наоборот, если оценивается только быстродействие, количество ошибок несомненно возрастет, когда разработчики будут стараться оптимизировать систему для скорейшего прохождения данного теста.
Отсутствие хороших и понятных показателей качества выдвигает высокие требования к технической квалификации руководителей,но альтернатива этому — систематическая тенденция награждать за любую бурную деятельность, а не за реальное продвижение к цели. Не забывайте, что руководители — тоже люди. Им нужны по крайнец мере те же знания о новых методах, что и людям, которыми они руководят. Как и в других областях, при разработке программ мы должны рассматривать долгосрочную перспективу.
Совершенно невозможно судить о производительности индивидуума по его работе в течение года. Однако, большинство работников имеют достаточн 1 долгий послужной список, по которому можно надежно оценить техническую зрелость работника и его производительность в последнее время. Отказ от учета такого списка— как это делается там, где личностей рассматривают как взаимозаменяемые винтики— оставляет руководителей на милость сбивающих с толку количественных показателей. Одно из последствий «долгосрочного» подхода и отказа от создания «школы управления взаимозаменяемыми идиотами» заключается в том, что личностям (и разработчикам, и руководителям) нужно дольше врастать в интересную сложную задачу, Это отбивает охоту перепрыгивать с одной работы на другую и переходить из одного отдела в другой «из соображений карьеры .
Целью должна быть низкая текучесть кадров как среди технического персонала, так и среди ключевых руководителей. Ни один руководитель не может добиться успеха без взаимопонимания с главными проектировщиками и программистами и без новых знаний в соответствуюьцей технической области. И наоборот, никакая группа проектировщиков и разработчиков не может в конечном итоге добиться успеха без поддержки со стороны компетен- 790 Глава 23. Разработка и проектирование тных руководителей и без хотя бы минимального выхода за рамки узкотехнического понимания проблемы, над которой они работают.
Там где требуются нововведения, старшие технические работники, аналитики, проектировщики, программисты и т. п. сталкиваются с критически важной и трудной ролью по ознакомлению с новыми методами. Эти люди должны изучить новую технику и во многих случаях отказаться от старых привычек. Это нелегко. Такие люди, как правило, внесли большой личный вклад в старые методы работы и опираются на свои успехи и репутацию, достигнутые при помощи этих методов. То же самое относится н ко многим техническим руководителям.
Естественно, часто такие люди боятся перемен. Это может привести к завышенной оценке сложности, связанной с нововведениями, и неохотному ознакомлению с проблемами старого подхода. Так же естественно, что люди, ратующие за перемены, склонны к завышению выгоды от новых методов и недооценке проблем, связанных с изменениями. Эти две группы личностей должны общаться, научиться говорить на одном языке и помочь друг другу выработать модель перехода.
Иначе — организационный паралич и уход наиболее способных личностей из обеих групп. Обе стороны должны помнить, что самые преуспевшие «консерваторы» — это вчерашние «радикалы». Получив возможность приобрести опыт без унижения своего достоинства, более опытные программисты и проектировщики могут стать самыми надежными и успешными проводниками перемен. Их здравый скептицизм, знание запросов пользователей, знакомство с организационными барьерами могут оказаться незаменимы.
Те, кто ратует за скорые и радикальные перемены, должны понять, что чаще всего необходим такой переход к новой технике, который требует постепенного привыкания. И наоборот, те, у кого нет желания видеть перемены, должны найти такие области, где перемены не нужны, а не вести ожесточенные арьергардные бои в областях, где новые требования уже значительно изменили условия достижения успеха. 23.5.4.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
