Sucer moins chaque année? [fermé]

10

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!"

Aditya P
la source
3
Les gens à mon humble avis qui pensent qu'ils sont parfaits et pensent qu'ils n'ont pas besoin de s'améliorer ont raison. Ils ne peuvent pas s'améliorer. Toute personne sensée sait qu'elle ne peut jamais être parfaite, il y a toujours place à l'amélioration / à l'apprentissage de nouvelles choses. Je serais horrifié si je découvrais que je ne peux pas m'améliorer - je ne veux pas penser que j'ai un plafond.
MAK
J'adore revenir aux projets que j'ai faits quand j'étais très nouveau et regarder du code qui était si difficile à écrire pour moi. Plusieurs fois, le code est tellement simple. Ça me fait rire.
The Muffin Man

Réponses:

6
  > 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.

k3b
la source
19

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.

Tables Bobby
la source
2
Je suis d'accord à 100%. Ce sont des assassins silencieux! Oh et super nom d'utilisateur, xkcd? :)
jamiebarrow
@jamiebarrow: Bien sûr. :)
Bobby Tables
un autre cas d'échec est la personne qui dit "tous les logiciels sont mauvais, tous leurs hacks, vos idées d'améliorations n'ont pas d'importance". Un peu déprimant de travailler avec ces types.
Doug T.
13

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 ...

ohho
la source
J'aime la façon dont vous mentionnez "écrire [certains] codes de test". Je crois que personne n'atteint jamais la perfection où il ne commettra jamais d'erreur en tant que programmeur - nous sommes tous humains et nous commettons des erreurs de temps en temps. Les tests unitaires et les tests d'intégration peuvent réduire nos erreurs. Et je remarque que vous dites «quelques» tests, ce qui est important, car parfois je me suis laissé emporter par des tests d'écriture qui n'étaient pas vraiment utiles.
jamiebarrow
En fait, je pense qu'en dessous "ne le répare pas, s'il n'est pas cassé" j'ajouterais "s'il est cassé, et c'est compliqué, reproduisez et corrigez le bogue avec le code de test"
jamiebarrow
2
Puis-je en ajouter quelques-uns? S'il s'agit d'une API, n'exposez pas plus de détails internes que nécessaire, si vous la cachez, vous pouvez la modifier plus tard. Utilisez toujours des constantes à la place des nombres magiques car elles sont plus faciles à documenter et à modifier. L'immuabilité est extrêmement utile, en particulier lorsque la concurrence est impliquée. Travailler sur la base de code de quelqu'un d'autre, c'est un processus infiniment précieux pour juger votre propre style de codage lorsque vous devez le justifier auprès de quelqu'un d'autre. Faites congeler la spécification (si possible) car il est plus difficile de toucher une cible en mouvement.
Evan Plaice
Si vous travaillez sur place ou à proximité de clients, emportez vos cartes sans autorisation et de puissance supérieure. S'ils vous demandent de changer quelque chose en dehors de la spécification, retirez la (je n'ai) pas de carte d'autorité suivie par la (référence à) une carte de puissance supérieure (de préférence un PM hors site qui peut prendre en charge les demandes). Dans le meilleur des cas, cela vous libérera pour vous concentrer sur le développement; dans le pire des cas, cela réduira le nombre de demandes de fonctionnalités de drive-by. (controversé) Revenez tôt et revenez souvent, si le retour devait se produire à la fin d'un bloc de code, il n'y aurait pas de mot-clé pour cela. J'espère que je continue de sucer moins chaque année.
Evan Plaice
4

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É

Rafa de Castro
la source
1
Je suis en désaccord avec vous sur un point, je crois que certains codes dont vous pouvez être fier. L'ironie, c'est que vous pouvez avoir un projet qui se déroule extrêmement bien, et en être fier, avec peut-être quelques petits ennuis. Ensuite, le prochain projet, vos WTF par heure sont élevés ... pour votre propre code! : D
jamiebarrow
1
Cela dépend peut-être de l'étape que vous êtes maintenant. Maintenant, je trouve du code que j'ai écrit il y a un an et même j'ai du mal à comprendre certains noms ou le but de certaines méthodes. Je trouve aussi du code découvert par des tests et des choses comme ça. Alors que je continue de m'améliorer, des choses comme ça ont tendance à être des exceptions plutôt que la norme et je commence à être gêné par des problèmes qui auparavant semblaient sans importance ...
Rafa de Castro
+1 pour le code propre bien que sa comparaison soit toujours avec vous-même.
Aditya P,
4

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.

Chris Browne
la source
3

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.

Jerry Coffin
la source
3
  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.

Nuit noire
la source
3

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.

Arseni Mourzenko
la source
C'est plus comme si vous posiez cette question, vous courez le risque de ressembler à quelqu'un qui ne sait pas écrire un bon code.
Aditya P
@AdityaGameProgrammer: Il y a une différence à faire entre un buggy, un code laid et un bon code qui, après un an ou moins, peut être écrit de manière plus élégante. (1.) Personne ne peut écrire un code parfait qui restera parfait pour toujours, nous devons donc admettre que notre code peut être amélioré au fil du temps. (2.) Nous acquérons de l'expérience et des connaissances au fil du temps, ce qui est également une source d'amélioration de l'ancien code.
Arseni Mourzenko
1

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.

JB King
la source
1

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.

Steven Evers
la source
lavage blanc = re-facteur? faites-vous référence à un code de projet ou à votre base de code personnelle.
Aditya P
1
@AdityaGameProgrammer: White wash = jetez tout et réécrivez-le depuis le début. Je parle de mon code personnel.
Steven Evers