Attention @Kalvn je pense que l'auteur du billet est passé à côté de beaucoup de choses (en tout cas il n'y fait pas mention).

Fragmenter son code permet de :

1. Tester les parties de code indépendamment les unes des autres.

D'où le fait que l'exemple vienne du Google Testing Blog.

Par exemple comment faire pour tester tous les use-case du if !pizza.Baked sans avoir à écrire plusieurs tests avec plein d'autres paramètres à initialiser alors que ce bloc de code n'a besoin que de oven et pizza ? Ça devient au mieux illisible sinon impossible.

2. Paralléliser le travail.

Je peux écrire la première fonction, tu écris la deuxième. Mais si tout est dans la même fonction, impossible de se répartir le travail. Le type qui a écrit le billet ne fait-il que des projets persos ou ça lui arrive de bosser en équipe ?

3. Mutualiser le code.

Simple, une fonction par préoccupation permet de réutiliser cette fonction ailleurs. Du coup l'auteur qui préfère le gros bloc rouge avec tout dedans, il mutualise à base de copier-coller ?

À titre d'exemple, en revoyant la duplication de code d'un projet classique qui peinait chez mon dernier client, nous avons économisé ~500 K€ / an car mettre à jour un code copier-coller 15 fois, ça implique 15 mises à jour à retrouver, étudier, comprendre, patcher et tester.

4. Ne pas avoir à maintenir des commentaires.

Le nom de la fonction/méthode est la documentation de ce que fait le code, pas besoin de commentaires. D'ailleurs ce nom est toujours à jour sinon le code ne compile plus, les tests échouent ou l'algorithme ne veut plus rien dire, choses qui se remarquent.

A contrario, un commentaire erroné (en gris sur fond noir hein) ne cassera rien puisqu'une erreur n'aura pas d'incidence. Donc il aura de plus en plus de chances d'être faux avec le temps et induira nos confrères en erreur par la suite.

C'est l'un des plus gros pilliers de Clean Code de Bob Martin. Comment le mec est passé à côté, c'est fou non 🤨 ?

5. D'organiser sa pensée.

Je code souvent en TDD double loops, voire multi-loops c'est-à-dire que j'écris mon process à l'aide d'interfaces (ou méthodes) à remplir ce qui me donne le plan de quoi faire.

Mieux que cela, le plan étant rédigé au début, il est hyper facile de s'arrêter à un endroit, de le commiter/pusher, puis de reprendre plus tard, ceci sans jamais casser de features ou le code des collègues. Bonne chance avec une grosse fonction bien procédurale.

Conclusion

Ça ressemble à l'avis d'un amateur ou de quelqu'un qui ne veut pas s'embêter parce que le stress chez les autres, who cares ? Potentiellement quelqu'un qui n'a jamais eu à maintenir de code-base ayant 10 ou 20 ans de vie et qui n'a fait que des projets greenfield, ce qui renvoie à de l'amateurisme.

Désolée d'être cinglante mais

Un peu comme celui d'Octo, le blog de la société Arolla est vraiment très riche en conseils et bonnes pratiques. Je le coudifie