ся в исходном коде и уметь проводить модификации, которые хоро% шо уживаются с имеющимся кодом.

Сопровождение

Чаще всего программисты занимаются сопровождением сущест% вующего кода, исправляя дефекты и поддерживая его работоспо% собность в меняющихся окружающих условиях. Для этого нужен тщательный, методичный подход. Может понадобиться широкое исследование, которое потребует напрячь ваши дедуктивные спо% собности, так как редко можно встретить систему, достаточно хоро% шо документированную для сопровождения, особенно если она ста% реет и приближается к концу своего существования.

4.Если программирование – это искусство, то каким должно быть соот ношение обдумывания и планирования, с одной стороны, и интуиции и инстинктивности – с другой? Чем руководствуетесь вы – инстинк том или планом?

Как мы уже видели, эффективные программисты применяют оба под% хода. Интуиция и творческое чутье позволяют создавать элегантный код. Параллельно с ними действует вдумчивое планирование, гаранти% рующее надежность, практичность и своевременный выпуск кода.

Нельзя вывести оптимальное соотношение или формулу для того и дру% гого. Эффективные программисты владеют обоими подходами и умеют проявлять сдержанность в их применении.

Глава 17. Вместе мы – сила

Вопросы для размышления

1.Почему программы пишут командами? В чем преимущества относи тельно самостоятельной разработки?

Разрабатывать программы в одиночку, видимо, проще; не нужно рабо% тать вместе с другими странными личностями, не нужно координиро% вать работу или страдать от неэффективного руководства. Нетрудно, однако, увидеть и многие преимущества групповой работы над про% граммным обеспечением.

Команде доступно решение более крупных задач в результате разделе% ния их на части и передачи отдельным разработчикам. Код можно соз% давать быстрее. В группе таланты разработчиков объединяются, обра% зуя нечто большее, чем простая сумма частей. Если отсутствует четко определенный проект или предварительный эскиз, то более широкий спектр навыков и знаний в группе имеет явное преимущество; коллек% тивная работа фильтрует идеи и предлагает лучшие решения. Рецензи% рование со стороны коллег обеспечивает лучшее качество работы.

Существует еще личная мотивация: технари любят работать над кру% тыми проектами. В составе команды вы можете работать над система%

С другой стороны, есть надежные индикаторы того, что команда не мо% жет работать эффективно. В этом списке есть как внутренние, так и внешние факторы:

•Нереалистичный график работы и срок окончания, устанавливае% мый до того, как команда может оценить объем работы.

•Неясные задачи проекта и отсутствие технических требований к про% екту.

•Нарушение коммуникативных процессов.

•Плохие или неподготовленные руководители команд.

•Плохо определенные роли и ответственность участников – кто и за что отвечает?

•Неправильное личное отношение к работе и личные цели.

•Некомпетентность членов команды.

•Оценка отдельных разработчиков не по заслугам, наличие любимцев.

•Оценка разработчиков по критериям, не соответствующим задачам команды.

•Большая текучесть кадров.

•Отсутствие изменений в процедуре руководства.

•Отсутствие обучения и наставничества.

3.Сравните групповую разработку программ и метафору строительства (см. раздел «Действительно ли мы собираем программы?» на стр. 240). Позволяет ли она лучше понять групповую работу?

Есть несколько метафор для описания нашей работы (например, спор# тивная команда, или хоровое общество Демарко, или фабрика, о ко% торой мы шутим здесь) (DeMarco 99). Проблема любой метафоры в том, что она справедлива лишь отчасти. У программирования есть свои задачи и проблемы. Химическая технология отличается от граж% данского строительства, а то отличается от съемки фильма, а съемка отличается от написания программ.

Метафора стройки полезна, хотя и не идеальна. В конце концов, мы сооружаем программу в соответствии с планом, из отдельных блоков (одни из которых мы изготавливаем сами, а другие покупаем или до% стаем). Вот полезные параллели:

•Вам нужна бригада: нельзя построить в одиночку ни небоскреб, ни высокотехнологичную программную суперструктуру уровня пред% приятия.

•У бригады есть задача: она должна завершить строительство в соот% ветствии с назначенными сроками и выделенным бюджетом.

•Кто%то является заказчиком работы, имея цель: это конечная цель работы.

•Все члены бригады заняты разными делами: разделение ролей по% могает выполнить работу. Есть архитекторы, строители, плотники, водопроводчики, электрики, прорабы, конторские работники, ох%

рана и пр. Каждый вносит свой важный вклад.

Каждое из этих обстоятельств связано с дополнительными затратами труда. Однако понятно, что команда программистов может создать бо% лее крупный продукт, чем работающий в одиночестве кодировщик. Отсюда следует, что должно существовать оптимальное соответствие между численностью команды и размером задачи; оно меняется в за% висимости от типа разрабатываемой системы.

По мере роста команды растет вероятность, что отдельные программи% сты начнут работать спустя рукава, поскольку на общем фоне это бу% дет незаметно. В «Мифическом человеко%месяце» Брукса показывает% ся, что подключение к проекту новых работников необязательно при% водит к его ускоренному завершению (Brooks 95).

Вкрупном проекте больше шансов, что успех или провал будут опре% деляться административными способностями, и больше возможностей для администраторов вызвать катастрофический провал.

Вцелом, чем меньше команда разработчиков, тем лучше; но она долж% на быть достаточно велика, чтобы суметь выполнить задачу.

6.Как защитить команду от проблем, создаваемых неопытными чле нами?

Неопытные программисты будут существовать всегда. Это верно для любой профессиональной области. Во многих профессиях новобранцы в той или иной форме проходят период ученичества и должны завер% шить академическое образование. Это гарантирует, что их мастерство будет на каком%то приемлемом уровне. Несмотря на обилие академи% ческих курсов программирования (разного качества), в нашей профес% сии не принято никакого формального вида ученичества. Наставниче% ство над молодыми программистами – великолепный способ быстро довести новичков до разумного стандарта.

Есть несколько приемов, делающих работу неопытных кодировщиков менее рискованной:

•Будьте разумны и не ждите от них чудес. Давайте стажерам посиль% ные задания.

•Следите за их ростом и старайтесь, чтобы они не боялись задавать вопросы и говорить о проблемах.

•Не требуйте от них слишком большого начального опыта: пусть пользуются популярными языками и инструментами, которые по% требуют меньше времени для набора скорости.

•Не применяйте новейшие технологии и приемы.

•Стандартизируйте набор инструментов в каждой команде, чтобы новичкам достаточно было освоить его один раз.

•Учите их.

•Рецензируйте их код.

•Выберите им наставников.

•Программируйте с ними в парах.