Часть 2. Проектирование на бумаге как выход из тупика
Продолжаю серию записок о коде. В прошлой части я кратко обрисовал проблему так или иначе наблюдающуюся у большинства известных мне фрилансеров. Как говорят в обществе анонимных алкоголиков (только не подумайте, что я его посещаю на постоянной основе, так захожу изредка): “Осознание проблемы - первый шаг на пути ее решения”.
Осознав, что с моим процессом разработки что-то конкретно не так, я сделал вывод: корень моих бед - недостаток проектирования. В связи с чем, было принято твердое решение при выполнении следующего заказа потратить как минимум 30 процентов времени на бумажную работу. Нужно сказать, что я с треском провалил проект. Оказалось, что занимаясь проектированием, я не только не смог улучшить положение дел, а наоборот только усугубил ситуацию, потратив огромное количество бесценных минут на ненужную работу.
Неудачными оказались и два следующих проекта. Причина оказалась банальной (это сейчас я понимаю, что она банальна, тогда мне казалось иначе) - я просто не умел проектировать. Например, в моей голове путались понятия “архитектура” и “требования к системе”, то что по идеи должно было входить в архитектуру каким-то чудесным образом оказывалось в требованиях, а о некоторых вещах, таких как отказоустойчивость, я вообще забывал подумать.
Другой, очевидный теперь, недостаток моих знаний заключался в том, что я совершенно не умел чувствовать размеры проекта. Крупные, средние, мелкие и очень мелкие задачи требуют совершенно разного подхода (теперь я это четко понимаю), если проект маленький, то проектирование не может и не должно занимать много времени (это невыгодно ни с экономической точки зрения, ни с позиции здравого смысла), но это не значит, что можно сразу приступать к кодированию. А вот, скажем, средние проекты требуют не только дополнительного внимания к проектированию, но и совершенно иных подходов.
Уже больше года старательно занимаясь вопросами проектирования, я так и не достиг того уровня когда можно сказать, что мои познания в этом вопросе стали достаточными. Я до сих пор не могу заниматься крупными разработками (как правило такие вещи делаются уже в команде), но для работы над средними и мелкими программами, накопленного опыта вполне достаточно. К сожалению, при увеличении размеров проекта, вся накопленная база знаний перестает работать (построить сарай не то же самое, что современный небоскреб). И в этом проблема любого программиста, когда делаешь шаг вперед на пути саморазвития, методы которые работали еще вчера перестают приносить каку-либо пользу сегодня. Приходиться учиться заново.
Сравнивая процент ошибок и необходимых доработок в моих программах сейчас и в прошлом году, могу сказать, что в среднем качество моего кода улучшилось на 30-40%. Таким образом мне не удалось полностью избавиться от ошибок при создании программ, но с каждым новым проектом я приобретаю все больше опыта в проектировании, а следовательно учусь более эффективно искать оптимальное решение.
С другой стороны, мне удалось добиться значительного ускорения в процессе исправления написанного кода, но это связано уже не с проектированием, а со стилем написания программ, о котором я расскажу в следующей части.
Конец второй части.
Часть 3. О том как сократить время затрачиваемое на исправление ошибок.
-
Ватрушка
Гость
17 августа, 2007да не плохо
-
bak$
Гость
18 августа, 2007полный бред, без обид
-
Evgeny Sergeev
Веб-разработчик, автор блога codeart.ru
19 августа, 2007bak$, я не телепат, что конкретно бред? Или ты только ради понта написал коммент?
-
Евгений
Гость
19 августа, 2007
Вообще планирование и проектирование - это разные вещи.
ИМХО…
Планировани6е - постоянный процесс. Результаты от выполнения каждой из запланированных задач непосредственно влияют на изменения оставшегося списка задач.
Проектирование - это это один из со процессов процесса разработки, который планируется как одна из задач. Но проектирование связано с остальными процессами. И их результат должен влиять на проектирование.
Вообще у разных подходов разработки ПО разное отношение к проектированию. Порой от него вообще отказываются… Например в пользу “историй”. С клиентом составляются пользовательские “истории” в которых указывается, что КТО-ТО ДОЛЖЕН МОЧЬ ЧТО-ТО ДЕЛАТЬ С ЧЕМ-ТО В СИСТЕМЕ. Список таких историй сортируется по важности. Истории должны описывать нечто реализуемое за короткий срок. После реализации следует тестирование и выбор следующей истории из списка. В данном случае все архитектурные диаграммы являются документацией для реализованных историй.
Ещё используется экспериментирование или тестирование. Когда опять же определяется главные требования, которые методом тестов реализуются. Далее выявляются очередные важные требования и тоже реализуются с постоянными тестами на не разрушение уже имеющегося и достижением нового.
Так же не забываем о постоянном рефакторинге.
В данной ситуации опять же архитектура - это уже результат, а не цель
-
Evgeny Sergeev
Веб-разработчик, автор блога codeart.ru
19 августа, 2007
Евгений, насчет планирования ты абсолютно прав, я его использовал как синоним слову “проектирование”, а это абсолютно разные понятия (поэтому пост немного поправил).
Насчет программирования с использованием “историй” (такого метода, честно говоря, я не знал, но по описанию очень похоже на “программирование по контракту”). Вообщем-то мне не совсем понятно как возникает реализация? Разве когда программист продумывает реализацию “истории” он не занимается проектированием?
По поводу экспериментирования и тестирования. Мне кажется, что либо ты тут упустил какой-то важный момент, либо я чего-то конкретно не понимаю, потому как приведенное описание не исключает этапа проектирования.
Для меня проектирование - комплекс мер позволяющих получить желаемый результат в виде законченного программного продукта, но не включающих в себя непосредственное кодирование.
Таким образом создание тестов до начала кодирования, в моем понимании, уже является проектированием.
-
Евгений
Гость
20 августа, 2007Да, без проектирования не обойтись, но я хотел сделать акцент на уходе от изначального полного проектирования всего приложения полностью к проектированию по необходимости. То есть не нужно строить мыльные замки со всеми возможными нюансами, а стоит проектировать и перепроектировать, решая постепенно все требуемые задачи в порядке их важности.
Рефакторинг кода ведь тоже включает момент проектирования.
-
Марадир
Гость
20 августа, 2007класно ждём продолжения
-
anycolor
Гость
21 августа, 2007В целом - много общих фраз, а именно путей решения проблем - не хватает. Мало текста уделено именно тому, что затронуто темой - проектированию на бумаге, ведь об этом тема- не так ли?
-
Evgeny Sergeev
Веб-разработчик, автор блога codeart.ru
22 августа, 2007Anycolor, сказываются ограничения по объему, да и повторять, то, что написано в сотнях учебниках не очень хочется.
А смысл замекти в том, что для того чтобы писать хороший код нужно думать “до” написания кода, а не “в процессе” или “после”.
Лучшие комментарии
Евгений
Гость
Вообще планирование и проектирование - это разные вещи.
ИМХО…
Планировани6е - постоянный процесс. Результаты от выполнения каждой из запланированных задач непосредственно влияют на изменения оставшегося списка задач.
Проектирование - это это один из со процессов процесса разработки, который планируется как одна из задач. Но проектирование связано с остальными процессами. И их результат должен влиять на проектирование.
Вообще у разных подходов разработки ПО разное отношение к проектированию. Порой от него вообще отказываются… Например в пользу “историй”. С клиентом составляются пользовательские “истории” в которых указывается, что КТО-ТО ДОЛЖЕН МОЧЬ ЧТО-ТО ДЕЛАТЬ С ЧЕМ-ТО В СИСТЕМЕ. Список таких историй сортируется по важности. Истории должны описывать нечто реализуемое за короткий срок. После реализации следует тестирование и выбор следующей истории из списка. В данном случае все архитектурные диаграммы являются документацией для реализованных историй.
Ещё используется экспериментирование или тестирование. Когда опять же определяется главные требования, которые методом тестов реализуются. Далее выявляются очередные важные требования и тоже реализуются с постоянными тестами на не разрушение уже имеющегося и достижением нового.
Так же не забываем о постоянном рефакторинге.
В данной ситуации опять же архитектура - это уже результат, а не цель
Evgeny Sergeev
Веб-разработчик, автор блога codeart.ru
Евгений, насчет планирования ты абсолютно прав, я его использовал как синоним слову “проектирование”, а это абсолютно разные понятия (поэтому пост немного поправил).
Насчет программирования с использованием “историй” (такого метода, честно говоря, я не знал, но по описанию очень похоже на “программирование по контракту”). Вообщем-то мне не совсем понятно как возникает реализация? Разве когда программист продумывает реализацию “истории” он не занимается проектированием?
По поводу экспериментирования и тестирования. Мне кажется, что либо ты тут упустил какой-то важный момент, либо я чего-то конкретно не понимаю, потому как приведенное описание не исключает этапа проектирования.
Для меня проектирование - комплекс мер позволяющих получить желаемый результат в виде законченного программного продукта, но не включающих в себя непосредственное кодирование.
Таким образом создание тестов до начала кодирования, в моем понимании, уже является проектированием.