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.
J’en avais déjà parlé lors de mon billet sur la collaboration technique, il semblerait que cette pratique se démocratise avec des conseils de Mozilla ou CapGemini (cache). Etsy va un peu plus loin en proposant des revues de systèmes (cache) 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.