вторник, 8 сентября 2009 г.

[comp.prog] Проектирование – моя самая нелюбимая часть разработки ПО

Точно знаю, что у многих программистов самая нелюбимая часть разработки – это написание документации. А вот у меня самая нелюбимая стадия – проектирование (хотя я знаю, по крайней мере одного человека, для которого проектирование является самой любимой частью разработки). Почему так?

На днях вдруг понял, с чем можно сравнить стадию проектирования :) С уборкой игрушек в комнате дочери.

Бывает, идем с ней приводить в порядок ее комнату перед сном – а там последствия двух Мировых Войн вместе взятых! Книги, карандаши, фломастеры, обрезки бумаги, краски, куклы, ленточки, резиночки, ниточки, тряпочки… И все это повсюду, вперемешку, в самых невообразимых сочетаниях…

Первая мысль у меня обычно нецензурная, состоящая из одного слова. Вторая мысль – нужно принести мусорное ведро и засыпать все это в него. Потом еще какие-то мысли приходят, такие же непрактичные, деструктивные и бесполезные. Но, в конце-концов, как-то я себя настраиваю, беру в себя руки и процесс начинается: книги в одну сторону, куклы во вторую, мягкие игрушки в третью, всякую мелочь – в мешок, обрезки и неподдающиеся идентификации фрагменты в мусор. В результате, за очень небольшое время нам удается создать какое-то подобие порядка (который моей женой, вероятно, воспринимается как последствие маленького локального конфликта, но уже не Мировой Войны).

Вот так же и с проектированием. Нужно написать вот такую программу. Какую именно? А вот такую. Ага, а вот с этим что делать? А вот с этим? А вот тогда что должно быть? Так, ладно, с требованиями типа понятно… Типа понятно… Да, я уже, вроде понял… Но вот тут что должно быть? Да уж, скромненький такой набор пожеланий собирается… Ну ладно, а как их воплотить? Что если так? А можно и вот так! Можно, только что лучше? Вот так, наверное… А почему? Ну хорошо, пусть будет так… А ведь еще можно вот так. Да, так даже лучше! Бля! Блин! Если так, то вот здесь не связывается… Лады, тогда здесь пусть будет вот так, а вот здесь мы поступим вот так… ПиздеОпаньки, опять засада… Нужно думать… Думай! Думай… Что? Как работа идет? Да нормально идет, проектированием занимаюсь. Да, через неделю, наверное, будет какой-то более-менее реалистичный макет… Думай! Думай!… Блин, послезавтра я обещался макет (долбоегений, однако, кто тебя за язык тянул!)… А может вот так? А потом вот так. А здесь вот так. О, вроде сходится. Да, точно сходится! ОхуеПошла, пошла родимая! Так, теперь вот это… Потом вот это… Сейчас вот это… Может пора уже начать писать? Нет, нужно еще вот это решить. Решаю… Решаю… Решаю… Вроде получилось. Может начинаем писать? Можно, наверное, но нужно еще вот это продумать… Думаю… Что-то придумал, можно сделать вот так. Да, так и сделаем! Ну что можно начинать писать? Дай прикинуть: это есть, это есть, это связали, это утрясли, это впихнули… Ну вроде можно начинать… Или нет? А если вот так? Вроде покрасивше будет. Да, так будет лучше, но нужно будет вот это чуть изменить. И вот это… Ага, и здесь чуть подправить… Или лучше так? БляБлин, перфекционист хуехренов! Хватит уже думать – месяц уже каракули на бумажках корябаешь, хватит! Трясти пора! Ладно, вот это выкидываем и вот так делаем. Погнали!

И все это для того, чтобы через пару недель и несколько тысяч строк отлаженного кода воскликнуть: “Ёптыть! АрхитЭктор, мать, мать, мать! А вот здесь нам что делать прикажете? Как же можно было об этом не подумать!”

PS. Если говорить серьезно, то я убедился на своем опыте, что чем больше сил вложено в проектирование, тем быстрее и проще идет процесс программирования (и даже отладки). И, наверное, я больше склонен к использованию “водопадной модели”, чем “экстремального программирования”, хотя без фанатизма. Но в любом случае, стадия проектирования тяжела тем, что из хаотичного множества совершенно разных мыслей и идей нужно выстроить жизнеспособную строгую модель, которая должна будет пройти суровую проверку. И вот эта необходимость упорядочения, помноженная на ответственность, делает проектирование моей самой нелюбимой частью разработки.

PPS. Заметка написана под впечатлением от выброшенного накануне очередного варианта проекта программы.

3 комментария:

Skynin комментирует...

Это да... кипят споры о "кирпичах" и "растворе", а здания рушатся потому что стены кривые.

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

Я решил, что этот программерский ужас закончится здесь. Я удалил весь код (все семь строк! Я был смел!) и начал сначала.

Глубокий вдох.

Сначала запишем требования к коду. Затем спроектируем код в соответствии с требованиями. Затем напишем код по проекту.

Бажная психология

jazzer комментирует...

А что там с тест-дривен-девеполмент? ;)

eao197 комментирует...

2Skynin: за ссылочку спасибо, раньше ее не видел.

2jazzer: не помню, чтобы я был когда-нибудь приверженцем TDD ;) Unit-тесты -- это да, дело очень хорошее (я даже некоторые функциональные тесты в виде unit-тестов делаю). Но unit-тесты не есть вотчина TDD.