Экономит ли проектирование время?

Сейчас в одной переписке возник вопрос по поводу нужно ли описывать систему, делать ТЗ и пр. Это в контексте небольшого сайта, выполняемого парой-тройкой человек. Одним из аргументов против, было то, что это займет лишнее время.
Я же в последнее время склоняюсь к мысли что любую программу нужно проектировать до начала разработки, как раз для экономии времени.

Если задача небольшая и я ее сам себе поставил и выполняю также один, то тут еще можно обойтись непродолжительными размышлениями. Но даже в этом случае я предпочитаю набросать несколько MindMap'ов.

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

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

Хорошо бы изначально иметь некий граф состояний системы. Например со стороны UI это будет точка, содержащая скриншот экрана, с описание что здесь за данные и как они зависят. Точка может иметь несколько входов и выходов, к другим точкам. Получили: внешний вид, данные и взаимосвязь. Далее на другом уровне продумывается дизайн внешнего вида, способ хранения данных в базе и пр. Если все это прописано достаточно четко, то с реализвацией может справится менее квалифицированный программист. Т.е. начинаем проектировать с верхних уровней абстракции и постепенно все уровни сходятся в один, в алгоритм на какомто языке. При этом все это должен видеть заказчик, чтобы при выдаче очередного релиза он вдруг не увидел новые вещи и ему не пришла гениальная идея о новом функционале. Пусть все эти идеи приходят в момент проектирования, но если проектирование происходит в голове и заказчик видит только результат, то что начинает формализоватся в виде кода, то тут уже поздно, это вызывает эффект домино... В общем вносить изменения уже нельзя ни в коем случае. Только писать сценарий заново и писать код заново!

И если идти таким путем, если знать что у нас будет лишь только такой функционал, лишь такие экраны, такие данные и пр. и пр. то программист никогда не будет думать «а что вдруг если?», «а на всякий случай сделаем здесь универсальней, малоли» и т.д. Программист будет лишь реализовывать требуемый и нерасширяемый код! А такой код пишется в разы быстрее, и ничего нет странного в таком подходе. Зачем нам возможности которые не используется? Почему за них должен платить заказчик если они ему не нужны? Не платит же заказчик дома за настраиваемые размеры оконных проемов, на тот случай если он решит поставить окна другого размера. Да и, как я уже говорил, писать такой код могут менее квалифицированные программисты.

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

UPDATE через несколько лет: теперь я не совсем согласен 🙂 все зависит от проекта

  • http:// Александр Нуйкин

    «любую программу нужно проектировать до начала разработки»:

    Такой подход далеко не универсален. Он подходит только в случае, если:

    1. Заказчик точно знает всего, что он хочет еще до начала проекта.

    2. Разработчики досконально знают (т.е. могут предусмотреть все проблемы):

    2.а. Язык программирования,

    2.б. Сторонние средства (библиотеки; основную систему, если речь идет о расширении; конкретную СУБД)

    В реальности такое врядли возможно. Потому-то «водопадная» модель (и ее разновидности) мне и не нравится. Гибкий вариант разработки, использующий «TDD/Refactoring/Непрерывная интеграция/Непрерывное взаимодействие с заказчиком» представляется намного более перспективным.

    Как правило (даже если у вас команда супер профессионалов в отношении платформы разработки, что врядли) — заказчику трудно сформулировать все, что он хочет. Эффективнее реализовать через TDD/Refactoring все, что хочет заказчик сейчас, показать ему это сейчас же, тут же выслушать замечания и тут же исправить недостатки и т.д. Если заказчик не может присутствовать постоянно, то нужен его представитель, если и представителя нет, то нужны встречи перед каждой итерацией, и итерации должны быть как можно короче.

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

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

    Что касается использования менее квалифицированых программистов... Чтобы таких использовать нужно:

    1. все очень хорошо и подробно задокументировать,

    2. чтобы они все это читали.

    Первое — не получится, т.к. заранее все не известно. Второе — потому что лень. Кроме того — чтобы правильно писать и быстро понимать написанное — уже нужна квалификация. Написать хорошее ТЗ — дело тяжелое. Разобраться в куче документации — тоже не просто.

    Выгоднее иметь «универсальных» разработчиков любой квалификации, которые будут и кодировать и тестировать и проектировать сообща. Обсуждать, критиковать и принимать решения — таким образом постепенно квалификация будет повышаться у всех во всех областях разработки. Причем через чем живее это общение будет — тем лучше. Например для распределенных проектов желательно иметь возможность общения через Skype вместо ICQ. Ну а когда все в одном месте работают — тут уж конечно живое человеческое общение ничем не заменить. А уже в дополнение — ICQ. А при использовании парного программирования квалификация повышается еще больше, т.к. происходит более тесный обмен опытом.

  • http://artamonov.ru splix

    За последние ~3 года мои взгляды довольно сильно изменились 🙂

    Сейчас я большее значение придаю agile (ну или как минимум итерация в rup'е), но и доскональное проектирование и прототипирование всетаки не отрицаю. Все очень сильно зависит от конкретного проекта. Каждая методика для своей ситуации.