This is when any developer from any team can make changes to any software component. When I wrote the post, I was surprised to learn that this practice refers to extreme programming 🙂
This approach gives the product flexibility and reduces the Time-to-Market for features. Nominally, each developer is responsible for the entire source code. But there is a danger in this.
Collective code ownership, — collective farm. In another way — "Collective farm". For some, this word has a clearly negative connotation, it smells of manure and sweaty people.
Why is the shade negative? The problem is in the environment.
Common means a draw. Not your own, not sorry.
So crutches are born, the code gets littered and starts to smell. The problem is not that programmers are bad. The problem is that the environment around us encourages "a five-year plan in three years" and "quickly, quickly, urgently in the prod yesterday". Often in such an environment, programmers quit before they face the consequences of their technical decisions.
To survive and succeed, the product must be healthy and must not degrade at the rate of making changes. And for this, all the components must be healthy.
We can create an environment that encourages the internal quality of the system and its components.
The environment is closely linked to workflows and regular activities.
I used to write about the continuous development process of engineering
Another such activity is the Architectural review of the sprint.
It turned out a lot of beeches, I will release a post about the Archrevue on Monday.
And how do you maintain internal quality?
Share your expertise in the comments
