Введение
В данной публикации речь пойдет о личном опыте разработки одного из проектов.
Хочется отметить в первую очередь что я не позиционирую себя как какой-то super-senior developer.
Все, что я здесь описал, пришло через боль и слезы разработки данного проекта. Для многих это статья покажется ни о чем.
В статье не будет примеров кода, названий или чего-то еще, только опыт, который доходил до меня через руки.
Все проблемы при проектировании основаны на том, что нет ни концепции, ни технического задания, отсутствие полной видимости проекта со старта разработки.
Итак, начнем
Изначально, при разработке, задачи были довольно ясны. Для решения задач решил использовать фреймворк laravel, более-менее спроектировав(!) проект, я приступил к разработке. Все было хорошо, пока проект не начал расти.
Решив, что некоторые моменты работают довольно медленно, например: импорт и обработка изображений в php по cron, было решено перенести это все на python, для мониторинга изменений в файловой системе было решено использовать watchdog, а для работы с изображениями — pillow с multiprocessing.
Соответственно, бизнес-логику связанную с хранилищем данных немного разнесло, т. к. я думал, что этого будет достаточно и больше она нигде не будет дублироваться (господи, какой я наивный).
Затем проект начал развиваться, потребовалось все больше сервисов, например таких как: sms/email-gateway, уведомления, обработка различных файлов xml/csv/etс и практически у каждого была своя бизнес-логика связанная с хранилищем данных, т. е. если логи я додумался сделать отдельным бизнес-слоем, то вот с остальным я особо не заморачивался в силу сроков разработки.
Потом пошла вообще жара в виде flask/android-приложения, как вы понимаете что в веб-сервере flask“а была своя же логика для работы с хранением данных, и все это на единой базе данных. Почему не делал это через laravel? Т.к. я не совсем на старте понимал, за что будет отвечать андроид-приложение, я решил делать это отдельным сервером. Я думал так будет лучше, но я ошибался. Мне приходилось дублировать код, но уже на другом языке.
Т.к. проект постоянно развивается и в нем могут меняться даже какие-то базовые концепции, код постоянно переписывался, причем обычно разными людьми, потихоньку превращаясь в лапшу, над которой особого желания работать не было. Так было и с базой данных. А теперь представьте какая была боль вносить изменения в базе данных? т. е. добавить/изменить какую-то таблицу, приходилось изменять модели/добавлять миграции в laravel, в sqlalchemy, сервисы и т. д.
Очередное изменение в базе — и у меня снова появлялся стресс, связанный с изменением кучи кода. Так продолжалось довольно длительное время, пока я не решил оставить проект в суппорте на текущем состоянии и писать проект с самого начала. Уже зная подводные камни, (не только в проектировании) строить новую архитектуру.
Прежде всего внимание уделили слою бизнес-логики, связанному с работой хранилища данных. Решено было всю работу с БД оставить в laravel, был написан простенький RPC (да, через HTTP неправильно, знаю), откуда с различных сервисов приходили команды и данные.
Это решало проблему с повторением бизнес-логики на разных ЯП связанных с БД.
По сути я занимался тем, что каждый раз делал MVP, которое оценивают люди и что-то меняют в проекте, поэтому конкретной речи о написании каких-либо доков по проекту не идет, все в головах разработчиков и руководства. Ну и постоянные правки кода неизбежно ведут к сами понимаете чему.
Вместо заключения
Далее я не скажу каких-то новых вещей, это и так все давно знают и понимают, но все же хотелось повториться:
- Максимально абстрагируйте все компоненты проекта — они не должны быть зависимы от других и тем более знать об остальных.
- Чем больше слоев бизнес-логики, тем лучше, но не всегда.
- Постоянно спрашивайте себя: зачем это надо? Какие задачи это решит?
- Конкретный ЯП лучше справится с этой задачей, но нужно ли это?
При старте проекта я не использовал ни функциональных тестов, ни приемочных, ибо времени на создание MVP было очень мало, о чем я очень жалел т. к. постоянно при разработке нового функционала приходилось много вещей держать в голове. Сейчас же все наоборот — без тестов вообще никуда.
Нет ничего страшного в том, что вы начнете разрабатывать такой проект с самого начала, используя полученный опыт с прошлых версий. Главное вовремя это понять, что, к сожалению, я понял не сразу. Или же я не прав и рефакторить код, написанный за несколько лет, проще?
Автор: Железный человек
