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

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

Автор: Codeart

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

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

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

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

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

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

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

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

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

Leave a Reply

« »