Code reviews : just do it

Ce titre est volontairement repris sur l'article d'Eric, car il s'agit d'une réponse/complément que je ne me voyais pas faire en commentaire.

Ayant travaillé chez TEA par le passé, j'ai donc la connaissance de la manière dont se passe les code reviews chez TEA, et je suis en phase complète avec les avantages listés par Eric : augmentation de la qualité et partage de l'information.
Il y a non seulement le fait que plusieurs yeux, plusieurs esprits passent sur un code, une problématique, et il y a donc un échange constant sur ce qui est fait, pourquoi et comment. Mais il y a aussi et surtout une vrai communication qui se met en place entre les développeurs, réduisant l'effet de chapelle (une seule personne capable d'intervenir sur un code) et augmentant la cohérence générale d'un projet.

J'ai également constaté un effet de bord plutôt sympathique, car lorsque l'on sait que son code va être relu, on s'oblige à le faire beaucoup plus propre et on s'interdit les petits raccourcis crade qu'on pourrait utiliser dans un moment de flemme, d'une manière semblable à ce qui se passe quand on code pour un projet open-source.

Depuis, je travaille en délégation chez M6Web, dans l'équipe Replay, et nous avons mis en place le même système : tout développement se passe dans sa branche propre, amène à la création d'une PR, et il faut la validation de 2 personnes de l'équipe (sur 8 personnes) pour que la PR soit mergeable.
Toutefois, ce système peut rapidement trouver ses limites. Chez M6Web, La focalisation par projet est moindre, du fait du nombre de personnes composant l'équipe et de l'organisation de la structure, ce qui implique que nous travaillons sur une grosse dizaine de projet en parallèle et cela à des impacts :

  • Il est souvent compliqué intellectuellement de switcher de projet et de problématique pour relire le code de quelqu'un d'autre
  • Savoir quelles sont les PR en attente sur une dizaine de projet est un vrai exercice d'équilibriste qui demande, à l'état brut, de parcourir les PR en attente sur tout les projets pour voir celles qui sont en attente.

Au final, nous avons un phénomène d'empilement des PR qui pénalise l'avancement quotidien.

Toutefois, tout ceci n'est qu'un problème d'organisation, et il vaut mieux trouver comment contourner les limites plutôt que de faire marche arrière sur la code review automatique.

Je ne manquerais pas de vous faire un retour des solutions que nous avons mises en place

La critique est aisée, mais l'art est difficile

A force de vous le répéter, je pense que vous savez tous maintenant que je m'ocupe de l'AFUP Lyon.

Nous sommes 3, Adrien Gallou, Sarah Haïm-Lubczanski et moi-même, à prendre chaque jour sur notre temps personnel pour vous proposer des événements de tout type : apéroPHP, ateliers, conférences.
Et, pour certains événements, nous faisons appel à d'autres bénévoles, qui sont moins impliqués, mais qui répondent présents lorsque nous avons besoin d'eux.

Tout ce travail est purement bénévole.

Tout ça pour vous dire que le but commun qui nous anime tous, c'est de proposer des événements techniques autour de PHP à Lyon, et permettre une émulation de notre petit monde dans notre ville, rien de plus.
Les seuls moments où nous parlons d'argent, c'est pour payer les frais engagés, rien de plus.

Alors, quand je vois un commentaire laconique, nous accusant d'avoir fait volontairement un plagiat, ça me touche beaucoup.
Je ne sais pas si c'est de la sur-sensibilité, mais j'ai lu "ah bah bravo les gars, vous faites pas chier, prenez le travail des autres sans trop vous embêter, c'est super intelligent les gars".

Est-ce que cette personne a envisagée que nous ayons pu choisir ce logo sans savoir qu'une équipe de NFL l'avais choisi ? Est-ce que cette personne a pu envisager que nous n'avions pas de mauvaises pensées ?
Est-ce si dur de ne pas commencer en agressant les gens, mais en les avertissants ?

Et cette personne, qui nous met le nez dans nos déjections, est-ce qu'elle a fait une proposition pour corriger ?

Comme le disais Philippe Néricault Destouches :

La critique est aisée, mais l'art est difficile

Partage de configuration git

Depuis que je travaille avec Git, j'ai un problème : "comment partager mes configurations entre mon poste de travail professionnel et mon poste de travail personnel ?"

Jusqu'à ce jour, j'avais trouvé une solution pour beaucoup de mes outils, mais j'avais toujours un soucis avec Git parce que le fichier de configuration contient des éléments qui ne sont pas partageables (l'email du commiteur, par exemple)

J'ai découvert récemment qu'il était possible d'inclure une fichier dans le fichier .gitconfig, et la solution est donc apparue.
J'ai finalement placé les éléments partageables dans une fichier spécifique que je versionne, et dans mon fichier ~/.gitconfig, il me suffit de placer le code suivant :

