Sucer moins chaque année? [fermé]

Sucer moins chaque année -Jeff Atwood

J'étais tombé sur cet article perspicace. Citant directement de la poste

J'ai souvent pensé que sucer moins chaque année améliorait les humbles programmeurs. Vous ne devriez pas être satisfait du code que vous avez écrit il y a un an. Si vous ne l'êtes pas, cela signifie soit A) que vous n'avez rien appris en un an, B) que votre code ne peut pas être amélioré, soit C) que vous ne revisitez jamais l'ancien code. Tous ces éléments sont le baiser de la mort pour les développeurs de logiciels.

1. À quelle fréquence cela vous arrive-t-il ou non?
2. Combien de temps avant de constater une réelle amélioration de votre codage? mois année?
3. Avez-vous déjà revu votre ancien code?
4. À quelle fréquence votre ancien code vous affecte-t-il? ou à quelle fréquence devez-vous gérer votre dette technique.

Il est certainement très pénible de corriger les anciens bogues et le code sale que nous avons pu faire pour respecter rapidement une date limite et ces correctifs rapides, dans certains cas, nous pourrions avoir à réécrire la plupart de l'application / du code. Aucun argument à ce sujet.

Certains des développeurs que j'ai rencontrés ont fait valoir qu'ils étaient déjà au stade évolué où leur codage n'a plus besoin d'être amélioré ou ne peut plus être amélioré.

• Est-ce que cela se produit?
• Si oui, combien d'années de codage sur une langue particulière s'attend-on à ce que cela se produise?

En relation:

Avez-vous déjà regardé en arrière certains de vos anciens codes et grimacé de douleur?

Star Wars Moment in Code "Luke! Je suis ton code!" "Non! Impossible! Ça ne peut pas être!"

  > Sucking Less Every Year ?

Non mais sucer différent chaque année :-)

Après mes premières critiques il y a plusieurs années, j'ai souffert du manque de conventions de nommage.

Ensuite, j'ai souffert que mon code était (inutile) implémenté pour être aussi générique que possible, mais cela rendait le code difficile à comprendre et à maintenir.

Ensuite, j'ai appris le développement piloté par les tests, InversionOfControl, quels génériques dot net où et bien d'autres.

conclusion

les souffrances des vieux mauvais habbits diminuent mais sont sur-compensées par les nouvelles souffrances que j'obtiens car j'apprends plus.

Fait intéressant, tous les programmeurs "rockstar" avec lesquels j'ai travaillé étaient extrêmement humbles, désireux d'apprendre et prêts à admettre qu'ils ne savent pas tout. Heck, beaucoup étaient carrément auto-dépréciés, au moins dans des moments légers.

Je ne pense pas avoir jamais rencontré un développeur qui pense que leur codage "ne peut pas être amélioré", mais quelque chose me dit que ces gars-là seraient à peu près aussi loin que possible de la rockstar - pour le dire doucement.

Les points suivants ne sont pas des conseils mais un journal personnel:

• en utilisant moins de variables globales
• n'utilisez pas d'abréviation pour les variables ou les noms de fonction
• écrire [certains] codes de test
• ne jugez pas le code comme lent (ou rapide) sans analyse comparative
• apprendre à charger le test d'une application
• ne le répare pas, s'il n'est pas cassé
• utiliser un outil de gestion de code source (git / hg)
• le refactoring est cool, ne sous-estimez pas le coût des tests qu'il apporte
• la sécurité est difficile, alors méfiez-vous le plus tôt possible
• patcher quelques bugs de projets open source
• blog quelque chose de nouveau
• la convivialité n'est peut-être pas une demande de fonctionnalité, mais elle est importante

Je n'ai pas tout appris en un an, tout prend du temps ...

