ZNP #2484; Как пишутся программные системы

Фредерик Брукс

Мифический человеко-месяц

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

Гораздо сложнее рыть вглубь, подбираясь к источникам знания, к самой сути, использовать все имеющиеся источники с книгами, признанными "золотым стандартом", во главе.

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

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

Именно такие занудные книги вкупе с многими часами практики и служат залогом превращения специалиста в настоящего мастер своего дела." -

примерно так я мотивировал себя на прочтение нетленного "МЧ-М" Фредерика Брукса. Едва взглянув на содержание и пролистав книгу мельком, я понял, что без такой вот самомотивационной речи не обойтись - книга весьма специфичная и определенно не нацелена на круг людей вне IT сферы: довольно сухой язык, выверенная структура как у программы, взвешенные и запутанные рассуждения, вызывающие мигрень у любого непосвященного в специфику вопроса читателя.

Но не зря же с момента ее выпуска в 1975 она издавалась 20 раз, райт?..

Автор

Фредерик Филлипс Брукс - американский ученый в области теории вычислительных систем. Стал бакалавром по физике, пошел дальше и получил ученую степень по прикладной математике в Гарварде, где его научным руководителем был легендарный Говард Эйкен - пионер компьютеростроения.

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

Затем началась его преподавательская карьера - Фредерик ни много ни мало основал факультет информатики в универе Северной Каролины и возглавлял его в течении 20 лет. До сих пор является действующим ученым-практиком и изучает виртуальную реальность и молекулярную графику, что бы это ни значило.

Не так много информации о нем публичном доступе, плюс она не такая гладкая и красивая на первый взгляд, однако это человек сделал огромный вклад в индустрию, и это объективная оценка - в 1999 году Брукс получил самую престижную премию в информатике, премию Алана Тьюринга за исторический вклад в архитектуру компьютеров, операционные системы и инженерию программного обеспечения.

Достаточно аргументов для выдачи Фредерику кредита доверия, хм?

Книга

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

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

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

Предисловие

Что знает обыватель о создании программ? Зачастую очень немного и не до конца правдивую информацию, засветившуюся в новостях.

Мы слышали про Билла Гейтса, написавшего в 16 лет программу для управления дорожным трафиком, бросившего универ и основавшего Microsoft; мы прекрасно осведомлены о Стиве Джобсе и его гаражном производстве, захватившем впоследствии умы всего мира; мы помним локальных гениев, то и дело проскакивающих под заголовками "Двое 20-летних разработчиков основали стартап стоимостью в ХХ миллионов долларов".

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

Программа - завершенный продукт, пригодный для запуска автором на системе, на которой она была разработана. Именно программа является результатом труда стартаперов, являясь скорее идеей, чем реально полезным инструментом, так называемым minimum viable product, с которым можно идти и просить денег у инвесторов или запускать страничку на кикстартере.

Чем же она отличается от того программного обеспечения, которым пользуются компании и частные лица на повседневной основе, от того, который вы можете купить, как Фотошоп?

Два пути:

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

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

Эссенция

Эссенция, а именно первые девять глав - тот самый мастрид, ради которого стоит читать МЧ-М

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

Рассмотрим детальнее, из чего состоят эти ямы:

• нехватка календарного времени

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

Если проект не укладывается в сроки, то добавление рабочей силы еще сильнее задержит его. (Закон Брукса)

Менеджеры склонны линейно экстраполировать время, потраченное на небольшие проекты или части систем при расчете сроков доставки больших программных продуктов в стиле "проект в 70к строк кода пилили полгода, значит, 140к строк напишут за год", что в корне неверно. В лучшем случае показатель временного ресурса растет как степенная функция с коэффициентом 1.5

• неэффективная организация команды

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

Идея Брукса состоит в том, чтобы бригады создавались по принципу операционных: один главный "хирург", один его правая рука, остальные имеют так или иначе вспомогательные роли - администрирование документации, адаптация инструментов, тестирование и т.д. Жизненно необходимо, чтобы продукт разрабатывался одним мыслителем и его вторым пилотом, который в крайнем случае сможет занять его место (bus-factor), остальные сугубо практики. Такие бригады обеспечат целостность продукта и повышение общей продуктивности за счет резкого уменьшения обмена информацией.

Помимо этого такая организация положительно отзывается на попытки масштабирования - предположим, для крупного проекта требуется 200 людей, тогда общение можно наладить всего для 20 "хирургов".

• демократия проектирования

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

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

Архитектор в данном случае является правителем - аристократом, представляющим интересы пользователя. Его задача использовать все свои знания в интересах пользователя и донести требуемое до исполнителя.

Разработчики-исполнители же сразу сосредотачиваются на той части задачи, которая была им выделена и могут проявить свои творческие и технические способности в полной мере, в результате бенефитят все.

• разрозненное документирование

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

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

• недостаточный обмен информацией

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

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

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

Практические нюансы [не релевантны]

Главы 9 - 17 более не имеют смысла, так как описывают условия работы в 75 году. К примеру, одна из глав посвящена работе с бумажной (!) документацией проекта, другая - способам работы с памятью в условиях ее невероятной стоимости (уже в 95 году 1мб подешевел почти в 5к раз).

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

• планирование на выброс

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

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

• планируйте систему с учетом будущих изменений

Постоянны только изменения. Необходимо изначально создавать структуру, позволяющую вносить изменения без критических побочных эффектов.

• оставание в полгода начинается с оставания в 1 день

Необходимо иметь четкие вехи продвижения проектов (не "завершена на 50%", а "проект собран в базовой конфигурации и готов к тестам"), иначе заметить и распознать проблему будет сложно

3. Работа над ошибками

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

В целом вполне читабельно, гораздо ближе к текущей ситуации (95 год на момент публикации), но и ничего кардинально нового. Приятное и логичное завершение книги.

Итог

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

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

P.S. Следующие заметки выйдут с запозданием и будут посвящены книге о циркадных ритмах, которыми я завершу свою ликбез-вылазку в царство Морфея.