Как стать автором
Обновить

Надо ли тратить время на проектирование?

Время на прочтение 4 мин
Количество просмотров 3.7K
Эта статья родилась как ответ на статью Про бесполезность длительного проектирования. Хотелось бы высказать свое мнение на этот счет, поделиться опытом, но уложить все это в комментарии не представляется возможным.

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


Создание Технического Задания


Прежде всего хотелось бы заметить, что проектирование это не только составление архитектуры, рисование UML, SADT и прочих диаграмм. Проектирование начинается с написания первой строчки ТЗ, если конечно оно у вас есть. Если вашей команде посчастливилось получить грамотно составленное ТЗ от заказчика, то радуйтесь — заказчик сделал за вас процентов 30 этапа проектирования. Если же у вас ТЗ нет, или оно не точное, местами надо доработать и «вот тут добавить рюшечку», то будьте готовы платить своим аналитикам, чтобы они трясли заказчика и вытрясали из него все мелочи и детали будущего проекта.

А что после ТЗ?


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

Конечно же этот этап можно построить и по-другому: группа разработчиков открывает ТЗ и начинает делать прототип, так как они его видят. В каком-то месте они обнаруживают «О! Вот это можно вынести в отдельный модуль — выносим!». На выходе получаем прототип, который как бы работает, показываем заказчику, получаем замечания, дорабатываем прототип и так по новой.

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

Когда проектировать серьезно, а когда прототипировать?


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

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

Во втором варианте возможны разные ситуации:
1. прототип устроил заказчика, там все супер, все в восторге! Поздравляю, вашей команде надо выдать нобелевскую премию. Эта ситуация чисто теоритическая, я бы даже сказал, мифическая;
2. некоторые вещи не устроили заказчика, некоторые косяки реализации увидели вы сами;
3. прототип ну совсем не правильный.
Во втором и третьем варианте надо дорабатывать прототип. В третьем, самом худшем варианте, прототип надо выкидывать безжалостно и делать с нуля. Опять же тут возможен вариант (при п.3), когда команде будет жалко выбрасывать двухнедельную работу, и в итоге в проект начинают вставляться костыли на самом первом этапе разработки (думаю не стоит пояснять что будет с проектом через два месяца такой работы?). В случае п.2 надо либо переделывать кардинально, либо вносить изменения в существующий код, но это все равно редактирование существующего кода, это внесение новых ошибок и трата времени программистов. Не проще ли потратить эти две недели на проектирование и анализ, вместо написания кода, который потом, практически со стопроцентной вероятностью будет либо полностью выброшен, либо существенно переписан?

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

Почему так?

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

Послесловие


Написал я много слов, теперь немного фатов и почему я вообще об этом заговорил:
Мне довелось стоять у истоков нескольких крупных систем. Одну из них я проектировал и разрабатывал с самого нуля. Эта система до сих пор развивается, работает и отлично переносит включение новых модулей, которые на первых этапах даже и не планировались. Сейчас в модели порядка двухсот сущностей, которые адекватно между собой связаны. В модели базы данных нет костылей в принципе. Так было заложено архитектурой — проще доработать правильно, чем вносить костыли. Модель взаимодействия модулей системы тоже прозрачна и не менялась с момента проектирования. Да, появлялись новые технологии, выходили новые фреймворки, и новые модули писались уже с использованием последних технологий программирования, но архитектура проекта не меняется. И я не представляю как я бы могу начать писать эту систему без этапа проектирования вообще!

Довелось так же видеть, как система (уже другая) начинает обрастать костылями, подпорками, заплатками, только потому что «тут все очевидно» и «че думать, копать надо!». Печальное зрелище, доложу я вам.
Теги:
Хабы:
+56
Комментарии 120
Комментарии Комментарии 120

Публикации

Истории

Работа

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн
PG Bootcamp 2024
Дата 16 апреля
Время 09:30 – 21:00
Место
Минск Онлайн
EvaConf 2024
Дата 16 апреля
Время 11:00 – 16:00
Место
Москва Онлайн