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

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

Автор: Evgeniy Sergeev

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

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

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

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

    ИМХО…

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

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

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

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

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

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

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

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

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

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

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

  1. да не плохо

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

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

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

    ИМХО…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Leave a Reply

« »