L'une des professions les plus envahies par des idiots est celle des managers qui gèrent des programmeurs. Pas tous, mais ceux qui n'ont jamais été programmeurs eux-mêmes. Ceux qui pensent qu'on peut "augmenter" l'efficacité (ou "améliorer l'efficacité" ?) avec des méthodes provenant de livres. Sans même se donner la peine de lire ces livres — il y a des vidéos, après tout.
Ceux qui n'ont jamais écrit de code. Ceux pour qui on tourne des films hollywoodiens sur des programmeurs — vous savez, ceux où l'on consulte des emails via la ligne de commande. Ceux qui ne s'intéressent à rien d'autre qu'aux indicateurs, aux délais et à leur propre salaire.
Ceux-là sont la majorité.
Mais ils sont idiots pour une autre raison. Ils veulent de l'efficacité, ou au moins de la productivité (allez, manager, cherche sur Google quelle est la différence), sans comprendre ni l'un ni l'autre. Sans comprendre le fond, le processus d'obtention du résultat, les pertes qui se produisent dans ce processus, les coûts de développement. En gros, travaillant avec un programmeur comme avec une boîte noire.
Ils se sont précipités pour gérer des programmeurs pour une seule raison : il y a du buzz, de l'argent, le marché et une foule d'autres idiots. Il y a de quoi se fondre dans la masse.
S'il y avait du buzz dans la production mécanique, ils s'y seraient précipités. Universels à la noix. Je ne serais pas surpris que le gars qui vend des sapins de Noël dans notre quartier en décembre soit un manager IT en vacances.
En gros, si vous le pouvez, rendez-vous de ces gars. Ne vous inquiétez pas, ils trouveront un emploi. Aucun d'eux ne fera jamais rien de bien tant qu'ils ne deviendront pas programmeurs eux-mêmes. Parce qu'ils ne comprennent pas le fond, le mécanisme, la logique du processus qu'ils gèrent.
Bon, assez parlé des managers. Passons aux choses sérieuses, pour les programmeurs. Comment améliorer l'efficacité du développement en apprenant à écrire du code de qualité.
Pour augmenter l'efficacité, il faut résoudre les tâches plus rapidement, sans perdre en qualité. Pour résoudre les tâches plus rapidement, vous devez savoir écrire du code de qualité immédiatement. Et « qualité », et « écrire », et « immédiatement ». Je vais expliquer par une métaphore.
Écrire du code de qualité, c'est comme parler correctement une langue étrangère. Lorsque vous ne connaissez pas la langue, vous perdez un temps fou à formuler vos pensées dans celle-ci.
Lorsqu'il faut s'exprimer rapidement, il arrive souvent qu'on colle des mots, souvent les mauvais, oubliant les articles, l'ordre correct des mots, sans parler des temps des verbes et de la prononciation déplorable.
S'il y a du temps pour formuler une réponse, il faut ouvrir un dictionnaire ou un traducteur en ligne, et passer beaucoup de temps à formuler ses idées. On ressentira malgré tout un malaise : on donne une réponse sans savoir si elle est correcte ou non. C'est la même chose avec le code – on a l'impression d'avoir écrit quelque chose qui fonctionne, mais sa qualité est incertaine.
On finit par perdre du temps des deux côtés. Réfléchir à une réponse prend du temps. Formuler cette réponse demande également du temps – et pas si peu que ça.
Si l'on a la compétence d'écrire un code de qualité, on peut formuler la réponse dès qu'elle germe dans notre esprit, sans perdre de temps supplémentaire à traduire.
La compétence d'écrire un code de qualité aide aussi dans la conception de l'architecture. On ne va pas envisager dans notre esprit des options incorrectes, irréalisables ou mal faites.
En résumé : la compétence d'écrire un code de qualité accélère considérablement la résolution des problèmes.
Mais ce n'est pas tout. Grâce aux managers incompétents, il y a une difficulté – en fait, nous n'avons pas de raison d'écrire un code de qualité. Le manager ne vérifie pas le code, le client ne le fait pas non plus. Nous montrons notre code l'un à l'autre rarement, juste parfois dans certains projets où il y a un « vérificateur » de code désigné ou un refactoring périodique.
Ainsi, dans la plupart des cas, du code de mauvaise qualité finit en production ou chez le client. La personne ayant écrit ce code négligé développe une connexion neuronale durable – on peut et doit écrire du code de mauvaise qualité – il est accepté, et on est même payé pour cela.
En conséquence, il n'y a aucune chance que la compétence d'écrire un code de qualité se développe. Le code écrit par un employé hypothétique n'est jamais vérifié par personne. La seule raison pour laquelle il pourrait apprendre à programmer correctement est la motivation interne.
Mais cette motivation interne entre en conflit avec les plans et les exigences d'efficacité et de productivité. Ce conflit est clairement résolu en défaveur d'un code de qualité, car on ne se fait même pas gronder pour du mauvais code. En revanche, on est sérieusement réprimandé en cas de non-respect des objectifs.
Que faire ? Je vois et propose deux voies qui peuvent être combinées.
La première consiste à montrer son code à quelqu'un au sein de l'entreprise. Pas de manière réactive (quand on le demande / oblige), mais de manière proactive (hé, regarde mon code, s'il te plaît). Ici, l'essentiel est de ne pas édulcorer les critiques, de ne pas essayer de formuler les critiques de manière polie. Si le code est mauvais, on le dit clairement : le code est mauvais. Avec des explications, bien entendu, et des recommandations sur la façon de l'améliorer.
Mais cette voie a aussi ses limites. Son applicabilité dépend du moment où le contact a eu lieu. Si le travail est déjà en production et qu'il s'avère que le code est mauvais, il n'est plus utile de le retravailler. En fait, cela pourrait entraîner une chute des métriques. Les responsables vont débarquer et submerger avec des exigences d'efficacité. Et même n'essaie pas de leur expliquer que le code de mauvaise qualité se traduira forcément par des bugs — cela te reviendra en boomerang. On peut seulement s'engager à ne plus faire ça à l'avenir.
Si le travail n'est pas encore livré, ou vient tout juste de commencer, alors critiquer le code (ou le projet ou l'idée) peut avoir un sens pratique — la personne finira par bien faire.
La deuxième voie, la plus cool, est de se lancer dans le développement open source pendant son temps libre. Quel est l'objectif ? Que de nombreux programmeurs, des vrais programmeurs, voient ton code et donnent leur avis. Dans l'entreprise, tout le monde est trop occupé. Mais les programmeurs du monde entier n'ont rien à faire, et si tu écris quelque chose d'utile d'un point de vue pratique, ils iront sûrement jeter un œil.
Le principal atout, à mon sens, est l'écriture de code pendant son temps libre, car il n'y aura pas de contradiction entre la qualité du code et la rapidité des résultats. Tu peux passer un an à écrire ton développement. Personne ne te mettra la pression en termes de délais, de cahier des charges, d'argent ou de patron. Liberté totale et créativité.
C'est seulement dans la créativité libre que tu comprendras et ressentiras ce qu'est un bon code, que tu verras la beauté des langages de programmation et des technologies, que tu apprécieras les défis d'affaires. Et tu apprendras à écrire un code de qualité.
Cependant, cela exigera de toi un investissement de temps personnel. Tout comme tout autre développement. Considère cela non pas comme un coût, mais comme un investissement en toi-même.
Source : habr.com
