Doctrine

Les valeurs & principes de l’Engineering chez Doctrine

Les quatre valeurs de Doctrine se déclinent et s'appliquent dans le quotidien de l’équipe d’engineering:

Challenge the Status Quo

Ce qui est mis en production aujourd’hui sera amené à évoluer. C'est pourquoi, lorsque tu construis une solution technique, il est important de proposer quelque chose sur lequel nous pourrons facilement nous appuyer lors des évolutions futures. Cela signifie également qu'en tant qu'ingénieur, tu as la responsabilité de challenger les choix techniques et l'implémentation en place.

Liberty and Responsibility

Tu es acteur du changement que tu veux voir dans le code ou dans les processus de Doctrine. Nous encourageons les ingénieurs à prendre des initiatives pour améliorer notre infrastructure, notre architecture et notre base de code en proposant et en mettant oeuvre de nouvelles idées. La liberté s'accompagne de responsabilités. Il est donc important que l'adoption d'un nouveau langage, d'une bibliothèque tierce structurante, ou d'un nouveau morceau d'architecture, ne soit pas fait de manière isolée mais en équipe. La responsabilité, c'est également d’assumer les conséquences de ses choix dans le temps.

Knowledge is Power

Pour assurer la construction d'une connaissance commune, nous attendrons de toi que :

• tu partages l’information de manière large et systématique en interne et de manière publique.
• tu prennes des décisions en incluant toutes les parties prenantes
• tu mettes par écrit tes choix et les raisons qui les motivent afin qu'ils puissent être partagés.

Au delà de la documentation des choix techniques, nous nous efforçons d'établir des pratiques, des APIs et des structures de données communes qui constitueront une connaissance commune à toute l'équipe.

Release Early, Release Often and Listen to your Customers

Pour soutenir les objectifs de Doctrine, nous devons avoir un rythme de mise en production régulier.

Mais nous ne devons pas compromettre l'expérience des développeurs, la capacité à itérer plus tard ou les objectifs de disponibilité de l’application (SLO) afin de déployer plus tôt.

Nous devons donc trouver l'équilibre pragmatique entre ce qui est à faire et ce qui est à ne pas faire:

A faire

Itérer sur les fonctionnalités : nous nous efforçons d'assurer une livraison rapide et une capacité d'itérer rapidement en mettant souvent en production.

Écouter le feedback : en écoutant nos clients, nous comprenons que nous devons concentrer l'effort technique là où il aura le plus d'impact pour les clients sur le long terme.

A éviter

Sortir des fonctionnalités buggées et non testées : nous savons que mettre en production tôt et souvent ne signifie pas mettre en production vite et mal.

Publier du code bancal, incohérent et/ou non documenté : nous savons que mettre en production tôt et souvent, surtout à long terme, nécessite une infrastructure, une architecture et une base de code solides, cohérentes, documentées et prêtes à évoluer, ce qui en soi demande du temps et des efforts.