Эта статья родилась как ответ на статью Про бесполезность длительного проектирования. Хотелось бы высказать свое мнение на этот счет, поделиться опытом, но уложить все это в комментарии не представляется возможным.
Во-первых, проектировать надо всегда, даже если в проекте все «очевидно и так».
Во-вторых, длительность проектирования и его цикличность будет зависить от того насколько сложен проект и насколкьо опытна команда исполнителя проекта.
Прежде всего хотелось бы заметить, что проектирование это не только составление архитектуры, рисование UML, SADT и прочих диаграмм. Проектирование начинается с написания первой строчки ТЗ, если конечно оно у вас есть. Если вашей команде посчастливилось получить грамотно составленное ТЗ от заказчика, то радуйтесь — заказчик сделал за вас процентов 30 этапа проектирования. Если же у вас ТЗ нет, или оно не точное, местами надо доработать и «вот тут добавить рюшечку», то будьте готовы платить своим аналитикам, чтобы они трясли заказчика и вытрясали из него все мелочи и детали будущего проекта.
Итак, ТЗ написано, утверждено и надо принимать решение как быть дальше. А дальше у нас должно продолжаться проектирование, потому что необходимо проанализировать требования заказчика, определиться как программа будет дробиться на модули, какие вообще будут слои в будущей системе. Этим всем должны заниматься архитекторы совместно с ведущими программистами и аналитиками. В результате на выходе мы получаем архитектуру системы, большинство неточностей выяснено у заказчика, архитекторы и ведущие программисты уже знают какие модули будут в проекте, как они будут взаимодействовать, какие технологии будут использоваться для каждого модуля. После этого программисты могут приступать к реализации.
Конечно же этот этап можно построить и по-другому: группа разработчиков открывает ТЗ и начинает делать прототип, так как они его видят. В каком-то месте они обнаруживают «О! Вот это можно вынести в отдельный модуль — выносим!». На выходе получаем прототип, который как бы работает, показываем заказчику, получаем замечания, дорабатываем прототип и так по новой.
В итоге во втором варианте мы получаем уже написанную программу, которая как бы работает и скорее всего как бы правильно. В первом же варианте скорее всего мало что написано, но зато архитекторы и ведущие программисты представляют как должна выглядеть система. Казалось бы второй вариант лучше? А вот и нет. Тут все будет зависеть от диаметра иглы.
Не буду говорить что я гуру проектирования, это скорее всего не так, но у меня есть опыт участия в крупных проектах.
На мой, возможно очень субъективный взгляд, начинать именно с написания прототипа, пропуская напрочь этап проектирования имеет смысл, только если команда разработчиков очень опытна и уже писала подобного рода системы. Например, команда в прошлом году сделала систему биллинга для местного провайдера телефонной связи. А теперь им заказали систему биллинга для интернет-провайдера. Тут вполне можно начинать с этапа создания прототипа, потому что команде знакома предметная область, примерно представляют как делается расчет абонентов, какие могут быть трудности и так далее. НО если команде дали вторым заказом написать систему продажи авиа- и жд- билетов, то вот тут я бы посоветовал прибегнуть к помощи архитекторов и аналитиков.
Во втором варианте возможны разные ситуации:
1. прототип устроил заказчика, там все супер, все в восторге! Поздравляю, вашей команде надо выдать нобелевскую премию. Эта ситуация чисто теоритическая, я бы даже сказал, мифическая;
2. некоторые вещи не устроили заказчика, некоторые косяки реализации увидели вы сами;
3. прототип ну совсем не правильный.
Во втором и третьем варианте надо дорабатывать прототип. В третьем, самом худшем варианте, прототип надо выкидывать безжалостно и делать с нуля. Опять же тут возможен вариант (при п.3), когда команде будет жалко выбрасывать двухнедельную работу, и в итоге в проект начинают вставляться костыли на самом первом этапе разработки (думаю не стоит пояснять что будет с проектом через два месяца такой работы?). В случае п.2 надо либо переделывать кардинально, либо вносить изменения в существующий код, но это все равно редактирование существующего кода, это внесение новых ошибок и трата времени программистов. Не проще ли потратить эти две недели на проектирование и анализ, вместо написания кода, который потом, практически со стопроцентной вероятностью будет либо полностью выброшен, либо существенно переписан?
Причем, если система должна быть распределенной, охватывать территориально разнесенн��е предприятия (или подразделения), обрабатывать достаточно большие объемы данных, если модель данных будет содержать несколько сотен сущностей из предметной области, то только на создание прототипа такой системы у вашей команды уйдет пара месяцев. На мой взгляд, построение такого рода систем в принципе невозможно без предварительного и продолжительного проектирования.
Потому что чтобы грамотно выделить логические слои системы, выделить модули, распределить задачи между модулями, нужно представлять в голове всю систему целиком. А для того, чтобы создать в голове у архитектора такую картину нужно время, которое идет именно в проектирование системы. И чем сложнее система, тем талантливей должен быть архитектор (и тем больше надо ему платить). Есл�� же система настолько обширна, что ее невозможно представить целиком, то надо выделять самые базовые модули, описывать их, определять интерфейсы взаимодействия и модель масштабирования этих модулей. опять же полезность данного этапа целиком зависит от опыта архитектора. Стоит ему допустить простейшую ошибку и через пару месяцев может рухнуть вся система.
Написал я много слов, теперь немного фатов и почему я вообще об этом заговорил:
Мне довелось стоять у истоков нескольких крупных систем. Одну из них я проектировал и разрабатывал с самого нуля. Эта система до сих пор развивается, работает и отлично переносит включение новых модулей, которые на первых этапах даже и не планировались. Сейчас в модели порядка двухсот сущностей, которые адекватно между собой связаны. В модели базы данных нет костылей в принципе. Так было заложено архитектурой — проще доработать правильно, чем вносить костыли. Модель взаимодействия модулей системы тоже прозрачна и не менялась с момента проектирования. Да, появлялись новые технологии, выходили новые фреймворки, и новые модули писались уже с использованием последних технологий программирования, но архитектура проекта не меняется. И я не представляю как я бы могу начать писать эту систему без этапа проектирования вообще!
Довелось так же видеть, как система (уже другая) начинает обрастать костылями, подпорками, заплатками, только потому что «тут все очевидно» и «че думать, копать надо!». Печальное зрелище, доложу я вам.
Во-первых, проектировать надо всегда, даже если в проекте все «очевидно и так».
Во-вторых, длительность проектирования и его цикличность будет зависить от того насколько сложен проект и насколкьо опытна команда исполнителя проекта.
Создание Технического Задания
Прежде всего хотелось бы заметить, что проектирование это не только составление архитектуры, рисование UML, SADT и прочих диаграмм. Проектирование начинается с написания первой строчки ТЗ, если конечно оно у вас есть. Если вашей команде посчастливилось получить грамотно составленное ТЗ от заказчика, то радуйтесь — заказчик сделал за вас процентов 30 этапа проектирования. Если же у вас ТЗ нет, или оно не точное, местами надо доработать и «вот тут добавить рюшечку», то будьте готовы платить своим аналитикам, чтобы они трясли заказчика и вытрясали из него все мелочи и детали будущего проекта.
А что после ТЗ?
Итак, ТЗ написано, утверждено и надо принимать решение как быть дальше. А дальше у нас должно продолжаться проектирование, потому что необходимо проанализировать требования заказчика, определиться как программа будет дробиться на модули, какие вообще будут слои в будущей системе. Этим всем должны заниматься архитекторы совместно с ведущими программистами и аналитиками. В результате на выходе мы получаем архитектуру системы, большинство неточностей выяснено у заказчика, архитекторы и ведущие программисты уже знают какие модули будут в проекте, как они будут взаимодействовать, какие технологии будут использоваться для каждого модуля. После этого программисты могут приступать к реализации.
Конечно же этот этап можно построить и по-другому: группа разработчиков открывает ТЗ и начинает делать прототип, так как они его видят. В каком-то месте они обнаруживают «О! Вот это можно вынести в отдельный модуль — выносим!». На выходе получаем прототип, который как бы работает, показываем заказчику, получаем замечания, дорабатываем прототип и так по новой.
В итоге во втором варианте мы получаем уже написанную программу, которая как бы работает и скорее всего как бы правильно. В первом же варианте скорее всего мало что написано, но зато архитекторы и ведущие программисты представляют как должна выглядеть система. Казалось бы второй вариант лучше? А вот и нет. Тут все будет зависеть от диаметра иглы.
Когда проектировать серьезно, а когда прототипировать?
Не буду говорить что я гуру проектирования, это скорее всего не так, но у меня есть опыт участия в крупных проектах.
На мой, возможно очень субъективный взгляд, начинать именно с написания прототипа, пропуская напрочь этап проектирования имеет смысл, только если команда разработчиков очень опытна и уже писала подобного рода системы. Например, команда в прошлом году сделала систему биллинга для местного провайдера телефонной связи. А теперь им заказали систему биллинга для интернет-провайдера. Тут вполне можно начинать с этапа создания прототипа, потому что команде знакома предметная область, примерно представляют как делается расчет абонентов, какие могут быть трудности и так далее. НО если команде дали вторым заказом написать систему продажи авиа- и жд- билетов, то вот тут я бы посоветовал прибегнуть к помощи архитекторов и аналитиков.
Во втором варианте возможны разные ситуации:
1. прототип устроил заказчика, там все супер, все в восторге! Поздравляю, вашей команде надо выдать нобелевскую премию. Эта ситуация чисто теоритическая, я бы даже сказал, мифическая;
2. некоторые вещи не устроили заказчика, некоторые косяки реализации увидели вы сами;
3. прототип ну совсем не правильный.
Во втором и третьем варианте надо дорабатывать прототип. В третьем, самом худшем варианте, прототип надо выкидывать безжалостно и делать с нуля. Опять же тут возможен вариант (при п.3), когда команде будет жалко выбрасывать двухнедельную работу, и в итоге в проект начинают вставляться костыли на самом первом этапе разработки (думаю не стоит пояснять что будет с проектом через два месяца такой работы?). В случае п.2 надо либо переделывать кардинально, либо вносить изменения в существующий код, но это все равно редактирование существующего кода, это внесение новых ошибок и трата времени программистов. Не проще ли потратить эти две недели на проектирование и анализ, вместо написания кода, который потом, практически со стопроцентной вероятностью будет либо полностью выброшен, либо существенно переписан?
Причем, если система должна быть распределенной, охватывать территориально разнесенн��е предприятия (или подразделения), обрабатывать достаточно большие объемы данных, если модель данных будет содержать несколько сотен сущностей из предметной области, то только на создание прототипа такой системы у вашей команды уйдет пара месяцев. На мой взгляд, построение такого рода систем в принципе невозможно без предварительного и продолжительного проектирования.
Почему так?
Потому что чтобы грамотно выделить логические слои системы, выделить модули, распределить задачи между модулями, нужно представлять в голове всю систему целиком. А для того, чтобы создать в голове у архитектора такую картину нужно время, которое идет именно в проектирование системы. И чем сложнее система, тем талантливей должен быть архитектор (и тем больше надо ему платить). Есл�� же система настолько обширна, что ее невозможно представить целиком, то надо выделять самые базовые модули, описывать их, определять интерфейсы взаимодействия и модель масштабирования этих модулей. опять же полезность данного этапа целиком зависит от опыта архитектора. Стоит ему допустить простейшую ошибку и через пару месяцев может рухнуть вся система.
Послесловие
Написал я много слов, теперь немного фатов и почему я вообще об этом заговорил:
Мне довелось стоять у истоков нескольких крупных систем. Одну из них я проектировал и разрабатывал с самого нуля. Эта система до сих пор развивается, работает и отлично переносит включение новых модулей, которые на первых этапах даже и не планировались. Сейчас в модели порядка двухсот сущностей, которые адекватно между собой связаны. В модели базы данных нет костылей в принципе. Так было заложено архитектурой — проще доработать правильно, чем вносить костыли. Модель взаимодействия модулей системы тоже прозрачна и не менялась с момента проектирования. Да, появлялись новые технологии, выходили новые фреймворки, и новые модули писались уже с использованием последних технологий программирования, но архитектура проекта не меняется. И я не представляю как я бы могу начать писать эту систему без этапа проектирования вообще!
Довелось так же видеть, как система (уже другая) начинает обрастать костылями, подпорками, заплатками, только потому что «тут все очевидно» и «че думать, копать надо!». Печальное зрелище, доложу я вам.
