title: Revue de systèmes

> Which all begs the question: what customs and standards should we define for our code? What makes code *good*? If our goal is to catch & eliminate bugs during development, we must be able to clearly define what we intend a piece of code to do, and present it in a way that is legible enough for a reader to assess whether it (likely) lives up to the task at hand. And if our goal is to enable collaboration on and reuse of code, we must find a way to build rapport with our collaborators, help them understand the goals of our code, and give them a simple but precise way of communicating back to us what contributions they would like to make to support those goals.
>
> <cite>*[Code Review in the Lab](http://mozillascience.github.io/codeReview/intro.html)* ([cache](/david/cache/8e01afc39222230889a79cc8c2334c7b/))</cite>

J’en avais déjà parlé lors de mon billet sur la [collaboration technique](/david/blog/2015/collaboration-technique/), il semblerait que cette pratique se démocratise avec des conseils de Mozilla ou [CapGemini](http://capgemini.github.io/learning/better-learning-code-reviews/) ([cache](/david/cache/c8a2558279f3d400151c8881ef778da8/)). Etsy va un peu plus loin en proposant des [revues de systèmes](https://codeascraft.com/2015/12/21/leveling-up-with-system-reviews/) ([cache](/david/cache/ebfb49281706086aecf734ca50aaced3/)) permettant de s’aligner en réduisant les frustrations.

**Parfois la co-amélioration est plus pragmatique que la co-construction. Attention toutefois, elle ne mène pas forcément au même endroit.** Soumettre une exécution c’est déjà orienter la discussion, parfois trop pour laisser libre cours aux idées des autres.