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