Кони Бюрер,
специалист в области разработки ПО,
компания Rational Software

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

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

Ремесло в сравнении с инженерной наукой

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

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

Почему? Причина проста. Хотя средневековые архитекторы обладали глубокими познаниями о способах постройки высоких зданий, они ничего не знали о законах физики. Они знали, что форма арочного потолка должна быть конической, но они никогда не слыхали о дифференциальных уравнениях. Знание средневековых архитекторов было основано исключительно на опыте, полученном из проб и ошибок, и не имело никакого научного основания. Короче говоря, средневековые архитекторы знали как делать, но не знали почему надо делать именно так*. Проектирование и строительство зданий было ремеслом, а средневековые мастера архитектуры были ремесленниками, а не инженерами.

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

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

Что сегодня представляет собой разработка программного обеспечения?

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

Я думаю, что это заблуждение. С моей точки зрения разработка ПО является чистым ремеслом. Она не может быть инженерной дисциплиной – и фактически не содержит никаких аспектов инженерной науки – потому, что она не имеет основных принципов. Все знание о способах разработки ПО основано исключительно на пробах и ошибках. Согласен, со времени зарождения программирования мы добились некоторых успехов. Такие мастера программирования, как, например, Грэйди Буч (Grady Booch), Джим Рамбау (Jim Rumbaugh) и Уокер Ройс (Walker Royce), изобрели в помощь разработчикам ПО успешные методы и правила, часто называемые оптимальными методиками. Но, подобно средневековым архитекторам, разработчики ПО изучили и испытали эти оптимальные методики путем проб и ошибок. Современным программистам не хватает системы основных принципов, на основе которых можно было бы строить свои правила и методы*.

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

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

В чем отличие разработки программного обеспечения?

Неспособность сообщества программистов превратить разработку ПО в успешную инженерную дисциплину вызвало немалое замешательство. Низкий процент успешного завершения программных проектов несомненно отдаляет разработку ПО от установившихся инженерных дисциплин. Для объяснения различий между разработкой ПО и остальными инженерными дисциплинами было предложено множество причин. Рассмотрим три известных примера.

Каждая инженерная дисциплина содержит элементы искусства и науки.

Это верно, но именно элемент науки, а не искусства, отличает инженерное дело от ремесла. И именно научного элемента не хватает разработке ПО, поскольку в ней отсутствуют основные принципы, на которых базируется любая наука. Более того, элемент искусства в инженерном деле является спорным. Спроектированный инженером-строителем мост может быть уродлив, но он всегда будет надежен. С другой стороны, разработка ПО является чистым искусством (или ремеслом), а качество программной системы зависит только от творческих способностей программиста*.

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

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

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

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

Продолжение статьи

Отправить ссылку на страницу по e-mail
Обсудить на форуме Rational Software