Souvent, les gens pensent qu'un bon code se produit tout à coup, mais pour la plupart d'entre nous, de simples mortels, un bon code se développe dans notre base de code. Je veux dire, il est très difficile d'écrire le logiciel parfait depuis le début, car les exigences changent constamment et nous ne sommes pas des programmeurs parfaits, donc les décisions stupides sont prises en permanence par les gestionnaires et les programmeurs. Ensuite, je vois que chaque exigence change une bonne occasion de refaçonner une partie de l'ancien code en un meilleur code (et d'être payé pour cela!) Et de rembourser un peu de dette technique. Comme on dit: "quittez le référentiel de code un peu mieux à chaque fois que vous validez du code". Votre système évoluera ensuite vers un système plus proche de l'idéal.

Je ne connais absolument aucun programmeur fier de son logiciel mais c'est bien. Cela signifie que le programmeur a appris dans le processus.

De plus, si vous lisez le livre "Clean Code", vous augmenterez votre propre code "suck factor" plusieurs fois. :RÉ

J'ai en fait les deux côtés de la médaille pour cela.

D'une part, vous regardez l'ancien code et vous voyez qu'il est plein de bogues et de façons compliquées de faire les choses qui sont simplement accomplies en profitant de techniques et de fonctionnalités de langage que vous ne connaissiez pas à l'époque.

D'un autre côté, vous repérez une solution particulièrement élégante à un problème et vous ne pouvez pas vous empêcher de dégager un sourire suffisant à quel point vous étiez intelligent à l'époque.

Et puis vous faites défiler quelques lignes et grimacez d'horreur au fait que vous ayez utilisé GOTO en C.

Hmm ... Je suis souvent assez agréablement surpris par la qualité de mon ancien code.

Si je le faisais aujourd'hui, je l'écrirais souvent différemment, mais si je devais vivre avec les limites du temps, je n'en suis pas sûr. Lorsque vous pouvez compter sur une machine typique ayant au moins quelques Go de RAM, vous pouvez (et devez souvent) écrire votre code un peu différemment que lorsqu'un gros disque dur faisait 100 mégaoctets.

1. À quelle fréquence cela vous arrive-t-il ou non?

2. Combien de temps avant de constater une réelle amélioration de votre codage? mois année?

3. Avez-vous déjà revu votre ancien code?

4. À quelle fréquence votre ancien code vous affecte-t-il? ou à quelle fréquence devez-vous gérer votre dette technique.

1. Chaque fois que j'apprends quelque chose de nouveau, j'espère que c'est tous les jours.

2. Si j'arrive à mettre en œuvre ce que j'ai appris, c'est immédiatement à partir du moment où je l'implémente.

3. Oui, uniquement pour (1) les nouvelles fonctionnalités, (2) les corrections de bugs, (3) la nostalgie, (4) voir comment j'ai résolu quelque chose, peut être utile.

4. En ce qui concerne 1., lorsque j'apprends à faire quelque chose de mieux, je suis conscient que certains projets plus anciens "auraient" pu être mieux réalisés. Je les laisse. Assurez-vous simplement que le prochain projet est fait de la meilleure façon. Je ne m'inquiète pas sauf si c'est un bug réel.

Dans une autre question , le sujet portait sur les moyens d'évaluer la qualité de votre propre code. Une de mes suggestions a été de le revoir dans quelques années, lorsque votre expérience est bien supérieure à ce qu'elle était lorsque le code a été écrit. Une citation de ma réponse à cette autre question est directement liée à votre question:

"dans mon cas, la durée de vie est d'un an: cela signifie que je peux modifier le code que j'ai écrit il y a six mois, mais si le code a été écrit il y a deux ans, il a de fortes chances d'être jeté, puis réécrit complètement, car ça craint juste trop. "

Alors oui, dans la pratique, chaque morceau de code que j'ai écrit devient insupportable de mon point de vue en un an. Et je ne parle pas de code jetable, mais aussi du code que j'ai écrit avec la qualité, la maintenabilité et la lisibilité à l'esprit. Pour le moment, il n'y a pas d'exceptions.

Pour répondre à votre deuxième question sur la durée de vie, cela varie beaucoup. Un morceau de code jetable a une durée de vie de zéro seconde : il aspire juste après l'avoir écrit, mais cela n'a pas d'importance. Certains morceaux de code que j'ai écrits étaient supportables après deux ans , mais nécessitaient quelques changements cosmétiques: un peu de refactoring, l'application des règles StyleCop, etc. En moyenne, dans mon cas précis, la durée de vie varie entre huit mois et un an pour C #, et entre deux six mois pour PHP.

Dois-je revoir mon ancien code? Oui, bien sûr, comme tous les développeurs, sauf si vous ne vous souciez pas de DRY et réinventez votre propre roue encore et encore. Il y a également des chances de revoir et d'améliorer le code très fréquemment si vous avez une base de code commune que vous utilisez dans de nombreux projets . Un autre point est que si vous travaillez sur d' énormes projets, certains peuvent vous prendre des années , vous devrez donc revoir l'ancien code.

Certains des développeurs que j'ai rencontrés ont fait valoir qu'ils étaient déjà au stade évolué où leur codage n'a plus besoin d'être amélioré ou ne peut plus être amélioré.

Lorsqu'une personne dit qu'elle est si parfaite qu'elle n'a pas besoin d'apprendre quoi que ce soit, cela signifie qu'elle n'est même pas capable de comprendre à quel point elle est totalement stupide.

Même si vous avez vingt ans d'expérience en informatique / programmation, les choses changent trop vite, il y a donc toujours de nouvelles choses à apprendre et de nouvelles techniques pour améliorer le code. Par exemple, un code C # écrit quand il n'y avait pas de .NET Framework 3.0 peut très probablement être rendu plus lisible et meilleur avec les nouvelles choses que nous avons aujourd'hui (y compris Linq, les contrats de code, etc.), et ce, même si l'ancien code a été écrit par le développeur le plus intelligent.

Cela arrive assez régulièrement lorsque je regarde le code et je me demande: "À quoi pensais-je quand j'ai écrit cela?"

Il y a généralement des améliorations tout le temps car parfois une nouvelle idée pour organiser le code, styliser le code ou quelque chose d'autre me viendra et même si ce n'est pas une grande amélioration, chaque petite chose peut aider qui en vaut la peine.

Selon l'environnement de travail, je vois peut-être du code d'il y a quelques années alors que je continue à travailler dans la même base de code et que je suis assez familier avec ce qui s'y trouve et quelque chose à gérer.

L'ancien code me tourmente presque toujours car d'habitude je change un système existant ou je le remplace. Dans les deux cas, je dois connaître les bizarreries du système existant pour m'assurer qu'elles sont présentes dans le nouveau.

Bien que je sois sûr qu'il y a des gens comme Jon Skeet qui peuvent juste penser à un code parfait, la plupart des autres personnes qui disent que leur code ne peut pas être amélioré disent que d'un point d'ego qui pourrait bien ne pas être attrayant. En même temps, en termes de trouver une grande amélioration à chaque fois, ce ne sera pas toujours le cas.

1. À quelle fréquence cela vous arrive-t-il ou non?

À quelle fréquence suis-je mécontent de mon ancien code? Presque toujours. Il y a de rares exceptions où j'ai du code dont je suis vraiment fier ... mais encore une fois, ils sont rares. On m'a dit que le code que j'avais écrit il y a quelques années était bon ... J'ai grincé des dents et j'ai pensé "pauvre pauvre pour avoir vu pire que les ordures que j'ai écrites".

2. Combien de temps avant de constater une réelle amélioration de votre codage? mois année?

C'est généralement par étapes ... J'entre vraiment dans un style ou une méthodologie (prenez des interfaces fluides par exemple ... car c'était le dernier style pour lequel j'avais un énorme wet) et boucher tout ce que j'écris pendant un mois ou quatre . Ensuite, cela commence à mieux paraître.

3. Avez-vous déjà revu votre ancien code?

Pas aussi souvent que je le voudrais. La plupart de mon ancien code appartient à d'anciens employeurs. Le code personnel est trop souvent blanchi.

4. À quelle fréquence votre ancien code vous tourmente-t-il? ou à quelle fréquence devez-vous gérer votre dette technique.

Étant donné que les employeurs précédents ont la plupart de mon ancien code, et je lave la plupart de mon code personnel ... pas très souvent du tout.