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

Ладно. От слов к делу. На днях пришлось (ну или не совсем пришлось, скорее захотелось) писать программу десктопную для диагностики автомобилей через интерфейс OBD-2, вообщем это тонкости, и к делу отношения не имеет. Довольно сложные алгоритмы, да и учитывая то что прикладные программы я последний раз разрабатывал лет пять-семь назад, то это вообщем то было довольно таки сложно.

Что же случилось?

За язык программирования был выбран Delphi, когдато в лохматые года я уже кодил на нем, да и на паскале кодить приходилось переодически. Собственно сама программа.

Диагностика должна была осуществлятся по K-линии, через интерфейс OBD-II, через COM порт. Естественно перед началом написания программы мной были изученны данные протоколы и принципы работы COM устройств. Ну и более менее представляя, что мне предстоит, я взялся за написание программы.

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

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

Что дальше?

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

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

Писать сразу?

При этом если бы я взялся изначально писать программу в лоб, конечный результат мог бы быть намного хуже. Абсурдно? Нет. За первую попытку я понял и разобрался в тонкостях работы протоколов, смог прикинуть как надо было сделать здесь и как надо было сделать там. Разве у вас не было такого что осознание правильного алгоритма приходит только после написания программы?

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

Так что же делать?

После всей этой эпопеи я принял для себя следующие правила:

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

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