đŸ‘¶ FERMETURE : L'Atelier est fermĂ© jusqu'au 29 aoĂ»t en raison d'un congĂ© paternitĂ©. đŸ‘¶

Qu'est-ce que l'appartenance du code ?

✒ Enzo SandrĂ© · 📆 22/08/2021 · 🧠 Psychologie · 🧼 MĂ©thodes de dĂ©veloppement

🔏 L’appartenance du code dĂ©signe le sentiment de responsabilitĂ© d’un dĂ©veloppeur ou d’une Ă©quipe sur un morceau de code. Une forte appartenance est corrĂ©lĂ©e avec un plus faible nombre de dĂ©fauts.

⛓ La forte appartenance dĂ©signe un modĂšle oĂč un code est presque exclusivement Ă©ditĂ© par ses contributeurs majeurs, Ă  savoir des dĂ©veloppeurs s’identifiant comme experts sur cette partie prĂ©cise du logiciel.
Elle s’oppose Ă  la faible appartenance, oĂč la part des modifications rĂ©alisĂ©es par des contributeurs mineurs est grande.
Il existe Ă©galement un phĂ©nomĂšne de non-appartenance, dĂ©signant l’abandon de parties entiĂšres du code, assimilable au code legacy.

đŸȘČ Dans leur Ă©tude de 2011, Bird et al. dĂ©montrent qu’un modĂšle de faible appartenance provoque plus de dĂ©fauts, principalement Ă  cause du manque de connaissance mĂ©tier des contributeurs mineurs. La littĂ©rature prĂ©cĂ©dente appuie ce point : la productivitĂ© d’un dĂ©veloppeur dĂ©pend bien plus de la connaissance du mĂ©tier de de son expĂ©rience prĂ©cĂ©dente.

🧠 Sedano et al. reprennent ces rĂ©sultats en prenant en compte les critiques de Brendan Murphy : le lien entre qualitĂ© et appartenance n’est pas seulement causĂ© par la connaissance du mĂ©tier, mais Ă©galement par la psychologie. Un dĂ©veloppeur ayant le sentiment d’ĂȘtre responsable d’un code y prĂȘtera plus d’attention car il s’y identifiera (Quality with a Name).

📐 DĂ©limiter arbitrairement des « parties du code » et nommer des responsables n’a qu’un effet trĂšs marginal sur la qualitĂ© et augmente le Facteur Bus, donc le risque projet !

✔ Combattre l’apathie logicielle suppose la comprĂ©hension des ressorts psychologiques derriĂšre le sentiment d’appartenance. Ultimement, Sedano et al. dĂ©fendent la propriĂ©tĂ© collective du code comme une pratique vertueuse, mais la dĂ©monstration est pour demain !

— SOURCES —

Todd Sedano, Paul Ralph, and CĂ©cile PĂ©raire. 2016. Practice and perception of team code ownership. In Proceedings of the 20th International Conference on Evaluation and Assessment in Software Engineering (EASE ’16). Association for Computing Machinery, New York, NY, USA, Article 36, 1–6. DOI:10.1145/2915970.2916002

Christian Bird, Nachiappan Nagappan, Brendan Murphy, Harald Gall, and Premkumar Devanbu. 2011. Don’t touch my code! examining the effects of ownership on software quality. In Proceedings of the 19th ACM SIGSOFT symposium and the 13th European conference on Foundations of software engineering (ESEC/FSE ’11). Association for Computing Machinery, New York, NY, USA, 4–14. DOI:10.1145/2025113.2025119

B. Murphy Code ownership more complex to understand than research implies. Software, IEEE, 32(6):19, Nov 2015

J. Shore, Quality With a Name, 2006

Enzo Sandré


DOIs: 10.1145/2025113.2025119 · 10.1145/2915970.2916002