0. ПРЕДИСЛОВИЕ

На берегу реки стоит лодочная мастерская, выпускает деревянные лодочки. Неплохие лодочки, хотя и выкрашены они в очень странные цвета. Но они плавают и слушаются руля, поэтому заказчики довольны (ну или хотя бы могут их терпеть). Иногда лодочки дают течь, тогда их возвращают в мастерскую. Работа над лодочками устроена так, что каждую лодочку создаёт -- и в последствии чинит -- один мастер; отдать лодочку в ремонт другому мастеру удаётся редко, поэтому болезнь, увольнение или уход мастера на пенсию -- большая проблема для мастерской.

Однажды в мастерской случился переполох. Пришёл заказ на постройку большого катера. Хозяин мастерской закупил металла и бросил на постройку катера лучших мастеров.

Внимание, вопрос! Сколько времени, сил и ресурсов уйдёт у мастеров по деревянным лодочкам на постройку катера? А если придёт заказ не на катер, а на 50-метровую яхту? А военно-морской корабль построит такая мастерская?

Увы, объекты такого масштаба в маленькой мастерской не построить никогда, даже если закупить самый качественный металл и бросить на строительство самых лучших мастеров. Для выпуска катеров, яхт и больших кораблей нужен завод. (Надо сказать, что я бы предпочёл, чтобы и маленькие лодочки выпускались на заводике... во всяком случае по чертежам и в соответствии с принятыми стандартами качества.)

Для создания больших программных проектов нужен завод по производству ПО. И такой завод ещё нужно суметь построить. Потому что завод -- это не только директорат и рабочие у станков. На заводе должен быть инженерный отдел, разрабатывающий чертежи с точностью до сотой доли миллиметра; применительно к программированию это группа аналитиков и архитекторов, разрабатывающая проектную документацию. На заводе -- цеха, у каждого цеха есть начальник, и у каждый бригады в цеху есть свой старший; применительно к ПО это значит, что над каждым проектом должен стоять менеджер среднего звена, а над большими -- так и не сколько. И у всех есть хорошо определённый Процесс; инженеры знают, что им надо разработать; на основе их разработок директорат знает, сколько и каких материалов надо закупить, и как переоборудовать цеха; начальники цехов вместе с чертежами получают от инженеров инструкции по их реализации и распределяют задания среди бригад. Каждый отдельный программист, может, и не видит всей системы в целом; но менеджер и архитектор, стоящие над проектом, видят и ведут проект в нужную сторону.

Метафора получилась выразительная потому, что управление разработкой ПО не так уж сильно отличается от управления разработкой чего угодно. Отличается, конечно, нельзя на разработку ПО поставить первого попавшегося менеджера. Но есть и много сходства; иногда до степени неразличимости.

1. SOFTWARE ENGINEERING

Про разработку ПО есть целая наука -- инженерия программного обеспечения. В ней много разделов, и в соответствии с этими разделами много этапов разработки сложных программных комплексов -- анализ требований и создание технического задания, проектирование и создание проектной документации, программирование и создание документации для программистов и системных администраторов, тестирование, эргономика ПО, создание документации для пользователя.

Классическим -- и наиболее устаревшим -- является последовательный, каскадный метод: анализ - проектирование - программирование - тестирование. Недостаток этого метода -- дороговизна возврата к предыдущим этапам. Если на этапе программирования (или, что ещё хуже, на этапе тестирования) возникает необходимость внести изменения в архитектуру, то при каскадном методе это оказывается сложно, медленно и дорого. Поэтому появилось много способов, изменяющих классический подход и позволяющих в той или иной степени добиться возможности возвращаться назад и перепроектировать уже спроектированное или перереализовать уже запрограммированное. Таким методом является, например, итеративный метод. Ещё одним из таких методов является спиральный метод разработки, созданный теоретиком и практиком инженерии ПО 80-90-ых годов Барри Боэмом.

Альтернативой классическим методам являются гибкие, адаптивные методики разработки -- Agile, Scrum, XP (экстремальное программирование). Один из авторов экстремального программирования Кент Бек учит, что гибкие методики предназначены, во-первых, для создания надёжного ПО, которое может подвергаться быстрым изменениям в условиях неопределённых или часто меняющихся требований бизнеса; а во-вторых для изменения процесса разработки, чтобы перепроектирование системы или внесение изменений в код стало частью процесса разработки -- таким образом упрощается, ускоряется и удешевляется возврат к предыдущим этапам.

Сам я сторонник классики. Не то, чтобы я был противником гибких методов. Но, во-первых, я редко оказываюсь в условиях неопределённых или часто меняющихся требований бизнеса; а во-вторых я уже больше 10 лет работаю удалённо, а удалённая работа не сочетается с отдельными элементами гибких методов, особенно с программированием парами.

Чего я совсем не приемлю, так это подхода некоторых "экстремальщиков", которые вычитали в книгах про XP, что проектирование не нужно и документацию писать не нужно, и на этом остановились, но говорят про себя "практикуем гибкие методы".