[include]
    path = ~/path/to/Save/Git/.gitconfig

Au revoir TEA

Je sais que je fais un peu de reprise puisque j'ai déjà utilisé un titre de ce genre il y a un peu plus d'un an.

Mais oui, je suis dans le même cas de figure qu'il y a un an, puisque j'ai déposé ma démission et que je ne suis un employé de T.E.A que jusqu'au 14 juin prochain.

Il y a milles autres à ce départ, mais je n'en parlerais pas sur ce blog.

Et si vous vous demandez ce que je vais faire maintenant, la réponse est que je rejoins CleverAge Lyon, pour aller travailler en délégation chez M6Web. Je deviens donc à la fois consultant CleverAge, et Lead Developer dans l'équipe replay de M6Web.

Je n'ai pas perdu une année, j'ai fait quelques trucs cool, j'ai beaucoup appris sur ce que je voulais et sur ce que je ne voulais pas, j'ai une idée beaucoup plus claire de la manière dont je veux travailler, et ça, c'est très important pour moi.

[EDIT]

Il s'avère que cet article a été lu de manière beaucoup plus large que ce que je m'attendais. En conséquence, je préfère le recentrer sur l'essentiel.

Retour sur le symfonyLive 2013 – partie 3 – seconde journée

Pourquoi Symfony est-il encore open-source ?

François Zaninotto a lancé très très fort cette nouvelle journée en nous parlant d'open-source, mais pas de la manière dont nous avons l'habitude de l'entendre.
En utilisant de nombreuses référence sociologique, anthropologiques et politique, il nous as donné son point de vue sur ce qu'est l'open-source, à savoir que l'Homme ne fait jamais rien gratuitement, et qu'il désire toujours un retour à toute action, y compris un don. Ce retour pouvant être matérialisé par de la reconnaissance, par un service en retour, par une discussion.
A partir de ce postulat, il démontre que les entreprises qui partagent ou qui contribuent à des projets open-source ne le font pas pour la beauté du geste, mais parce qu'elles aussi voient ce qu'elles peuvent en retirer.

Au delà de la justification un peu grosse de la monétisation que Sensio essaye de faire autour de Symfony, j'avoue que cette conférence a déclenché en mois de nombreuses questions sur lesquelles il va falloir que je me penche dans les semaines à venir, et dont j'espère pouvoir vous faire un retour

Les bundles que vous allez regretter de ne pas avoir connu plus tôt

Damien Alexadre, de Jolicode a continué en nous listant une série de bundle Symfony2 assez pratique (ou à éviter à tout prix).
Mais plutôt que de faire un grand discours, je pense que les slides parlent d'elles-même.

Development worflow

Matthieu Moquet, de Blablacar nous a expliqué le workflow de développement utilisé par Blablacar, et surtout la manière qu'ils ont utilisés pour intégrer tous les intervenants du projet (équipe QA, traducteurs) dans leurs procédure de déploiement.
Au global, le processus semble bien rodé, mais le workflow Git semble un peu trop cérémonial pour que je sois totalement convaincu.

Toutefois, petite information intéressante puisque j'ai appris qu'ils ont utiliser Crew, de l'excellent @dondouny, pour gérer leur revues de code.s

Lien vers la présentation

Twig et composant de formulaire

J'ai suivi par la suite 2 conférences, une sur Twig donnée par Grégoire Pineau, et une sur le composant de formulaire de Symfony2 par Hugo Hamon.
Bien que le contenu de ces présentation était clair et efficace, je n'y ai rien appris puisque j'utilise déjà ces 2 outils.

42 bonnes pratiques pour Symfony2

La dernière conférence de la journée était présentée par Tugdual Saunier qui nous a transmis une liste de 42 bonnes pratiques pour bien développer avec Symfony2.
Pour ma part, j'en retiendrais surtout 3 :

  • Ne jamais prendre une recommandation au pied de la lettre, toujours la contextualiser
  • Symfony2 est un framework PHP Objet, donc chercher comment développer en PHP Objet, pas en Symfony2
  • La documentation est importante, lisez là. Et si vous l'avez déjà lu, relisez là.

Keynote de clôture

Lors de la keynote de clôture, Fabien Potencier et Grégory Pascal, nous ont annoncés les prochains évènements à venir, à savoir les prochains Symfony Live (Berlin, Londres, ...), mais surtout la création d'un nouveau cycle de conférence, la SymfonyCon, qui sera LE grand évènement international de la communauté Symfony, et qui aura lieu une fois par an dans une ville d'Europe, les Symfony Live devenant eux des évènements locaux.
La première SymfonyCon aura lieu en décembre 2013 à Varsovie.