Conseils sur le patron persuader que la révision du code est une bonne chose [fermé]

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/15874

Question

dire une des œuvres Let dans une entreprise hypothétique qui a plusieurs développeurs qui travaillent rarement ensemble sur des projets et le patron ne croyait pas que les revues de code valent le temps et le coût.

Quels sont différents arguments qui pourraient être présentés dans ce scénario qui décrira les avantages de la révision du code? Par ailleurs, quels sont les arguments potentiels contre la révision du code ici et comment peuvent-ils être contrés?

Était-ce utile?

La solution

Si vous devez vous justifier une telle substance de base, vous avez un problème plus grave.

Vous êtes l'expert, votre équipe doit décider quelles sont les pratiques que vous utilisez. Peut-être vous devriez commencer à convaincre votre patron de ce principe très important.

Votre patron est censé décider QUOI pour faire et surtout POURQUOI le faire. Vous devez prendre soin de Comment construire

(cela ne signifie pas que vous ne pouvez pas suggérer quoi et pourquoi faire des choses dans votre entreprise bien sûr). Un grand patron devrait encourager ses employés à participer à la stratégie d'entreprise)

Mais voici comment je vois les examens de code pairs:

Parce que la programmation est un travail intellectuel très intense, une personne ne peut pas assurer que tout est parfait. Par conséquent, la révision du code assurez-vous que:

  • des vulnérabilités ou des bugs sont détectés avant l'application est livré
  • l'éducation mutuelle constante entre les développeurs (presque gratuitement) est atteint
  • standard respect du code pour faciliter la maintenance de l'application
    • code
  • correspond aux exigences

Tout le monde prend des avantages directs de celui-ci:

  • le développeur qui augmente son / ses connaissances et peut transmettre son propre à sa / ses coéquipières
  • le client / utilisateur qui a moins de bugs et dépenser moins dans l'entretien
  • le patron qui a plus heureux clients / utilisateurs et dépensent moins dans les formations

Autres conseils

Revue de code peut obtenir plusieurs développeurs familiers avec la même code. C'est une bonne chose. Que faire si l'auteur original décide de quitter ou pire, quelque chose de mal qui lui arrive. Si les examens de code sont faites régulièrement, d'autres peuvent prendre plus rapidement.

pairs peut-être en mesure de repérer les éventuels bugs ou problèmes de performance lors de l'examen du code. Cela réduit les efforts d'AQ et de développement. Cela peut compenser le surcoût impliqué dans des revues de code.

Commentaires code promouvoir le partage des connaissances. Les pairs peuvent dire de meilleures façons ou d'autres moyens de faire des choses. Je me suis beaucoup appris de mes pairs par le biais des revues de code.

Code de l'aide de commentaires renforcez les directives de codage suivies par l'équipe. Si l'équipe n'a pas, qui doit être rectifié. Code est destiné à être écrit une fois et lu plusieurs fois. directives de codage sont un pas vers un code lisible. Code est destiné à être lisible par les pairs. Quoi de mieux que d'avoir des revues de code pour assurer la lisibilité?

Beaucoup de grandes réponses ici. Certaines choses que je voudrais ajouter:

Lorsque vous devez expliquer le code à quelqu'un d'autre, souvent au cours de l'explication du développeur peut réaliser tout à coup, il a un bug. Je l'ai vu arriver encore et encore que le dev arrête mort dans ses pistes et dit « oh, attendez que ne va pas » avant l'examinateur a compris la chose assez pour voir le bogue.

Connaître votre code sera inspecté par quelqu'un d'autre vous donne plus d'incitation à utiliser les normes de codage (facilitant l'entretien) ou de l'utilisation des méthodes moins « cow-boy » que personne ne vous sauf (et parfois même pas vous-même) ne comprendra jamais. Vous ne voulez pas être gêné lorsque vous montrez votre code à quelqu'un d'autre, vous faire un meilleur travail sur elle en premier lieu. En raison du facteur d'embarras, il laisse moins du code commenté avec: « Je ne sais pas pourquoi cela fonctionne, mais ne plaisante pas avec elle. » dans la base de code.

Les développeurs qui ont la nécessité d'une surveillance ou une formation plus poussée sont facilement identifiables. Ainsi sont les incompétents pur et simple. Le plus tôt vous pouvez trouver et à résoudre les problèmes les performances, mieux l'équipe dans son ensemble et plus la qualité de l'application sera. Il est bon de trouver cette information avant de prendre le petit nouveau qui a besoin de formation et de l'affecter au plus dur, plus une partie critique de votre application.

