#code-review

Explore how to progressively expose your Azure DevOps extension releases in production to validate, before impacting all users.

I don’t know what else to say, the title kind of says it all. This post discuss the deployment rings of your application, basically rolling out changes in phases.

Route and process data automatically using Logic Apps

Microsoft Learn module on how to proc…

The importance of code review: skipping to do a code review because it looks involved, could end up costing you — since you have to add to that code and it wasn’t well structured to begin with.

One good heuristic on when something needs to be restructured is: if there is too much going in a class to keep in your head, call that out in your review — ask people to break it out into a separate class.

This is also the “S” in SOLID — Single Responsibility Principle. You can get technical and argue what a responsibility is. But if you can’t keep everything going on in the class in your head, that’s too much. If the tests for that class look large and/or complex, that’s too much.

The smaller class will ensure the code is more comprehensively tested — since you can see all the different behaviors. Each class will be a lot easier to understand too.

How do you ensure that you don’t have class explosion? Class explosion is bad when you have 1 object that needs to depend on 20 objects to do its work. If 1 object, only depends on 5 — it’s small enough to wrap your mind over how it works. Each of those objects can depend on 4 other objects and in the context of each class it’s easy to understand what they do. This is good.

I’ve been thinking of code reviews lately and how can I be more effective when doing them. Here are my thoughts.

A code review has 2 main goals:

To improve the quality of the code being reviewed.

To spread knowledge.

How do you improve the quality of code?

You improve the quality of code by taking it closer to ideal code. So what is ideal code? Ideally designed code:

Works well today

Is easy to change for tomorrow

Does not create an operational burden

How do you spread knowledge in code reviews?

Just the fact that someone else reviews your code means they have better knowledge on how a feature works. You are improving the bus-factor of your software/product.

Code reviews can be an educational experience for new developers who might not know the best way of doing things. The change you are suggesting might be small in the scope of the review at hand. But that small change, as it carries through their career can have a positive impact on many other projects to follow. When you provide educational tidbits, make sure to specify the reason why someway is better — that is what makes it educational.

You can pick up on nice ways of doing things from seeing how others have done something.

In essence:

Give feedback, that will:

Make software work better today. For example: identifying bugs, missed edge cases, performance problems etc.

Make software easier to change for tomorrow. For examples: identifying architecture problems, promoting good code structure, following code conventions etc.

Decrease operational burden created by the software. For examples: Recommending good logging behavior, suggesting alternatives to things that would require manual maintenance etc.

Ou pourquoi la revue de code est une étape absolument nécessaire et comment la mettre en place

A quoi sert vraiment une revue de code ?

Si l’on croit la plupart des articles sur le sujet, la revue de code est sensé “permettre de détecter les défauts dans le processus de développement le plus en amont possible” et donc limiter le risque de bug.

Concrètement, je trouve que c’est un résumé réducteur, j’y vois plutôt ces deux objectifs : - Vérifier qu’une tâche développée ne contient pas d’erreur de logique, qu’elle est relativement optimale (ou en tout cas pas inutilement complexe) et que tous les cas d’utilisation ont été implémentés - S’assurer que le code sera compréhensif et maintenable (donc correctement écrit ou documenté lorsque nécessaire, avec des variables et méthodes aux noms intelligibles, ect)

Pour le premier point, les tests unitaires sont censés déjà remplir cette fonction; il faut bien cependant que quelqu’un vérifie, a minima :

que les tests sont bien écrit

qu’ils ont du sens

qu’ils ne font pas que bêtement appeler du code pour augmenter la couverture / que les assertions sont pertinentes

qu’ils prennent en compte les cas aux limites, etc.

Pour le second point, c’est déjà plus relatif… mais la finalité est de comprendre ce que fait le code le plus rapidement possible, sans avoir à demander à celui qui l’a écrit (auquel cas il faut, de facto, le notifier pendant la revue)

Et bien évidement le code doit être sans redondance, le plus homogène possible avec le reste de l’application (pas deux termes différents pour parler de la même chose) et doit être refactoré si besoin, selon le temps disponible pour cela. De plus, en dehors de ces objectifs, la relecture de son code par un tiers reste évidement un excellent moyen de vérifier que l’on a pas commis des erreurs d'inattention basique ; et c’est aussi le meilleur accompagnement à donner à quelqu’un qui arrive sur un projet pour qu’il monte en compétence ! C’est également une formidable aide à la cohésion d’équipe, surtout entre développeurs ne se connaissant pas / n’ayant pas travaillé ensemble et un outil d’amélioration continue !

Comment faire du code review

Avec des outils comme gitHub, gitLab ou encore bitBucket, il est très simple de mettre en place des demandes de relectures de code avant validation (pull request chez gitHub & bitBucket), plus besoin donc d’aller lire le code de quelqu’un par dessus son épaule et surtout, les ajouts, suppressions et modifications sont affichées de manière intelligible !

Pour aller avec l’outillage, il faut la méthodologie qui sied bien : avec git, le plus simple reste sans doute de faire du git flow, et de ne merger les branches qu’à la validation du code review. La taille de l’équipe et son organisation importe également énormément ! La revue de code va prendre du temps et demander de la concentration pour être efficace, et même si, idéalement, tout le monde devrait relire le code des autres et l'approuver à l’unanimité, c’est bien souvent impossible au delà de 3 développeurs sur un projet… 2 relecteurs par demande semble être le meilleur compromis. Bien entendu, les revues de code doivent être faites dans un délai raisonnable après la publication d’une demande de relecture, et ne pas s’empiler (le stock, c’est le mal) Pour une revue de code plus efficace, il convient d’avoir un template contenant une checklist de point critiques à vérifier :

Si le développement implique du front, poster une capture d’écran

Si un ajout/modification de base est faite, la documentation doit être mise à jour

Avoir un lien vers le ticket de la tâche à réaliser (jira, trello, bugzilla, mantis...)

Ect...

Comment relire / proposer une amélioration ?

Avant de relire, il faut connaitre la description de la feature derrière le code, il est donc indispensable d’avoir un lien vers le ticket concerné. L’outil de revue de code doit permettre l’ajout de commentaire, c’est indispensable. Ceux-ci se doivent d’être le plus clair possible, sans quoi le développeur va perdre du temps à essayer de comprendre ce qui ne va pas; il ne faut donc pas hésiter en cas de doute à relire le code directement avec le développeur qui l’a initié, cela est parfois plus rapide et efficace que d’écrire des remarques incompréhensibles pour autrui. Basiquement, il faut, avec le besoin en tête, regarder les modifications de code et voir si on les comprend et si elles sembles pertinentes. En cas d’incompréhesion, faire un commentaire en proposant un autre nom / une autre façon de faire Si le code est clair mais qu’il pourrait être amélioré, proposer un code plus optimal, et si possible en exprimant le niveau de criticité (par exemple : si tu as le temps, fais ceci... versus ton code va générer des fuites mémoires vu les volumes attentdus, fais plutôt comme cela...)

How to: How to help a struggling newbie do a better job?

How to help a struggling newbie do a better job?

I have been the only developer and the de-facto “senior developer” on my company’s flagship product for a while (a .NET WinForms app, but that is not related). Just recently, they brought in a “newbie” developer with a fresh computer science degree. No experience with source control, unit testing, software maintenance, etc.

I recently assigned him…