Comment faites vous pour faire des retours sur ce genre de soucis ?
Sur tout ce qui est "simple", je fais le correctif dans une PR à part en mode "Je trouve ça plus clair à relire/comprendre vous en pensez quoi ?". Ça prend pas plus de temps que de pointer les abréviations et de partir dans des débats compliqués, et ça marche souvent.
Pour le reste («l'objet pour que dalle», «les fonctions de 5 kilomètres»), c'est normalement assez facile d’être plusieurs dans l'équipe a appuyer le fait que c'est pas terrible et que ca vaut le coup de passer un peu de temps à remettre d'équerre.
Dans une de mes boites, on a fait de la code review en équipe de code pas à nous (pour comprendre comment fonctionne une lib ou un outil qu'on utilise). Ça permet d'arriver à des conclusions consensuelles du genre :
- C'est chiant à lire les fonctions de plus de deux écrans,
- Mais pourquoi il y a 15 couches d'abstractions pour un truc qu'on ne peut pas modifier,
- Mais pourquoi ce concept change de nom juste dans cette classe ?
En gros, passer par du code neutre (qui n’était fait par personne dans la boite) a permis de virer l'aspect affectif dans la critique du code et sortir des règles validées par tout le monde.
[^] # Re: Tu n'es en rien en voie d'extinction
Posté par Guillaume Rossignol . En réponse au journal Je fais partie d'une espèce menacée d'extinction. Évalué à 6.
Sur tout ce qui est "simple", je fais le correctif dans une PR à part en mode "Je trouve ça plus clair à relire/comprendre vous en pensez quoi ?". Ça prend pas plus de temps que de pointer les abréviations et de partir dans des débats compliqués, et ça marche souvent.
Pour le reste («l'objet pour que dalle», «les fonctions de 5 kilomètres»), c'est normalement assez facile d’être plusieurs dans l'équipe a appuyer le fait que c'est pas terrible et que ca vaut le coup de passer un peu de temps à remettre d'équerre.
Dans une de mes boites, on a fait de la code review en équipe de code pas à nous (pour comprendre comment fonctionne une lib ou un outil qu'on utilise). Ça permet d'arriver à des conclusions consensuelles du genre :
- C'est chiant à lire les fonctions de plus de deux écrans,
- Mais pourquoi il y a 15 couches d'abstractions pour un truc qu'on ne peut pas modifier,
- Mais pourquoi ce concept change de nom juste dans cette classe ?
En gros, passer par du code neutre (qui n’était fait par personne dans la boite) a permis de virer l'aspect affectif dans la critique du code et sortir des règles validées par tout le monde.