Je ne vois pas bien ce qu'il y a de pathologique là-dedans. C'est un paradigme comme un autre, celui suivi par tous les langages fonctionnels du LISP jusqu'à nos jours, langages qui ont tous pour modèle le lambda-calcul d'Alonzo Church.
En fait c'est le même problème que je rencontre un peu régulièrement dans ma carrière: l'absolutisme des dogmes.
Attends faut tout décomposer en unité fonctionnelle, résultat : un paquet de classe n'ayant qu'une seule fonction, des plats de spaghetti a tout va...
Attends faut faire des interfaces pour toutes les classe; résultat un paquet d'interface vide étendant une autre, et une seul implémentation qui s'appelle InterfaceImpl; petit indice si votre implémentation d'interface est juste InterfaceImpl, faut revoir la copie
Attends faut faire des micro-service : résultat des échange permanent entre certain service qui sont intimement liés et qui foutent le border lors de certaines interaction pour la gestion des cas d'erreur
Attends faut coder générique : Résultat un code illisible; note bien l’absence de généricité pose aussi problème quand faut corriger 5 ou 6 fois le même problème.
Je ne dit pas que tout ce qui est au dessus est mal, mais avoir un peu de souplesse lorsqu'on applique les dogmes ou paradigmes peut largement simplifier le code, la maintenance et la lisibilité. Mais attention a pas tomber dans l'excès et changer de paradigme & de méthode tout le temps; il faut trouver un juste équilibre.
Et la... Toute la question est là. Il y a de bons développeur qui...
...
nan j'déconne y'en a pas :P
Bref lorsqu'on énonce des principes de codage/programmation, il faut en expliquer la raison et le gain, pour permettre au développer (ou architecte) de déroger à ces principes si le besoin s'en fait sentir, les appliquer bêtement et aveuglement finit fatalement par des usine à gaz.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: goto return cave
Posté par fearan . En réponse au journal Is return the new goto ?. Évalué à 5.
En fait c'est le même problème que je rencontre un peu régulièrement dans ma carrière: l'absolutisme des dogmes.
Je ne dit pas que tout ce qui est au dessus est mal, mais avoir un peu de souplesse lorsqu'on applique les dogmes ou paradigmes peut largement simplifier le code, la maintenance et la lisibilité. Mais attention a pas tomber dans l'excès et changer de paradigme & de méthode tout le temps; il faut trouver un juste équilibre.
Et la... Toute la question est là. Il y a de bons développeur qui...
...
nan j'déconne y'en a pas :P
Bref lorsqu'on énonce des principes de codage/programmation, il faut en expliquer la raison et le gain, pour permettre au développer (ou architecte) de déroger à ces principes si le besoin s'en fait sentir, les appliquer bêtement et aveuglement finit fatalement par des usine à gaz.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent