Tominoff

2 года назад

Мне нравится слоистая архитектура, описанная Мартином. 🫶 Между тобой и пониманием как работает система в целом, всего лишь один барьер - язык программирования. К счастью, этот барьер, на деле, является лишь небольшим препятствием, поскольку многие ООП языки похожи. Вот, например, поступил мне на оценку сайт со следующей, как выяснилось, структурой: C# приложение как core с бизнес логикой + rest api в качестве I/O - слоеная архитектура с выделенными сущностями, юзкейсами и контроллерами. Там ещё есть laravel, по сути это дополнительный I/O слой, проксик между клиентом и описанным выше c# приложением - получает запрос, передает в api c# приложения, получает ответ и генерирует html. Ну и ещё несколько менее важных частей, вроде интерфейса администратора, rest api для него, базы данных и т.п. Клиент хочет соскочить с иглы c# и вообще максимально унифицировать кодовую базу, чтобы не было проблем с поиском подрядчиков в будущем - как я понял - искать шарпистов трудно и дорого. Ещё труднее найти среди них фуллстеков, которые и в шарп и в php и в typescript могут одновременно. Пока что обоснованно предлагается перейти полностью на js/ts - найти фуллстек жаваскриптизёра уж точно проще и дешевле чем фуллстека полиглота. Но вернёмся к архитектуре. Итак, первый плюс выбранного подхода - я относительно легко разобрался в том как работает система, совершенно не зная c# и потратив на это от силы минут 30-40. Да, тонкости я не изучал, но этого времени оказалось достаточно чтобы охватить все основные части и проследить взаимодействия между ними. 👍 Второй плюс - работы по переписыванию будут выполнены гораздо проще и быстрее, опять же, благодаря архитектуре - нам не нужно тратить время на осмысление всего проекта, прошлых требований бизнеса, взаимодействия компонентов в нём и прочие нюансы - всё уже написано достаточно понятно. 💪 Третий плюс - для начала мы вообще можем просто переписать core часть этого приложения, лишь перенося критическую бизнес логику и сущности с одного языка на другой практически без изменений. 👌 Если бы в проекте присутствовали интеграционные тесты - можно было бы тестировать наш новый код старыми тестами и гарантировать отсутствие отклонений! 🔥 Подытожим: Бизнес получает быстрый, дешёвый и надёжный (особенно при наличии тестов) результат Разработчик не тратит время на сбор и разработку старых требований, не тратит много времени на изучение системы, не тратит время на тотальное переписывание (описанный случай - исключение, но даже так - не требуется переписывать тотально и сразу всё) — А теперь представьте подобный перенос приложения, только где нет четких границ между компонентами, а значит с размазанной по контроллерам и моделям бизнес логикой и прочими прелестями «типичных» «mvc» проектов. Где куча движущихся частей и нет никакой устойчивой основы. 🫠 В большинстве случаев это бы означало переписывание проекта с нуля, что требует помимо сбора новых требований, получить ещё и старые, потратить кучу времени на переписывание этих требований в коде, дебаг, новые тесты и прочие прелести. 😩 Но даже и на поддержку такого проекта требуется тратить гораздо больше времени - без чётких границ часто можно поймать эффект бабочки, когда даже малозначительное изменение в одном месте влечёт за собой волну непредвиденных багов в другом. А в худшем случае можно ещё и эффект домино получить, когда придётся менять вслед за этим целые иерархии программных единиц. 🪦 — Я убеждён - мы с вами в первую очередь должны оставаться ленивыми прагматиками - то что написано однажды, было бы неплохо переиспользовать, а не переизобретать заново. В первую очередь профессия программиста о том как помочь бизнесу экономить и зарабатывать деньги. Даже если вся твоя команда - это только ты, всегда лучше потратить немного больше времени на этапе проектирования, чем потом постоянно бороться со своим кодом и багами при поступлении новых требований. Да и следующие поколения программистов на проекте будут вынуждены заниматься тем же вместо решения конкретных задач и спасибо они уж точно не скажут.