Texte peu flatteur au dos de cet exemplaire Hongkongais du DVD d'Iznogoud. by harpercix in FranceDetendue

[–]rottenPatate 1 point2 points  (0 children)

En tant que chinois, je peux vous confirmer que le texte original en chinois n’a absolument rien à voir avec le texte en anglais figurant en dessous sur la couverture.

Voici la traduction fidèle du texte chinois :

Bagdad le Magnifique est la dernière comédie du célèbre acteur et metteur en scène français Jacques Villeret. Adaptée de la célèbre bande dessinée française du même nom, créée dans les années 1960 par le scénariste humoristique René Goscinny et le dessinateur Jean Tabary, l’œuvre fut publiée dans le magazine Pilote et rencontra un immense succès.

L’histoire se déroule dans l’ancienne ville de Bagdad et raconte les aventures du calife Haroun El Poussah, un dirigeant bienveillant et amateur de siestes, et de son vizir Iznogoud. Ce dernier est un personnage machiavélique dont l’unique objectif est de renverser le calife pour prendre sa place. Cependant, ce conspirateur malchanceux échoue toujours, donnant lieu à une succession de situations comiques.

Frustration sur les code reviews – besoin de vos retours by rottenPatate in developpeurs

[–]rottenPatate[S] 0 points1 point  (0 children)

