L'un des idiots surchargés est les gestionnaires qui gèrent les programmeurs. Pas tous, mais ceux qui n'étaient pas programmeurs eux-mêmes. Ceux qui pensent qu'il est possible "d'augmenter" l'efficacité (ou d'augmenter "l'efficacité"?) Par des méthodes issues des livres. Sans même prendre la peine de lire ces mêmes livres - Vidosik est, après tout, un gitan.
Ceux qui n'ont jamais écrit de code. Ceux pour qui des films hollywoodiens sur les programmeurs sont faits - enfin, ceux où ils regardent les e-mails en ligne de commande. Ceux qui ne sont intéressés par rien d'autre que les indicateurs, les conditions et leur propre salaire.
Celles qui sont les plus.
Mais ce sont des idiots pour une autre raison. Ils veulent de l'efficacité, ou du moins de la productivité (allez, manager, google, quelle est la différence), ne comprenant ni l'un ni l'autre. Généralement ne comprenant pas l'essence, le processus d'obtention du résultat, les pertes survenues dans ce processus, les coûts de développement. Bref, travailler avec un programmeur comme avec une boîte noire.
Ils se sont heurtés à la gestion de programmeurs pour exactement une raison: ici, il y a le battage médiatique, l'argent, le marché et un tas de mêmes idiots. Il y a où se perdre.
S'il y avait un battage médiatique dans l'industrie de l'assemblage mécanique, nous y courrions. Les break sont mauvais. Je ne serai pas surpris que le mec qui vend des arbres de Noël dans notre quartier en décembre soit un responsable informatique en vacances.
Bref, si possible, poursuivez ces gars dans le cou. Ne vous inquiétez pas, ils trouveront un emploi. Aucun d'eux ne fera rien de décent jusqu'à ce qu'il devienne programmeur. Parce qu'il ne comprend pas l'essence, le mécanisme, la logique du processus qu'il contrôle.
Eh bien, ça suffit sur les gestionnaires. Maintenant, pour les programmeurs. Comment augmenter l'efficacité du développement en apprenant à écrire du code de haute qualité.
Pour augmenter l'efficacité, il est nécessaire de résoudre rapidement les problèmes sans perte de qualité. Pour résoudre les problèmes plus rapidement, vous devez être en mesure d'écrire immédiatement du code de haute qualité. Et «qualité», et «écrire», et «tout de suite». Je vais expliquer avec une métaphore.
Écrire un code de qualité, c'est comme parler avec compétence dans une langue étrangère. Lorsque vous ne connaissez pas la langue, vous passez beaucoup de temps à formuler vos réflexions à ce sujet.
Si vous devez le dire de toute urgence, vous n'avez qu'à coller quelques mots, souvent pas ceux dont vous avez besoin, oubliez les articles, l'ordre correct des mots, sans parler des temps des verbes et de la mauvaise prononciation.
S'il reste du temps pour la formulation de la réponse, vous devrez ouvrir un dictionnaire ou un traducteur Internet et consacrer beaucoup de temps à la formulation de vos réflexions. Le sentiment, cependant, sera toujours désagréable: vous dites la réponse, et vous ne savez pas si elle est correcte ou non. De même avec le code - il semble avoir écrit, il semble fonctionner, mais il est de qualité ou non - HZ.
Il en résulte une double perte de temps. Il faut du temps pour trouver une réponse. Il faut aussi du temps pour formuler cette réponse - d'ailleurs, pas si peu.
Si l'habileté 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 passer plus de temps sur la traduction.
La compétence d'écrire du code de qualité aide à la conception architecturale. Vous ne considérerez tout simplement pas les mauvaises options, irréalisables ou au corps à corps dans votre tête.
En résumé: la capacité d'écrire du code de haute qualité accélère considérablement la résolution des problèmes.
Mais ce n'est pas tout. Grâce à valenki-managers, il y a un problème - nous n'avons donc aucune raison d'écrire du code de haute qualité. Le gestionnaire de code ne regarde pas, le code client ne regarde pas. Nous nous montrons rarement le code, seulement occasionnellement, dans certains projets où il y a un «inspecteur de code» désigné ou une refactorisation périodique.
Il s'avère que, dans la plupart des cas, le govnokod va à la production ou au client. La personne qui a écrit le govnokod forme une connexion neurale stable - le govnokod est non seulement possible d'écrire, mais aussi nécessaire - il est accepté, et même payé pour cela.
En conséquence, l'habileté à é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 apprend à programmer normalement est la motivation intrinsèque.
Mais cette motivation intrinsèque entre en conflit avec les plans et les exigences d'efficacité et de productivité. Cette contradiction est résolue clairement pas en faveur d'un code de haute qualité, car ils ne blâment même pas le govnokod. Et pour ne pas avoir réalisé le plan - autrement.
Comment être Je vois et propose deux façons qui peuvent être combinées.
La première consiste à montrer votre code à une personne de l'entreprise. Pas de manière réactive (lorsqu'on lui a demandé / forcé), mais de manière proactive (euh, mec, regardez mon code, s'il vous plaît). L'essentiel ici n'est pas de suspendre la morve de sucre, n'essayez pas de mettre du code poli sur la critique du code. 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 sur la façon de l'améliorer.
Mais cette façon est aussi moyenne. Son applicabilité dépend du point auquel le contact s'est produit. Si le travail est déjà entré en production et qu'il s'est avéré que le code est de la merde, il n'y a aucun sens à le refaire. Plus précisément, les occasions - les mesures s'affaisseront également. Les managers vont attaquer et écraser les exigences d'efficacité. Et n'essayez même pas de leur expliquer que le govnokod reviendra certainement sous forme de bugs - il vous sortira de côté. On ne peut que s'engager à ne plus le faire.
Si le travail n'a pas encore été remis ou vient de commencer, alors verser de la merde sur le code (ou son projet, l'idée) avec de la merde peut avoir un sens assez pratique - une personne le fera normalement.
La deuxième façon, la plus cool, est de faire du développement open source après les heures. Après tout, quel est le but: pour un groupe de programmeurs, à savoir des programmeurs, de voir votre code et d'en parler. A l'intérieur de l'entreprise, personne n'a 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.
La principale caractéristique, à mon avis, est d'écrire du code après les heures, car la contradiction entre la qualité du code et la vitesse du résultat ne fonctionnera pas. Écrivez au moins un an votre développement. Ni les délais, ni les savoirs traditionnels, 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 code sympa, verrez la beauté de YaP et de la technologie, et ressentirez le charme des tâches commerciales. Eh bien, vous apprendrez à écrire du code de haute qualité.
Certes, cela vous obligera à passer du temps personnel. Comme, en fait, tout autre développement. Considérez cela non pas comme un coût, mais comme un investissement en vous-même.