Je regardais / écoutais cette excellente conférence de Simon Brown sur les Monolithes modulaires de GOTO 2018.
En cela, il mentionne un terme appelé Programmation culte Cargo et cela m’a vraiment touché.
J’ai récemment rejoint une nouvelle entreprise avec un nouveau langage de programmation, de nouveaux outils, de nouveaux processus et une nouvelle équipe. En fait, c’est à peu près tout « nouveau ».
Cela m’a amené à faire beaucoup d’apprentissage ces derniers mois. Étant relativement expérimenté, j’aime regarder les « pourquoi » plutôt que les « comment » lorsque j’apprends de nouvelles choses. Ce que j’ai réalisé, c’est que ce n’est pas l’approche la plus courante.
Lorsqu’un utilisateur est chargé d’ajouter à une base de code existante, d’étendre la solution actuelle, il vérifiera très probablement comment cela a été fait précédemment, en copiant l’approche pour sa solution. Ils peuvent / suivront aveuglément ce modèle comme c’est le cas auparavant. Des blocs supplémentaires sont ajoutés au sommet de la tour, sans se demander si c’est la bonne chose à faire. Si tout le monde fait cela, cela finira par arriver.
C’est de là que vient le terme « Programmation culte Cargo ».
Wikipedia l’explique comme ceci:
La programmation Cargo cult est un style de programmation informatique caractérisé par l’inclusion rituelle de structures de code ou de programme qui ne servent à rien. La programmation Cargo cult est généralement symptomatique du fait qu’un programmeur ne comprend ni un bogue qu’il tentait de résoudre, ni la solution apparente (comparer le débogage de fusil de chasse, la magie profonde). Le terme programmeur cargo cult peut s’appliquer lorsqu’un programmeur informatique non qualifié ou novice (ou un programmeur inexpérimenté avec le problème en question) copie un code de programme d’un endroit à un autre avec peu ou pas de compréhension de son fonctionnement ou s’il est nécessaire dans sa nouvelle position.
La programmation culte Cargo peut également faire référence à la pratique consistant à appliquer aveuglément un modèle de conception ou un style de codage sans comprendre les raisons de ce principe de conception. Les exemples sont l’ajout de commentaires inutiles à du code explicite, l’adhésion excessive aux conventions d’un paradigme de programmation spécifique ou l’ajout de code de suppression pour des objets que le garbage collection aurait collectés automatiquement.
Imaginez un scénario où vous travaillez sur un bogue, en trouvant le code à l’origine de la panne. Vous n’êtes pas très sûr de ce qui se passe, alors vous;
- Google l’erreur.
- Vous trouvez une question StackOverflow.
- Recherchez la réponse la plus mise à jour.
- Copiez et collez la solution dans votre code.
- Essayez de déboguer pour voir si cela a résolu votre problème.
Il l’a, alors vous l’enregistrez et passez à autre chose.
Ça vous semble familier?
Pourquoi faisons-nous cela? Pourquoi prenons-nous aveuglément cet extrait et l’utilisons-nous tel quel dans notre implémentation?
Le cas d’utilisation n’est probablement pas le même, donc je serais surpris si les solutions l’étaient. Exemples simples mis à part, comprendre le raisonnement derrière la solution est plus important que la solution elle-même. Il y a beaucoup de choses que vous ne pouvez pas faire avec quelque chose que vous ne comprenez pas. Vous ne pouvez pas le modifier, l’améliorer ou le tester. Vous ne pouvez pas le documenter et vous ne pouvez pas le posséder.
Nous aimons tous ce qui est nouveau, et la direction semble particulièrement aimer suivre les tendances populaires, suivre les progrès technologiques.
La plupart des équipes suivront désormais une approche Agile. Les tests TDD et automatisés peuvent être très utiles dans certains scénarios, l’intégration continue supprime une grande partie des frais généraux de l’équipe d’infrastructure, le Big Data et l’IA peuvent grandement améliorer la satisfaction des utilisateurs et la conteneurisation et, plus récemment, les Microservices transforment notre ancienne architecture monolithe en services autonomes plus petits.
Chacune de ces avancées est brillante en soi, et je ne cautionne aucune d’entre elles. Ma difficulté est de savoir si nous devons tous les adopter dans tous nos processus et notre code? Nous voyons des articles de blog de Netflix, Facebook, Twitter montrant comment leur utilisation a transformé leur fonctionnement. Si les grandes entreprises les jugent nécessaires, ne devrions-nous pas aussi? C’est là que la programmation culte cargo reprend sa tête laide.
Nous devons comprendre les problèmes de nos conceptions actuelles, pourquoi ils se sont produits et comment ils peuvent être abandonnés à l’avenir. Oui, ces nouveaux processus peuvent nous aider à résoudre nos problèmes, mais les suivre aveuglément dans le faible espoir qu’ils font n’est pas la voie à suivre, et cela n’a aucun sens logique.
Je mentionne spécifiquement les Microservices car beaucoup d’entreprises semblent faire la transition, citant des avantages tels que:
- Temps de développement plus rapide
- Évolutivité élevée
- Facile à améliorer
- Facilité de déploiement
- Équipes autonomes avec la liberté de choisir la technologie
Avec une liste comme celle-ci, à quoi penser ? Sautons tous dans le train en marche!
Attendez une seconde are y a-t-il des inconvénients à cette approche ?
- Complexité architecturale
Dans les architectures monolithiques, la complexité et le nombre de dépendances résident à l’intérieur de la base de code, tandis que dans les architectures de microservices, la complexité se déplace vers les interactions des services individuels qui implémentent un domaine spécifique
- Complexité opérationnelle
- Comment provisionner des ressources de manière évolutive et rentable
- Comment faire fonctionner efficacement des dizaines ou des centaines de composants de microservices sans multiplier les efforts
- Comment faire face à un manque de normes et d’hétérogénéité environnements qui incluent différentes technologies et personnes ayant des compétences différentes
- Comment gérer le versionnage
- Comment suivre et déboguer les interactions sur l’ensemble du système
- Comment suivre des centaines de pipelines de déploiements de code et leurs interdépendances
Ces éléments sont extraits du livre blanc « Défi des Microservices » d’Amazon. Maintenant, je ne sais pas pour vous, mais les inconvénients me semblent beaucoup plus effrayants que les avantages. Encore une fois, je ne dis pas que ce n’est pas la bonne approche à adopter, mais à moins que ces avantages l’emportent sur les inconvénients, que gagnez-vous en suivant cette approche?
Le problème « public ».
C’est vraiment simple, Arrêtez d’utiliser le mot-clé Public, arrêtez de créer automatiquement des classes publiques. Pourquoi le faisons-nous?
Le problème avec l’utilisation du mot clé public est que vous manquez les avantages liés à l’encapsulation. Pourquoi l’utilisons-nous autant? C’est à peu près le mot par défaut que nous utilisons lors de la création de classes, tous les exemples utiliseront des classes publiques, les assistants et les extraits implémenteront des classes publiques. Il est temps d’arrêter. Combien de personnes ont un compte Facebook public? La plupart des choses dans ce monde sont privées, comme devraient l’être nos cours. Rendez-les privés par défaut, puis si vous avez besoin qu’ils soient publics, changez-les ensuite.
Avec une grande expérience vient une grande appréhension.
Plus vous êtes dans un domaine, moins vous êtes naïf face aux améliorations perçues qu’un nouvel outil ou processus apportera. La plupart des idées d’aujourd’hui proviennent de recherches sur le terrain vieilles de plusieurs décennies, qui sont finalement adoptées. Une fois que quelque chose a été adopté en masse, il est plus facile de se sentir à l’aise avec l’embrasser pleinement. Autrement dit, si c’est la bonne chose à faire.
» Le bon jugement vient de l’expérience, et l’expérience vient du mauvais jugement »
– Rita Mae Brown
Alors n’hésitez pas à parcourir les interwebs pour trouver des solutions et des tutoriels à vos problèmes; continuez à explorer de nouveaux langages, frameworks et implémentations. Sachez simplement pourquoi ils fonctionnent, plutôt que simplement comment. Nous apprenons tous de nos propres expériences et erreurs, donc comprendre les fondamentaux vous empêchera de continuer sur la même voie à l’avenir.