// codeart.ru / Работаем с кодом / Часть 2. Проектирование на бумаге как выход из тупика Форум

Часть 2. Проектирование на бумаге как выход из тупика rss подписка

Автор: Evgeniy Sergeev

Продолжаю серию записок о коде. В прошлой части я кратко обрисовал проблему так или иначе наблюдающуюся у большинства известных мне фрилансеров. Как говорят в обществе анонимных алкоголиков (только не подумайте, что я его посещаю на постоянной основе, так захожу изредка): «Осознание проблемы — первый шаг на пути ее решения».

Осознав, что с моим процессом разработки что-то конкретно не так, я сделал вывод: корень моих бед — недостаток проектирования. В связи с чем, было принято твердое решение при выполнении следующего заказа потратить как минимум 30 процентов времени на бумажную работу. Нужно сказать, что я с треском провалил проект. Оказалось, что занимаясь проектированием, я не только не смог улучшить положение дел, а наоборот только усугубил ситуацию, потратив огромное количество бесценных минут на ненужную работу.

Неудачными оказались и два следующих проекта. Причина оказалась банальной (это сейчас я понимаю, что она банальна, тогда мне казалось иначе) — я просто не умел проектировать. Например, в моей голове путались понятия «архитектура» и «требования к системе», то что по идеи должно было входить в архитектуру каким-то чудесным образом оказывалось в требованиях, а о некоторых вещах, таких как отказоустойчивость, я вообще забывал подумать.

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

Уже больше года старательно занимаясь вопросами проектирования, я так и не достиг того уровня когда можно сказать, что мои познания в этом вопросе стали достаточными. Я до сих пор не могу заниматься крупными разработками (как правило такие вещи делаются уже в команде), но для работы над средними и мелкими программами, накопленного опыта вполне достаточно. К сожалению, при увеличении размеров проекта, вся накопленная база знаний перестает работать (построить сарай не то же самое, что современный небоскреб). И в этом проблема любого программиста, когда делаешь шаг вперед на пути саморазвития, методы которые работали еще вчера перестают приносить каку-либо пользу сегодня. Приходиться учиться заново.

Сравнивая процент ошибок и необходимых доработок в моих программах сейчас и в прошлом году, могу сказать, что в среднем качество моего кода улучшилось на 30-40%. Таким образом мне не удалось полностью избавиться от ошибок при создании программ, но с каждым новым проектом я приобретаю все больше опыта в проектировании, а следовательно учусь более эффективно искать оптимальное решение.

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

Конец второй части.

Часть 3. О том как сократить время затрачиваемое на исправление ошибок.

  1. Часть 3. О том, как сократить время на исправление ошибок

    Лучшие комментарии

  1. Вообще планирование и проектирование — это разные вещи.

    ИМХО…

    Планировани6е — постоянный процесс. Результаты от выполнения каждой из запланированных задач непосредственно влияют на изменения оставшегося списка задач.

    Проектирование — это это один из со процессов процесса разработки, который планируется как одна из задач. Но проектирование связано с остальными процессами. И их результат должен влиять на проектирование.

    Вообще у разных подходов разработки ПО разное отношение к проектированию. Порой от него вообще отказываются… Например в пользу «историй». С клиентом составляются пользовательские «истории» в которых указывается, что КТО-ТО ДОЛЖЕН МОЧЬ ЧТО-ТО ДЕЛАТЬ С ЧЕМ-ТО В СИСТЕМЕ. Список таких историй сортируется по важности. Истории должны описывать нечто реализуемое за короткий срок. После реализации следует тестирование и выбор следующей истории из списка. В данном случае все архитектурные диаграммы являются документацией для реализованных историй.

    Ещё используется экспериментирование или тестирование. Когда опять же определяется главные требования, которые методом тестов реализуются. Далее выявляются очередные важные требования и тоже реализуются с постоянными тестами на не разрушение уже имеющегося и достижением нового.

    Так же не забываем о постоянном рефакторинге.

    В данной ситуации опять же архитектура — это уже результат, а не цель :)

  2. Евгений, насчет планирования ты абсолютно прав, я его использовал как синоним слову «проектирование», а это абсолютно разные понятия (поэтому пост немного поправил).

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

    По поводу экспериментирования и тестирования. Мне кажется, что либо ты тут упустил какой-то важный момент, либо я чего-то конкретно не понимаю, потому как приведенное описание не исключает этапа проектирования.

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

    Таким образом создание тестов до начала кодирования, в моем понимании, уже является проектированием. :-)

  1. да не плохо

  2. полный бред, без обид

  3. bak$, я не телепат, что конкретно бред? Или ты только ради понта написал коммент?

  4. Вообще планирование и проектирование — это разные вещи.

    ИМХО…

    Планировани6е — постоянный процесс. Результаты от выполнения каждой из запланированных задач непосредственно влияют на изменения оставшегося списка задач.

    Проектирование — это это один из со процессов процесса разработки, который планируется как одна из задач. Но проектирование связано с остальными процессами. И их результат должен влиять на проектирование.

    Вообще у разных подходов разработки ПО разное отношение к проектированию. Порой от него вообще отказываются… Например в пользу «историй». С клиентом составляются пользовательские «истории» в которых указывается, что КТО-ТО ДОЛЖЕН МОЧЬ ЧТО-ТО ДЕЛАТЬ С ЧЕМ-ТО В СИСТЕМЕ. Список таких историй сортируется по важности. Истории должны описывать нечто реализуемое за короткий срок. После реализации следует тестирование и выбор следующей истории из списка. В данном случае все архитектурные диаграммы являются документацией для реализованных историй.

    Ещё используется экспериментирование или тестирование. Когда опять же определяется главные требования, которые методом тестов реализуются. Далее выявляются очередные важные требования и тоже реализуются с постоянными тестами на не разрушение уже имеющегося и достижением нового.

    Так же не забываем о постоянном рефакторинге.

    В данной ситуации опять же архитектура — это уже результат, а не цель :)

  5. Евгений, насчет планирования ты абсолютно прав, я его использовал как синоним слову «проектирование», а это абсолютно разные понятия (поэтому пост немного поправил).

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

    По поводу экспериментирования и тестирования. Мне кажется, что либо ты тут упустил какой-то важный момент, либо я чего-то конкретно не понимаю, потому как приведенное описание не исключает этапа проектирования.

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

    Таким образом создание тестов до начала кодирования, в моем понимании, уже является проектированием. :-)

  6. Да, без проектирования не обойтись, но я хотел сделать акцент на уходе от изначального полного проектирования всего приложения полностью к проектированию по необходимости. То есть не нужно строить мыльные замки со всеми возможными нюансами, а стоит проектировать и перепроектировать, решая постепенно все требуемые задачи в порядке их важности. :)

    Рефакторинг кода ведь тоже включает момент проектирования.

  7. класно ждём продолжения

  8. В целом — много общих фраз, а именно путей решения проблем — не хватает. Мало текста уделено именно тому, что затронуто темой — проектированию на бумаге, ведь об этом тема- не так ли?

  9. Anycolor, сказываются ограничения по объему, да и повторять, то, что написано в сотнях учебниках не очень хочется.
    А смысл замекти в том, что для того чтобы писать хороший код нужно думать «до» написания кода, а не «в процессе» или «после».

  10. Evgeny Sergeev полностью согласен с вашей фразой

    «чтобы писать хороший код нужно думать “до” написания кода, а не “в процессе” или “после”»

    за частую при написании какого либо проекта ловлю себя на мысли что начинаю лепить код из головы и та идея которая была изначально начинает расплываться и в конце концов результат не соответствует тому начальному плану!

Leave a Reply

« »