YAGNI, KISS, DRY, WET, SLAP, ASAP, YOLO - qu'est-ce que tout cela signifie?
Ave, codeur! Si vous avez déjà lu de la littérature de programmation en anglais, suivi des cours en anglais, travaillé avec d'autres codeurs anglophones ou simplement correspondu avec eux, vous avez probablement rencontré ces abréviations et lorsqu'un codeur barbu a dit KISS à un autre, je vous garantis que votre sourcil au moins légèrement surélevé.
Dans cet article, nous analyserons ce que ces mots, ou plutôt ces abréviations, sont populaires parmi les IT-shniks anglophones.
Visuels ici: youtu.be/ub0YtnSwqRA
KISS ("Reste simple, stupide")
Ce n'est pas un pattern, pas un anti-pattern ou même un groupe de rock des années 70, dans ce cas, c'est l'un des principes ou approches les plus populaires pour programmer quoi que ce soit.
En fait, ce principe exige que votre code soit aussi simple que possible, car un tas de fonctions inutiles qui se dupliquent et l'habitude de se gratter l'oreille gauche avec la main droite ne sont pas le signe d'un programmeur professionnel.
Plus le code est simple, plus il est facile de le comprendre, respectivement, moins il y a de chances de brûler une chaise sous une personne qui ramassera ce code après vous.
Steve McConnell a dit un jour: "Écrivez le code comme s'il était soutenu par un psychopathe violent qui sait où vous vivez."
Par conséquent, il vaut mieux ne pas vraiment compliquer les choses qui n'en ont pas besoin.
DRY ("Ne vous répétez pas")
Le principe Don't Repeat Yourself est de nature très similaire à KISS. C'est assez simple et en même temps a un sens large. C'est assez simple et en même temps a un sens large - vous avez la blague?
Copier et coller et dupliquer des fragments de votre propre code comme la scoliose ou la déficience visuelle - au fil du temps, tous les programmeurs en souffrent. Il n'y a rien de mal. Tout le monde a parfois besoin de vérifier rapidement quelque chose (comportement attendu ou autre) pour ensuite déterminer s'il vaut la peine de l'écrire correctement. Mais il est définitivement inacceptable d'envoyer un tel code en production.
DRY nous rappelle que chaque comportement répétitif dans le code peut et doit être récupéré (par exemple, à l'intérieur d'une fonction) pour une réutilisation ultérieure. Avoir deux morceaux du même code dans votre base de code n'est pas une bonne chose. Cela peut souvent entraîner une désynchronisation et d'autres erreurs dans votre code, sans parler de l'augmentation de la taille du programme.
WET ("Nous aimons taper")
Les solutions WET sont répandues dans les architectures à plusieurs niveaux où un développeur peut être chargé, par exemple, d'ajouter un champ de commentaire à un formulaire dans une application Web. La chaîne de texte "commentaire" peut être répétée dans une étiquette, une balise HTML, un nom de fonction de lecture, une variable privée, une base de données DDL, des requêtes, etc. L'approche DRY supprime cette redondance en utilisant des cadres qui réduisent ou éliminent toutes les tâches d'édition sauf les plus importantes, tout en laissant la possibilité d'ajouter de nouvelles variables en un seul endroit.
YAGNI ("Tu n'en auras pas besoin")
Vous n'en avez pas besoin - c'est un principe qui peut contredire les vues de certains programmeurs, ainsi que de ceux qui ont ajouté des décimètres au programme scolaire.
Être prêt pour l'avenir est généralement une bonne chose, mais pas dans la programmation. Laisser un code destiné uniquement aux futures extensions n'est pas un problème.
Mais si vous êtes une cyber-peluche par nature, et à partir de l'idée même de ne laisser que le nécessaire, la chaise sous vos rouleaux commence à fondre, alors voyons-le - est-ce une mauvaise approche de la programmation ou est-ce une clinique dans la vie?
Les projets de codeur ne sont pas des choses qui ont une fin claire. À moins que l'auteur n'abandonne l'idée (et ne la transmette à quelqu'un d'autre), le projet se poursuit essentiellement. Par conséquent, il y a et il y aura toujours place à l'amélioration, que ce soit le concept, l'architecture ou même le code lui-même.
C'est une chose - à quoi ressemble le code idéal dans votre tête - sans erreurs ni béquilles, et autre chose - ce qui se passe réellement.
Naturellement, une légère touche de tristesse et d'apathie peut comprendre le codeur par une froide soirée d'automne et le codeur peut décider de mettre dans le programme les soi-disant «points d'extension» (endroits conçus pour prendre facilement en compte les nouvelles fonctionnalités) s'ils ne sont pas utilisés raisonnablement ou ne sont pas une fonction obligatoire devenez alors juste un monument à la procrastination et ajoutez une complexité et une taille inutiles à la base de code. À bien y penser, cela va même à l'encontre du principe KISS discuté précédemment.
SLAP ("Principe d'abstraction à un niveau")
Le principe de couche unique d'abstraction (SLAP) définit comment nous devons organiser notre code (les fonctions pour être spécifiques) afin de le maintenir à jour.
Les fonctions longues et complexes sont difficiles à vivre. Ils sont difficiles à comprendre pour les autres développeurs et difficiles à tester. Si pas du tout sur nos doigts, alors, dès que nous sommes confrontés à une telle abomination, nous devons immédiatement la transformer en plusieurs petites fonctions!
Comme l'a dit Robert Martin, «les fonctions ne devraient faire qu'une seule chose, et elles devraient bien le faire».
Mais comment organiser exactement nos fonctions? Au fur et à mesure que vous, mon ami à quatre pattes, deviendrez plus expérimenté en programmation, vous commencerez à mieux comprendre les aspects pratiques, esthétiques et fonctionnels de la programmation et un principe appelé SLAP qui est destiné à vous aider.
En gros, vos fonctions ne devraient faire qu'une seule chose, ou en d'autres termes SLAP, ne devraient avoir qu'un seul niveau d'abstraction.
Fondamentalement, une fonction qui lit les entrées utilisateur, par exemple, n'a pas besoin de la traiter non plus. Au lieu de cela, vous devrez utiliser une fonction distincte qui se situe à un niveau d'abstraction différent et inférieur. Plus une fonction est générale et plus elle utilise d'autres fonctions, plus elle est élevée dans la hiérarchie d'abstraction.
FOOBAR ("F **** d au-delà de toute reconnaissance")
Pour paraphraser en russe: «brisé pour qu'il ne puisse pas être restauré».
C'est une expression merveilleuse qui est venue à l'informatique de l'argot militaire, avec d'autres chefs-d'œuvre, tels que, par exemple, SNAFU - "Situation normale - tout foutu"; c'est quelque chose comme: "la situation est tout à fait naturelle, mais tout a été en vain."
La légende raconte que les programmeurs C ont utilisé les noms «foo» et «bar» pour les variables comme soi-disant «espace réservé» ou espaces réservés, en particulier dans les exemples du didacticiel. Ainsi, leurs petites têtes brillantes étaient libérées du fardeau de trouver de nouveaux noms et pouvaient se concentrer sur la résolution de problèmes.
Au fil du temps, cela est devenu une tradition et a migré du C vers de nombreuses langues moins anciennes, de sorte que des exemples de ces noms peuvent être trouvés dans les manuels partout, et le mot «FooBar», appliqué au projet, signifie que vous pouvez commencer à chercher autre chose ...
ASAP ("Dès que possible")
"Dès que possible."
Récemment, c'est devenu une tendance «dès que raisonnablement possible» - «dès que possible, mais dans des limites raisonnables».
Il a également été utilisé à partir de l'argot de l'armée déjà pendant la Première Guerre mondiale. Il est activement utilisé à ce jour, si cet acronyme est souvent utilisé dans la correspondance avec les supérieurs, cela peut indiquer de manière éloquente le niveau d'organisation dans l'entreprise ou les compétences de gestion et la capacité de prioriser parmi les patrons. Mais il y a, bien sûr, des exceptions, lorsque la situation est devenue incontrôlable et Foobar en général.
FYI ("Pour votre information")
Le sens officiel est "Je le porte à votre attention", mais traduit vaguement: "pour que vous le sachiez". Se produit dans la correspondance e-mail partout, en particulier lorsque la correspondance n'est pas menée personnellement avec vous, le soleil clair, mais, néanmoins, ils ont décidé de vous informer.
TL; DR ("Trop long; je n'ai pas lu")
Un analogue de notre "multi-lettre, neosilil". Cela se voit souvent sous de longs articles, dans lesquels l'auteur révèle son âme et arrache les voiles, mais le lecteur est trop paresseux pour se plonger dans cet opus.
DIY ("Faites-le vous-même")
Fais le toi-même. Provient des noms de petits ateliers de construction vendant des produits pour réparer une maison plutôt que pour la construire. L'implication était que le travail est de petites choses et que vous pouvez le faire vous-même, sans embaucher de personnel qualifié.
Par la suite, le concept a migré vers l'informatique et peut convenir, par exemple, dans des situations où un spécialiste doit travailler dans un domaine connexe, mais il est si petit et trivial qu'il est plus facile de le faire soi-même.
Yolo on ne vit qu'une fois")
"On ne vit qu'une fois." Par analogie avec le latin «carpe diem» («saisir le moment»), il s'agit d'un appel à une vie bien remplie, même à des comportements qui peuvent comporter certains risques. C'est le dernier argument à la frontière avec une expérience déraisonnable ou un plaisir débridé, mais parfois il peut véhiculer un message plus raisonnable: il est stupide de laisser la peur dominer vos décisions, car vous ne vivez qu'une seule fois.
Et rappelez-vous, YOLO, alors KISS. C'était V. A bientôt sur la chaîne! Ave!