L'une des professions les plus idiotes est celle des managers qui gèrent les programmeurs. Pas tous, mais ceux qui n’étaient pas eux-mêmes programmeurs. Ceux qui pensent qu’il est possible « d’augmenter » l’efficacité (ou d’augmenter « l’efficacité » ?) en utilisant les méthodes tirées des livres. Sans même prendre la peine de lire ces mêmes livres, la vidéo est gitane.
Ceux qui n’ont jamais écrit de code. Ceux pour qui les films hollywoodiens sur les programmeurs sont faits - enfin, ceux pour qui ils regardent leurs e-mails en utilisant la ligne de commande. Ceux qui ne s'intéressent à rien d'autre que des indicateurs, des délais et leur propre salaire.
Ceux qui sont majoritaires.
Mais ils sont idiots pour une autre raison. Ils veulent de l'efficacité, ou du moins de l'efficacité (allez, manager, Google quelle est la différence), sans comprendre ni l'un ni l'autre. Sans comprendre généralement l'essence, le processus d'obtention du résultat, les pertes qui surviennent dans ce processus, les coûts de développement. Bref, travailler avec un programmeur comme s'il était une boîte noire.
Ils se sont heurtés à la direction des programmeurs pour exactement une raison : il y a le battage médiatique, l'argent, le marché et une bande des mêmes idiots. Il y a un endroit pour se perdre.
S'il y avait un battage médiatique dans la production d'assemblages mécaniques, nous y courrions. Les breaks sont nuls. Je ne serais pas surpris que le vendeur de sapins de Noël dans notre quartier en décembre soit un responsable informatique en vacances.
Bref, si possible, tirez sur ces gars dans le cou. Ne vous inquiétez pas, ils trouveront un emploi. Aucun d’entre eux ne fera jamais quelque chose de décent tant qu’il ne deviendra pas lui-même programmeur. Parce qu'il ne comprend pas l'essence, le mécanisme, la logique du processus qu'il contrôle.
Bon, assez parlé des managers. Passons maintenant au point, pour les programmeurs. Comment augmenter l'efficacité du développement en apprenant à écrire du code de haute qualité.
Pour augmenter l’efficacité, vous devez résoudre les problèmes plus rapidement sans perdre en qualité. Pour résoudre les problèmes plus rapidement, vous devez être capable d’écrire immédiatement du code de haute qualité. Et « de haute qualité », et « écrire » et « immédiatement ». Laissez-moi vous expliquer avec une métaphore.
Écrire du code de haute qualité, c’est comme parler correctement une langue étrangère. Quand on ne connaît pas une langue, on passe beaucoup de temps à essayer d’y formuler ses pensées.
Si vous avez un besoin urgent de dire quelque chose, vous vous contentez de quelques mots, souvent pas les bons, vous oubliez les articles, l'ordre correct des mots, sans parler des temps verbaux et d'une mauvaise prononciation.
Si vous avez le temps de formuler une réponse, vous devrez ouvrir un dictionnaire ou un traducteur en ligne et passer beaucoup de temps à formuler vos pensées. Cependant, le sentiment sera toujours désagréable : vous dites la réponse et vous ne savez pas si elle est correcte ou non. C’est la même chose avec le code – il semble avoir été écrit, il semble fonctionner, mais savoir s’il est de bonne qualité ou non est un mystère.
Cela s’avère être une double perte de temps. Il faut du temps pour trouver une réponse. Il faut également du temps pour formuler cette réponse – et pas si peu.
Si la capacité d'écrire du code de haute qualité est présente, la réponse peut être formulée immédiatement, dès qu'elle a mûri dans la tête, sans consacrer de temps supplémentaire à la traduction.
La capacité d'écrire du code de haute qualité est utile lors de la conception de l'architecture. Vous n’envisagerez tout simplement pas d’options incorrectes, irréalisables ou de mauvaise qualité dans votre tête.
Pour résumer : la capacité d’écrire du code de haute qualité accélère considérablement la résolution de problèmes.
Mais ce n'est pas tout. Grâce aux gestionnaires de bottes en feutre, il y a un problème : nous n'avons aucune raison d'écrire du code de haute qualité. Le manager ne regarde pas le code, le client ne regarde pas le code. Nous nous montrons rarement le code, seulement parfois, dans certains projets où il existe un « vérificateur » de code désigné ou une refactorisation périodique.
Il s'avère que dans la plupart des cas, le code merdique va à la production ou au client. Une personne qui a écrit du code merdique forme une connexion neuronale stable - il est non seulement possible d'écrire du code merdique, mais c'est aussi nécessaire - c'est accepté, et ils paient même pour cela.
En conséquence, la capacité d’écrire du code de haute qualité n’a aucune chance de se développer. Le code écrit par un employé conditionnel n'est jamais vérifié par personne. La seule raison pour laquelle il apprendra à programmer normalement est la motivation interne.
Mais cette motivation interne entre en conflit avec les plans et les exigences d’efficacité et de productivité. Cette contradiction n’est clairement pas résolue en faveur d’un code de haute qualité, car les gens ne critiquent même pas les gens pour leur code merdique. Et pour l'échec de la réalisation du plan - quand même.
Que dois-je faire? Je vois et propose deux chemins qui peuvent se combiner.
La première consiste à montrer votre code à une personne au sein de l’entreprise. Pas de manière réactive (lorsque demandé/forcé), mais de manière proactive (euh, mec, regarde mon code, s'il te plaît). L'essentiel ici est de ne pas publier de morve sucrée, de ne pas essayer de critiquer le code sous une forme polie. Si le code est de la merde, nous le disons : le code est de la merde. Avec des explications, bien sûr, et des recommandations pour l'améliorer.
Mais ce chemin est également médiocre. Son applicabilité dépend du point où le contact a eu lieu. Si le travail est déjà entré en production et qu'il s'avère que le code est de la merde, cela n'a aucun sens de le refaire. Plus précisément, les raisons - les mesures s'affaisseront également. Les managers se précipiteront et vous écraseront avec leurs exigences d’efficacité. Et n'essayez même pas de leur expliquer que le code merdique reviendra certainement sous forme de bugs - cela se retournera contre vous. Vous ne pouvez que vous engager à ne plus recommencer.
Si le travail n'a pas encore été livré ou vient de commencer, alors verser de la merde sur le code (ou son projet, son idée) peut avoir une signification assez pratique - la personne le fera normalement.
La deuxième façon, la plus intéressante, consiste à réaliser du développement open source en dehors des heures de travail. Quel est le but : qu'un groupe de programmeurs, à savoir des programmeurs, voient votre code et en parlent. Tout le monde au sein de l’entreprise n’a pas le temps. Mais les programmeurs du monde entier n'ont toujours rien à faire, et si vous écrivez quelque chose d'utile du point de vue de l'application, ils regarderont certainement à l'intérieur.
L'astuce principale, à mon avis, est d'écrire du code en dehors des heures de travail, car la contradiction entre la qualité du code et la rapidité de livraison du résultat ne fonctionnera pas. Écrivez votre développement pendant au moins un an. Ni les délais, ni les spécifications techniques, ni l'argent, ni le patron ne vous mettront la pression. Liberté et créativité totales.
Ce n'est que dans la créativité libre que vous comprendrez et ressentirez ce qu'est un bon code, que vous verrez la beauté du langage et de la technologie et que vous ressentirez le charme des tâches commerciales. Eh bien, vous apprendrez à écrire du code de haute qualité.
Certes, cela vous demandera de consacrer du temps personnel. Comme tout autre développement. Considérez cela non pas comme un coût, mais comme un investissement – en vous-même.
Source: habr.com