Je milite activement pour l’utilisation des « boring technologies », les technologies ennuyeuses, mais maitrisées par rapport aux solutions « tendances ». Le plus dur étant de savoir où s’arrêter et de déterminer à quel moment il est temps de changer de solutions.
Voir la publication originale
Cette dernière est republiée ici afin de ne pas dépendre entièrement d'une plateforme tierce.
Choisir une technologie « ennuyante », c’est par exemple pousser une base de données relationnelle dans ses retranchements avant de vouloir passer sur une technologie NoSQL. C’est aussi concevoir un monolithe modulaire bien structuré au maximum de ses capacités avant de basculer sur des microservices.
L’idée dans tout ça, c’est de pousser les technologies jusqu’à leurs limites avant de changer de solution technique. Cela signifie qu’il est essentiel de se former et de se documenter sur ces dernières pour connaitre l’ensemble de leurs capacités et pas forcément s’arrêter à notre cercle de connaissance.
Le piège, c’est l’anticipation et le marketing. Pour prendre l’exemple de la base de données, bien souvent on démarre avec une base de donnéee relationnelle. Le produit grandit, les données s’accumulent et aux premiers signes de charge, on souhaite passer à l’échelle et introduire une nouvelle technologie.
Le problème que je vois, c’est qu’on a souvent exploré un minimum de ce que les SGBD peuvent offrir. En tant que développeur, les ORM nous éloignent du monde des bases de données, la couche d’abstraction tue nos compétences SQL et les performances de nos applications.
Maîtriser les ORM, optimiser des requêtes, ajuster les index, utiliser des fonctionnalités SQL avancées (telle que les CTE, les index fulltext, la mise en cache…). Poncer une technologie jusqu’au bout, c’est accepter de ne pas toujours choisir la solution la plus élégante, mais la plus pragmatique. C’est repousser le moment où l’on va devoir introduire de la complexité supplémentaire.
Le plus dur dans tout ça, c’est d’identifier le moment où l’on atteint la limite. Quand optimiser coûte plus cher que de changer une partie du système.
Bien souvent dans ces cas-là, c’est l’expérience et la connaissance approfondie des outils qui font la différence.
