Darkmira encourage la contribution à Symfony

Entre deux missions avec Darkmira, j’ai eu l’opportunité d’être immergé dans l’écosystème de l’Open Source avec le très connu et très utilisé framework Symfony pendant une semaine.

Accompagné par Nicolas Grekas, j’ai alors pu participer à l’amélioration de la version de Symfony actuelle. Il m’a guidé sur un besoin à faire sur le framework qui touchait plusieurs modules composant symfony.

La particularité dans mon cas de cette contribution est que je n’avais que très peu utilisé Symfony lorsque j’ai commencé cette contribution, je ne me sentais pas “légitime” de contribuer, pensant que la contribution est réservé à la core-team et aux personnes connaissant Symfony depuis des années. J’ai donc commencé cette semaine de contribution avec beaucoup d’à-priori et étant persuadé que j’allais rencontré une très grosse difficulté et un mur infranchissable compte tenu de mon manque d’expérience dans le framework.
Cependant ce qui me paraissait au premier abord difficile a en fait pris facilement tout son sens, tout simplement en réalisant une chose très simple :
Le framework Symfony n’est pas écrit en “Symfony”, il est écrit en PHP, et en PHP très épurée. Cela parait idiot à dire mais je crois que c’est quelque chose que nous ne réalisons pas instantanément lorsque nous pensons à la contribution à l’open-source en général.

Réaliser cela signifie qu’avec de bonnes bases en PHP on peut arriver à contribuer à n’importe quel framework, qu’il soit connu ou non.

J’ai pu de ce fait prendre la demande, lire le code source de Symfony et attaquer le problème à résoudre :

Le souci sur Symfony que j’ai résolu concerne les évolutions de fonctions lors du passage en version majeure. En effet il n’est pas possible de rajouter lors d’une version évolutive (ex 4.2 => 4.3) une nouvelle variable dans une fonction, même avec une valeur par défaut, car cela peut casser l’héritage que les projets pourraient implémenter sur ces fonctions, et casserai la compatibilité d’une version évolutive ancienne vers nouvelle.

Il y a deux possibilités pour palier à ce problème :

• Soit la fonction ou toute la classe passe final pour la prochaine version majeure (ex 4.3 => 5.0 )
• Soit les nouvelles variables dans ces fonctions sont ajoutés mais commentés de cette manière :

Pour le second cas, l’implémentation est plus compliqué, car mettre la prochaine variable en commentaire n’indique en rien à PHP qu’une nouvelle variable sera ajouté dans la prochaine version majeure. Par conséquent il était nécessaire de déclencher un @trigger_error avec un message indiquant que la fonction prendra un nouvel argument pour la prochaine version majeure, et que ne pas les implémenter de suite est déprécié, avec comme code erreur le E_USER_DEPRECATED natif de PHP

Non seulement ce trigger n’était pas implémenté dans les différents modules qui avait commenté leur nouvelle variable, mais il est aussi nécessaire de ne pas déclencher le trigger lorsque la nouvelle variable a bien été implémenté par le développeur. Par conséquent, et c’est là qu’il est intéressant de voir que l’on utilise bien les fonctions natives de PHP et pas Symfony, il faut faire une vérification sur le nombre d’argument entré via func_num_args() et vérifier que l’on est bien dans un cas d’héritage en utilisant également des outils natifs de PHP, les classes de Reflexion.

Ce qui donnait comme condition :

Avoir développé ces modifications m’a par la suite lancé dans les tests unitaires en créant des classes vides héritant des objects à tester, puis en vérifiant que le @trigger_error était bien lancé lorsque j’instanciai ma classe et que j’appelais ma fonction sans tous les arguments requis. Et ainsi j’ai ouvert ma PR.

Sur cette PR j’ai pu avoir une grande aide de la communauté, et j’ai pu découvrir qu’elle est bienveillante, et que les personnes participantes encouragent à l’optimisation et au minimalisme du code, pour rendre le tout le plus maintenable, simple et concis possible.

Cette approche est différente de ce que l’on pourrait vivre lors d’un projet dans une entreprise. Même si nous cherchons à en faire le moins possible pour le meilleur résultat, il n’est pas toujours facile dans le contexte d’une entreprise d’arriver à faire un code propre et le moins possible verbeux et d’avoir le temps de faire de la refactorisation poussée. Alors que lors de ma contribution à Symfony, j’ai pu découvrir que cette partie est à raison très importante, ce framework étant le plus utilisé en France, il n’est pas permis de laisser le code tel qu’on l’a fait la première fois même s’il est fonctionnel, il faut chercher un niveau de refactorisation poussé à son maximum. Et dans ce sens il est très intéressant de participer à l’open source et à la contribution de Symfony pour développer ses capacités professionnelles et personnelles dans ce sens, et réfléchir à la refactorisation à chaque instant.

La communauté va vous aider et vous guider à appliquer les bonnes pratiques, les design patterns si il est possible de les mettre en place, et via la contribution vous allez monter en compétences dans l’écriture de code la plus simple, efficace et maintenable possible. Au delà de contribuer à de l’open-source, cette dimension est importante pour votre développement professionnel de développeur web.

La suite de ma PR m’a permis d’ajouter des vérifications sur le trigger, en l’occurrence de vérifier si la classe dont est issu ma fonction n’est pas un héritage via un mocker ni via un test unitaire, et de revoir et corriger les backlogs de mise à jour de la version actuelle et de la prochaine version majeure, et sur cette partie j’ai pu aussi voir que le moindre espace en trop est à proscrire, ce qui est normal étant des backlogs qui seront lu de très nombreuses fois

Ce que j’ai pu tirer de cette contribution, c’est que l’expérience professionnelle apporté est bien différente de l’expérience que l’on peut trouver en mission ou en interne dans une entreprise. En effet le contact que l’on a avec la communauté open source n’est pas le même qu’avec des collègues, et que le contact se veut bienveillant et nous encourage à chercher la perfection. Donc même si vous êtes débutant à Symfony, il vous est possible de contribuer et de vivre votre expérience dans la contribution à ce framework, il n’est pas nécessaire de tout connaitre, et l’accompagnement sera présent pour vous aider à mener à bien votre tâche et pour vous permettre de délivrer un code propre et optimisé.

Et je vous laisse avec une de mes citations de développeur favorite et qui a été ma ligne de conduite pour cette contribution : “Codez toujours comme si la personne qui allait maintenir votre code était un violent psychopathe qui sait où vous habitez.”

Retrouvez-moi sur Twitter (@Darkmira1 ou @kevinjhappy) pour continuer la discussion et savoir où me croiser.