Pull to refresh

Comments 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:

Отдельный респект за либу телеги и ее поддержку в чатах.

Спасибо :) к слову, как раз готовлю статью по проекту на базе PlaguBot

Sign up to leave a comment.

Articles