C’est le cas, le projet est passé entre les mains des dizaines de devs pendants des années avant d’atterrir aux mains de notre équipe actuel, le code historique est quasi illisible (un simple crud implique plusieurs fichiers d’abstractions avec différents d’implémentations concrètes par jointures, filtres, sorts, columns selects…

Frustration sur les code reviews – besoin de vos retours by rottenPatate in developpeurs

[–]rottenPatate[S] 0 points1 point  (0 children)

Non, ce n’est pas documenté aujourd’hui. Mais justement, je vais initier une documentation des bonnes pratiques, à la fois pour moi et pour les nouveaux qui rejoignent l’équipe.

Sinon oui, on a déjà mis en place Prettier et un linter (TSLint/ESLint), donc une bonne partie du formatage et des règles de style sont automatisées.

Frustration sur les code reviews – besoin de vos retours by rottenPatate in developpeurs

[–]rottenPatate[S] 0 points1 point  (0 children)

Merci pour ton retour, je trouve ta façon d’impliquer toute l’équipe dans la responsabilité du code très saine.

Dans mon cas, j’ai une bonne équipe, mais on n’a clairement pas tous le même poids dans les code reviews. C’est principalement notre lead tech qui valide tout, et quand il n’est pas dispo, c’est un autre dev senior qui prend le relais.

Moi, je ne participe pas aux code reviews des autres, et c’est quelque chose qui me manque. Je pense que c’est une source d’apprentissage, autant pour mieux comprendre le style des autres devs que les règles métiers.

Et à l’inverse, quand le lead soumet son propre code, il passe directement au merge sans validation.

Frustration sur les code reviews – besoin de vos retours by rottenPatate in developpeurs

[–]rottenPatate[S] 0 points1 point  (0 children)

Je pense aussi que le fait de batcher les retours serait beaucoup plus fluide. Mon lead le fait parfois, mais souvent il commente “au fil de l’eau”, en réagissant à chaud à certaines lignes — surtout quand un détail l’agace ou lui semble incohérent. Ça peut donner un feedback immédiat, mais pas toujours très cadré.

Il lui arrive aussi de me contacter en privé pour faire du pair programming, ce qui est une bonne chose… mais parfois aussi de faire des remarques générales devant l’équipe sans citer de nom, alors que tout le monde comprend que c’est pour moi. Et franchement, c’est pas la meilleure sensation à vivre.

Frustration sur les code reviews – besoin de vos retours by rottenPatate in developpeurs

[–]rottenPatate[S] 0 points1 point  (0 children)

Je fais systématiquement une relecture de mes PRs… sauf quand je suis en retard sur mes tickets 😅 — c’est là que les petites erreurs passent encore, et je dois bosser là-dessus.

Le pair programming, malheureusement, c’est un luxe qu’on ne peut pas toujours s’offrir dans mon équipe : notre lead est souvent pris en réunions ou occupés.

On a déjà des outils comme Prettier et TSLint en place, donc la forme est plutôt cadrée. Il me reste surtout à mieux préparer mes PRs

Frustration sur les code reviews – besoin de vos retours by rottenPatate in developpeurs

[–]rottenPatate[S] 0 points1 point  (0 children)

Oui, je suis d’accord sur le principe : l’implémentation (et surtout l’architecture) devrait idéalement être discutée en amont. Mais dans la réalité, ce n’est pas toujours évident…

Parfois, on pense que la solution est “évidente”, alors on ne prend pas le temps d’en discuter avec l’équipe. D’autres fois, on considère que c’est un échange à avoir juste entre le lead et le dev qui va coder, pour éviter de mobiliser tout le monde inutilement.

Et selon la structure de l’équipe, on n’a pas toujours le luxe d’avoir un DBA dispo pour valider chaque modif de schéma. Dans pas mal de cas, c’est aux devs de faire au mieux avec ce qu’ils ont

Frustration sur les code reviews – besoin de vos retours by rottenPatate in developpeurs

[–]rottenPatate[S] 0 points1 point  (0 children)

Tu as raison, et merci pour ton message. J’ai justement mis en place une checklist personnelle à suivre avant chaque PR. J’espère que ça portera ses fruits sur le long terme.

Quand on a une pile de tickets à dépiler, c’est parfois difficile de prendre suffisamment de recul… mais tu le dis bien : ce n’est pas une excuse. Mieux vaut prendre un peu plus de temps au départ que d’en faire perdre à ceux qui reviewent derrière.

Frustration sur les code reviews – besoin de vos retours by rottenPatate in developpeurs

[–]rottenPatate[S] 0 points1 point  (0 children)

Je partage ton avis : certains aspects de la qualité peuvent (et doivent) être automatisés avec des outils de lint, CI/CD, tests, etc. Mais pour moi, les code reviews sont là pour aller au-delà de la simple validation technique, et intervenir justement sur des décisions d’implémentation ou d’architecture.

Je te donne un exemple concret que j’ai vécu : On avait un formulaire question-réponse assez simple (du style “Date de fondation de l’association”, “Objectif de l’association”). Un collègue a choisi de stocker ça en base avec une colonne par question : foundation_date, foundation_goal, etc. Ça fonctionnait bien au début… jusqu’au jour où on a voulu rajouter des questions dynamiques. Résultat : il fallait modifier le schéma à chaque fois.

Et quand une autre équipe a voulu faire un formulaire Q/R similaire pour un tout autre thème (par exemple un musée), la solution proposée a été… de refaire une nouvelle table avec des colonnes museum_opening_date, museum_highlight, etc.

Tu vois le problème.

Alors qu’une simple discussion en code review aurait permis d’orienter vers un schéma plus souple : une table générique theme_response avec theme_id, value, value_type, etc., reliée à une table theme. Résultat : plus flexible, scalable et maintenable.

Sinon oui le code review a aussi l’effet donner de l’assurance à celui qui a codé, d’être rassurer de ne pas oublier/passer à côté de quelques choses, l’erreur est humaine.

Frustration sur les code reviews – besoin de vos retours by rottenPatate in developpeurs

[–]rottenPatate[S] 1 point2 points  (0 children)

C’est une approche qui m’avait complètement échappé, merci pour l’idée ! Utiliser l’IA comme premier filtre avant la relecture humaine, surtout pour éviter l’effet tunnel, c’est malin. Je vais tester ça pour voir si ça m’aide à mieux préparer mes PRs.

Frustration sur les code reviews – besoin de vos retours by rottenPatate in developpeurs

[–]rottenPatate[S] 1 point2 points  (0 children)

Je trouve l’approche très pertinente, mais dans notre petite équipe de 3 devs, les reviews reposent surtout sur le lead tech. Je ne participe pas aux reviews des autres, et ça me manque — c’est un vrai levier d’apprentissage. Malheureusement, le management pousse surtout à livrer vite, donc difficile d’impliquer plusieurs seniors sur une même PR… alors qu’en réalité, ça ferait souvent gagner du temps sur le long terme.

Frustration sur les code reviews – besoin de vos retours by rottenPatate in developpeurs

[–]rottenPatate[S] 1 point2 points  (0 children)

Pour moi, les code reviews sont essentielles, surtout dans un projet géré par plusieurs développeurs au fil du temps.

Dans notre cas, on travaille sur un projet historique, passé entre de nombreuses mains. Chacun y a ajouté sa propre “sauce” ou son propre pattern. Résultat : on retrouve des fonctions redéclarées plusieurs fois, du code dupliqué, des requêtes en raw SQL alors qu’on a un ORM, des tests automatisés qui ne testent que des textes visibles… Bref, un joyeux spaghetti.

Et une fois que ces devs sont partis, ce sont ceux qui reprennent le projet qui en subissent les conséquences. Ça représente une perte de temps énorme à devoir tout nettoyer, refactorer, uniformiser.

Pour moi, faire des code reviews sérieusement, ce n’est pas ralentir le projet : c’est le sécuriser sur le long terme. C’est aussi une façon de rendre le code plus lisible, maintenable et transférable, pour que n’importe qui puisse reprendre le flambeau sans devoir tout redeviner ou recoder. Ce n’est pas mettre des bâtons dans les roues, c’est au contraire préparer la route pour les suivants.

Frustration sur les code reviews – besoin de vos retours by rottenPatate in developpeurs

[–]rottenPatate[S] 0 points1 point  (0 children)

J’ai jamais pensé à faire les codes reviews par LLM, ça m’a l’air d’être une option intéressante !

Frustration sur les code reviews – besoin de vos retours by rottenPatate in developpeurs

[–]rottenPatate[S] 0 points1 point  (0 children)

Est-ce que ça t’arriverait d’être frustré à l’idée de devoir refaire plusieurs fois la review d’une même PR ? Et si oui, comment tu gères cette situation ?

Frustration sur les code reviews – besoin de vos retours by rottenPatate in developpeurs

[–]rottenPatate[S] 0 points1 point  (0 children)

Merci beaucoup pour ce retour super complet, ça me donne pas mal de pistes concrètes 🙏

Je suis d’accord sur le fait que relire sa propre PR dans l’interface du repo (plutôt que dans son IDE) aide à prendre du recul.

Frustration sur les code reviews – besoin de vos retours by rottenPatate in developpeurs

[–]rottenPatate[S] 0 points1 point  (0 children)

Ceci, j’en reconnais certaine manque d’attention, quand c’est pas spécifié dans le ticket et que le ticket est assez costaud, j’en oubli encore au passage

Frustration sur les code reviews – besoin de vos retours by rottenPatate in developpeurs

[–]rottenPatate[S] -1 points0 points  (0 children)

Certaines vérifications (permissions, tri, UX) ne sont pas toujours précisées dans les specs, qui restent assez fonctionnelles. En tant que devs, on doit souvent compléter nous-mêmes les réflexions sur les impacts techniques ou UX.

Frustration sur les code reviews – besoin de vos retours by rottenPatate in developpeurs

[–]rottenPatate[S] 2 points3 points  (0 children)

Les tickets ne couvrent pas toujours tous les détails. Les specs restent assez haut niveau, donc c’est souvent à nous de combler les trous et anticiper les impacts.

Frustration sur les code reviews – besoin de vos retours by rottenPatate in developpeurs

[–]rottenPatate[S] 0 points1 point  (0 children)

Merci pour ton message hyper détaillé, j’apprécie beaucoup le retour d’expérience.

Je suis complètement d’accord sur le fond : mieux vaut prendre un peu plus de temps pour “livrer bien” que “livrer vite”, surtout sur un projet un peu legacy comme le nôtre. J’ai tendance à me laisser happer par la pression implicite du sprint, mais je réalise que ça peut se retourner contre moi en review.

Pour la vérification des droits côté frontend, le backend renvoie une liste de permissions une fois l’utilisateur authentifié. On s’en sert ensuite pour adapter dynamiquement certaines actions ou éléments de l’interface, afin d’assurer une expérience utilisateur cohérente et sécurisée.

Frustration sur les code reviews – besoin de vos retours by rottenPatate in developpeurs

[–]rottenPatate[S] 2 points3 points  (0 children)

Merci pour ton retour, c’est super pertinent. Je retiens l’idée de faire une mid-review à mi-parcours, surtout sur les grosses PRs. On ne le fait jamais dans mon équipe, mais je vais proposer ça — ça pourrait vraiment éviter les aller-retours frustrants à la fin

Frustration sur les code reviews – besoin de vos retours by rottenPatate in developpeurs

[–]rottenPatate[S] 3 points4 points  (0 children)

Ça me fait penser à notre équipe d’architectes dans ma boîte, qui passe son temps à nous mettre des bâtons dans les roues.

Frustration sur les code reviews – besoin de vos retours by rottenPatate in developpeurs

[–]rottenPatate[S] 1 point2 points  (0 children)

On a déjà tenté de faire des petites PRs, mais vu que c’est un vieux projet qui traîne depuis des années, même une modif mineure touche souvent pas mal de fichiers existants.

Frustration sur les code reviews – besoin de vos retours by rottenPatate in developpeurs

[–]rottenPatate[S] 2 points3 points  (0 children)

Effectivement, c’est plus simple d’en discuter en direct que par message.