Depuis que j'ai acquis de l'expérience dans une maison de logiciels, j'ai trouvé difficile de tolérer le code non soigneusement structuré, sans aucune forme d'architecture ni de beauté ni de clarté, que cela fonctionne ou non, c'est ce que c'est censé faire.
Je trouve que je suis toujours rattrapé dans le code de refactoring comme celui-ci parfois "à mes propres frais" est l'endroit où se trouve mon confort V Productivité Dilemme.
Quel est le moyen le plus rapide de traiter avec un code mal écrit que vous héritez de votre expérience? Ecrivez le vôtre ou l'encapsulation / refacteur Qu'est-ce qu'il y a là, du temps constamment?
10 Réponses :
Il n'y a évidemment pas de bonne réponse à votre question. Dans certains cas, vous refacteur. Dans d'autres, vous commencez à partir de zéro.
Parfois, la meilleure réponse est de la laisser seule à l'exception des frontières, où elle interface avec un code de qualité supérieure. Une fois l'interface propre, vous pouvez toujours nettoyer la laideur à l'intérieur ou simplement le remplacer. Mais sans ces murs d'interface en place, aucune tentative de fixation de la partie du gâchis devient beaucoup semblable à tirer sur un fil lâche sur un pull et à la regarder tous.
comme l'analogie des murs. Merci!
J'ai entendu un podcast sur Hanselminutes sur ce sujet juste l'autre jour Parler avec Michael Plumes , qui a un livre sur ceci: Travailler efficacement avec le code hérité . J'encourage une lecture. J'ai moi-même traité avec beaucoup de mauvais code héritage dans le passé et pensez généralement que vous devriez refroidir / réécrire les mauvaises parties progressivement, faites attention à ce que vous ne causiez pas trop de casse et que vous soyez stratégique sur le refacteur / réécriture . J'encourage aussi la présente lecture de Joel: choses que vous ne devriez jamais faire, partie I < / p>
+1 pour le commentaire spolsky. La réécriture de zéro est dangereuse et rarement une bonne idée.
Si cela fonctionne, laissez-le seul. Nous ne sommes pas payés pour rendre le code magnifique, nous sommes payés pour le rendre fonctionnel. Je ne préconise pas l'écriture de code laid, par tous les moyens rendent votre propre code aussi beau que vous le souhaitez (bien que la beauté soit subjective, bien sûr). Sachez simplement qu'il n'y a pas d'avantage commercial dans la modification de code qui fonctionne, peu importe la façon dont les fesses vous pensez.
montre-moi un client qui se soucie de la beauté du code de préférence à sa fonctionnalité et je vais vous montrer un client qui sera en faillite en cinq ans.
S'il y a un bogue dans ce code, vous pouvez considérer refactoring, mais, même alors, cela devrait être secondaire à la correction du bogue.
Sauf que nous sommes payés pour rendre le code maintable afin que nous puissions apporter des modifications au fil du temps. Par définition, le mauvais code est non motivé, alors laissez-le seul n'est pas une option. Bien sûr, à partir de zéro, c'est aussi une mauvaise idée, mais il y a une telle chose comme un terrain moyen ici.
@Steven: Alors le temps de faire c'est quand vous en avez besoin. Les ressources ne sont pas illimitées, chaque décision que vous faites pour faire un moyen que vous ne pouvez pas faire B (Yagni). Si vous avez des codeurs allongés à ne rien faire, de tous les moyens, le refacteur si vous le souhaitez. Sinon, cela fonctionne et la maintenabilité n'entre pas en jeu (puisque vous êtes pas en réalité le maintenir).
On m'a appris à «se sentir coupable de quitter un gâchis», ce qui signifie beau = code plus maintenu = des temps de construction plus courts et des avantages plus longs à terme, constitue le meilleur moyen d'y aller. Sans porter dans l'agile chose, combien faut-il envisager de «la santé du code» lors de la construction du code hérité?
@Steven - Nous sommes payés pour faire quelque chose qui fonctionne. Si cela est maintenu (et que mon code est), c'est un avantage supplémentaire. Cependant, j'ai vu un code terrible de Dieu qui fonctionne simplement. Il n'est pas nécessaire de modifier cela à moins que cela provoque un problème ou qui causera un problème. Beaucoup de code mal conçu ne seront jamais problématiques et la fixation est mauvaise pour les affaires.
@PAX: Pour être clair, je n'ai jamais suggéré que nous nous asseyons toute la journée, refactoring. Le temps que j'ai suggéré était au début du développement ultérieur, à la mettre en place des frontières afin que nous puissions faire ces changements en toute sécurité. @Steve: Non, la maintenabilité n'est pas une avantage facultatif, c'est une exigence primaire. Je ne sais pas de toi, mais je ne suis jamais embauché pour écrire quelque chose qui sera immédiatement gelé. Si ce n'est pas un échec complet, une nouvelle version sera attendue immédiatement après le premier navire.
@Stevensudit, je comprends d'où viennent d'où vous venez. Si le code a besoin doit être changé pour une raison quelconque, alors, oui, envisagez de le nettoyer aussi. Mais la question indiquait que «si cela fonctionne ou non» - ma conflit était que vous ne devriez pas perdre votre temps de nettoyage du code qui fonctionne parfaitement bien depuis qu'il nuit à d'autres travaux plus précieux et plus précieux. Même s'il y a du temps libre à "résoudre" cela, je réfléchirais à deux fois, puisque toute modification mène le risque de la rompre vraiment.
@PAX: Vous avez un point. En fait, je suis d'accord sous une réserve, qui est que le code ne fonctionne pas seulement, mais il n'y a aucun plan à présent pour le changer. Si nous devons le changer, le nettoyage peut-être peut bien être une condition préalable nécessaire. Sinon, les dépenses ne peuvent probablement pas être justifiées.
Je suis d'accord, @steven, toute modification substantielle bénéficiera d'un nettoyage en premier lieu puisque le nettoyage peut être amorti et les avantages sont susceptibles d'être supérieurs au coût.
règle la plus importante: s'il n'est pas cassé, ne le réparez pas (même si c'est laid).
Donc, à moins d'un bogue dans le code, ou si vous devez le mettre à jour pour ajouter de nouvelles fonctionnalités, ne le touchez pas.
Deuxième règle: Si possible, assurez-vous d'avoir des tests d'unités en place avant vous commencez à refactoriser. Des cas de test à la fois pour la pièce qui est actuellement brisé et pour les parties qui fonctionnent actuellement.
Troisième règle: Ne pas réécrire / refactoriser tout à la fois. Essayez de le casser dans de petites unités de travail et assurez-vous que chacun d'entre eux fonctionne correctement avant de commencer la suivante.
En outre, je trouve que la réécriture et le remplacement (pièce par pièce) est généralement plus productive que le refactoring.
Si vous êtes bon du tout, il y a un certain nombre de nettoyages que vous pouvez faire en toute sécurité. Tant qu'il y a des tests de régression en place pour attraper le gobelage rare, l'analyse des coûts / avantages est fortement en faveur de ces changements. Un exemple de changement généralement sûr peut être corrigé le nom d'une variable de manière à ce qu'il soit précis, en particulier si vous utilisez un outil de refactorisation au lieu de la recherche et de remplacement de texte.
@Steven: Les micro-refacteurs tels que le changement de noms de variables devraient être sûrs, mais je pense qu'il parle de changements plus importants. De plus, je serais insuffisant de manière difficile à justifier le coût et au risque de procéder à ces opérations de nettoyage de code, à moins que je devais mettre à jour la partie du code, et le nettoyez-vous pour le nettoyer. Si vous modifiez des noms de variables ou des avertissements du compilateur est le seul changement qui serait effectué à un fichier dans un cycle de publication / QC donné, je préfère ne pas le faire.
@Thilo, je ne voudrais pas être en désaccord et ce que vous avez dit à propos du cycle est particulièrement pertinent. Il y a de bons moments pour faire de gros changements, comme au début d'une nouvelle libération et de très mauvais moments, tels que juste après QC.
Selon combien de temps vous avez et sur la façon dont le code est vraiment merdique, le scénario va de tout jeter et réécrire tout de zéro à la sorte de le laisser comme il est et prenez la douleur de la laidité.
La réécriture de tout n'est probablement pas une option, si le code fonctionne réellement, même s'il pourrait être très moche. Cependant, pour développer que le code avec de nouvelles fonctionnalités pourrait être impossible sans refactoring. Prenez votre temps et faites de petits changements. Compiler et tester souvent!
Si le code est à la fois buggy et laide et , vous devez également introduire de nouvelles fonctionnalités. Ensuite, cela en vaut vraiment la peine d'envisager de réécrire le tout. Il ne peut y avoir que tant de spaghettis dans le code, jusqu'à ce qu'il devienne ingérable.
aller avec vos tripes. Si cela se sent mal et en désordre lorsque vous codez, car le code est moche et méchant. Il suffit de commencer à changer la pièce en pièce, bientôt le code "sera à vous", vous saurez ce que le code fait agir, vous en faites votre territoire :)
acclamations!
La beauté est dans l'oeil du spectateur.
architecture? Êtes-vous un de ces astronautes d'architecture?
Je vais supposer que lorsque vous dites que vous "héritées", vous voulez dire que vous avez été embauché dans une position où la base de code existante était un gâchis. L'autre interprétation est que cela vous a été laissé dans une volonté - qui serait très cool, mais peu probable ...
Je pense que la chose la plus importante que vous puissiez faire est d'examiner le code, d'identifier les risques et de planifier leur adressage. Il s'agit d'une approche très professionnelle et mesurée pour résoudre les problèmes et devrait être envisagée favorablement par la direction. Ce dont vous avez besoin pour communiquer très clairement est la valeur que vous allez ajouter à l'entreprise bien que vos efforts de refactoring étant donné que cela n'ajoute pas nécessairement des fonctionnalités qui se traduisent à des ventes (ou quelle que soit l'activité) à court terme.
Les avantages incluent des choses comme:
Vous devez trouver des raisons du refacteur qui ont une corrélation directe avec les pilotes de l'entreprise. Si vous ne savez pas ce qui plonge dans l'entreprise, alors avez une discussion un type de gestion approprié qui peut aider.
Mon conseil est assez simple - le refactoring est bon aussi longtemps que cela est fait pour une bonne raison. Une raison comme "le code n'est pas soigneusement structuré, sans aucune forme d'architecture ni de beauté ni de clarté" n'est pas assez de motivation. Engager la gestion et les faire exciter des possibilités qu'une base de code améliorée leur donnera!
... puis livrez-le. Si vous ne le faites pas, vous allez ressembler à un clown.
Faites ce que vous pouvez, mais souvenez-vous toujours: c'est leur code, pas le vôtre.
Je comprends, mais vous le tolérerez parce que c'est votre travail. En fin de compte, les clients ne donneront pas deux craps à quel point votre code est "magnifique". Il suffit de refroidir des choses lorsque vous réparez des bugs, pas beaucoup d'autre que vous pouvez faire.
Ils se soucient si le code est si moche que le produit est expédié tard et regorge de défauts. La laideur n'est pas cosmétique; C'est le manque de maintenabilité.
Vous avez tous les deux raison; D'où le dilemme.
La laideur n'équivaut pas nécessairement à buggy. J'ai vu un code sérieusement laid qui fonctionne (et beau code qui est plein de bugs, aussi bien). Si le code laid continue de fonctionner, il y a NO Business Business pour le changer. S'il cesse de travailler alors, d'accord, allez-y et réparez-le et profitez-en également de la possibilité de le rendre plus facilité - être conscient du rapport coût / avantage.
@Joe: Je suis tout à fait d'accord. @PAX: Oui, le code laid peut être sans bug, quand d'abord écrit. Il ne peut tout simplement pas rester sans bug que le développement continue. Vous dites "si le code laid continue de travailler", mais c'est le gros si ici.