Comment maintenez-vous une base de code de mauvaise qualité?

Question

Pour pouvoir conserver le code que j'écris, je dois bien nommer les variables, documenter mon code, veiller à ce que rien ne se répète, que les abstractions fonctionnent de sorte que les hacks ne sont pas nécessaires ... et commentent avec parcimonie, car les commentaires interrompent souvent moi en lisant le code.

Mais beaucoup d'autres bases de code que j'ai vues ressemblent davantage à un maelström. Les noms de variables sont foobar, les choses sont calculées même si elles n’ont jamais été utilisées, de nombreux hacks et correctifs sont appliqués, les abstractions échouent, les scripts de déploiement échouent ... Le code est une soupe incompréhensible et presque inutilisable.

Alors! Je suis curieux. Comment réussissez-vous à maintenir une base de code de mauvaise qualité?

Answer 1

Discipline

Answer 2

Refactoring constant; Lorsque vous ouvrez un fichier de code et que vous voyez quelque chose d'étrange, vous pouvez investir quelques minutes afin d'améliorer la conception du code existant.

Avoir une suite de tests unitaires peut vous aider, car cela vous permet de savoir si le code que vous modifiez fonctionne toujours ou s'il est interrompu en raison de votre modification.

Cela ressemble un peu à l’histoire d’une fenêtre cassée dans une maison. Lorsque vous voyez une fenêtre cassée, vous devriez la réparer. Si vous ne le corrigez pas, les choses commenceront à se détourner de là, et le résultat sera un désordre ininterrompable.

La plupart de mes projets sont également réalisés sous ContinuousIntegration; en plus de la construction et de l'exécution d'unittests, une analyse de code statique (fxcop) est également effectuée. De temps en temps, je regarde les résultats et j'essaie de réparer certaines violations signalées.

Answer 3

En général, ce que vous décrivez est la tendance naturelle de n’importe quelle base de code à augmenter l’entropie. Cela se produit dans chaque projet en vertu de son développement et de son maintien. Pour lutter contre cette augmentation constante, je suggérerais ce qui suit:

1. Quelqu'un de l'équipe disposant de suffisamment d'autorité doit s'en soucier. C'est la partie la plus importante. Si personne ne s'en soucie, cela ne se fera pas. Ce point semble évident, mais ce n’est pas le cas.

2. Définissez les normes et les meilleures pratiques. La plupart des langues ont un livre écrit par quelqu'un sur les meilleures pratiques. Par exemple, dans PERL, il existe un très bon ouvrage sur les meilleures pratiques Perl de Damain Conway. À moins que vous ne le fassiez, chaque membre de l'équipe a sa propre manière d'écrire du code, nommer des variables, commenter, etc.

3. Avis de code. Vous aurez besoin d'une liste de contrôle pour la révision du code. Il ne suffit pas que votre changement fonctionne, il doit également se conformer à la liste des meilleures pratiques. Nous avons mis en place une révision de code à deux niveaux, le premier niveau étant constitué de critiques de code par des pairs et le second niveau est un gestionnaire de publication soucieux de la qualité du code.

4. Avis de conception. Lorsqu'un bogue ou une amélioration est corrigé dans le système de suivi des bogues, il est important que ce dernier soit examiné par un tableau de contrôle des modifications, qui décide de la planification du travail et indique également qui doit revoir la conception du travail. C'est là que vous conservez les abstractions de code et assurez-vous que la modification sera conforme aux documents de conception et aux objectifs du projet. L’architecte logiciel de l’équipe ou un concepteur principal doit faire partie du CCB.

5. Déclencheurs de qualité d'enregistrement du code. Certaines meilleures pratiques peuvent être directement appliquées par code. Ecrivez de petits scripts qui vérifient votre code pour des choses comme le formatage, l’utilisation des tabulations / espaces, etc. Cela vous aidera à penser la qualité du code différemment.

Quelques lecture pour référence.

Answer 4

Les examens par les pairs établissent rapidement une norme de qualité du code difficile à quantifier sur un morceau de papier. Les tests unitaires vous permettent de changer de code sans crainte. Discipline, beaucoup.

Answer 5

Une question connexe: comment les gens parviennent-ils à écrire un code de mauvaise qualité?

Voici la réponse.

Une bonne stratégie pour les personnes incompétentes de notre secteur est la suivante:

1. Développez la capacité de produire un son impressionnant, en particulier pour les non-techniciens et les semi-techniciens. Etre capable de paraître assez plausible aux techniciens, assez pour les maintenir en déséquilibre.

2. Créez un désordre complet avec le code que vous touchez.

3. Maintenant, voici la partie cruciale: Partir et trouver un meilleur travail ailleurs juste avant que vous ne soyez découvert. Le meilleur moment dépendra des circonstances.

Answer 6

J'aimerais vous présenter un terme que j'ai entendu il y a quelques années - Dette technique . Voici une (1) entrée Wikipedia et une autre de (2) site Web .

En gros, je ne pense pas que les gens commencent par vouloir construire un logiciel minable. Ce qui se produit habituellement, c’est que les délais sont réduits, que les exigences sont modifiées ou remplacées à mi-développement et que de nombreuses autres réalités commerciales sont au cœur du développement de la qualité et de la conception.

De Fowler:

  

& "faire les choses à la manière rapide et sale   nous met en place avec une dette technique,   qui est similaire à une dette financière.   Comme une dette financière, la technique   dette supporte des paiements d’intérêts qui   venir sous la forme de l'effort supplémentaire   que nous devons faire à l'avenir   développement en raison de la rapide et   choix de design sale. "

Sur Wikipedia:

  

