Le culte du fret est inévitable

Il n’est pas controversé que les nouveaux développeurs ne puissent s’empêcher de culte cargo.Ils n’ont tout simplement pas assez appris de la pile pour vraiment comprendre ce qui se passe sous le capot et pourquoi les choses doivent être faites d’une certaine manière.

Par exemple, dans l’un de mes premiers cours de programmation, nous avons appris qu’en Java, le point d’entrée du programme est:

public static void main (String args)

Il a fallu des années pour arriver au point où je comprends chaque partie de cette signature de méthode.Même si cela m’avait été expliqué à l’époque, je ne l’aurais pas compris.J’aurais dû comprendre la visibilité de la méthode, les méthodes classe par rapport à l’instance, les types de retour, les types de paramètres, les tableaux (par opposition aux listes / vecteurs), les arguments de ligne de commande (et comment ils sont analysés par le shell) et divers détails sur l’implémentation de Java.

Et c’est OK.Il s’avère que vous n’avez guère besoin de comprendre tout cela pour écrire des programmes de ligne de commande ou même d’interface graphique en Java.

Nous ne nous attendons pas à ce que les nouveaux développeurs connaissent les tenants et les aboutissants de chaque décision qu’ils prennent.Ils n’ont tout simplement pas programmé assez longtemps pour comprendre tous les détails de chaque partie de la pile.

Nous ne nous attendons pas non plus à ce qu’ils sachent que git stocke les commits dans un graphe acyclique dirigé et que chaque branche est un pointeur vers un nœud dans le graph.It c’est assez bon pour qu’ils puissent faire git checkout et git commit et continuer leur travail.Et c’est assez bien s’ils suivent une règle comme « ne jamais fusionner en avance rapide » (ou « toujours fusionner en avance rapide »).

Mais même pour les développeurs seniors, c’est inévitable.Quel développeur senior comprend vraiment toutes les commandes git qu’il doit rechercher sur le débordement de pile ?Ou la partie awk et sed du one-liner qu’ils ont recherché hier sur GitHub?Ou chaque en-tête de la réponse HTTP avec lequel leur API d’application Web répond ?Ou quand utiliser l’URL HTTPS par rapport à l’URL SSH de votre dépôt GitHub ?Ou comment configurer au mieux votre instance PostgreSQL locale ?Ou votre instance Neo4j ?Ou comment déboguer votre configuration rvm/rbenv/chruby/virtualenv sans la détruire et la reconstruire à partir de zéro ?

La seule façon de ne pas être culte est de tout savoir.Et personne ne sait tout.

Le cultage de cargaison est bon

Le cultage de cargaison est bon lorsqu’il est utilisé responsibly.It nous évite d’avoir à tout savoir.Lorsqu’il est bien utilisé, il s’agit de tirer parti de l’expertise durement acquise de tout le monde dans le domaine.Sans doute, utiliser n’importe quelle abstraction sans comprendre comment cela fonctionne (ce qui est tout le point de l’abstraction!) est une cargaison selon la définition de Lippert.

De plus, le cultage de cargaison est souvent un bon choix. »Ces gens semblent savoir ce qu’ils font, alors je vais suivre leur exemple », est une stratégie parfaitement rationnelle.

En fait, la communauté de la programmation encourage activement le culte du fret.Lorsque nous disons aux gens: « n’utilisez pas l’état global » ou « suivez PEP8 », nous leur disons de transporter du culte.Par exemple, un développeur comprendrait idéalement les façons (parfois pas si) subtiles dont l’état global peut vous mordre, mais jusqu’à ce que la compréhension soit là, il vaut mieux l’éviter.

Quelques autres grandes utilisations du cargo culting:

• « Convention sur la configuration » comme on le voit dans Rails (et ses innombrables clones), Django et Ember.js
• Guides de style et leurs outils, tels que Rubocop, JSLint et Auto PEP8
• De nombreux outils d’analyse statique, tels que CodeClimate, Reek, Flay et Flog
• Les directives de l’application 12factor
• Code smells

Comment cargo cult de manière responsable

Évidemment, le cargo culting présente des inconvénients majeurs, mais maintenant nous avons également vu des avantages .Nous aimerions utiliser des outils et des techniques qui font le travail maintenant, sans toujours avoir à bien comprendre pourquoi ils fonctionnent.Au lieu d’éviter complètement le culte de la cargaison, comment pouvons-nous le culte de la cargaison efficacement?

