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

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

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

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

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

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

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

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

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

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