" Activités pouvant être reportées   inclure la documentation, écrire des tests,   assister à TODO commentaires et   s'attaquer au compilateur et au code statique   avertissements d'analyse. Autres exemples de   dette technique comprend la connaissance que   n'est pas partagé autour de l'organisation   et le code qui est trop déroutant pour être   modifié facilement. "

Ce que j'ai vu (et demandé à plusieurs équipes de développement de faire) est de refactoriser et de nettoyer la base de code très tôt dans les itérations de développement, généralement au début, avant que de nouveaux travaux ne soient développés.

Les examens par les pairs, les tests unitaires et les testeurs de logiciels professionnels contribuent tous à rembourser une partie de cette dette technique, ainsi qu’à une bonne prévision (et à une bonne réutilisation du code).

Si vous avez le budget, les tests automatisés peuvent être un bon investissement si vous êtes prêt à payer l’entretien (temps, efforts).

Il existe de nombreux outils de qualité tels que fxCop (et d’autres similaires), mais vous devez choisir avec soin les approches que vous envisagez d’adopter.

Les efforts visant à maintenir la qualité de la conception et de la base de code doivent être pris en compte. Réfléchissez donc bien au moyen le plus efficace et le plus utile pour votre équipe de développement / produit / entreprise / client, etc.

.

[(1) http://en.wikipedia.org/wiki/Technical_debt ]
[(2) http://martinfowler.com/bliki/TechnicalDebt.html ]

Answer 7

C’est le cas lorsque vous écrivez le code et que les lecteurs le lisent

1. A laissé les mauvaises habitudes
2. Utiliser une procédure utile, une fonction, un nom de variable
3. Utilisez la documentation sur son fonctionnement (procédure / fonction / calcul / etc.) et sur ce qui résulte de quoi. Ne faites pas de commentaire inutile.
4. Essayez de donner du style à votre code afin que les internautes le sachent (par exemple, en utilisant un code de style GNU)

ou
Utilisez un code d’embellissement pour cela
5. Pensez à travailler en équipe (même si vous étiez seul) et pas seulement à vous qui allez lire votre code (même s'il l'était).
6. Le code du refactor devrait également être utile.
7. Consultez vos coéquipiers à propos du code que vous avez écrit. Peut-il le lire?
8. Apprenez de la communauté OpenSource , son fonctionnement et le partage de codes & amp; patchs
9. Si vous le pouvez, utilisez SVN ou CVS pour conserver votre code

.

et rappelez-vous le KISS principe ( K eep I t S , S tupide)

et bien sûr Simple, Lean, Mean & amp; Belle

si cela s’est inversé (d’autres personnes écrivent, vous avez lu), je ne savais pas quoi dire: D (donnez peut-être que les personnes qui suivent les conseils LOL)

Answer 8

Documentation, contrôle de source, tests unitaires et bon programmeur.

Answer 9

Une suite complète de tests unitaires qui permet de modifier et de refactoriser sans vous soucier de la rupture du code existant.

Je vous recommande de vous procurer un exemplaire de l'article de Michael Feather intitulé "Travailler efficacement avec le code hérité".

Answer 10

Fridgemagnet dit: "Les programmeurs stupides ont des bases de code immaculées"

Answer 11

Vous ne pouvez mal gérer une base de code que si vous êtes une très petite équipe de développement (moins de 10 à 20 personnes sur un seul projet). Si votre projet grandit et que votre équipe grandit, soit vos pratiques évolueront, soit vous échouerez.

Le changement dont vous parlez concerne essentiellement le passage du piratage à la programmation et enfin au génie logiciel.

En génie logiciel, vous reconnaissez que tous les membres de l'équipe ne sont pas parfaits. Vous révisez le code, vous vous assurez que les autres se testent, vous vous revérifiez.

Vous commencez à voir le besoin d'un architecte capable de digérer les désirs du client et de les traduire en un document de conception. Cela peut facilement prendre un mois avant que quiconque ne soit ajouté au projet (mais au fil du temps de développement, vous gagnerez peut-être des mois, voire des années!). Il veille à ce que tout ait un sens et s'intègre raisonnablement bien.

Vous disposez de documents de conception, généralement basés sur UML, de sorte que différentes parties de l'équipe puissent comprendre les points d'intégration. Vous reconnaissez que tout ce qui a été fait doit éventuellement être refait sans les personnes qui l'ont fait, vous devez donc le documenter.

Votre processus qualité devient beaucoup plus strict et ils commencent à appliquer des règles comme si vous archiviez uniquement les modifications qui traitent des bogues spécifiques lors des tests.

Les tests, la refactorisation, etc. sont évidemment essentiels et sont renforcés par les pairs et les revues d'équipe.

Je ne dis pas que ce genre de choses est toujours nécessaire, ce n'est évidemment pas le cas, mais dans votre question, vous parlez de bases de code cruelles, et ces bonnes pratiques sont souvent la solution à ce problème.

Généralement, ces bonnes pratiques sont mises en œuvre après un projet GIANT qui échoue complètement parce que le code est si nul. Ensuite, ils licencient tous ceux qui ne peuvent ignorer le blâme, engagent des gestionnaires qui, espérons-le, ont de l'expérience dans des projets de grande envergure et (s'ils ne manquent pas d'argent), ils recommencent à zéro.

Au moins c'est mon expérience. YMMV

Answer 12

Vous avez juste besoin de pratique, de bons outils, de capacités et de volonté pour rompre avec les mauvaises habitudes et apprendre.

Answer 13

Le codage ressemble beaucoup à l’écriture manuscrite. Tout le monde a son propre style. L'un des plus grands défis auxquels j'ai été confronté lors de la maintenance du code hérité consiste à essayer de comprendre ce qui se passe. Cela revient généralement à un manque de cohérence dans la base de code.