Le nom de ce modèle est fonction.
Plus précisément, il s'agit d'une interface, qui est généralement un ensemble de fonctions.
Quelles langues as-tu apprises?
L'une des premières lorsque nous apprenons la programmation, nous apprenons le principe de la logique réutilisable. Cela nous amène invariablement à fonctionner - la pierre angulaire de chaque projet logiciel. Les fonctionnalités elles-mêmes ne sont pas si mauvaises, mais c'est précisément parce qu'elles sont utilisées comme un composant réutilisable que les logiciels d'écriture, de maintenance et de mise à l'échelle deviennent si coûteux.
Pourquoi?
L'écriture de code réutilisable est difficile.
Non ce n'est pas comme ça. C'est inacceptable.
Tout développeur peut écrire du code réutilisable, quelle que soit son expérience. Des langages comme JavaScript, Python, Ruby et Go sont constitués de millions de petits modules communs qui démontrent la facilité d'écriture de code source simple et réutilisable. Il est facile d' écrire du code réutilisable .
Refactorisons cette déclaration.
Mais ce n'est pas le cas non plus. Jetez un œil à la bibliothèque node.js
repeat-string
en npm. Il ne fait que répéter la ligne et les développeurs la téléchargent dix-sept millions de fois par semaine.
Nombre de téléchargements de la chaîne de répétition en npm
Dix-sept millions est juste le nombre de téléchargements. Ce nombre ne nous donnera aucune idée du nombre de fois où cette fonction est utilisée dans le code source. Le montant doit être astronomique!
Alors qu'est-ce que je fais?
Comment pouvez-vous trouver un module comme
repeat-string
pour votre projet node.js? Recherchez "chaîne de répétition" dans npm . Peut-être que vous entrez "string repeat", mais les résultats seront similaires. Le problème dont je parle peut être vu dans le deuxième résultat de recherche. Et au quatrième, au neuvième, au dixième et au onzième.
Jetez un œil à ces exemples. Chaque bibliothèque offre un comportement complètement identique.
Exemples de bibliothèques de répétition de lignes npm
Voyez-vous quel est le problème?
Non, pas que l'un d'eux soit asynchrone pour une raison inconnue. Sans oublier que la répétition de chaînes fait partie du langage JavaScript (
"A".repeat(5)
) depuis plus de six ans maintenant . Le problème est que chaque bibliothèque est différente:
- Dans la signature des données entrantes. Certains peuvent recevoir
(string, int)
, d'autres peuvent recevoir(int, string)
. L'un accepte les nombres à virgule flottante, l'autre nécessite une fonction de rappel. - Dans la signature de la sortie. Chaque bibliothèque imprime une chaîne, sauf une, qui n'imprime rien et transmet son résultat à la fonction de rappel. Et permettez-moi de ne même pas commencer à analyser leurs erreurs.
- Dans le comportement quand ils sont exécutés. L'un est asynchrone, les autres sont synchrones.
- Par la méthode d'octroi de l'accès. Certains donnent accès à une seule fonction exportée, d'autres fournissent une fonction en tant que méthode d'un objet.
Vous pouvez blâmer JavaScript pour diverses raisons, mais ce n'est pas un problème avec la langue. En raison de la popularité de JavaScript et des limitations de ses bibliothèques standard, ce problème est si courant que j'ai pu le démontrer avec un exemple aussi simple que la répétition de chaînes. En revanche, rien ne m'empêche de recréer toutes ces différences dans une autre langue. C'est un exemple très simple, mais à mesure que la fonctionnalité devient plus complexe, ces différences deviennent encore plus prononcées.
Pourquoi c'est un problème?
Le problème est qu'une telle richesse d'options ne crée aucune valeur , seulement des problèmes. Ils n'affectent pas la «logique métier» (c'est-à-dire ce qui compte en premier lieu). Ce sont les détails de mise en œuvre. Parfois, ces options découlent d'un manque de quelque chose dans la langue ou le cadre, et parfois ce ne sont que des choix spontanés. Nous essayons de choisir une option qui simplifiera le travail du développeur maintenant ou dans le futur, mais il est impossible de prédire l'avenir. De telles solutions sont vraiment diaboliques - chaque option que vous choisissez semble bonne au début, alors que tout fonctionne. Nous recevons un coup de pouce de dopamine et nous avons l'impression d'être au sommet du monde. Seigneurs de tous les systèmes! Cependant, lorsque nous avons besoin d'ajouter, de remplacer ou de changer quelque chose, nous nous rendons compte que nous n'étions pas ce génie.
À quelle fréquence devons-nous changer quelque chose? Tous les jours. C'est ce que nous faisons. À quelle fréquence le logiciel est-il défectueux à cause de cela? Littéralement à chaque fois. Parfois, la panne est mineure et nous la réparons avec peu d'effort. Nous avons accepté le fait qu'un logiciel défectueux est normal. Même lorsque nous écrivons des tests automatisés qui ne font que vérifier que quelque chose est cassé.
Le problème des interfaces vient du fait qu'un programmeur peut prendre de nombreuses décisions au cours du processus de développement. Décisions telles que le choix entre les paramètres de position, les configurations et les éditeurs de liens, asynchrone ou synchrone, global ou local, avec état ou sans état, constructeurs contre usines, approche fonctionnelle ou orientée objet, et un nombre infini d'autres options. Chaque choix est déterminé par les meilleures pratiques modernes et chacun devient un grain de sable emprisonné à l'intérieur du mécanisme.
Ce problème n'est pas nouveaucependant, nous l'acceptons et enseignons cette approche à chaque nouvelle génération. Pourquoi? Le problème n'est pas que nous prenons les mauvaises décisions, mais que l'on nous présente de mauvaises options. Chaque option est un kaléidoscope de compromis, et la bonne réponse dépend du point de vue. Lorsque tout est un compromis, il y a toujours une meilleure option . Vous pouvez toujours réécrire votre code pour l'améliorer.
Refactorisons notre déclaration une troisième fois.
Cette déclaration n'est pas si attrayante, mais plus proche de la vérité.
Sans code à coller, nous devons repasser chaque pli de l'interface avant de pouvoir l'utiliser. Vous devez personnaliser chaque morceau de code qui entre dans l'application. Chaque entrée. Chaque conclusion. Chaque API. Nous poussons les linkers sur les adaptateurs et les emballons dans des usines basées sur les services. Mais aucune quantité de maquillage ne rendra votre modèle de conception joli .
C'est comme si nous construisions des logiciels au 18ème siècle. Nous avons scié manuellement les arbres en planches de toutes tailles. Nous fabriquons des marteaux et perforons des clous à partir de rien, juste pour construire une maison qui ressemble exactement à la suivante. Cela coûte trop cher et prend trop de temps. Même après l'achèvement du projet, nous sommes toujours tirés au sol par le fardeau du soutien. Les dimensions ne sont pas standard, le câblage choque les électriciens, et les constructeurs qui viennent de sortir de l'école professionnelle n'aiment pas la façon dont nous fabriquons les clous. Il est grand temps que Leroy-Merlin et le numérique 2x4 apparaissent dans le monde du logiciel.
«Salut, je m'appelle Tim. Je travaille en tant que responsable technique chez Google, j'ai 30 ans d'expérience en codage, mais je dois trouver comment obtenir la longueur d'une chaîne en Python. "
Pour obtenir de l'aide avec une API pour vous rechercher en permanence personnellement ?
Ce ne sera pas une surprise si je dis que nous pourrions avoir des normes suffisamment bonnes pour tout le monde. Microsoft a introduit la technologie COM dans les années 90 pour échanger la logique entre les applications écrites dans n'importe quel langage. La technologie JVM a presque le même âge et a démontré combien de langues peuvent gérer le même bytecode et également interagir les unes avec les autres. Le monde continue de redécouvrir Flow depuis des décennies et Linda comme moyen de relier les boîtes noires distribuées les unes aux autres, et Docker est une nouvelle façon de voir ce que peut être une boîte noire moderne.
Ce problème présente de nombreuses possibilités, et beaucoup essaient de le résoudre. Dapr et WasmCloud semblent de nouvelles solutions prometteuses ... Ils résolvent partiellement le problème de différentes manières. Aussi triste que soit l'état du développement logiciel aujourd'hui, j'ai plus d'espoir aujourd'hui qu'au cours des 10 dernières années. Cette brève période de promesses passionnantes est venue de JavaScript, qui promettait de créer une plate-forme universelle sur laquelle des applications amorphes pourraient se répandre dans le monde entier, mais en conséquence, elle s'est transformée en un tas d'électrons, de réactions et de RAM gaspillée. Pour moi, Web Assembly est devenu une nouvelle source d'optimisme. C'est loin d'être idéal, mais c'est aussi merveilleux. L'idéal ne gagne jamais.
Publicité
Vous recherchez un serveur à louer pour les projets de débogage, un serveur pour le développement et l'hébergement? Vous êtes définitivement notre client :) Facturation quotidienne des serveurs, créez votre propre configuration en quelques clics, l'anti-DDoS est déjà inclus dans le prix.
Abonnez-vous à notre chat sur Telegram .
