Normes de codage Python vs productivité

Je travaille pour une grande organisation humanitaire, sur un logiciel de construction de projet qui pourrait aider à sauver des vies dans les situations d'urgence en accélérant la distribution de nourriture. De nombreuses ONG ont désespérément besoin de nos logiciels et nous accusons un retard de plusieurs semaines.

Une chose qui m'inquiète dans ce projet est ce que je pense être une concentration excessive sur les normes de codage. Nous écrivons en python / django et utilisons une version de PEP0008, avec diverses modifications, par exemple, la longueur des lignes peut aller jusqu'à 160 caractères et toutes les lignes doivent aller aussi longtemps que possible, pas de lignes vides entre les importations, des règles d'habillage de ligne qui s'appliquent uniquement à certains types de classes, beaucoup de modèles que nous devons utiliser, même s'ils ne sont pas le meilleur moyen de résoudre un problème, etc. etc.

Un développeur principal a passé une semaine à réécrire une grande partie du système pour répondre aux normes de codage alors nouvelles, jetant plusieurs suites de tests dans le processus, car la réécriture signifiait qu'ils étaient «invalides». Nous avons passé deux semaines à réécrire toutes les fonctionnalités perdues et à corriger les bogues. Il est le principal développeur et sa parole a du poids, il a donc convaincu le chef de projet que ces normes sont nécessaires. Les développeurs juniors font ce qu'on leur dit. Je sens que le chef de projet a un fort sentiment de dissonance cognitive à propos de tout cela, mais il est néanmoins d'accord avec véhémence car il ne sait pas quoi faire d'autre.

Aujourd'hui, j'ai eu de sérieux problèmes parce que j'avais oublié de mettre des espaces après des virgules dans un argument de mot clé. J'ai été littéralement crié par deux autres développeurs et le chef de projet lors d'un appel Skype. Personnellement, je pense que les normes de codage sont importantes, mais je pense aussi que nous perdons beaucoup de temps à les obséder, et quand j'ai exprimé cela, cela a provoqué la rage. Je suis considéré comme un fauteur de troubles dans l'équipe, une équipe qui cherche des boucs émissaires pour ses échecs. Depuis l'introduction des normes de codage, la productivité de l'équipe a considérablement chuté, mais cela ne fait que renforcer l'obsession, c'est-à-dire que le développeur principal blâme simplement notre non-respect des normes pour le manque de progrès. Il pense que nous ne pouvons pas lire le code de l'autre si nous ne respectons pas les conventions.

Cela commence à devenir collant. Maintenant, j'essaie de modifier divers scripts, autopep8, pep8ify et PythonTidy pour essayer de faire correspondre les conventions. Nous exécutons également pep8 contre le code source, mais il y a tellement d'amendements implicites à notre norme qu'il est difficile de tous les suivre. Le développeur principal choisit simplement les défauts que le script pep8 ne détecte pas et nous crie lors de la prochaine réunion debout. Chaque semaine, de nouveaux ajouts aux normes de codage nous obligent à réécrire le code existant, fonctionnel et testé. Dieu merci, nous avons encore des tests (j'ai annulé certains commits et corrigé un tas de ceux qu'il a supprimés).

Pendant ce temps, il y a une pression croissante pour respecter le délai.

Je crois qu'un problème fondamental est que le développeur principal et un autre développeur principal refusent de faire confiance à d'autres développeurs pour faire leur travail. Mais comment y faire face? Nous ne pouvons pas faire notre travail parce que nous sommes trop occupés à tout réécrire.

Je n'ai jamais rencontré cette dynamique dans une équipe de génie logiciel. Ai-je tort de remettre en question leur adhésion aux normes de codage? Quelqu'un d'autre a-t-il connu une situation similaire et comment s'en est-il sorti avec succès? (Je ne cherche pas une discussion juste des solutions réelles que les gens ont trouvées)

