A place to cache linked articles (think custom and personal wayback machine)
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

index.md 4.9KB

4 yıl önce
12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182
  1. title: Qualité vs. productivité
  2. url: https://www.miximum.fr/blog/qualite-productivite/
  3. hash_url: 3162dca46b9057f5366599de4b83333d
  4. <p class="lead" itemprop="headline">
  5. Quelques questionnements sur la relation entre ancienneté, qualité et productivité.
  6. </p>
  7. <div itemprop="articleBody">
  8. <p>Il y a quelques temps, j'ai posté sur Twitter une boutade sous forme de
  9. diagramme.</p>
  10. <figure>
  11. <img src="https://i.miximum.fr/i/2018/04/HLI0T1AEI9.png" alt="diagrammes représentant l'évolution de la répartition de mon temps de travail avec les années."/>
  12. <figcaption>
  13. Plus les années passent, moins je code.
  14. </figcaption>
  15. </figure>
  16. <p>À la réflexion, la situation, présentée comme une blague, n'est pourtant pas si
  17. éloignée de la réalité.</p>
  18. <p>J'observe des évolutions dans la manière dont je travaille.</p>
  19. <p>J'ai commencé à coder vers le lycée. À cette époque, et pendant plusieurs
  20. années, je me lançais dans l'écriture de code avant d'avoir réfléchi. À vrai
  21. dire, l'écriture me servait de processus de réflexion, et je ne savais pas
  22. vraiment ou je voulais en venir tant que je n'avais pas terminé d'écrire ma
  23. fonction.</p>
  24. <p>Quand je rencontrais un bug, ou que mon code ne fonctionnait pas correctement,
  25. j'avais tendance à bidouiller « jusqu'à ce que ça marche », sans avoir de vraie
  26. compréhension du problème.</p>
  27. <p>« Tiens, cette partie du programme ne fonctionne pas. Et si je modifie ça ? Et
  28. là ? Et comme ça ? »</p>
  29. <p>Inutile de dire que d'un point de vue technique, le résultat obtenu n'était pas
  30. terrible.</p>
  31. <p>Avec le temps, j'ai commencé à coder <em>moins vite</em> ; à chercher à mieux
  32. comprendre la problématique avant de la résoudre.</p>
  33. <p>La pratique déterminante a été le passage au développement piloté par les tests
  34. (TDD). Écrire les tests d'une fonction avant d'écrire la fonction nécessite de
  35. sacrément bien réfléchir à <em>ce que doit faire ou ne pas faire</em> ladite fonction.</p>
  36. <p>Avec une meilleure compréhension de ce qu'est un code fiable et maintenable
  37. dans le temps, il était également inévitable de passer plus de temps à
  38. refactoriser du code existant.</p>
  39. <p>À ce moment là, je me suis aperçu que mon code était moins sujet aux bugs et
  40. comportements inattendus.</p>
  41. <p>J'ai remarqué que cette évolution a continué jusqu'à aujourd'hui. Je ne suis
  42. pas précisément en fin de carrière, mais pas sans expérience non plus.</p>
  43. <p>Maintenant, je suis tellement délicat avec mon code que je me fais l'impression
  44. d'être un vieillard tremblotant en train de choisir une tasse dans un magasin
  45. de porcelaine.</p>
  46. <p>La moindre ligne nécessite un temps infini.</p>
  47. <p>Il m'arrive parfois de passer une heure juste pour choisir un nom de variable
  48. approprié.</p>
  49. <p>Je pense et repense à tous les cas de figures possibles, les cas d'erreurs, les
  50. logs, les exceptions, la performance, l'accessibilité, les conséquences à long
  51. terme, les impacts métiers, etc.</p>
  52. <p>J'ai souvent entendu dire qu'il était rentable d'embaucher des devs seniors
  53. parce qu'ils pouvaient avoir 10x la productivité des juniors. J'y croyais. Mais
  54. chez moi, ça n'en prends pas le chemin. À vrai dire, je me sens 10x moins
  55. productifs aujourd'hui qu'avant.</p>
  56. <p>J'ai parfois une légère tendance à succomber à la suringénieurisation.</p>
  57. <p><em>Je ne dis pas que c'est une bonne chose.</em></p>
  58. <p>Si je fais le point, je trouve que mon travail d'aujourd'hui est <em>vraiment</em>
  59. beaucoup plus robuste qu'il y a dix ans. Le code sans bug n'existe pas, mais je
  60. suis beaucoup moins souvent confronté à des comportements indésirables ou
  61. inattendus qu'auparavant. Étonnamment, une fois le code écrit, je ne
  62. refactorise plus tant que ça (en tout cas, moins qu'à une époque).</p>
  63. <p>En contrepartie, je suis effaré par mon manque de productivité. Quand je
  64. travaille pour des clients, je m'étonne parfois de ne pas être pris pour un
  65. arnaqueur, tant il m'arrive de passer une journée à corriger un seul bug, à
  66. réaliser une seule petite fonctionnalité.</p>
  67. <p>Je suis bien convaincu que cette façon de faire a une certaine valeur, mais
  68. <em>j'ai l'impression d'être allé trop loin.</em> Le déséquilibre qualité /
  69. productivité est trop important (le terme <em>qualité</em> étant à comprendre comme un
  70. terme technique, je ne m'envoie pas des fleurs).</p>
  71. <p>Après tout, si d'un point de vue <em>purement technique</em>, il est impossible de
  72. faire de la sur-qualité, un projet, c'est aussi des contraintes temporelles,
  73. stratégiques, commerciales, économiques, etc.</p>
  74. <p>Faut-il revenir à une écriture de code un peu moins <em>pesante</em>, quitte à
  75. refactoriser plus et plus souvent ?</p>
  76. <p>Il est assez facile de reconnaître sa progression, mais plus difficile de
  77. déterminer quelle est la prochaine étape. Comment ma façon de travailler
  78. va-t-elle évoluer ? Qu'est-ce qui me ferait passer à l'étape d'après ? Je me
  79. pose sincèrement la question. Comment ça se passe chez vous ?</p>
  80. </div>