Bienvenue sur le podcast Artisan Developer, l'émission pour les programmeurs qui veulent
vivre une carrière épanouissante.
Prêt à passer au niveau supérieur ? C'est parti !
Encore une fois, merci Xavier pour votre participation et le partenariat qui nous a donné l'occasion
de faire cette belle arène.
Avec cette question, est-ce que du code de qualité coûte plus cher ?
Cher auditeur, si tu n'as pas encore participé, je t'invite à venir participer dans l'arène.
Et ce que j'avais envie d'aborder avec toi, plus que d'essayer de répondre à cette question,
si tu as envie à un moment donné, tu pourras amener ton opinion.
Moi, ce qui m'intéressait vraiment aujourd'hui, c'était de voir avec toi.
Comment est-ce qu'on aborde cette question de la qualité dans le milieu universitaire,
dans le milieu de la recherche en fait ? Parce que ce qu'on fait nous, c'est beaucoup
de choses empiriques.
Les consultants, on amène notre expertise, notre expérience.
Mais je ne vois pas grand chose, peut-être parce que c'est un biais que je ne connais
pas, mais je ne vois pas trop cet aspect recherche et ça m'intéresse beaucoup.
Comment vous travaillez sur ces enjeux de qualité, vous les scientifiques ?
Ok, merci Benoît pour l'invitation.
On peut se toyer aussi, ça serait peut-être plus simple.
Ouais, c'est une super question que tu me poses là et je vais t'avouer qu'il y a eu
un énorme changement dans la communauté des chercheurs, notamment grâce à GitHub,
essentiellement, qui nous a permis à nos chercheurs d'avoir énormément d'informations,
c'est ce qui nous manquait un tout petit peu, énormément de projets justement pour vérifier
des théories.
Ça, je pense que ça va te plaire.
Alors en fait, ce qui s'est passé avant GitHub, c'est que les chercheurs aient essayé
des théories, ce qu'on fait en recherche en informatique, on a une théorie par exemple,
la programmation orientée objet va avoir moins de bugs.
Donc on avait des théories et difficile de vérifier cette théorie.
Donc du coup, on avançait des arguments, on essayait de montrer que ça marchait dans
certains cas, mais très très très difficile de prouver la théorie du style, enfin je ne
sais pas, faire du test avant de développer, ça apporte des gains.
Et puis, et puis GitHub est arrivé et surtout, il y a plein de chercheurs qui sont allés
reprendre des méthodes utilisées dans les sciences sociales.
Qu'est-ce qu'on va faire ? Eh bien on va regarder plein plein plein de projets, mais
quand je te dis plein au début, c'était vraiment beaucoup, 10 000, 20 000, 100 000
projets et on va regarder comment se comportent ces projets par rapport à notre théorie.
Alors je vais te raconter un papier qui m'a vraiment plu moi en 2008, ce papier est sorti
en 2008, c'est un papier qui a été fait par des auteurs qui ont travaillé avec Microsoft.
Si même et moins est bonne, les auteurs c'est Nagapan et Zimmerman.
Et en 2008, il se souhaitait intéresser à une propriété, une théorie qui était très
intéressante sur la propriété du code.
Qu'est-ce que ça veut dire ? Ça veut dire on veut savoir si on prend un fichier, on veut
savoir si ce fichier appartient à un développeur ou pas.
Alors comment on fait ? Ce qu'ils ont trouvé, et puis c'est pas si bête finalement,
c'est qu'on pouvait mesurer quantitativement la propriété d'un fichier, il suffit de regarder
si le développeur a écrit plus de x% des lignes.
Donc maintenant il y a des outils qui existent, à l'époque ça n'existait pas, maintenant
il y a des outils comme Git Blame où tu peux savoir quel est l'auteur qui a écrit la ligne.
Donc je prends un fichier et si j'ai écrit plus de 70% des lignes par exemple, je peux
considérer que je suis propriétaire du fichier.
T'hésite pas à m'interrompre un peu nous, si il y a des choses qui sont inquiets.
Ah non, je t'écoute, je bois tes paroles, j'imagine plein de trucs, je me dis mais c'est
génial cette idée, pour étudier à quel point est-ce qu'on peut recorrer les
sas avec une notion de responsabilité collective ? Est-ce qu'on peut dire que plus les fichiers
vont être modifiés par un maximum de monde et plus tu auras ce sentiment de propriété
collective du code ?
Eh ben c'est exactement ce qu'ils ont voulu mesurer, donc tu vois tu as déjà l'intuition
de ce papier.
En fait ils sont intéressés à savoir s'il va aller mieux avoir un ou deux propriétaires
forts, c'est-à-dire c'est eux qui ont fait quasiment toutes les lignes, ou est-ce
qu'il vaut mieux avoir au contraire des propriétaires faibles et donc plusieurs développeurs
qui vont contribuer aux fichiers.
Et qu'est-ce qu'ils ont fait ? Eh ben essentiellement ils ont mesuré donc la propriété des fichiers
et en parallèle ils ont mesuré le nombre de bugs dans les fichiers.
Donc ça on peut le faire aussi avec des bons projets sous-guites, ceux qui sont bien
documentés là où on sait où sont les bugs.
Et donc en gros ils ont mesuré savoir s'il y avait plus de bugs dans les fichiers où
il y avait peu de propriétaires, ou l'inverse plus de bugs dans les fichiers où dans lequel
il y avait plein plein plein plein plein plein de propriétaires.
Tu comprends l'idée Benoit ?
Ouais je comprends tout à fait, là je me pose plein de questions sur les biais qu'il
peut y avoir mais du coup avant d'attaquer les biais et de taqueler le truc j'ai envie
d'écouter la conclusion.
Alors la conclusion elle est double et c'est ça qui était super intéressant avec ce papier.
Donc ils ont regardé les projets industriels et ils sont aperçus que sur les projets industriels
il fallait avoir des propriétaires forts.
L'intuition après on la comprend, en gros qu'est-ce qu'ils ont fait ? Donc ils ont
mesuré plein plein de projets chez Microsoft, ils en avaient beaucoup et ils ont vu que
quand il y avait peu de propriétaires mais des propriétaires forts, ben c'était déficit
où il y avait moins de bugs.
Alors ça c'est intéressant parce que ce qu'ils ont expliqué derrière, ils sont
allés voir la développeur, ils ont un peu posé la question, eh bien le développeur
qui est propriétaire il est un peu fier de son fichier et il n'a pas envie que les
autres viennent modifier donc dès qu'il y a une modification d'un autre le développeur
va regarder ça et il va contrôler la qualité des contributions qui sont apportées au fichier.
Donc ça c'était leur conclusion en 2008 si même Maraïbone où ils ont dit ben il vaut
mieux avoir des propriétaires forts.
Alors suite à ça nous on a refait l'étude dans le labo à Bordeaux sur les projets
open source et là c'était énorme parce qu'on a repris exactement leur méthodologie et
on a trouvé quasiment le résultat inverse.
Dans les projets open source il vaut mieux avoir plusieurs contributeurs pour qu'il y
ait moins de bugs.
Tu vois comme c'est marrant en fait quoi parce que là ce que j'ai essayé de montrer c'est
qu'on découvre grâce à ces méthodes on découvre si nos hypothèses de base sont
vraies ou fausses et on s'aperçoit qu'il n'y a pas de vérité vraie il y a des vérités
contextuelles.
C'est vraiment tu penses lié au contexte ou est-ce que c'est lié à des biais du genre
un biais d'échantillonnage sur des projets, un biais de quantité et de projet, un biais
sur la manière de mesurer les bugs.
Alors voilà tout ce qui est biais ça fait maintenant donc tu vois là il y a une super
conférence qui s'appelle MSR Mining Software Repository qui montre comment on enlève ces
biais.
Et là dessus franchement pour, alors je vais pas abaciner avec la théorie quoi, mais on
en est quasiment au même niveau que les gens qui disent moi je crois pas au sondage.
Alors les sondages peuvent se tromper c'est vrai mais ils trompent maintenant à quelques
pourcentages quoi.
Si tu veux ils sont pas bien loin si tu regardes le sondage comme en gros qui vont être les
trois premiers sur un sondage politique il va pas beaucoup se tromper le sondage.
Il ne sait pas du tout de l'aléatoire.
Sur les recherches statistiques qu'on fait sur les projets on est à peu près sur
les mêmes taux de confiance donc on peut mesurer le taux de confiance, on est souvent
au-delà de 95% de taux de confiance.
Ok d'accord et qu'est-ce qui a fait la différence alors pour toi entre les deux ? C'est vraiment
qu'une question de contexte ?
C'est qu'une question de contexte essentiellement parce que si tu regardes sur les projets
industriels les équipes sont plus réduites.
Les équipes sont plus réduites elles changent moins.
On a fait un autre papier juste après avec Mathieu qui était en thèse chez moi et on
a montré cette notion de turnover.
Cette notion de turnover elle est beaucoup plus forte sur les projets open source donc
il y a d'autres chercheurs, Thommen s'en Belgique par exemple qui ont montré que la
vivacité des communautés open source se mesure par rapport au flux des contributions
à ce qu'il y a de nouveaux contributeurs qui viennent d'autres qui partent etc.
Et donc cette richesse dans les communautés open source elle est vraiment basée sur
un turnover des gens qui vont arriver ce qui n'est pas vrai dans les projets industriels
où la richesse vient plutôt de la stabilité de l'entreprise.
Est-ce que c'est à peu près la même équipe qui gère le produit et ils savent exactement
ce que ça fait ?
Ça veut pas dire qu'ils ne vont pas changer le produit, que le produit ne va pas évoluer
mais ça dépend vraiment du contexte.
Écoute, je trouve que c'était passionnant, la boîte de temps est déjà mangée.
Je t'ai remercie pour cet apport, on mettra quelques liens pour aller un petit peu plus
loin.
Si les auditeurs veulent en savoir plus sur ce que tu fais, ils peuvent venir où ?
Oui, ils peuvent venir.
C'est une très bonne question.
Maintenant tout est accessible en ligne, malheureusement parfois c'est un peu payant.
Ce qu'il faut faire, il y a deux façons de faire.
Premièrement je vais faire un peu de pub à Google.
Google Scholar est vraiment pas mal.
Vous mettez les mots-clés, ils vous sortent les articles de recherche.
C'est un moteur de recherche qui est fait que pour les chercheurs quasiment.
Google Scholar.
Une fois que vous trouvez un ou deux papiers qui vous intéressent, regardez les noms des
auteurs, prenez le nom, mettez-le encore une fois dans votre moteur de recherche favori
et associé à cela DBLP.
En gros c'est la bibliothèque de tous les articles de tous les chercheurs.
Donc si vous mettez l'auteur suivi de DBLP, vous aurez tous les articles qui l'a écrit,
bien souvent s'il en a écrit un qui vous plaît.
Il y en a trois, quatre autres derrière qui vont vous plaire aussi.
Voilà, c'est le début.
Après il faut rentrer en contact avec des chercheurs peut-être.
Eh bien merci Xavier pour tout ça.
Quant à toi cher auditeur, j'espère que tu as apprécié ce podcast et rejoins-nous
dans la reine, répondre à cette question.
Est-ce que du code de qualité coûte plus cher ?
Choisis ton camp, vote pour ton champion et je te dis à demain.