Antichesse (o ^ω^ o)
J'ai vécu une phase comme ça, entre 2014 et 2016 où ça devenait penible pour moi de coder. J'avais même accepté un job de chef de projet en 2015 c'est dire ! À cette époque, j'avais l'impression d'avoir fait le tour de la question, toutes les applications avaient tout le temps les mêmes couches, avec les mêmes frameworks et systématiquement le code technique et les classes anémiques prédominaient.
Puis j'ai redécouvert la programmation fonctionnelle (la vraie, pas celle de Java) mais aussi la programmation orientée objets (la vraie aussi, pas celle de Java) alors que j'étais pourtant sûr et certaine de maîtriser l'une et l'autre.
J'ai alors accepté l'idée que je ne savais coder ni dans l'une ni dans l'autre et que tout ce qui m'était présenté comme des "patterns" embarqués out-of-the-box par des frameworks comme Spring Boot étaient en réalité des anti-patterns et souvent parmi les pires !
J'ai commencé à détester coder à cette époque parce que le code était devenu une procédure à dérouler dans une architecture normée, pensée et plébiscitée par des non-développeurs que le marché appelait "architectes" et cela m'ôtait toute possibilité de réfléchir à comment faire et surtout de faire mieux que ces tripotés d'ingénieurs-cadres hélicoptères ne sachant plus trier une liste.
Ce qui m'a redonner l'envie de coder ce fût la découverte de Kotlin en 2015, de Yegor Bugayenko à la même époque et les cours de Kysofer qui a passé des week-ends entiers à me faire découvrir tout un tas de choses notamment :
- Pourquoi et en quoi l'API stream de Java 8 n'était pas du tout de la programmation fonctionnelle.
- Pourquoi je n'avais jamais créé ni utilisé le moindre objet au sens OOP du terme avec JPA ou des DTO.
- En quoi la composition vs héritage n'était pas du tout ce que je pensais et ce qu'internet disait.
- Pourquoi si j'avais du mal à écrire des tests c'était à cause des architectures procédurales et qu'en réalité c'était facile et que j'adorais ça.
- En quoi écrire la doc était une perte de temps mais était obligatoire à cause des architectures orientées techniques et non métier.
Et tellement d'autres choses. @Kysofer tu avais raison quand tu me disais : " j'adore mon métier, mais je déteste mon travail ".
Bref si vous ne codez plus, quittez l'IT, les meilleurs entraîneurs sont ceux qui ont boxé jusqu'au bout, pas ceux qui n'ont fait ca que 4 ou 5 ans.
@Chlouchloutte m'a faite découvrir ce diagramme il y a quelques minutes.
J'avoue que je ne sais pas trop quoi en penser dans le sens où il m'apparaît comme très procédurale. Typiquement en OOP (Object Oriented Programming), nous avons une encapsulation des données et les traitements qui s'appliqueront sur elles au sein d'une même classe. Or, le découpage en couche implique une séparation des données dans des structures et l'application d'une logique applicative, répartie en couche. Les structures / entités traversant toutes les couches.
Ce n'est pas objet pour un sou. Et ce sera même quasiment impossible de coder proprement en objet avec de telles architectures puisque chaque couche insistera pour séparer les entités des traitements. De facto, nous nous retrouverons avec une armada de développeurs arguant que l'objet "sainul" puisqu'ils ne pourront tout simplement jamais exprimer facilement en objet. Ainsi, les classes issues de l'OOP se résumeront à être de simple modules (au sens Functional-Programming du terme, c'est-à-dire un namespace de fonctions) et les instances ne seront plus que des singletons, qu'ils soient gérés manuellement ou via Spring.
Pour faire de l'objet, il faut que votre architecture soit orientée objet (je simplifie). Pour coder en fonctionnel, il faut que vos données soit accessibles dans des monades (je simplifie aussi). Pour tirer le meilleur des deux mondes, il vous suffit d'avoir une architecture orientée objet, des algorithmes codés via une approche fonctionnelle. Mais visiblement, mes contemporains préfèrent une lutte de religion radicale que de découvrir les avantages de l'autre camp.
@Chlouchloutte j'aurai quand même besoin de te reposer des questions.