La seule grande mise en garde: le risque inhérent à la secte du fret est que vous ne serez pas en mesure de prédire ce qui va mal, ni même la classe de problèmes que vous pourriez rencontrer, car vous ne comprenez pas fondamentalement les décisions que vous prenez.Cela dit, voici quelques conseils.

Écrire des tests

Vous pouvez écrire des tests automatisés pour vous assurer que votre code fonctionne comme prévu, même si vous ne comprenez pas pourquoi le code fonctionne.Un exemple simple serait que si vous copiez et collez un algorithme de tri à partir d’un débordement de pile, vous pouvez écrire un test pour vous assurer qu’il fonctionne.

Soyez prudent, cependant, car les tests ne sont pas aussi bons pour prouver qu’il n’y a pas d’effets secondaires ou de bord inattendus cases.In l’exemple de l’algorithme de tri, vous ne saurez pas quels cas de bord vous devez vous inquiéter.

Refactorisez sans pitié

Plus vous conservez le code, plus il sera facile de raisonner sur le moment où une décision de chargement doit être modifiée.Et rappelez-vous, vous ne pouvez pas refactoriser efficacement sans tests.

Isoler le code culté du fret

Dans la mesure du possible, isoler le code culté du fret dans une classe ou un module.Plus vous pouvez l’isoler, plus vous limitez ses dommages potentiels.De plus, plus il est isolé, plus il sera facile de le remplacer ou de le réécrire une fois que vous en comprendrez plus.

Ne chargez pas cult dans les parties critiques de votre application

Par exemple, si une concurrence élevée est une nécessité absolue pour votre application, vous ne pouvez probablement pas copier du code de threading à partir du débordement de pile.Même choisir un langage qui gère bien la concurrence (comme Elixir, Go ou Clojure) ne résoudra pas comme par magie votre problème.Malheureusement (ou heureusement), vous devrez vraiment creuser et apprendre quelque chose.

Ne chargez pas le culte si l’échec conduit à de mauvaises choses

Si la sécurité, la vie privée, l’argent, etc. des gens. sont à risque, ne chargez pas le culte.À titre d’exemple évident, si le fabricant de rythme de quelqu’un exécute un certain one-liner C que vous avez copié à partir de Stack Overflow, vous feriez mieux de savoir pourquoi votre petit truc fonctionne et quels sont les cas d’échec et les effets secondaires.

Évitez les cultes de cargaison lorsque vous traitez avec des entrées variables

Par exemple, si vous ne connaissez pas très bien awk et que l’entrée de votre one-liner awk proviendra de l’entrée de l’utilisateur, elle risque de se casser.Si vous pouvez prédire les différentes formes que votre entrée peut prendre, cela vous aidera, mais vous devez garder à l’esprit que cela risque de casser sur des cas d’entrée que vous n’étiez pas en mesure de prévoir.

Surveiller en production

Juste parce que cela fonctionne sur votre machine, ne supposez pas que cela fonctionnera en production où l’environnement diffère et où les utilisateurs font des choses que vous n’avez jamais envisagées.La surveillance des erreurs, des exceptions, des échecs d’assertion et des performances peut vous permettre de savoir si quelque chose ne va pas avant que vos utilisateurs, vos clients ou votre patron ne s’en rendent compte.

Revue de code, programmation de paires, outils d’analyse statique, etc.

Obtenez d’autres yeux, virtuels ou autres, pour regarder votre code.La programmation par paires et la révision du code sont des exemples évidents, mais les outils d’analyse statique (par exemple CodeClimate) peuvent également être utiles.En plus de détecter des erreurs évidentes, ils sont particulièrement utiles pour signaler du code qui pourrait ne pas toujours fonctionner comme prévu.

Passez à une compréhension plus profonde

En commençant par la culture du fret, lorsque vous décidez de plonger profondément dans le sujet, vous aurez déjà un contexte.Le chemin vers une compréhension plus profonde peut être l’auto-apprentissage, le mentorat, la programmation en binôme ou tout simplement le faire vous-même pour apprendre.

Ce sont de vieilles nouvelles

Les conseils énumérés ci-dessus sont probablement tout ce que vous avez entendu auparavant.C’est parce que nous travaillons tous avec des connaissances limitées.Nous avons tous un culte de la cargaison tout le temps et nous avons développé une intuition, des techniques et des directives afin que nous puissions avancer avec une connaissance partielle et limiter les dégâts que nous pouvons faire.Plutôt que jamais cargo cult, les bons développeurs apprennent à cargo cult efficacement.