Я в начале 2000-х писал приложение для учета некоммунальных услуг ЖКХ для местного МУПа. Начинался этот проект как тестовое задание для приема на работу.
Писать можно было на чем угодно, но на тот момент для меня лучшим инструментом казался Clipper 5.x, которым я, как мне тогда казалось, более-менее владел.
Проблема усугублялась еще и неразговорчивостью специалистов, работу которых мне было поручено автоматизировать.
Забегая вперед скажу, что автоматизация, в конце концов, удалась, из режима работы 3 человека по 8 часов в день 6 дней в неделю, за 6 месяцев после начала внедрения, вышли в режим 1 человек 2 часа в день 5 дней в неделю... Т.е. 3*8*6*4 = 576 человеко-часов превратилось в 2*5*4 = 40 ч/ч, КПД был увеличен в 14.4 раза.
Так вот, когда ты в принципе умеешь программировать, но не разбираешься в предметной области, необходимо работать парно с профильным специалистом, буквально жить неразлучно до конца проекта. Так я и поступил (и поступаю всегда).
Но тётушки, работу которых я автоматизировал, никогда в жизни не занимались постановкой задач, декомпозицией, формализацией и прочими прелестями проджект менеджмента, и добиться от них простых смыслов бывало сложнее, чем от пленных партизан. Первым этапом я брал входящую-исходящую документацию и выстраивал все пути трансформации данных.
Далее я реализовывал эти пути как разумел и предоставлял тётушкам.
И о чудо, обычно на этом этапе прорезался дар речи (тётушки, как все нормальные люди, обожают критиковать то, что по их мнению "не так"), и на меня начинал сыпаться поток весьма конкретных и ёмких ЦУ (ценных указаний), которые я подробно документировал и впоследствии претворял в жизнь.
Через некоторое время я овладел предметной областью настолько, что тётушки стали меня приглашать "ловить глюки", которые они периодически нагромождали в своих длительных и мучительных расчетах на калькуляторе.
Первые месяцы они вели двойной учет, по старинке в своей огромной бухгалтерской книге, и в программе, и программу проверяли по книге. Через 2-3 месяца они убедились, что в программе "цифры" точнее, ошибки отлавливаются быстрее, меньшими усилиями, и стали уже свою книгу проверять по программе. Через 5-6 месяцев я написал им модуль расчета и распечатки месячного отчета, и они перестали вести свою книгу, просто печатали ее каждый месяц на огромном матричном принтере.
Теперь о том, как строилась архитектура приложения. Конечная версия носила номер 4, и 4 раза пришлось переписать приложение с нуля. На 4-й раз я понял, что либо я как-то грамотно организую архитектуру, либо это будет провал, т.к. мне до чертиков надоело каждый раз переписывать одно и то же.
Условно можно разделить основной функционал приложения на 2 фазы - ввод/редактирование/просмотр данных и построение отчетов/выборок. С отчетами и выборками тёмный лес, т.к. требования меняются непредсказуемым образом любое количество раз в году (по началу), а вот с вводом и редактированием данных в целом ситуация стабильная, тем более за предыдущие 3 версии я достаточно хорошо исследовал этот процесс.
Ввод/редактирование данных осуществляется посредством форм, которые, в общем случае, повторяют структуру таблицы БД, за исключением случаев, когда присоединяются поля из справочников.
Я вообще по натуре человек ленивый, и вместо того чтобы 100 раз метнуться и что-то по мелочи исправить, я предпочитаю долго запрягать, а потом быстро и беззаботно ехать.
Первейшая проблема программ на Clipper 5.x это банальное отсутствие таблиц БД, либо слетевшие индексы. Это первое, чем я озаботился. программа при запуске проверяет наличие или отсутствие таблиц и индексов, и чего не хватает - достраивает на лету. Таким образом можно потерять данные, но программа, все равно, работать будет. Чтобы это стало возможным, потребовалось в программе прописать структуры таблиц БД и индексов.
Вторым этапом, дико устав копипастить на 95% совпадающий код для построения форм, а, потом, когда надо что-то поменять, добавить или исправить, шариться по тоннам на 95% идентичного кода в сотне мест, я решил прибиться к стану метапрограммирования.
Для этого потребовалось каждую форму описать неким образом, и под это описание разработать генератор форм/генератор гридов. Когда мне это, далеко не с первого раза и далеко не сразу, но таки удалось, добавление новой формы/грида в программу стало сводиться к описанию структур необходимых таблиц, индексов к ним, и структуры формы, и, после компиляции, программа на лету строила все необходимые интерфейсы.
В метаописание формы я добавлял и ссылки на другие таблицы, и генератор автоматически понимал их как ссылки на справочники, в результате чего в форме появлялось в этом месте не поле ввода, а кнопка вызова справочника.
Причем генератор грамотно отрабатывал множественную вложенность, и каждый вызываемый справочник имел полный функционал CRU (Create, Read, Update), включая фильтрацию по столбцам и сортировку.
Таким образом я создал мощный и гибкий генератор интерфейсов, а разработка CRU-части приложения сводилась к разработке описания структур таблиц, индексов и метаописания форм.
Ну а каждый отчет или выборку приходилось программировать вручную, благо их было конечное число и когда основные были реализованы, новые добавлялись, а старые изменялись довольно редко, и такой боли не причиняли, как формы.
Для реализации этого функционала пришлось пропатчить стандартный грид TBrowse (он применяется для просмотра таблиц).
Резюме следующее - для построения грамотной архитектуры необходимо иметь минимальный опыт в пару-тройку тысяч часов бурного кодинга, и успеть собрать основные грабли, успеть устать от боли копипасты и дебаггинга. Так же нужно досконально понимать и видеть целиком предметную область. Тогда из человеческой лени и стремления к идеалу, и будет рождаться некая архитектура, причем у каждого она будет своя, индивидуальная.
Я совершенно обоснованно полагаю, что подобный путь прошел любой, кто нагородил свой велосипед хоть однажды, и многие из тех, кто ездит на чужих велосипедах.
P.S.: когда я мигрировал в веб, через некоторое время я снова вынужден был пройти аналогичный путь, в результате которого родился простенький AJAX-фреймворк на стеке PHP+Smarty+DBSimple+jQuery. Сегодня я всеми силами стараюсь от него уйти, хотя для своих задач он достаточно хорош. Был опыт, когда на шареном хостинге за 5 баксов проект на этом фреймворке со скрипом но держал 30-40 тысяч уников в сутки (после ряда оптимизаций) и достаточно хорошо был защищен от топорного взлома через SQL-инъекции благодаря DBSimple...