Parfois, il est juste une question de corriger une perception erronée qui sauvera la même erreur dans un tas d'autres endroits. Par exemple, nous avons examiné récemment une SQL pour les rapports complexes et avons constaté que plusieurs de nos nouveaux développeurs avaient le même malentendu où trouver une pièce spécifique de l'information dans la base de données (certes l'endroit où ils cueillies semblait logique qui est un problème de conception de base de données, nous également besoin de fixer) qui serait critique à écrire correctement tous les rapports. En trouvant le problème et le corriger dans les premiers rapports qu'ils ont écrit, il a sauvé la même erreur de se produire dans le reste des rapports. Et quelque chose le plus (dans le temps de travail ici non pas l'âge) devs étaient tellement habitués à ce qu'ils ne pensaient pas qu'il avait besoin expliquant est sorti. Elle a également nous a fait comprendre qu'il y avait d'autres choses dont nous avions besoin probablement pour vous assurer que les développeurs les plus récents ont été mis à la vitesse sur.

Juniors peut apprendre du code plus sophistiqué écrit par les aînés (qui ont tendance à mieux comprendre les cas de piégeage d'erreur et de bord par exemple) et les personnes âgées peuvent apprendre des nouvelles techniques utilisées par les juniors qui n'ont pas été exposés encore.

Parfois, les gens qui travaillent sur différentes parties mais connexes du realize d'application qu'ils vont dans deux directions différentes et mutuellement exclusives. Ooops, plus facile de fixer maintenant.

Il est pas si facile de se faufiler dans les valeurs codées en dur qui vont changer au fil du temps juste pour obtenir la chose au travail maintenant. Cela empêche beaucoup de bugs futurs tels que les choses qui changent au début de chaque exercice.

Je l'ai parfois été coincé sur la façon de faire quelque chose et appris une nouvelle technique qui vient d'être ce que je voulais à partir du code examen quelqu'un stuff autre.

Si vous connaissez la façon dont les autres membres de votre équipe pensent (qui revue de code vous aidera à donner que la compréhension), alors il sera plus facile de résoudre les problèmes plus tard parce que vous allez commencer par une compréhension de la façon dont Joe aurait approché ce genre de problème.

ainsi que le partage des connaissances mentionnées par les autres, trouver des exemples de bugs qui auraient été trouvés lors d'une révision du code et de mesurer combien de temps ils ont pris pour fixer - ce qui inclut le temps consacré à la recherche du problème et de libérer la version patchée comme ainsi que le temps réel corriger le bogue.

Prenez ce coût, ce qui sera probablement au moins deux ou trois jours d'effort et le contraste au moment où vous auriez passé un examen de code et d'agir sur les résultats.

Cela montrera votre patron que les examens de code valent la dépense.

Examens du code Can:

  • conduire à l'élaboration d'une bibliothèque de code qui peut être partagé
  • Fournir une convention de nommage uniforme pour les variables, constantants, tables de base de données
  • Aide processus de Streamline
  • peut aussi conduire à une révision du processus de découverte et les exigences de collecte
  • conduire au développement de widgets que nous pouvons vendre comme addons aux applications. ( Construire une fois payé chaque fois que nous implémentons )
  • création de nouveaux produits

Contre

  • Nous n'avons pas le temps

Si c'est vrai, alors comment se fait-il semble toujours avoir le temps de faire les choses deux ou trois fois pour le même client, mais nous avons jamais assez de temps pour le faire dès la première fois.

Si vous avez besoin de faire référence à un document alors je ne cherchez pas plus loin que la prestigieuse « code complet. » Dans ce document, le livre décrit combien d'erreurs sont pris avec les tests unitaires vs examen par les pairs. Il est étonnant. Les tests unitaires, si ma mémoire est bonne, prise seulement ~ 30% de tous les bugs alors que les examens officiels par les pairs attrapent ~ 70%.

Prenez cette information, lui montrer dans le livre et faire appel à son côté financier. Il faut beaucoup plus longtemps et est beaucoup plus cher pour permettre à des insectes à travers que de les attraper tôt.

Que diriez-vous d'une démo en cours d'exécution (une semaine de projet de type « mickey ») exécuté en parallèle par deux équipes, l'une en utilisant la revue de code, l'autre non.

A la fin de la semaine, d'évaluer la qualité du travail de chaque équipe, je suis tout à fait sûr que les examinateurs de code se détacheront en mieux.

Lors de sa présentation, l'accent sur la grande image.

Liste des avantages (meilleur code, moins de bugs, moins réécritures, etc.) et la révision du code de mention comme un des techniques que vous recommanderiez.

Je faire partie d'une image plus grande de faire de l'artisanat logiciel

  • revues de code
  • Tests
  • retrospectives
  • le partage des connaissances
  • l'éducation
  • Livres
  • midi conférences

Préparez-vous à faire beaucoup de travail vous-même dans la promotion de ces principes.
La plupart de tous ne vous attendez pas à la persuasion pour être une « une réunion et fait » un peu chose.
Vous devez construire le cas au fil du temps avec le calme et de manière cohérente. Lorsque vous êtes le plus ennuyé par des insectes qui auraient été fixés par de meilleures techniques, est souvent le pire moment pour faire votre cas que vous êtes plus susceptibles d'être trop émotionnel et moins rationnel. Cela peut sembler un peu contre-intuitiuve mais il est ce que je l'ai appris plus de 30 ans de programmation. De toute évidence YMMV.

scroll top