пятница, августа 03, 2007

Кумулятивный принцип разработки софта

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

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

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

С превращением требований в дизайн приложения дела обстоят хуже всего. Например, последователи Кента Бека эту часть разработки софта вообще не признают. Их принцип – садись и кодируй, дизайн возникнет сам по себе, а когда он возникнет - мы его отрефакторим. Другие подходят к проблеме во всеоружии OOP, OOD, SOA, c арсеналом паттернов, всегда имея наготове принцип Лискоу, или другой убойный инструмент для монтажа правильного дизайна. Для многих это процесс сродни шаманству, то что требования определяют дизайн – это понятно, он вот каким образом??! Ну а для менеджера есть только две архитектуры: правильная и неправильная. Правильна – та, которая позволяет за выделенные деньги получить хоть как-то работающее приложение. Все остальные - неправильные. И надо признать, что именно они ближе всего к истине.

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

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

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

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

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

5 комментариев:

Анонимный комментирует...

Данный принцип можно применить к любому процессу создания чего-либо, будь то автомобиль, сотовый телефон, космический корабль. Только конечно принцип Лискоу к кораблю не прикрутить :)
Есть правда одна проблема, все четыре этапа очень нужные и без них никуда, но как же всем (или почти всем) последователям Бека удается сдавать проекты?

Анонимный комментирует...

Ну да, всё верно :)

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

Sergey Rozovik комментирует...

to C...R...a...S...H
> Данный принцип можно применить к любому процессу создания чего-либо

Вовсе нет. Например автомобиль ВАЗ. Вонючий двигатель, дребезжащий салон - и, заметь, отлично продается на просторах нашей страны.

> но как же всем (или почти всем) последователям Бека удается сдавать проекты?

Далеко не всем удается :) Но, это тема отдельного разговора...

Анонимный комментирует...

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

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

Flegmatic комментирует...

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