Комментарии 10
Как по мне, тут не хватает одной вещи - оценки масштаба проектов с какой-то другой точки зрения. Ну т.е. вот у вас 120 модулей получилось - у вас в проекте скажем сколько LOC? Как понять, много это модулей, или мало, как оценить объективно?
В открытых проектах я почти не вижу даже 30 модулей, хотя бы пустых. У меня в проекте как минимум 100 модулей с наполнением - то есть таких, которые реально имеют код и отвечают за что-то свое :) писать про проект-пустышку, где половина модулей была бы без контента вовсе - как-то неспортивно, что ли :)
Не, ну спортивно или нет - это другая история. Ну вот последний проект, что я смотрел - это был apache kerby, который является открытой java реализацией Kerberos - сервера и клиента. Ну т.е. это проект достаточно крупный, и в тоже время это проект, который можно охватить целиком (пусть и не за 15 минут). И там, для сравнения, всего 43 pom.xml (я посчитал). Вот мне поэтому и интересно - у вас проект, условно, в три раза сложнее? Или ваши модули по какой-то причине наполненные, но мелкие? Ну или еще проще - у вас очевидно есть проблемы с управлением этими сотнями модулей - вы про них статью написали, так? А вот где профит от таких мелких модулей в большом количестве? Ну раз вы их в таком количестве создаете - значит это чем-то удобно?
Я так понимаю, Kerby - это проект с биндингами к системе Kerberos + обвязки вокруг. Такие проекты у меня тоже есть, но их невыгодно делать на описанной в статье архитектуре - там не всегда есть ярковыраженные client/common/server куски, а когда есть - их нетрудно внедрить. У нас проекты в основном клиент-серверные и по-сути то, что в Kerby умещается в модуль, у нас умещается в common каждой фичи и потом добавляются обвязки в client и server. Мелкие модули у нас есть, но они обычно появляются на старте фичи, бОльшая часть из них в итоге разрастаются, что тоже легко поддерживается этой архитектурой. Банальный пример - у нас была фича работы с файлами, где были репозитории, мультиплатформенные абстракции, для каждого таргета были нужные обвязки, а на клиенте/сервере были биндинги для отправки с клиента на сервер и загрузки с сервера на клиент на каждую платформу в том виде, в каком это было нужно. Понятно, что о мелкости тут можно поспорить, но в целом выглядит как самодостаточная фича
Ну и я полагаю, Apache Kerby в основном создан на Java для JVM в основном для серверов или клиентов на JVM, у нас же поддерживаются нативный Android и Web(Kotlin/JS, html, css), при желании можно будет нативные таргеты добавить и это не потребует больших усилий
Алексей, спасибо за статью! Жду продолжения.
PS:
Отдельный респект за либу телеги и ее поддержку в чатах.
Как не свихнуться с кучей модулей в проекте