Comment dois-je procéder pour corriger le code d'un programmeur moins expérimenté?

19

Un peu d'histoire: je suis l'un des deux programmeurs de notre département de 10 personnes (les autres sont artistes et management). Nous faisons tous les deux le codage nécessaire pour bien faire avancer les choses et développer tous les projets à venir. Je programme depuis environ 4 ans maintenant, où c'est son premier "vrai" travail (comme il le dit). Nous travaillons généralement sur différents projets à tout moment.

Il y a quelques mois, j'ai développé un ensemble (pas du tout parfait) de classes qui devaient être utilisées pour un projet ultérieur. Une grande partie de ce projet lui a été déléguée (pour des raisons de facturation) pour concevoir et programmer une interface graphique. Depuis qu'il était nouveau, j'ai aidé un peu avec la conception et j'ai dit de demander de l'aide s'il en avait besoin avec le reste. Il a terminé l'interface il y a quelques semaines, qu'il a démontré pour montrer que cela fonctionnait, bien qu'un peu lent.

La prochaine partie de ce projet a commencé et je travaille dessus. J'ai ouvert l'interface pour commencer avec les étapes suivantes et j'ai immédiatement rencontré des problèmes (un peu lent était un peu d'euphémisme, des erreurs sur les actions courantes, etc.). J'ai regardé dans le code pour quelques problèmes et je trouve O(n^n)sur les appels qui devraient être O(n), des hypothèses de type sans vérification d'erreur (c'est en Python), des références à l'interface graphique ajoutée au code d'origine, etc.

Maintenant, je voudrais vraiment lui apprendre ce qui n'allait pas et comment y remédier, mais il est déjà passé à son prochain projet, et c'était il y a quelques semaines. J'ai peur de me dire "Retourne et fais-le bien!" (avec l'aide bien sûr) est trop sévère, et nous avons encore d'autres projets à réaliser dans l'intervalle. Dois-je simplement corriger le code moi-même pour l'instant et essayer d'attraper les choses à l'avenir?

code-reviews bug

— TorelTwiddler
source

4

À l'avenir, y a-t-il une possibilité de s'entendre sur des directives de codage, qui empêcheraient des erreurs comme vous l'avez décrit?

— Benni

5

C'est une bonne chose que vous ne couriez pas immédiatement vers la direction et ne lui parliez pas. Certaines entreprises sont tournées vers le blâme. Lorsque vous archivez les correctifs, trouvez un moyen de les regrouper, puis demandez à ce type de les consulter plus tard. D'un autre côté, même un nouveau diplômé ne devrait pas coder quoi que ce soit à O(n^n)moins qu'il n'y ait tout simplement pas d'autre moyen. S'ils le font, alors ils ont probablement obtenu un C en algorithmes ou ne l'ont pas pris ou avaient un professeur merdique. Utiliser une sorte d'outil pour aider à trouver des problèmes communs serait bien. Peut-être que la prochaine tâche ce gars peut écrire des tests de performance?

— Job du

Un O (n ^ n) sans documentation expliquant pourquoi est tout simplement faux, point. Si vous devez vraiment le faire, les commentaires devraient mieux expliquer pourquoi.

— Loren Pechtel

Était sur le point d'écrire que "hé, O (n * n) n'est pas si mal, de nombreuses applications l'exigent ..." mais j'ai alors réalisé que ce n'était pas un signe de multiplication, mais un tueur ^!

— Max

O (n ^ n) peut être d'une amplitude plus rapide que O (n) si O (n) a une constante énorme et n est petit. codinghorror.com/blog/2007/09/… Là encore, n ^ n est extrême: D

— Codeur

33

Il semble que l'instauration d'une sorte de politique de révision du code puisse être bénéfique à plusieurs niveaux. Quelques avantages immédiats:

