Smart Reading - Ключевые идеи книги - Мифический человеко-месяц, или Как создаются программные системы. Фредерик Брукс

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

Спустя 20 лет, в редакции 1995 года, Брукс указал на уязвимое место в этой схеме: если она реализуется линейно, накопление ошибок неизбежно и с увеличенным на отладку кода временем. В издании 1975 года Брукс настаивал на практике пилотной системы, которую программисты должны создать перед тем, как разработают окончательную модель. Пилот выявит ошибки в проектировании, а потом будет полностью отредактирован. За 20 лет подход к созданию программ изменился, и в 1995-м Брукс признает: принцип «Планируй выбросить!» не работает. Он указывает на преимущества инкрементной модели – поэтапной стратегии, когда разные части системы разрабатываются в разное время и разными темпами, а если одна часть готова, ее сразу интегрируют в систему. Но его базовый принцип остался неизменным: добавить рабочую силу в отстающий по графику проект – окончательно затормозить процесс.

Концептуальная целостность – ключевое условие проекта. Вспомним средневековые соборы Европы, которые строились десятилетиями, но сохранили стилистическое единство. К этому же должны стремиться разработчики ПО. Отличный пример концептуальной целостности – интерфейс WIMP (windows, icons, menus, pointers – окна, значки, меню, указатели), ныне известный каждому пользователю.

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

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

Каждый подпроект такой сети содержит две лидерские роли: роль продюсера [2] Роль технического директора на мелком проекте выполняет techlead. (он собирает команду, распределяет работу, определяет график, ищет ресурсы) и роль технического директора [3] Подход отчасти устарел. Наиболее современный подход – группа так называемых Т-специалистов, максимально взаимозаменяемых сотрудников, в которой каждый знает какую-то часть функционала очень хорошо, но может делать и все остальное. , или архитектора (он продумывает дизайн и отвечает за концепцию). Иногда, особенно в малых командах, продюсер и директор могут быть одним и тем же человеком. Однако в крупном проекте каждая из ролей требует полного рабочего дня, и в этом случае роли лучше разделить: продюсер может быть главой группы, а директор – его правой рукой, и наоборот.

Для обеспечения концептуальной целостности системы важно отделить архитектуру от реализации. Архитектура проекта определяет, что сделано, реализация – как сделано.

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

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

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