What is application modularity?

Question

css

Let's say I have a team that can write any code, and I know superficially about programming (nothing specific, but a lot of top-level), but I want, for example, an android application, but such that new functions can be introduced there most seamlessly, preferably any (for example, an application is being written for compiling fitness programs, but such that later it can be conveniently connected to a Google calendar, implement and make friends with a module that helps to create a nutrition program, etc.).

What actions begin in the team after the words that the application should be modular and written technical specifications for functionality and visuals?
Well, immediately according to the results of Google search and questions on qna and stackoverflow)

Or should all possible functions be planned for 10 possible years at once in order to somehow answer this question?

I would like at the very beginning not to set myself an unsolvable task in the future (by reasonable means), and at the same time not to turn the application into a 500+ megabyte frankenstein.
Are you looking for assemblies on github and is going to the world on a thread on a half-knee?)
And in more detail? Choosing a database, renting a server, and what is needed so that the internal functionality can be conveniently scaled?

Answer 1

This is done with multi-gradient:

background-image: -webkit-linear-gradient(45deg, transparent 48%, rgba(255, 255, 255, 0.1) 50%, transparent 52%), -webkit-linear-gradient(135deg, transparent 48%, rgba(255, 255, 255, 0.1) 50%, transparent 52%), url("../images/Wallpapers 1600x900.jpg");
    background-image: linear-gradient(45deg, transparent 48%, rgba(255, 255, 255, 0.1) 50%, transparent 52%), linear-gradient(-45deg, transparent 48%, rgba(255, 255, 255, 0.1) 50%, transparent 52%), url("../images/Wallpapers 1600x900.jpg");
    background-size: 2em 2em,
                     2em 2em,
                     100% 100%;

Here you can read about it:
https://htmlacademy.ru/demos/8#step1

Answer 2

Modularity is a property of architecture.
It goes without saying that it must be thought through from the very beginning, because then changing it is usually very painful (that is, for a long time, up to rewriting everything from scratch).
In general, start by studying OOP, then the question, in theory, will disappear.
And the skill will come with experience.

Answer 3

What actions begin in the team after the words that the application should be modular and written technical specifications for functionality and visuals?

The question is being solved with the architecture, what language and framework will be used, what objects will be needed, what the interface will look like, what icons are needed, what tables in the database, how they are connected, what can be taken from the finished one, and what will be written from scratch and about a thousand more small details...

Or should all possible functions be planned for 10 possible years at once in order to somehow answer this question?

No, in the presence of a normal architecture, software features are quite easily integrated with already written code, the OOP itself just sinks for low connectivity, that is, the maximum independence of the components. If everything +- is within the oop canon, there shouldn't be much of a problem.

Database selection, server rental,

The task is already being solved, including the planned storage volume, and renting a server is more likely based on the expected load, which, of course, will also be completely different for different applications.

and what is needed so that the internal functionality can be conveniently scaled?

Do not mess up when planning the architecture, the rest can be solved.

Answer 4

I recommend the book "Clean Architecture" to you , in which "Uncle Bob" talks very well about what modules are, how to divide a program into modules. For a view "from above" probably nothing more is needed.
But the team must also understand, accept and follow the principles of architecture. That is, you can’t just break the program into modules and hope that everything will be fine from there. If these modules are "dirty" written, maintaining the program will still be a pain, even with a good architecture (albeit less of a pain than with a bad architecture). Therefore, modularity is a necessary but not sufficient condition for a program to be maintainable in the long run.