Dev Easy Notes

🎛 Многомодульность

Когда я только начал работать в качестве Android разработчика, моей первой компанией был аутсорс. Это была очень маленькая компания и в основном были мелкие заказы на проекты длительностью 2-3 месяца. Довольно часто я был единственным разработчиком на проекте. Я ничего не слышал про многомодульность, что это и зачем. 

В этот же период был расцвет докладов про архитектуры. Тогда только начинали говорить про многомодульность. Я помню как смотрел доклады от разработчиков Яндекс Карт, Lift, Uber идея многомодульности казалась невероятно крутой. Разумеется я подумал, раз крутые ребята так делают на своих проектах то и я так должен делать.  На основных проектах времени на это особо не выделяли и поэтому многомодульность можно было попробовать только на своих pet проектах.

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

Есть такая штука как Закон Конвея. Суть такая, что архитектура ПО повторяет архитектуру организации в которой это ПО создается/используется. Другими словами, архитектура в приложении повторяет архитектуру бизнеса.

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

Чаще всего это будут и разные команды разработки. Если над Android приложением работают 40 разработчиков, это не значит, что они прям вместе работают. Они разбиваются на отдельные команды по 2-3 человека и каждый пилит свою часть. Разумеется в этом случае в нашем приложении нужно делать отдельные модули. Потому как это разные экраны и развиваться они должны независимо. Грубо говоря это разные приложения, которые работают в рамках одного процесса и имеют одинаковые UI элементы (если дизайнер адекватный). В одном модуле мы бы просто сошли с ума, постоянно исправляя конфликты, и задевая код другой команды.

Когда ребята из крутых компаний говорят про многомоудльноть, они ее делают не потому что это круто с инженерной точки зрения. Это просто единственный способ убрать сложность возникающую когда огромная куча людей работает над одной кодовой базой. Она нужна только тогда, когда бизнес достигает того размера, что начинает разделяться на отделы, работающие независимо друг от друга.

И поэтому довольно забавно слушать истории, когда ребята из аутсорса, при заказе приложения на 3-4 месяца, без дальнейшей поддержки затаскивают многомодульность. Она там не нужна, многомодульность это про очень долгую поддержку большой командой, что чаще всего есть только в продуктовой разработке. В небольшом проекте использовать многомодульность это оверхед.

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

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

👍38🥰2

www.tgoop.com/dev_easy_notes/171

1.83K viewsOct 3, 2022 at 14:31

🎛 Многомодульность

Когда я только начал работать в качестве Android разработчика, моей первой компанией был аутсорс. Это была очень маленькая компания и в основном были мелкие заказы на проекты длительностью 2-3 месяца. Довольно часто я был единственным разработчиком на проекте. Я ничего не слышал про многомодульность, что это и зачем. 

В этот же период был расцвет докладов про архитектуры. Тогда только начинали говорить про многомодульность. Я помню как смотрел доклады от разработчиков Яндекс Карт, Lift, Uber идея многомодульности казалась невероятно крутой. Разумеется я подумал, раз крутые ребята так делают на своих проектах то и я так должен делать.  На основных проектах времени на это особо не выделяли и поэтому многомодульность можно было попробовать только на своих pet проектах.

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

Есть такая штука как Закон Конвея. Суть такая, что архитектура ПО повторяет архитектуру организации в которой это ПО создается/используется. Другими словами, архитектура в приложении повторяет архитектуру бизнеса.

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

Чаще всего это будут и разные команды разработки. Если над Android приложением работают 40 разработчиков, это не значит, что они прям вместе работают. Они разбиваются на отдельные команды по 2-3 человека и каждый пилит свою часть. Разумеется в этом случае в нашем приложении нужно делать отдельные модули. Потому как это разные экраны и развиваться они должны независимо. Грубо говоря это разные приложения, которые работают в рамках одного процесса и имеют одинаковые UI элементы (если дизайнер адекватный). В одном модуле мы бы просто сошли с ума, постоянно исправляя конфликты, и задевая код другой команды.

Когда ребята из крутых компаний говорят про многомоудльноть, они ее делают не потому что это круто с инженерной точки зрения. Это просто единственный способ убрать сложность возникающую когда огромная куча людей работает над одной кодовой базой. Она нужна только тогда, когда бизнес достигает того размера, что начинает разделяться на отделы, работающие независимо друг от друга.

И поэтому довольно забавно слушать истории, когда ребята из аутсорса, при заказе приложения на 3-4 месяца, без дальнейшей поддержки затаскивают многомодульность. Она там не нужна, многомодульность это про очень долгую поддержку большой командой, что чаще всего есть только в продуктовой разработке. В небольшом проекте использовать многомодульность это оверхед.

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

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

BY Dev Easy Notes