Règles non écrites de réécriture du code d'un autre membre de l'équipe [fermé]

40

Nous pratiquons la propriété collective de code. À ma connaissance, cela signifie que tout développeur peut modifier n’importe quelle ligne de code pour ajouter des fonctionnalités, pour refactoriser, corriger des bugs ou améliorer les conceptions.

Mais qu’en est-il de la réécriture complète du code d’un développeur qui fait toujours partie de l’équipe? Devrais-je lui demander d'abord? Quelle est la meilleure pratique?

Sglahn
la source
5
Je ne vois aucun inconvénient à supprimer le code si cela est nécessaire - à condition que vous utilisiez le contrôle de source. Les autres réponses à cette question décrivent l'éthique de la suppression du code de quelqu'un d'autre très bien.
Anonyme
9
Je ne pense pas que cela soit spécifiquement mentionné dans les [excellentes] réponses: même si le code existant mérite une réécriture, si cela fonctionne maintenant, il est très probablement une perte de temps [d'argent] à réécrire. J'ai appris que dans de nombreux scénarios, le plus rapide est le sale chemin. Vous êtes payé pour écrire du code, vous devez donc être aussi efficace que possible. Vous n'avez pas besoin d'un framework bien conçu pour quelque chose qui ne sera exécuté que quelques fois. Vous ne voulez pas prendre une semaine pour faire quelque chose qui aurait pu être fait en une journée en utilisant de mauvaises pratiques de conception. Plusieurs fois, les gestionnaires préfèrent cette approche.
taz
9
@taz - Ceci est la base du modèle Big Ball of Mud ( laputan.org/mud ).
Matthew Flynn
@ MatthewFlynn - Excellent article. La phrase "Big Ball of Mud" est apparue tellement de fois que cela ressemblait à une expérience déjà vécue de la "Pratique" d'Allan Iverson ( youtube.com/watch?v=eGDBR2L5kzI ). ;-)
Happy Green Kid Naps
3
Besoin de plus de contexte. Pourquoi changez-vous le code, quelle est l'étendue du changement - heures, jours, semaines, mois de travail. Qui paie pour le changement et en a-t-il vraiment besoin? Qui approuve la nécessité du changement. Qu'est-ce que vous traitez et comment cela a-t-il échoué si mal que vous avez commencé dans ce pétrin?
mattnz

Réponses:

62

Je pense qu'une bonne communication est toujours la meilleure pratique. Parlez au développeur et voyez s'il y a une raison pour que le code soit codé ainsi. Il se peut qu’ils aient eu l’intention de revenir en arrière et de le reformuler depuis des lustres, qu’ils l’aient fait de cette façon pour une très bonne raison ou que vous puissiez tous les deux apprendre quelque chose de la conversation.

Entrer et réécrire sans communication préalable est une recette de mauvaise volonté.

Matthew Flynn
la source
1
Oui, j'ai appris par expérience que certains développeurs peuvent être extrêmement agités si vous corrigez même des bugs dans leur code sans rien demander. Bien entendu, il s'agissait d'un projet sans suivi des problèmes ni planification des tâches, et je suis étonné qu'il ait même été livré.
moelleux
+1 pour "parler au développeur" - nous avons un bogue (enfin, au moins un, probablement plus) que le client attend maintenant ... et qui est à ce jour enfoui que j'étais le seul à savoir vaguement pourquoi il avait été laissé. seul.
Izkata
3
Je ne suis pas en désaccord avec la "bonne communication" en principe, mais je pense que cette réponse est un peu banale. En écartant toutes les questions gênantes sur les circonstances qui ont conduit à poser cette question, peu importe la raison pour laquelle un développeur répond par "oui" ou par "non" à la question "dois-je réécrire votre code?" , parce que ce ne sera pas nécessairement la meilleure solution pour l’équipe ou le produit. Bien sûr, on devrait essayer de découvrir tout ce que l'on peut sur les hypothèses et les décisions originales, mais comment savons-nous que le PO ne l'a pas déjà fait?
Aaronaught
2
@Aaronaught - La question de savoir s'il faut d'abord demander au développeur d'origine implique que l'OP n'a pas encore parlé au développeur d'origine et n'a donc pas essayé de découvrir tout ce qu'il peut. J'espère que la réponse est le contraire du banal - c'est fondamental.
Matthew Flynn
1
Si vous pratiquez réellement la propriété collective de code, vous avez alors le droit de modifier, réécrire ou supprimer tout code à votre convenance. Cela est particulièrement vrai si vous faites de la programmation en binôme. Cela dit, avant de procéder à un changement majeur (comme une réécriture) du code écrit par une personne donnée, il serait sage de le lui parler. Dans la plupart des cas que j’ai vu (y compris avec mon propre code), leur réponse a été: "Oh oui; désolé! Ce code est un désastre; je n’ai tout simplement pas bien fait les choses. Voici quelques idées pour l’améliorer. S'il te plait, va courir avec ça! "
Jeff Grigg
35

La prémisse même de cette question soulève un certain nombre d'inquiétudes que je ne pense pas que les réponses existantes tentent de répondre de manière adéquate. Permettez-moi de poser quelques questions de suivi ici:

  1. Êtes-vous absolument certain que vous parlez de réécriture et non de refactorisation? Par définition, les modifications apportées au style ou à la structure du code qui entraînent une mise en œuvre améliorée (ou simplement différente) sans modification du comportement externe constituent un refactor, pas une réécriture. Diviser une routine monolithique de 500 lignes en un ensemble de 50 sous-routines peut impliquer l'écriture d'un peu de nouveau code, mais ce n'est pas une réécriture. Le terme réécrire implique de jeter tout un produit ou une fonctionnalité et de recommencer à zéro; ce n'est pas quelque chose à prendre à la légère.

  2. Si le code original a un comportement si erroné ou si sa mise en œuvre est si complexe qu'elle nécessite une réécriture complète, pourquoi n'a-t-il pas été pris en compte par le processus de votre équipe et traité dans son contexte approprié (c'est-à-dire techniquement plutôt que socialement)? Un code défectueux ou douteux doit être exposé rapidement sur une équipe en bonne santé via des tests, des revues de code, des revues de conception, etc. Les avez-vous?

  3. Le responsable / responsable technique est-il au courant du problème et si non, pourquoi? Quel que soit votre type de processus, la qualité du code est généralement la responsabilité du responsable du développement. C’est la première personne à qui vous devriez vous adresser - bien sûr, pas dans le contexte de "untel a écrit un code de merde" mais simplement "je pense que je vois un problème majeur ici, pouvons-nous parler de réécriture?" Si cela ne justifie pas ce type de discussion, alors peut-être que cela ne justifie pas non plus une réécriture?

  4. Si la taille et la portée du code incriminé sont suffisamment grandes pour justifier une discussion sérieuse sur une réécriture, pourquoi appartient-il exclusivement à un développeur? La plupart sinon toutes les fois où j'ai vu du code et pensé «réécrire», il a été piétiné par une douzaine de personnes différentes et le mal est un résultat direct de l'accumulation d'incohérences de style, de suppositions erronées ou altérées et de bonnes vieilles hacks à la mode. Le code se développe avec le temps, précisément à cause de sa propriété partagée.

    Ce que je veux dire, c’est étrange qu’une personne possède une telle bande de code dans un environnement qui est supposé être une propriété collective. D'autres personnes ont-elles peur de toucher au code de ce développeur? Ont-ils peur de soulever le sujet? Il existe peut-être un problème sous-jacent lié à la dynamique de votre groupe, ou à ce développeur en particulier; si c'est le cas, ne l'ignorez pas. Ou alors, c’est peut-être la première fois que vous travaillez sur ce projet, et si oui, pourquoi envisagez- vous une réécriture si tôt dans le jeu? Quelque chose à propos de la situation ne semble pas s'additionner pour moi.

  5. La question précise, au premier alinéa, any developer can change any line of code to add functionality, to refactor, fix bugs or improve designs. Une réécriture ne fera-t-elle pas ces choses? Ou va-t-il faire quelque chose de plus - et si oui, quoi? Fondamentalement, quelles sont les raisons pour lesquelles vous souhaitez procéder à une réécriture, et dans quelle mesure êtes-vous certain qu'elles bénéficieront au produit ou à l'équipe? Vous n'avez pas besoin de répondre pour moi, mais vous feriez mieux d'avoir des points objectifs à faire si et quand vous choisissez d'en discuter avec l'équipe.

J’ai vraiment l’impression que cette question implique une grande quantité de contexte et qu’il ne faut pas y répondre sans une compréhension très claire de ce contexte. La réponse "correcte" dépend entièrement de votre équipe, de votre produit, de votre organisation, de votre personnalité, de votre processus, de la portée du code d'origine, de la portée des modifications, etc. Ceci est, OMI, un problème que vous devez absolument aborder avec votre équipe , pas sur un site de questions / réponses en ligne.

Aaronaught
la source
3
+1 La seule réponse correcte dans cette discussion.
mattnz
D'après mon expérience sur les équipes XP avec propriété collective de code (et programmation par paires), les modifications majeures apportées à la conception ou à la "réécriture" de parties du système impliquent généralement une discussion avec la plupart des membres de l'équipe (tous ceux qui s'en soucient). Avec des fonctionnalités essentielles, la conception existante est ce que l'équipe pouvait faire de mieux à l'époque. Si cela ne peut pas être changé facilement, il est utile de recueillir les idées de chacun sur ce qu'il pense que cela devrait faire et les différentes manières de l'améliorer. Si vous ne pouvez pas obtenir un consensus, essayez des "pics" ou des expériences pour collecter des informations.
Jeff Grigg
11

Pourquoi éditez-vous le code?

Existe-t-il des bugs ou s'agit-il d'un défaut de conception plus fondamental?

Dans le premier cas, je m'inquiéterais d'une réécriture pour corriger ce qui pourrait n'être que des bugs mineurs dans le code.

Dans ce dernier cas, bien que je m'attende à ce que "mon" code soit potentiellement réécrit, je serais parfaitement heureux que cela se produise.

C’est là l’intérêt de la propriété collective du code: le code que vous écrivez doit être modifié, voire remplacé, si quelque chose de mieux se présente.

ChrisF
la source
3
C’est la seule réponse jusqu’à présent avec laquelle je puisse être d’accord. Si quelque chose doit être réécrit, je le réécris. Je ne regarde même pas pour voir qui était l'auteur original; pourquoi devrais-je? En supposant qu'il y ait des tests (il y en a , n'est-ce pas?), Et en supposant que son objectif est raisonnablement clair ou expliqué par des commentaires (sinon, il faut absolument qu'il disparaisse), alors je saurai assez rapidement si j'ai cassé quelque chose. Bien sûr, je parle de la réécriture de quelques classes, et non d’un framework complet, mais si la réécriture est aussi volumineuse, il s’agit davantage d’un problème de planification / planification de projet que de propriété partagée.
Aaronaught
6

En règle générale, si vous êtes tous d'accord pour dire que vous êtes tous responsable du code, vous pouvez alors réécrire n'importe quel code s'il s'agit d'une amélioration. Parlez-en d'abord avec l'autre développeur par courtoisie. Il y a peut-être des raisons valables pour lesquelles c'est écrit d'une certaine manière. Sur le plan personnel, de nombreux développeurs s’investissent émotionnellement dans ce qu’ils produisent et, comme d’autres l’ont dit, vous ne voulez pas de mauvaise volonté.

Plus précisément, cela dépend un peu de la dynamique de l’équipe. Un développeur senior sur le point de réécrire le code d'un développeur junior devrait probablement effectuer une révision du code (mon site) avec eux avant de simplement le réécrire. De cette façon, le développeur junior peut apprendre de la situation.

Matt S
la source
5

Peu importe que le développeur d'origine soit dans l'équipe ou non, ou même si vous êtes le développeur d'origine. La réécriture complète de tout code partagé doit être exécutée par votre équipe, pour les raisons suivantes:

  • Cela prend beaucoup de temps. Si quelqu'un travaille sur un changement connexe, vous ne voulez pas perdre son temps.
  • D'autres personnes ont une perspective différente. Même si vous avez programmé 20 ans, quelqu'un d'autre pourrait savoir des choses sur les interactions avec du code que vous touchez rarement.
  • Les autres développeurs sont le "client" du code source. Le code source est écrit pour être lu par les autres développeurs. Ils peuvent avoir des exigences en matière d’architecture, des modifications de style ou des demandes de fonctionnalités qu’ils ne veulent pas dans ce code, mais qu’ils n’ont pas eu le temps. Vous ne voulez pas terminer un refactor uniquement pour découvrir qu'un autre développeur a besoin de le refactoriser d'une manière différente.
Karl Bielefeldt
la source
4

Comme Matthew Flynn l'a dit, il est nécessaire de parler d'abord au développeur. Le développeur initial peut dire des choses importantes sur la fonctionnalité et expliquer pourquoi telle ou telle solution a été proposée.

Mais avant de refactoriser ou de réécrire le code, effectuez une sauvegarde ou une branche contenant ce code. Si l'ancien code fonctionne bien, il restera une chance de le récupérer.

Si vous avez un système de contrôle de source (que je suppose que vous avez), alors, si possible, refactoriser tout le code et seulement après, quand vous êtes sûr que tout fonctionne bien, vérifiez-le.

Ne supprimez pas l'ancien code, au moins avant d'être sûr que le nouveau code fonctionne correctement. Mais laisser l'ancien code là-bas pour toujours n'est pas une bonne chose non plus. Je vous suggère de supprimer le code un peu plus tard, comme dans un mois après le test.

SuperM
la source
2
"Je vous suggère de supprimer le code un peu plus tard" - où doit-il rester entre-temps? Dans un bloc commenté? C'est à quoi sert le contrôle de source: conserver une copie de sauvegarde de tout le code modifié / supprimé pour une extraction facile, tout en préservant la pureté du code source actuel.
dj18
@ dj18, je garde généralement le code commenté pendant un moment pour le rendre plus évident et pour que tous les utilisateurs du code puissent voir qu'il a été modifié en même temps. En outre, il est plus facile de rechercher de cette façon lorsque le code vient d'être édité
superM
1
C'est une autre fonction d'un système de contrôle de version approprié: vous pouvez voir quand les changements ont été archivés, comparer les versions pour voir exactement ce qui a changé d'un archivage à l'autre et associer des commentaires à des archivages pour expliquer pourquoi une modification a été apportée. S'il est si important que les autres sachent tout de suite qu'un morceau de code a été modifié, envoyez peut-être une notification par courrier électronique au lieu d'attendre que les autres développeurs aient votre mot à dire.
dj18
2
La connaissance du fait que cette réponse doit être obtenue du développeur d'origine doit figurer dans le code , ou du moins dans les commentaires ou la documentation qui l'accompagne. Si ces informations sont importantes, il ne faut pas que cela reste dans le cerveau de quelqu'un, et les politiques de développement ne devraient pas encourager cela. Aussi, pourquoi ne pas supprimer l'ancien code? Vous pouvez le récupérer si vous en avez vraiment besoin. c'est ce que le contrôle de révision est pour .
Aaronaught
1
@Aaronaught: Je pense que ce que superM voulait dire était du type "here be dragons" ou "leçons apprises". Alors que les pièges devraient être assez évidents pour un programmeur expérimenté, les choix subtils sont moins évidents et peuvent ne pas être bien documentés. (Je suis d'accord que ce sont de mauvais signes qui doivent être adressés.)
rwong
2

Quelle est la portée de celui-ci?

  • Si vous retravaillez quelques lignes pour être plus efficace, faites-le. Peut-être demander s'il y a un risque que vous effaciez un comportement subtil. Signalez le changement en cours de mêlée ou par e-mail une fois que c'est fait, à moins que ce ne soit vraiment trivial (corriger une faute de frappe).

  • Si vous retravaillez une classe de taille décente, vous devriez probablement vous demander de bien comprendre la conception / le comportement. Informez les gens à l'avance pour que toute personne susceptible de travailler dans le même secteur puisse être mise au courant et se coordonner avec vous.

  • Si vous retravaillez un système plus volumineux, vous devez absolument travailler avec votre équipe pour l'informer des modifications et planifier sa conception.

Telastyn
la source
1

Si vos auteurs originaux sont là, communiquez avec eux. Pas juste pour l'étiquette, mais pour des informations supplémentaires, au cas où il y a des cas ou des circonstances que vous n'êtes pas au courant. Parfois, ils vous disent quelque chose de précieux.

Nous avons un contrôle de code abyssal. J'ai actuellement une tonne de choses à revoir et à entretenir, et je n'ai même personne avec qui faire la révision de code. Les auteurs précédents (à part moi) n'ont pas pris la peine de commenter un code. Et ils sont partis de l'entreprise. Il n'y a personne à poser sur le code.

Lorsque je réécris, je commente, avec des commentaires que j'ai commentés, ainsi que la date et le nom / initiales, et pourquoi cela a été commenté. Je commente le nouveau code, avec le nom ou les initiales, la date, la raison pour laquelle il a été ajouté, etc.

Des commentaires supplémentaires sont faits dans l'en-tête du paquet (er, généralement), indiquant quelles fonctions / procs / SQL / etc. ont été changés, avec la date. Il est facile de rechercher des sections qui ont été modifiées et ces sections ont une documentation complète.

Les commentaires sont bon marché. Les dates seront un indicateur de ce qui a changé, et après x-nombre de (jours / révisions / nouvelles embauches / retraites), le code peut être nettoyé des anciens commentaires et le reste est la nouvelle base.

Marc
la source
1

D'après mes observations, la pratique générale est la suivante: ne supprimez jamais le code. Il suffit de commenter et de le garder.

Ma pratique est de commenter tout en le remplaçant. (Principalement à titre de référence.) Ensuite, supprimez-le sur le commit final du changement en cours. (Cela nécessite un contrôle de version et une compréhension de la façon d'inverser les modifications.)

Lorsque je trouve un ancien code commenté, j'essaie de le supprimer dans un commit séparé avec les commentaires appropriés. Cela facilite la restauration ou l'inspection de la modification si nécessaire.

Pour tous les changements, vous devriez pouvoir utiliser l'historique des révisions pour déterminer le ou les développeurs qui ont créé le code. (L'historique de révision annoté aide ici.) Contactez-les si possible pour savoir pourquoi le code est tel qu'il est. Sur de nombreux projets, le temps de nettoyage ne se produit pas et les choses sont laissées pour compte. Vérifiez le gestionnaire de bogues pour voir s’il existe un enregistrement du nettoyage requis. Parfois, les modifications doivent être nettoyées une ou deux versions plus tard.

Si vous changez le code, il y a probablement une raison pour laquelle vous travaillez avec ce code. Vérifiez auprès du développeur d'origine pour savoir pourquoi le code est tel qu'il est. S'il existe une raison légitime de ne pas le réparer, ajoutez un commentaire expliquant pourquoi le problème n'a pas été résolu ou pourquoi il ne devrait pas être changé. Cela permettra au prochain développeur de gagner du temps.

Des balises telles que FixMe, ToDo, Bug et Hack peuvent être utilisées pour indiquer du code pouvant être modifié ultérieurement. (Il est acceptable de marquer les limitations en tant que Bug et de ne pas les corriger si elles ne sont pas déclenchées dans les conditions requises.) Cela pourrait être un bug si un programme de comptabilité à domicile débordait à 20 millions de dollars, mais je ne perdrais pas beaucoup de temps à réparer il.

Les modifications de révision de code doivent être effectuées par le développeur d'origine s'il est approprié de modifier le code.

BillThor
la source
2
Presque rétrogradé, jusqu’à ce que j’ai vu "Alors efface-le sur le commit final".
Joshua Drake
1

Cela dépend probablement de la raison pour laquelle la réécriture est nécessaire. Si c'est parce qu'il y a des problèmes avec ce qui est écrit, et il y en a toujours eu, alors il faut en parler, même si c'est pour minimiser la fréquence à laquelle le code doit être corrigé à l'avenir.

Ma suggestion dans ce cas est de coupler lors de la correction du code. De cette façon, il fournit un bon exemple des états intermédiaires et (espérons-le) un certain contexte pour expliquer pourquoi le code réécrit est meilleur. Aussi (si ce n'est que comme un exercice personnel), essayez de refactoriser le code pour qu'il soit meilleur sans une réécriture totale. Ce sera plus difficile, mais c'est bon pour vous.

D'autre part, il y a d'autres moments où une réécriture est appelée:

  • L’équipe a beaucoup appris depuis l’écriture du code, et le ou les développeurs qui l’ont écrit l’écriraient différemment maintenant, même sans votre contribution.

  • Une nouvelle fonctionnalité requise change la situation de sorte qu'une mini-réécriture ciblée est appropriée.

Dans ces cas, je ne m'ennuierais probablement pas avec une conversation.

En y réfléchissant, il me semble que plus le code existe depuis longtemps, moins une conversation est nécessaire.

Sean Reilly
la source
1

Je pense que @aaronaught a fait quelques bons arguments, ce qui conduit vraiment à la réponse que je voulais donner, à savoir que cela dépend vraiment de qui fait le changement (et pourquoi) et qui a écrit le code.

Dans mon expérience personnelle, le code est normalement modifié car il ne fonctionne pas comme prévu ou vous devez simplement étendre ce qu’il fait.

Dans un environnement de développement en équipe, vous ne devriez pas avoir à (et peut-être ne pas être capable) de parler au codeur d'origine, tout devrait être clair à partir du code.

Cela conduit ensuite à la question qui occupe la plus grande partie de mon temps, ce qui était l’intention du programmeur d’origine, et c’est cette question qui conduit le plus souvent à la suppression de code, et c’est pourquoi nous devrions tout commenter, et où les programmeurs débutants inexpérimentés tombent souvent en faute.

Tout programmeur qui modifie le code de quelqu'un d'autre (refactoring) doit vraiment, par courtoisie et pratique, copier le même style de code du code déjà en place et commencer par déterminer le fonctionnement du code d'origine et ses résultats. pour, et va réellement, atteindre. Souvent, cela en soi identifie les bugs, mais cela force certainement les gens à supporter la douleur que la prochaine personne aura à regarder votre code.

Dans mon équipe, tout le monde peut supprimer, refactoriser ou réécrire quoi que ce soit, et je considère la «propriété» comme une pratique qui engendre la paresse, comme si une personne était sûre d'être informée de tout changement, pourquoi aurait-elle besoin de rendre le code lisible.

Donc, en bref, non, vous ne devriez pas avoir à demander à l'auteur original du code, et si vous regardez le code, c'est un signe que son code n'est pas assez lisible, ou que vous devez l'améliorer. tes compétences. Cependant, je trouve bon de laisser le code original en place, commenté, jusqu'à ce que vous soyez absolument certain qu'en réécriture, vous n'avez pas accidentellement supprimé la fonctionnalité requise. Personne n'est parfait.

Sibaz
la source
-2

Souvent, le code est écrit d'une certaine manière pour une raison. Communiquer le changement à l'auteur fonctionne toujours pour le mieux.

Chuck Conway
la source