Что такое модульность приложения?

Question

[Gorgio Govani]

Допустим у меня есть команда, которая может написать любой код, а я поверхностно знаю про программирование (ничего конкретного, но много верхнеуровневого), но хочу себе, например, приложение для андроида, но такое, чтобы туда можно было наиболее беспроблемно внедрять новые функции, желательно любые (например, пишется приложение для составления фитнес программ, но такое чтобы потом его можно было удобно связать с гугл календарем, внедрить и подружить модуль помогающий составить программу питания и т.д.).

Какие действия начинаются в команде после слов, что приложение должно быть модульным и написанного ТЗ по функционалу и визуалу?
Ну сразу по результатам гуглопоиска и вопросов на qna и стаковерфлоу)

Или все возможные функции должны быть запланированы сразу на 10 возможных лет, чтобы хоть как-то ответить на этот вопрос?

Хотелось бы в самом начале не поставить себе в будущем неразрешимую задачу (разумными средствами), и при этом не превратить приложение в лагучего франкенштейна на 500+ мегабайт.
Ищутся сборки на гитхабе и с миру по нитке штото на полуколенке собирается?)
А поподробнее? Выбор бд, аренда сервака, а что нужно для того, чтобы внутренний функционал можно было удобно масштабировать?

Comments

[AlexVWill]

Написанию любого кода предшествует создание грамотного ТЗ.

Answer 1

[dollar]

Модульность - свойство архитектуры.
Само собой разумеется, её надо продумывать с самого начала, потому что потом менять её обычно очень больно (т.е. долго, вплоть до переписывания всего с нуля).

Вообще начните с изучения ООП, тогда вопрос по идее отпадёт.

А навык придёт с опытом.

Comments

[nozd up]

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

[dollar]

nozd up, так от джуна до архитектора - примерно столько же лет. :)
Вопрос автора предполагает, что у него уже есть команда, вопрос про архитектуру, и при это сам вопрос на уровне джуна. Поэтому простого решения здесь быть не может, имхо.

Answer 2

[ThunderCat]

Какие действия начинаются в команде после слов, что приложение должно быть модульным и написанного ТЗ по функционалу и визуалу?

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

Или все возможные функции должны быть запланированы сразу на 10 возможных лет, чтобы хоть как-то ответить на этот вопрос?

Нет, при наличии нормальной архитектуры программные фичи достаточно легко интегрируются с уже написанным кодом, собсно ооп как раз топит за низкую связанность, то есть максимальную независимость компонент. Если все +- в пределах канона ооп, особых проблем быть не должно.

Выбор бд, аренда сервака,

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

а что нужно для того, чтобы внутренний функционал можно было удобно масштабировать?

Не накосячить при планировании архитектуры, остальное решаемо.

Answer 3

[Михаил]

Я вам рекомендую книгу "Чистая архитектура", в ней "дядюшка Боб" очень хорошо рассказывает о том что такое модули, как разделять программу на модули. Для взгляда "сверху" наверное больше ничего и не надо.

Но команда тоже должна понимать, принимать и следовать принципам архитектуры. То есть нельзя просто разбить программу на модули и надеяться что дальше все будет хорошо. Если эти модули будут написаны "грязно", то сопровождение программы все равно превратится в боль, даже при наличии хорошей архитектуры (хотя и в меньшую боль чем при плохой архитектуре). Поэтому модульность - необходимое, но не достаточное условие сопровождаемости программы в длительной перспективе.