Элементы гибких методик работают только вместе, из них тяжело выбрать что-то нужное и выбросить остальное как ненужное. Экстремальное программирование убирает этап проектирования и отказывается от документации по определённым причинам, а потому знает, чем и как их заменить. Отдельный этап проектирования заменяется ежедневным перепроектированием и рефакторингом. Все виды документации заменяются интенсивным личным общением. Представитель заказчика постоянно находится среди разработчиков, они ежедневно общаются, поэтому не нужно писать ТЗ. Программисты постоянно общаются между собой, поэтому нет необходимости писать документацию для программистов. Программирование в парах приводит к тому, что код постоянно обсуждается, а ежедневная перетасовка пар -- к тому, что каждый разработчик досконально знает весь код системы. Только в таких условиях экстремальное программирование работает.

2. УПРАВЛЕНИЕ РАЗРАБОТКОЙ

Я считаю, что над каждым проектом должен стоять администратор (менеджер среднего звена), управляющий процессом разработки ПО. А над большими проектами -- так и несколько менеджеров, в зависимости от количества подсистем.

И над каждым проектом должен стоять инженер (архитектор, проектировщик, ведущий программист).

Менеджер занимается людьми и их взаимодействием. Лидер создаёт команду.

Проектировщик разрабатывает архитектуру системы, деление на подсистемы, их взаимодействие. Ведущий программист следит за процессом разработки, качеством кода и документации.

Я встречал людей, которые могли совмещать 2 эти должности, но это скорее исключение. Успешно совмещать административную, лидерскую и инженерно-техническую работу могут лишь редкие гении.

3. ПРОЕКТИРОВАНИЕ

Я сторонник тщательной проработки архитектуры и детализации модулей и их взаимодействия. Сторонники гибких методов обходятся без предварительного проектирования за счёт того, что осуществляются перепроектирование ежедневно. Это необходимо в условиях часто меняющихся требований со стороны заказчика, но я не могу представить себе самолёт или луноход, управляемый ПО, разработанным экстремальным программированием.

Этап проектирования в хорошем проекте может занимать до 60% времени работы над проектом, но зато на этом этапе будет разработана архитектура с такой степенью детализации, что программистам-то и работы не останется. Вся работа программистов сведётся к переводу проектной документации на язык программирования.

4. ТРИ ЛИЦА ПРОГРАММЫ

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

Редко так бывает, что программа быстро пишется, отдаётся заказчику и забывается навсегда. Обычный жизненный цикл программного проекта -- разработка - внедрение - сопровождение. И на этапе сопровождения могут вноситься существенные изменения.

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

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

5. ДОКУМЕНТАЦИЯ И КАЧЕСТВО КОДА

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

В экстремальном программировании качеству кода тоже уделено внимание. Поскольку каждый программист в XP может работать над любой частью кода, весь код должен быть единообразен. Либо экстремальная команда разрабатывает единый стандарт кода на все свои проекты, либо на каждый проект отдельно, но весь проект должен быть написан в едином стиле.

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

Документация для системных администраторов и администраторов баз данных содержит инструкции по установке, инициализации и сопровождению работающих программ, установке дополнительных модулей, настройке БД, модернизации программ при выходе новых версий.

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

Программисты обычно открещиваются от подобного процесса; стандартная фраза "да я тогда только ваши бумажки и буду писать, когда же мне программировать?" Это отговорка. Написание документации и прочей информации вне кода действительно несколько уменьшает эффективность работы над кодом отдельного программиста, но увеличивает эффективность работы проекта и всей организации. С хорошей документацией, например, становится гораздо проще ввести в проект нового разработчика.

Так же я твёрдый сторонник единообразия кода. Каждая организация или хотя бы каждый проект должны выработать и формализовать стандарты на стиль исходного кода. Я считаю необходимым использовать полуавтоматизированные программы проверки качества и стиля кода -- pyflakes/pep8/pylint/pychecker. Помимо единообразия стиля они, бывает, находят ошибки в коде. Ещё я рекомендую использовать программы автоматической генерации документации (epydoc, doxygen). Эти программы создают стандартного вида web-странички, в которые выносится информация из комментариев к модулям, классам и т.д. О необходимости таких комментариев я уже говорил выше, а программы автоматической генерации документации требуют написания этих комментариев на своих особых языках разметки, что увеличивает единообразие комментариев. Опять же, у меня были случаи, когда программы генерации документации находили мне ошибки в коде.

6. ДРУГИЕ СПОСОБЫ ОБЩЕНИЯ РАЗРАБОТЧИКОВ

Помимо кода и документации необходимо наладить разные формы общения среди разработчиков. Я предпочитаю интенсивное электронное общение, а не личное присутствие на совещаниях. Во-первых, я работаю вне офиса. А во-вторых, часто от совещаний не остаётся никак следов, в то время как я считаю, что от совещания должен остаться протокол, хотя бы краткий; "слушали; постановили; а вот эти идеи отвергли"; отвергнутые идеи тоже следует вносить в протокол, чтобы не возвращаться к ним снова и снова при последующих обсуждениях, или возвращаться, но уже в других условиях и с другими аргументами.

Поскольку программисты такие протоколы добровольно всё равно вести не будут, я предпочитаю уменьшить число и продолжительность личных совещаний, и перейти к электронному общению. От электронных средств остаётся как минимум полный архив (хотя выжимки из него хорошо бы создавать вручную).