Ma réaction à un commentaire (je ne l'ai pas publié).
@SirBenJamin_ 1 hour ago
In my experience, most coupling problems (and other architecture problems) are caused by teams where everyone works on all parts of the codebase, i.e people don't specialise in a particular area, they just pick up the next ticket on the backlog, and then even worse, other people who also have no experience in the area review the code. Managers will see this as a good thing, as they think they're getting more bang for their buck by 'spreading the knowledge.' ... but I really don't think it ever ends up like that, and the codebase suffers
I think "everyone works on all parts of the codebase" could not be a problem per se if the knowledge is evenly distributed. In very big systems it might not be possible and thus I agree with you that specialization could be an useful strategy. Also, you back this with your experience, so empirical evidence strenghtens your point.
In systems not so big, I think that T shape profile along with good ownership distribution (with pair programming, ensemble programming, ADRs), could also have positive effects on coupling problems. Meaning having knowledge a bit larger than hers scope could help having a glance of neigbourg culture (such as how mapping is done in the team next to me).
Techniques such as "swarming" : helping others being stuck or learning things outside of our initial scope (ex. QA, learning a bit of programming skill, Backend learning a bit of frontend ...) might help growing more shared mental models and thus slowly growing in the direction of full stack profile.
This lovely comic illustrates it pretty well I think : https://blog.crisp.se/2009/06/26/henrikkniberg/1246053060000
Here is a visualization of a Java program. Each big circle represents a Class. The initial size (mass) of the circle is proportional to the number of fields and methods in the class. Each time the class calls a method of another class, the mass of the class increases, and a small circle will spawn. If class A calls B.method(), the small circle will have the same color (color B) as the circle that represents class B. If there are lots of small circles with color B following circle A, then the force of attraction on circle B exerted by circle A will be big. (Circle B does not attract Circle A if there are no small circles with color A following Circle B).
Question: Can you tell by looking at the visualization as to how the methods in classes are interacting with each other?
would you be able to describe it?
Is it a good way to visualize coupling between classes?
Is it good for anything at all?
Thank you so much
Locality of Behaviour (LoB)
Carson Gross
May 29, 2020
“The primary feature for easy maintenance is locality: Locality is that characteristic of source code that enables a programmer to understand that source by looking at only a small portion of it.” – Richard Gabriel
The LoB Principle
Locality of Behaviour is the principle that:
The behaviour of a unit of code should be as obvious as possible by looking only at that unit of code