Vous pouvez directement influencer la qualité de son code avant que le code ne soit validé, ce qui maintient la qualité de base du code élevée
Vous empêche de faire des erreurs similaires qu'une autre paire d'yeux pourrait attraper
En l'absence de directives de codage, les revues conduisent naturellement à la cohérence du style de codage
Le partage des connaissances. S'il n'y a que deux d'entre vous et que l'un est renversé par un bus ...

Maintenant, lorsque vous allez de l'avant et commencez à nettoyer son code, utilisez-le comme exercice d'enseignement lorsque vous recherchez une révision de ce code. Vous obtiendrez vos informations examinées, et il pourrait apprendre comment mieux faire la prochaine fois.

— nithins
source

3

La révision du code +1 est une excellente façon de procéder. Je suggérerais de le formuler plus dans le sens de "Pourriez-vous jeter un coup d'œil aux modifications que j'ai apportées pour m'assurer de ne rien manquer" plutôt que "Voici les façons dont j'ai amélioré votre code".

— Steve Jackson

1

+1 Je dirais que la révision du code est beaucoup mieux adaptée que les "directives de codage des règles d'or". Peu de choses ne sont jamais correctes.

— Max

J'aime vraiment cette idée, merci. Maintenant, je vais devoir chercher un peu sur les bonnes façons de faire des revues de code!

— TorelTwiddler

1

Il existe en fait un bon article divertissant avec quelques notions de base disponibles sur mumak.net/stuff/your-code-sucks.html . Il s'agit principalement de techniques comportementales pour effectuer des évaluations de manière constructive, ce qui est extrêmement important pour des évaluations réussies.

— nithins

@TorelTwiddler, rappelez-vous simplement que les révisions de code sont pour l'apprentissage, pas pour le blâme. Soulignez les choses qu'il a bien faites, alors il sait qu'elles sont bonnes en même temps qu'elles suggèrent des façons de s'améliorer.

— CaffGeek

5

Jamais jamais jamais réparer leur code, sinon ils n'apprendront rien d'autre que s'ils font des erreurs, vous les rattraperez et les réparerez. La tâche n'est pas terminée tant qu'elle n'est pas terminée . J'ai eu beaucoup de chance quand j'ai commencé professionnel et mon superviseur direct a revérifié tout ce que j'avais commis, et s'il y avait une meilleure solution ou si j'avais fait une erreur idiote me le dirait, ce qui signifie que mes compétences se sont améliorées, ce qui signifie que je me suis amélioré plus rapidement et développé une peau plus dure.

Le laisser glisser fera naître de mauvaises habitudes, le corriger maintenant les rendra mieux à même de critiquer et de vérifier trois fois avant de prétendre que c'est fait.

— Nicholas Smith
source

2

Pouvons-nous en déduire que le projet "fonctionne" et a été réalisé dans un laps de temps raisonnable (quoique avec des problèmes de conception flagrants mais réparables)? Si c'est le cas, il est en bien meilleure forme que de nombreux projets que j'ai vus au fil des ans.

Je pense que plus de communication aiderait votre équipe - et cela pourrait être fait avec une révision régulière du code.

Il est bon que vous soyez sensible au fait d'être "trop sévère" et je pense que vous garderez cela à l'esprit que la révision du code ne doit pas être une expérience démoralisante sur les sièges chauds où les juniors sont grillés et examinés. Cela peut également être un moyen pour les développeurs seniors de démontrer les bonnes pratiques et pour que chacun puisse se faire confiance en étant poli et amical même en présence d '"erreurs".

Les gens apprennent bien quand ils voient à quoi ressemblent de très bonnes choses. C'est mieux que de signaler systématiquement chaque petit défaut. Le O (n ^ n), cependant, doit être délicatement et constructivement souligné.

— Angelo
source

0

Partagez vos connaissances.

Je lui offrirais de l'aide sur son nouveau projet en échange d'un enseignement d'un senior à un junior.

Pourquoi ne pas jumeler la programmation sur les deux projets?

— mouviciel
source