About architecture
Problemsβ
Usually, the conversation about architecture is raised when the development stops due to certain problems in the project.
Bus-factor & Onboardingβ
Only a limited number of people understand the project and its architecture
Examples:
- "It's difficult to add a person to the development"
- "For every problem, everyone has their own opinion on how to get around" (let's envy the angular)
- "I don't understand what is happening in this big piece of monolith"
Implicit and uncontrolled consequencesβ
A lot of implicit side effects during development/refactoring ("everything depends on everything")
Examples:
- "The feature imports the feature"
- "I updated the store of one page, and the functionality fell off on the other"
- "The logic is smeared all over the application, and it is impossible to track where the beginning is, where the end is"
Uncontrolled reuse of logicβ
It is difficult to reuse/modify existing logic
At the same time, there are usually two extremes:
- Either the logic is written completely from scratch for each module (with possible repetitions in the existing codebase)
- Either there is a tendency to transfer all-all implemented modules to
shared
folders, thereby creating a large dump of modules from it (where most are used only in one place)
Examples:
- "I have N implementations of the same business logic in my project, for which I still pay"
- "There are 6 different components of the button/pop-up/... In the project"
- "Dump of helpers"