Без проектирования сложно масштабировать систему

Рассуждения про проектирование системы.

Проектирование

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

Постепенно накапливается много компонентов системы, вы начинаете оптимизировать схему, что-то убираете, что-то группируете/объединяете, где-то применяется динамическая схема работы (за счет параметров). Постепенно из сложной запутанной схемы вырастает лаконичное Решение на бумаге.

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

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

Почему игнорируют или пропускают стадию проектирования?

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

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

Рассмотрим пример с API:

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

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

Проектирование аналитической структуры предприятия

Проектировать можно как программу (из каких модулей состоит, как они взаимодействуют, какие классы или функции нужно написать и т.д.), так и аналитическую структуру предприятия.

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

Контроль данных

Обязательно закладывайте в проектировании элемент контроля данных. Например, у вас должно быть описано или отображено на схеме, как вы будете автоматически сверять правдивость данных. Например, вы выгрузили данные из системы, сформировали отчеты и отправили руководству. Через час звонок и неприятный разговор. А если бы у вас были заложены механизмы контроля данных, то вам бы пришла отбивка - выявлены расхождения между системой аналитики и отчетом в системе 1С Предприятие.

Какие бесплатные инструменты для проектирования есть

Я использую очень часто сервис https://app.diagrams.net/ (ранее https://draw.io). Документы можно сохранять на гугл диск и повторно открывать хоть с работы, хоть из дома.