Les normes de codage ne sont pas le problème. Le problème est que la direction ne peut pas déterminer quel est le problème. Cela conduit à "Faites quelque chose… n'importe quoi!" mode. Vous cherchez une solution rationnelle, mais c'est un problème irrationnel. Le mieux que vous puissiez faire est de:

• Faites des critiques constructives de leurs idées, mais une fois la décision prise, ne vous plaignez pas continuellement.
• Faites tout ce que vous pouvez pour faciliter les réécritures.
• Arrêtez de stresser. Les délais manqués sont le problème de la direction, pas le vôtre. Faites de votre mieux, mais n'assumez pas la responsabilité de leurs mauvaises décisions.
• Si vous savez quelque chose qui pourrait vous aider, dites-le-leur. Votre mention de standups donne l'impression que vous essayez de faire de l'agile, mais le reste ne semble pas très agile. Voyez si vous pouvez fournir des fonctionnalités limitées plus tôt au lieu d'essayer de respecter un gros délai avec tout. Créez des user stories pour les réécritures afin de savoir clairement comment elles impactent le backlog.
• Commencez à chercher un autre emploi. Sérieusement. Les entreprises dans un tel état ne sont pas loin de commencer à licencier.
• Faites imprimer des T-shirts "Je vous l'ai dit" :-)

Quelqu'un doit décider si l'expédition ou l'adhésion servile aux normes de codage est la vraie priorité. Je sais quelle serait ma préférence; s'il passe des tests unitaires et d'acceptation, je dis bateau. Une fois expédiée, l'entreprise peut décider de dépenser ou non le temps et l'argent pour régler la dette technique.

Les problèmes d'espaces après des virgules sont facilement résolus avec un outil de prettification de code. Trouvez un outil qui applique toutes vos conventions de codage et exécutez cet outil sur tout le code modifié avant la génération et les tests. Des IDE décents le font déjà pendant que vous écrivez le code.

Ai-je tort de remettre en question leur adhésion aux normes de codage?

Cela dépend du groupe. Personnellement , je pense que tout doit être remis en question. Certains considèrent ce questionnement comme un affront; que je ne leur fais pas confiance.

Quelqu'un d'autre a-t-il connu une situation similaire et comment s'en est-il sorti avec succès?

J'ai demandé comment ces normes améliorent la productivité. J'ai mesuré le temps que j'ai passé à fouiner avec les normes par rapport à «faire avancer les choses». En fin de compte, les pouvoirs qui seront décidés de s'en tenir aux normes. Ça arrive. Je me plaignais d'eux plus fort que d'habitude quand ils étaient la cause pour moi de ne pas faire les choses, mais sinon je me concentrais pour faire mon travail. Se battre continuellement n'est pas non plus bon pour la productivité ...

Si, comme vous le dites, les choses sont nettement pires en raison des normes, alors le respect des normes devrait invalider l'argument du lead et laisser le vôtre. Si les gens ne peuvent pas voir cette corrélation (largement) objective entre la mise en œuvre de la norme et la baisse de productivité, il n'y a pas grand-chose d'autre à faire. Apprenez à y faire face et si vous ne le pouvez pas, cherchez un endroit moins bureaucratique.

Les normes ne devraient pas être mises en place tard dans le projet avec une échéance imminente. C'est quelque chose qui aurait dû être mis en place au début du projet ou quand il y a du temps mis de côté dans le calendrier du projet (de préférence après l'expédition initiale) pour le refactoriseur de code potentiellement incriminé.

Si cela a été fait en fin de projet, c'est une erreur de votre chef (IMHO).

Cependant , cela ne signifie pas que si vous n'êtes pas d'accord avec votre piste, vous devez simplement vous lancer dans la mutinerie. C'est ton boulot . Vous travaillez en équipe . Vous avez une piste . Il devrait certainement y avoir un certain niveau de démocratie dans l'équipe, mais à la fin, le chef est le dictateur. S'il dit de faire quelque chose, vous le faites.

En fin de compte, en se conformant à ses demandes et normes, vous ne lui fournissez pas un bouc émissaire facile pour les délais manquants.

