Existe-t-il un moyen d'éviter le code spaghetti au fil des ans ?

Question

J'ai eu plusieurs emplois de programmation. Chacun d'entre eux comptait 20 à 50 développeurs et le projet durait de 3 à 5 ans.

Chaque fois, c'est la même chose. Certains programmeurs sont brillants, d'autres sont moyens. Tout le monde a son diplôme de CS, tout le monde a lu des modèles de conception. Les intentions sont bonnes, les gens s'efforcent d'écrire du bon code, mais au bout de quelques années, le code se transforme en spaghetti. Des changements dans le module A cassent soudainement le module B. Il y a toujours ces parties de code que personne ne peut comprendre, sauf la personne qui l'a écrit. Il est impossible de modifier l'infrastructure et les problèmes de rétrocompatibilité empêchent l'introduction de bonnes fonctionnalités. La moitié du temps, vous voulez simplement tout réécrire à partir de zéro.

Et les personnes plus expérimentées que moi considèrent cela comme normal. C'est normal ? Est-ce que ça doit l'être ? Que puis-je faire pour éviter cela ou dois-je l'accepter comme une réalité de la vie ?

Edit : Les gars, je suis impressionné par la quantité et la qualité des réponses ici. Ce site et sa communauté déchirent !

Answer 1

Une diligence impitoyable combinée à des tests unitaires constants est le seul moyen d'éviter un code spaghetti. Et encore, ce n'est qu'une solution de fortune. Dès que vous cessez de faire attention, les pâtes apparaissent.

Très souvent, je constate que le code spaghetti est introduit parce que quelqu'un est tout simplement paresseux ce jour-là. Il sait qu'il y a une meilleure façon de faire et n'a tout simplement pas le temps. Lorsque vous voyez cela se produire, il n'y a qu'une seule chose à faire.

Appelez-les sur ce point et demandez-leur de le modifier.

Je trouve qu'indiquer la meilleure façon de faire lors d'une revue de code est généralement suffisant pour faire avancer les choses. S'ils le vérifient et que j'en suis convaincu, je le remanierai moi-même.

Est-ce que j'ai parfois l'air un peu excentrique ? Je suis sûr que oui. Mais franchement, ça ne me dérange pas. Je ne suis pas un imbécile et j'aborde ce sujet de la meilleure façon possible. Cependant, le fait de laisser un mauvais code être enregistré garantit à peu près que je vais devoir le déboguer à un moment donné dans le futur. Je préfère prendre un peu de flaque maintenant et obtenir le bon code.

Je pense également qu'une culture de tests unitaires permet d'éviter le code spaghetti. Il est beaucoup plus difficile de tester un code spaghetti qu'un code bien structuré. Avec le temps, cela oblige les gens à garder leur code quelque peu factorisé.

Answer 2

Je crois que la clé pour éviter la pourriture du code réside dans des méthodologies de conception et de mise en œuvre ascendantes (je le crois tellement que j'ai donné ce nom à mon entreprise - Think Bottom Up !) Les outils de choix ici sont :

• Programmation par contrat
• Conception en couches
• Se concentrer sur le découplage
• Toujours construire en pensant à la réutilisation, en recherchant des solutions génériques.
• Maintenir des cadres légers, simples et ciblés

Comme l'ont suggéré d'autres répondants, vous devez détecter les problèmes à un stade précoce. Avec les développeurs débutants, cela signifie du mentorat (la programmation par les pairs est excellente ici) et des revues (revues de code et de conception). Avec les développeurs plus expérimentés, cela signifie la vigilance.

Surtout, n'ayez pas peur du remaniement. Si le remaniement vous effraie, vous êtes déjà coulé. Si le remaniement est considéré comme "mauvais", c'est que quelque chose ne va pas dans votre entreprise.

Quand vous réparez quelque chose, faites-le correctement. J'utilise le terme "fux" pour décrire un correctif qui a été fait de la mauvaise façon, car il ne fait que "fux" votre base de code.

Salud,

Dan

Answer 3

20 à 50 développeurs, c'est probablement le problème. Ce chiffre est assez élevé et il faudrait beaucoup de gestion et de ressources pour tout contrôler.

J'envisagerais de diviser le projet en petits segments réutilisables. Abstraire certaines couches du système central.

Answer 4

Créez des "pare-feu" entre les différentes zones du code. Pour ce faire, vous définissez différentes zones ou couches de code, et vous définissez une API unique (en Java, cela se fait généralement avec une interface) à laquelle chaque couche répond. Il doit y avoir des interfaces ou des classes de base que l'API utilise, mais qui ne "savent" rien des éléments internes de ces couches. Par exemple, l'interface graphique ne doit pas savoir ou se soucier de la façon dont vous stockez les données, et votre base de données ne doit pas savoir ou se soucier de la façon dont les données sont présentées à l'utilisateur final.

Ces API ne doivent pas être coulées dans le béton. Vous devriez pouvoir ajouter des éléments si nécessaire, à condition de vous assurer que vous ne polluez pas les pare-feu.

Answer 5

Je pense que le point principal est quand vous dites

vous voulez juste tout réécrire à partir de zéro.

Acceptez-le.
Utilisez autant de tests unitaires que possible, puis laissez le refactoring devenir une pratique courante. .
Des tests automatisés et unitaires garantiront que les changements n'introduiront pas de régressions ; consacrer un certain pourcentage de votre temps à la refactorisation de l'ancien code (et cela signifie, moins de nouvelles fonctionnalités !) garantissent que la base de code existante ne vieillira pas, ou du moins pas si vite.