De plus, je suis un ardent défenseur des normes de codage (surtout à mesure que la taille d'une équipe augmente), mais elles doivent être mises en œuvre quand cela a du sens.

Votre question était «ai-je tort de remettre en question leur adhésion aux normes de codage?». http://c0x.coding-guidelines.com/Introduction.pdf (pour le langage de programmation C) contient des études référencées sur la valeur des directives de codage. Voir section 9 à partir de la page 39.

Les normes de codage sont mises en œuvre pour une raison. Une chose qui semble manquer dans la question initiale est la compréhension de la raison de ces normes particulières sur le projet particulier (ou dans l'organisation particulière). La décision de les implémenter sur le code existant était basée sur une logique. Sans connaître la logique, il est difficile de commenter la «bonté» de cette décision.

J'appuie ce que quelqu'un a dit que les normes sont mises en œuvre pour la «productivité à long terme» - des questions telles que la maintenabilité du code. Peut-être qu'un événement s'est produit qui a sérieusement retardé le projet en raison de la confusion et d'une mauvaise interprétation.

Il semble qu'il y ait beaucoup d'émotion des deux côtés - essayez d'obtenir une discussion raisonnée.

Comme vous l'avez probablement vu par les autres réponses et commentaires, votre projet a de gros problèmes, donc ce que je vais suggérer n'a pas de grandes chances de succès, mais c'est quelque chose que vous pouvez essayer sans trop de risque en ce qui concerne votre propre peau.

Demandez une rencontre entre quatre yeux avec votre développeur principal. Dites que vous êtes intéressé à bien comprendre les avantages d'être si strict avec la norme de codage et pourquoi la base de code était en si mauvais état avant de les introduire. Il est très important que vous gardiez une attitude très ouverte et "j'essaie d'apprendre" pendant cette discussion. Votre développeur principal est probablement déjà plus stressé que vous ou tout autre membre de votre équipe, et sera probablement très défensif dès qu'il sentira la critique.

Essayez de pousser la discussion dans le sens d'essayer de trouver des moyens d'atteindre votre objectif commun; fournir rapidement des logiciels fonctionnels et maintenables.

Par exemple, certains fruits à faible pendaison n'ajoutent rien de plus aux directives de codage. Chaque fois que cela se produit, le code qui respectait auparavant les directives ne le fait plus, ce qui signifie que vous devez réécrire des morceaux de code. J'espère que votre développeur principal peut voir que même si la règle ajoutée ajoute de la valeur (de son point de vue), cela pourrait ne pas faire autant de bien que motiver la réécriture à cette phase du projet déjà en retard.

Si cela fonctionne, vous pouvez essayer de lui faire supprimer les règles les plus arbitraires qui ne peuvent pas être mises en forme automatiquement avec un outil.

Les normes de codage sont bonnes. Changer les normes de codage coûte cher (enfin, c'est cher si vous les rendez moins permissifs; si un changement à la norme laisse tout le code existant toujours conforme, ce n'est pas un problème), cela ne devrait donc être fait qu'en cas de nécessité absolue.

Une chose à faire, peut-être, est de demander au responsable de vérifier tout le code avant de valider / fusionner / quoi que ce soit pour s'assurer qu'il est conforme à la norme, car apparemment la chaîne d'outils existante semble incapable de le vérifier automatiquement.

logiciel qui pourrait aider à sauver des vies en cas d'urgence en accélérant la distribution de nourriture

Je crois en de bonnes normes de codage, mais je crois aussi que sauver des vies est beaucoup plus important.

Votre plus grande priorité doit être de sauver la vie des gens . Imaginez si ce logiciel distribue de la nourriture à votre famille ou à votre équipe. Tout le reste peut venir ensuite.

La bonne nouvelle: vous avez des tests. Les tests vous aideront à respecter vos normes de codage sans casser les fonctionnalités, mais cela devrait se produire après l'expédition , pas avant.