Practical Go: conseils pratiques pour la rédaction de programmes Go maintenables

Ce travail est placé sous licence Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Pourquoi devons-nous rechercher la simplicité? Pourquoi est-il important que les programmes écrit en Go soient simples?

Nous avons tous été dans une situation où nous nous sommes dit "Je ne comprends pas ce code", n’est ce pas ? Nous avons tous travaillé sur des programmes dans lesquels nous avons peur de faire un changement parce que nous craignions que cela ne casse une autre partie du programme, une partie que nous ne comprenons pas et que nous ne savons pas réparer: c’est de la complexité.

La complexité transforme un logiciel fiable en logiciel peu fiable. C’est la complexité qui tue les projets logiciels. Voici pourquoi la simplicité est le but le plus élevé du langage Go. Quels que soient les programmes que nous écrivions, nous devrions être en mesure de convenir qu’ils sont simples.

Pourquoi est il important que le code Go soit lisible ? Pouquoi devrions-nous nous efforcer d’écrire du code lisible ?

La lisibilité est importante car tous les logiciels, et pas seulement les programmes Go, sont écrits par des humains pour être lus par d’autres humains. Le fait que les logiciels soient exécutés également par des machines est secondaire.

Le code est lu beaucoup plus de fois qu’il n’a été écrit: un seul morceau de code sera lu des centaines, voire des milliers de fois au cours de sa durée de vie.

La lisibilité est essentielle pour comprendre ce que fait le programme. Si vous ne pouvez pas comprendre ce que fait un programme, comment pouvez-vous espérer le maintenir? Si un logiciel ne peut pas être maintenu, il sera réécrit; Et ça sera la dernière fois que votre entreprise investira dans Go.

Si vous écrivez un programme pour vous-même, il ne devra peut-être fonctionner qu’une seule fois, ou que vous êtes la seule personne qui le verra jamais, dans ce cas faites ce qui vous convient le mieux. Mais s’il s’agit d’un logiciel auquel plus d’une personne contribuera ou qui sera utilisée par des personnes suffisamment longtemps pour que les exigences, les fonctionnalités ou l’environnement dans lequel il sera exécuté évolue, votre objectif doit être que votre programme puisse être maintenu.

La première étape vers l’écriture d’un code maintenable consiste à s’assurer que le code est lisible.

Le dernier principe sous-jacent que je tiens à souligner est celui de la productivité : la productivité des développeurs est un sujet épineux, mais il se résume à ceci: combien de temps consacrez-vous à des travaux utiles dans l’attente de vos outils ou désespérément perdus dans une base de code étrangère? Les développeurs Go devrait sentir qu’ils peuvent faire beaucoup avec Go.

Une blague dit que Go a été conçu en attendant la compilation d’un programme C++. La compilation rapide est l’un des éléments clés de Go, c’est un point essentiel pour attirer de nouveau développeurs. Bien que la vitesse de compilation reste un champ de bataille constant, il est juste de dire que les compilations prennent quelques minutes dans d’autres langages et quelques secondes dans Go. Cela aide les développeurs Go à se sentir aussi productif que leurs homologues travaillant dans des langages interprétés sans les problèmes de fiabilité inhérents à ces langages.

Plus fondamental à la question de productivité des développeurs, le développeur Go réalise que le code est écrit pour être lu et place ainsi l’acte de lire du code au-dessus de celui de l’écrire. Go va jusqu’à imposer, via l’outillage et la paramétrage, à ce que tout code soit formater dans un style spécifique. Cela élimine la friction de l’apprentissage d’un dialecte spécifique à un projet et aide à repérer les erreurs parce qu’elles ont simplement l'air incorrectes.

Les développeurs Go ne passent pas des jours à déboguer des erreurs de compilation impénétrables. Ils ne perdent pas du temps avec des scripts de compilation compliqués ou à déployer du code en production. Et surtout, ils ne passent pas leur temps à essayer de comprendre ce que leurs collègues ont écrit.

C’est à la productivité que pensent les équipes de développeurs Go lorsqu’ils disent que le langage doit passer à l’échelle.

Go n’est pas un langage optimisé pour écrire des programmes intelligibles sur une seule ligne. Go n’est pas optimisé pour écrire un programme dans le moins de lignes possibles. Nous ne l’avons pas optimisé en fonction de la taille du code source sur le disque, ni du temps qu’il faut pour taper le code du programme dans un éditeur.

La clé de cette clarté réside dans les identifiants que nous choisissons dans nos programmes Go. Parlons des qualités d’un bon identifiant:

Parlons de chacune de ces propriétés plus en détail.

Parfois, les gens critiquent le style Go qui recommande des noms de variables courts. Comme l’a dit Rob Pike: "Les programmeurs Go veulent des identifiants de bonne longueur".^[1]

Andrew Gerrand suggère d’utiliser des identifiants plus longs pour indiquer au lecteur des choses plus importantes.

Nous pouvons en tirer quelques lignes directrices:

Regardons cet exemple

Dans cet exemple, la variable de plage p est déclarée à la ligne 13 et est utilisée une seule fois, à la ligne suivante: p vit très peu de temps à la fois sur la page et pendant l’exécution de la fonction. Un lecteur intéressé par la valeur de p n’a besoin de lire que deux lignes.

En comparaison people est déclaré dans les paramètres de la fonction et vie pendant sept lignes. La même chose est vraie pour sum et count, cela justifie donc l’utilisation de noms plus longs. Le lecteur doit parcourir un plus grand nombre de lignes pour les localiser, il faut donc qu’elles soient plus lisibles.

J’aurais pu choisir s pour sum et c (ou éventuellement n ) pour count mais cela aurait réduit toutes les variables du programme au même niveau d’importance. J’aurais pu choisir p au lieu de people mais cela aurait posé problème pour le choix du nom de la variable dans la boucle for …​ range. Le choix de person à la place de p dans la boucle aurait l’air bizarre, car la variable éphémère d’itération porte un nom plus long que le groupe de valeurs dont elle est dérivée.

Vous ne devriez pas nommer vos variables d’après leurs types pour la même raison que vous ne nommez pas vos animaux domestiques "chien" et "chat". Vous ne devriez pas non plus inclure le nom de votre type dans le nom de votre variable pour les mêmes raison.

Le nom de la variable doit décrire son contenu, pas le type de contenu. Prenons l’exemple ci-dessous:

Quels sont les avantages de cette déclaration? Nous pouvons voir que c’est une map et que cela à un rapport avec le type *User, c’est probablement une boone chose. Mais usersMap est une map, or Go est un langage typé de façon statique, il ne nous permettra pas d’utiliser accidentellement pour autre chose, le suffixe Map est donc redondant.

Maintenant considérons que nous ayons à déclarer d’autres variables telles que:

Nous avons maintenant trois variables de type map, userMap, companiesMap et productsMap, chacun étant un map de strings sur différents types. Nous savons que ce sont des maps et que leurs déclarations nous empechent d’utiliser l’une à la place de l’autre. Le compilateur déclanchera une erreur si nous essayons d’utiliser companiesMap dans le code alors qu’il s’attend à trouver une map[string]*User. Dans cette situation, il est clair que le suffixe Map n’améliore pas la clarté du code, tout en contraignant à le saisir partout.

Ma suggestion est d’éviter tout suffixe qui ressemble au type de la variable.

Ce conseil s’applique également aux paramètres d’une fonction, par exemple:

Nommer config le paramètre de type *Config est redondant. Nous savons qu’il est de type *Config puisque c’est écrit.

Dans ce cas, considérer l’utilisation de conf, voir même juste c si la durée d’utilisation de la variable est suffisamment courte.

S’il y a plus d’une variable de type *Config, l’usage de conf1 et conf2 est moins descriptif que original et updated car ces dernières risquent moins d’être confondues.

Une autre propriété d’un bon nom est qu’il doit être prévisible. Le lecteur devrait être capable de comprendre l’utilisation d’un nom lorsqu’il le rencontre pour la première fois. Lorsqu’ils rencontrent un nom commun, ils devraient pouvoir supposer qu’il n’a pas changé de signification depuis la dernière fois qu’il l’a vu.

Par exemple, si votre code transmet un handle de base de données, assurez-vous qu’il porte le même nom chaque fois qu’il apparait: plutôt que de combiner d *sql.DB, dbase *sql.DB, DB *sql.DB et database *sql.DB, au lieu de cela harmoniser les noms sur quelque chose comme:

Cela favorise la reconnaissance: si vous voyez une db, vous savez que c’est un *sql.DB et que celle-ci a été identifiée localement ou fournie par l’appelant.

Des conseils similaires s’appliquent aux récepteurs de méthode; utilisez le même nom de récepteur pour chaque méthode de ce type. Cela permet au lecteur de s’approprier plus facilement l’utilisation du récepteur entre les méthodes de ce type.

Enfin, certaines variables d’une seule lettre sont traditionnellement associées aux boucles et au comptage. Par exemple, i, j et k sont généralement des variable d’incrémentation pour les boucles for. n est généralement associé à un compteur ou à un accumulateur. v est un raccourci courant pour une valeur dans une fonction de codage générique, k est couramment utilisé pour la clé d’une map et s est souvent utilisé en tant que raccourci pour les paramètres de type chaîne de caractère.

Comme avec l’exemple de base de données ci-dessus, les programmeurs s’attendent à ce que i soit une variable d’incrément d’une boucle. Si vous vous assurez que i est toujours une variable de boucle, non utilisée dans d’autres contextes en dehors d’une boucle for, lorsque les lecteurs rencontrent une variable appelée i ou j, ils savent qu’une boucle est proche.

Go propose six façons de déclarer des variables

Je suis sûr qu’il y en a d’autres auquelles je n’ai pas pensé. C’est quelque chose que les concepteurs de Go reconnaisse comme probablement une erreur, mais il est trop tard pour changer les choses maintenant. Avec toutes ces différentes façons de déclarer une variable, comment éviter que chaque développeur Go choisit son propre style ?

Je souhaite présenter des suggestions sur la façon de déclarer des variables dans mes programmes, c’est le style que j’essaie d’utiliser dans la mesure du possible.

Le préfixe var sert à indiquer que cette variable a été délibérément déclarée comme étant la valeur zéro du type indiqué. Cela correspond également à la nécessité de déclarer des variables au niveau du package à l’aide de var, par opposition à la syntaxe de déclaration courte - bien que je ferai valoir plus tard que vous devriez absolument éviter d’utiliser des variables au niveau du package.

Pour expliquer pourquoi, regardons l’exemple précédent, mais cette fois en initialisant délibérément chaque variable:

Dans les premier et troisième exemples, dans Go, il n’y a pas de conversions automatiques d’un type à un autre; le type situé à gauche de l’opérateur d’affectation doit être identique à celui situé à droite. Le compilateur peut en déduire le type. De la variable déclarée à partir du type du côté droit, l’exemple peut être écrit de manière plus concise, comme ceci:

Cela nous laisse avec une initialisation explicite des players sur 0 ce qui est redondant car 0 est la valeur zéro des joueurs. Il est donc préférable de préciser que nous allons utiliser la valeur zéro en écrivant à la place

Qu’en est-il de la deuxième déclaration? Nous ne pouvons pas écrire

Parceque nil n’a pas de type.^[3]Au lieu de cela, nous avons le choix. Voulons-nous la valeur zéro pour une slice?

ou voulons-nous créer une slice avec zéro éléments ?

Si nous voulions pour ce dernier, que ce ne soit pas la valeur zéro pour la slice, alors nous devrions indiquer clairement au lecteur que nous faisons ce choix en utilisant la formulation de déclaration abrégé :

Ce qui indique au lecteur que nous avons choisi d’initialiser les things explicitement.

Cela nous amène à la troisième déclaration,

Ce qui à la fois initialise explicitement une variable et introduit l’utilisation inhabituelle du mot clé new que certains développeurs Go n’aiment pas. Si nous appliquons notre recommandation de syntaxe de déclaration courte, l’instruction devient

Ce qui indique clairement que thing est explicitement initialisée au résultat de new(Thing) - un pointeur vers un Thing - mais nous laisse toujours l’utilisation inhabituelle de new. Nous pourrions résoudre ce point en utilisant la forme compacte littérale initialisation de struct,

Ce qui fait la même chose que new(Thing), d’où la raison pour laquelle certains développeur Go sont contrariés par cette duplication de fonctionnalité. Cependant, cela signifie que nous initialisons clairement thing avec un pointeur sur un Thing{}, qui est la valeur zéro pour un Thing.

Au lieu de cela, nous devrions reconnaître que thing est déclarée comme étant sa valeur zéro et utiliser l’adresse de l’opérateur pour transmettre l’adresse de thing à json.Unmarshall

En résumé:

J’ai parlé d’un objectif de l’ingénierie logicielle visant à produire du code lisible et maintenable, et vous allez pouvoir consacrer l’essentiel de votre carrière à des projets dont vous n’êtes pas le seul auteur. Mon conseil dans cette situation est de suivre le style de l’équipe.

Changer de style au milieu d’un fichier est discordant. L’uniformité, même si ce n’est pas votre approche préférée, a plus de valeur pour la maintenabilité que vos préférences personnelles. Ma règle de base est la suivante: si le code passe dans gofmt alors cela ne vaut généralement pas la peine de faire une revue de code pour ça.

Lorsque vous ajoutez un commentaire à une variable ou à une constante, ce commentaire doit décrire le contenu de la variable et non son objectif.

Dans cet exemple, le commentaire explique pourquoi la valeur six est attribuée à randomNumber. Le commentaire ne décrit pas l’utilisation où randomNumber sera utilisé. Voici d’autres exemples:

Dans le contexte de HTTP, le code 100 est appelé StatusContinue, tel que défini dans la RFC 7231, section 6.2.1.

Puisque godoc est la documentation de votre package, vous devriez toujours ajouter un commentaire pour chaque symbole public - variable, constante, fonction et méthode - déclaré dans votre package.

Voici deux règles du guide de style Google

Il y a une exception à cette règle : vous n’avez pas besoin de documenter les méthodes qui implémentent une interface. En particulier, ne faites pas ça :

Ce commentaire ne dit rien. Il ne vous dit pas ce que fait la méthode, en fait c’est pire, il vous dit d’aller chercher la documentation ailleurs. Dans cette situation, je suggère de supprimer complètement ce commentaire.

Voici un exemple du package io

Notez que la déclaration de LimitedReader est directement précédée de la fonction qui l’utilise, et la déclaration de LimitedReader suit la déclaration de LimitedReader elle-même. Même si LimitedReader.Read n’a pas de documentation en soi, il est clair qu’il s’agit d’une implémentation de io.Reader.

Écrire un bon package Go commence par le choix d’un bon nom du package. Pensez au nom de votre package comme une accroche-éclair pour décrire ce qu’il fait en un seul mot.

Tout comme j’ai parlé des noms de variables dans la section précédente, le nom d’un package est très important. La règle de base que je suis n’est pas "quels types dois-je mettre dans ce package ?". Normalement, la réponse à cette question n’est pas "ce package fournit le type X", mais "ce package vous permet de parler HTTP".

Une cause fréquente de mauvais noms de packages est ce que l’on appelle les packages utilitaires. Ce sont des packages où les aides et le code utilitaire communs se figent avec le temps. Comme ces packages contiennent un assortiment de fonctions sans rapport, leur utilité est difficile à décrire en termes de ce que le package fournit. Cela conduit souvent à ce que le nom du package soit dérivé de ce qu’il contient - les utilitaires.

Les noms de packages comme utils ou helpers se retrouvent couramment dans les grands projets qui ont développé des hiérarchies de packages profondes et qui veulent partager les fonctions d’aide sans rencontrer de boucles d’importation. En extrayant les fonctions utilitaires vers un nouveau package, la boucle d’importation est rompue, mais parce que le package provient d’un problème de conception dans le projet, son nom ne reflète pas son but, seulement sa fonction de rupture du cycle d’importation.

Ma recommandation pour améliorer le nom des packages d' utils ou d' aides est d’analyser où ils sont appelés et si possible de déplacer les fonctions pertinentes dans le package de l’appelant. Même si cela implique de dupliquer du code d’aide, c’est mieux que d’introduire une dépendance d’importation entre deux packages.

Dans le cas où les fonctions utilitaires sont utilisées à de nombreux endroits, préférez plusieurs packages, chacun centré sur un seul aspect, à un seul package monolithique.

Les packages avec des noms tels que base ou commun sont souvent trouvés lorsque des fonctionnalités communes à deux ou plusieurs implémentations, ou des types communs pour un client et un serveur, ont été refaits dans un package séparé. Je crois que la solution est de réduire le nombre de packages, de combiner le client, le serveur et le code commun en un seul package nommé d’après la fonction du package.

Par exemple, le package net/http n’a pas de sous-packageage client et server, mais un fichier client.go et server.go, contenant chacun leurs types respectifs, et un fichier transport.go pour le code de transport du message commun.

Comme Go n’utilise pas d’exceptions pour le flux de contrôle, il n’est pas nécessaire d’indenter profondément votre code juste pour fournir une structure de niveau supérieur pour les blocs try et catch. Plutôt que d’imbriquer le chemin qui réussi de plus en plus profondément vers la droite, le code Go est écrit dans un style où le chemin du succès continue sur l’écran au fur et à mesure que la fonction progresse. Mon ami Mat Ryer appelle cette pratique "le codage en ligne de mire". ^[5]

Ceci est réalisé en utilisant des clauses de garde, des blocs conditionnels avec des conditions préalables à l’entrée d’une fonction. Voici un exemple tiré du package bytes,

En entrant dans UnreadRune, l’état de b.lastRead est vérifié et si l’opération précédente n’était pas ReadRune, une erreur est immédiatement renvoyée. De là, le reste de la fonction procède avec l’affirmation que b.lastRead est supérieur à opInvalid.

Comparez ceci à la même fonction écrite sans clause de garde,

Le bloc de la condition qui réussi, cas le plus courant, est imbriqué à l’intérieur de la première condition if et la condition qui réussie retourne nil. La découverte de cela nécessite un contrôle minutieux des accolades de fermeture. La dernière ligne de la fonction renvoie maintenant une erreur, et l’appelé doit tracer l’exécution de la fonction jusqu’à l’accolade d’ouverture correspondante pour savoir quand le contrôle va atteindre ce point.

C’est plus sujet aux erreurs pour le lecteur et le développeur qui maintient le code, d’où la raison pour laquelle Go préfère utiliser des clauses de garde et retourner l’erreur au plus tôt.

Chaque déclaration de variable, en supposant qu’aucun initialisateur explicite n’est fourni, sera automatiquement initialisée à une valeur qui correspond au contenu de la mémoire mise à zéro. Il s’agit de la valeur zéro. Le type de la valeur détermine la valeur zéro de la valeur ; pour les types numériques, elle est égale à zéro, pour les types de pointeurs, elle est égale à nil, de même pour les slices, les maps et les channels.

Cette propriété de toujours mettre une valeur à une valeur par défaut connue est importante pour la sécurité et l’exactitude de votre programme et peut rendre vos programmes Go plus simples et plus compacts. C’est ce dont parlent les programmeurs de Go lorsqu’ils disent "donnez à vos structures une valeur zéro utile".

Considérons le type sync.Mutex. sync.Mutex contient deux champs entiers non exportés, représentant l’état interne du mutex. Grâce à la valeur zéro, ces champs seront mis à 0 à chaque fois qu’un sync.Mutex est déclaré. sync.Mutex a été délibérément codé pour profiter de cette propriété, rendant le type utilisable sans initialisation explicite.

Un autre exemple d’un type avec une valeur zéro utile est bytes.Buffer. Vous pouvez déclarer un bytes.Buffer et commencer à y écrire sans initialisation explicite.

Une propriété utile des slises est que leur valeur zéro est nil. Cela a du sens si l’on considère la définition d’un en-tête de la slice dans le runtime.

La valeur zéro de cette structure impliquerait que len et cap ont la valeur 0, et le array, le pointeur vers la mémoire contenant le contenu du tableau de support de la slice, serait nil. Cela signifie que vous n’avez pas besoin de faire explicitement une slice, vous pouvez simplement le déclarer.

Une propriété utile, quoique surprenante, des pointeurs non initialisées - aucun pointeur - est que vous pouvez appeler des méthodes sur des types qui ont une valeur nulle. Ceci peut être utilisé pour fournir des valeurs par défaut simplement.

La clé pour écrire des programmes maintenables est qu’ils doivent être couplés de manière lâche - un changement dans un package devrait avoir une faible probabilité d’affecter un autre package qui ne dépend pas directement du premier.

Il y a deux excellentes façons d’obtenir un couplage lâche en Go

Dans Go, nous pouvons déclarer des variables à la portée de la fonction ou de la méthode, ainsi qu’à la portée du package. Lorsque la variable est publique, avec un identificateur commençant par une majuscule, sa portée est effectivement globale à l’ensemble du programme - tout package peut observer le type et le contenu de cette variable à tout moment.

L’état global mutable introduit un couplage étroit entre les parties indépendantes de votre programme car les variables globales deviennent un paramètre invisible pour chaque fonction de votre programme ! Toute fonction qui repose sur une variable globale peut être cassée si le type de cette variable change. Toute fonction qui repose sur l’état d’une variable globale peut être cassée si une autre partie du programme change cette variable.

Si vous voulez réduire le couplage, une variable globale est créée,

Une des choses que j’ai tendance à retenir dans la révision de code pour les programmeurs qui passent d’autres langages à Go est qu’ils ont tendance à trop utiliser les packages.

Go ne fournit pas de moyens élaborés d’établir la visibilité. Go manque de modificateurs d’accès de Java, public, protected, private et de façon implicite default. Il n’y a pas d’équivalent à la notion de classes friend du C++.

En Go nous n’avons que deux modificateurs d’accès, public et privé, indiqués par la majuscule de la première lettre de l’identifiant. Si un identifiant est public, son nom commence par une majuscule, cet identifiant peut être référencé par tout autre package Go.

Étant donné le choix limité pour contrôler l’accès aux symboles d’un package, quelles pratiques les programmeurs Go doivent-ils suivre pour éviter de créer des hiérarchies de packages trop compliquées ?

Le conseil que je me surprends à répéter est de préférer des packages moins nombreux et plus grands. Votre position par défaut devrait être de ne pas créer un nouveau package. Cela conduira à ce que trop de types soient rendus publics, créant ainsi une surface API large et peu profonde pour votre package…​

Les sections qui suivent explorent cette suggestion plus en détail.

Votre fonction main et votre package main devraient en faire le moins possible. C’est parce que main.main agit comme un singleton ; il ne peut y avoir qu’une seule fonction principale dans un programme, y compris les tests.

Parce que main.main est un singleton, il y a beaucoup d’hypothèses intégrées dans les choses que main.main appellera qu’elles ne seront appelées que pendant main.main ou main.init, et seulement une fois. Il est donc difficile d’écrire des tests pour du code écrit dans main.main, donc vous devriez vous efforcer de déplacer le plus possible votre logique métier hors de votre fonction principale et idéalement hors de votre package main.

Si vous deviez retirer quelque chose de cette présentation, ce devrait être ce conseil de Josh Bloch. Si une API est difficile à utiliser pour des choses simples, alors chaque appel de l’API aura l’air compliquée. Lorsque l’appel réelle de l’API est compliquée, elle sera moins évidente et plus susceptible d’être négligée.

Il y a quelques années, j’ai donné une conférence ^[8] sur l’utilisation des options fonctionnelles ^[9] pour rendre les API plus faciles à utiliser pour leur cas par défaut. L’essentiel de cet exposé était que vous devriez concevoir vos APIs pour le cas d’utilisation commun. Autrement dit, votre API ne devrait pas exiger de l’appelant qu’il fournisse des paramètres dont il ne se soucie pas.

Supposons que l’on m’ait confié la tâche d’écrire une fonction qui permet de rendre persistante sur disque une structue Documents.

Je pourrais écrire cette fonction, Save, qui prend *os.File comme destination pour écrire le Document. Mais cela pose quelques problèmes

La déclaration de Save empêche la possibilité d’écrire les données dans un emplacement réseau. En supposant que le stockage en réseau est susceptible de devenir nécessaire plus tard, la définition de cette fonction devrait changer, ce qui aurait un impact sur tous ses appelants. De plus Save est pénible à tester, car il fonctionne directement avec des fichiers sur disque. Ainsi, pour vérifier son fonctionnement, le test devrait lire le contenu du fichier après avoir été écrit. Et je devrais également m’assurer que f est écrit dans un endroit temporaire et toujours supprimé par la suite.

*os.File définit également un grand nombre de méthodes qui ne sont pas pertinentes pour l’enregistrement, comme la lecture des répertoires et la vérification pour voir si un chemin est un lien symbolique. Il serait utile que la définition de la fonction Save ne puisse décrire que les parties d' *os.File qui sont pertinentes.

Que pouvons-nous faire ?

En utilisant io.ReadWriteCloser nous pouvons appliquer le principe de ségrégation d’interface pour redéfinir Save pour prendre une interface qui décrit des choses plus générales en forme de fichier.

Avec ce changement, n’importe quel type qui implémente l’interface io.ReadWriteCloser peut être substitué au précédent *os.File.

Ceci rend l’enregistrement à la fois plus large dans son application, et clarifie à l’appelant de l’enregistrement quelles méthodes du type *os.File sont pertinentes pour son opération.

Et en tant qu’auteur de Save, je n’ai plus la possibilité d’appeler ces méthodes non liées sur *os.File car elles sont cachées derrière l’interface io.ReadWriteCloser.

Mais nous pouvons aller un peu plus loin avec le principe de la ségrégation des interfaces.

Premièrement, il est peu probable que si la fonction Save suit le principe de la responsabilité unique, elle lira le fichier qu’elle vient d’écrire pour en vérifier le contenu, ce qui devrait être la responsabilité d’un autre code.

Ainsi, nous pouvons réduire la spécification de l’interface que nous passons à Save à l’écriture et à la fermeture.

Deuxièmement, en dotant Save d’un mécanisme de fermeture de son flux, dont nous avons hérité dans ce désir de le faire ressembler encore à un fichier, la question se pose de savoir dans quelles circonstances le wc sera fermé.

Éventuellement, Save appellera Close sans condition, ou peut-être Close sera appelé en cas de succès. Cela pose un problème pour l’appelant de Save car il peut vouloir écrire des données supplémentaires dans le flux après que le document soit écrit.

Une meilleure solution serait de redéfinir Save pour ne prendre qu’un io.Writer, le décharger complètement de la responsabilité de faire autre chose que d’écrire des données dans un flux.

En appliquant le principe de ségrégation d’interface à notre fonction Save, les résultats ont été simultanément une fonction qui est la plus spécifique par rapport à ses exigences - elle n’a besoin que d’une chose inscriptible - et la plus générale par rapport à sa fonction, nous pouvons maintenant utiliser Save pour sauvegarder nos données dans tout fichier qui implémente io.Writer.

Si vous étiez dans ma présentation hier, j’ai parlé des ébauches de propositions visant à améliorer le traitement des erreurs. Mais savez-vous ce qui est mieux qu’une syntaxe améliorée pour la gestion des erreurs ? Pas besoin de gérer les erreurs du tout.

Cette section s’inspire du livre récent de John Ousterhout, A philosophy of Software Design footnote:[]. L’un des chapitres de ce livre s’intitule "Définir les erreurs hors de l’existence". Nous allons essayer d’appliquer ce conseil à Go.

Enfin, je tiens à mentionner que vous ne devez traiter les erreurs qu’une seule fois. Gérer une erreur signifie inspecter la valeur de l’erreur et prendre une seule décision.

Si vous prenez moins d’une décision, vous ignorez l’erreur. Comme nous le voyons ici, l’erreur de w.WriteAll est éliminée.

Mais prendre plus d’une décision en réponse à une seule erreur est également problématique. Ce qui suit est un code que je rencontre fréquemment.

Dans cet exemple, si une erreur se produit pendant w.Write, une ligne sera écrite dans un fichier journal, notant le fichier et la ligne où l’erreur s’est produite, et l’erreur est également renvoyée à l’appelant, qui éventuellement va le journaliser, et renvoyer jusqu’en haut du programme.

L’appelant fait probablement la même chose

Vous obtenez ainsi une pile de lignes en double dans vos logs,

mais en haut du programme, vous obtenez l’erreur originale sans aucun contexte.

J’aimerais aller un peu plus loin parce que je ne considère pas que les problèmes liés à l’enregistrement et au retour ne sont qu’une question de préférence personnelle.

Le problème que je vois beaucoup est que les programmeurs oublient de revenir d’une erreur. Comme nous l’avons déjà dit, le style Go consiste à utiliser des clauses de garde, à vérifier les conditions préalables au fur et à mesure que la fonction progresse et à revenir tôt.

Dans cet exemple, l’auteur a vérifié l’erreur, l’a enregistrée, mais a oublié de revenir. Cela a causé un bug subtil.

Le contrat de traitement des erreurs dans Go stipule que vous ne pouvez pas faire d’hypothèses sur le contenu d’autres valeurs de retour en présence d’une erreur. Comme la formation JSON a échoué, le contenu de buf est inconnu, peut-être qu’il ne contient rien, mais pire il pourrait contenir un fragment JSON à moitié écrit.

Parce que le programmeur a oublié de revenir après avoir vérifié et journalisé l’erreur, le tampon corrompu sera passé à WriteAll, qui réussira probablement et donc le fichier de configuration sera écrit incorrectement. Cependant, la fonction retournera très bien, et la seule indication qu’un problème s’est produit sera une simple ligne de log se plaignant de la formation de JSON, et non un échec à écrire la configuration.

Quel est le problème avec ce programme ?

Le programme fait ce que nous avions prévu, il sert un simple serveur web. Mais il fait aussi quelque chose d’autre en même temps, il gaspille le CPU dans une boucle infinie. C’est parce que le for{} sur la dernière ligne de main va bloquer la goroutine principal parce qu’il ne fait aucune E/S, n’attend pas sur un verrou, n’envoie ou ne reçoit pas sur un canal, ou ne communique pas avec le scheduler.

Comme le runtime Go est généralement planifié en coopération, ce programme va tourner en vain sur un seul processeur, et peut finir par être bloqué en temps réel.

Comment pourrions-nous régler ce problème ? Voici une suggestion.

Cela peut paraître stupide, mais c’est une solution commune que je vois couramment dans la nature. C’est symptomatique de ne pas comprendre le problème sous-jacent.

Maintenant, si vous êtes un peu plus expérimenté en go, vous pouvez écrire quelque chose comme ceci.

Une instruction select vide sera bloquée indéfiniment. C’est une propriété utile parce que maintenant nous ne faisons pas tourner un CPU entier juste pour appeler runtime.GoSched(). Cependant, nous ne traitons que le symptôme, pas la cause.

Je veux vous présenter une autre solution qui, je l’espère, vous est déjà venue à l’esprit. Plutôt que d’exécuter http.ListenAndServe dans un goroutine, nous laissant avec le problème de ce qu’il faut faire avec le goroutine principal, exécutez simplement http.ListenAndServe sur le goroutine principal lui-même.

Voici donc mon premier conseil : si votre goroutine ne peut pas progresser tant qu’elle n’a pas obtenu le résultat d’une autre, il est souvent plus simple de faire le travail vous-même plutôt que de le déléguer. Ceci élimine souvent beaucoup de suivi d’état et de manipulation de canal nécessaire pour sonder un résultat depuis un goroutine jusqu’à son initiateur.

Quelle est la différence entre ces deux API ?

Tout d’abord, les différences évidentes ; le premier exemple lit un répertoire dans une slice puis retourne la slice entière, ou une erreur si quelque chose a mal tourné. Cela se produit de manière synchrone, l’appelant de ListDirectory bloque jusqu’à ce que toutes les entrées du répertoire aient été lues. En fonction de la taille du répertoire, cela peut prendre beaucoup de temps, et pourrait potentiellement allouer beaucoup de mémoire à la construction de la diapositive des noms des entrées du répertoire.

Examinons le deuxième exemple. C’est un peu plus Go comme, ListDirectory renvoie un canal sur lequel les entrées de répertoire seront passées. Quand le canal est fermé, c’est votre indication qu’il n’y a plus d’entrées de répertoire. Comme la population du canal se produit après le retour de ListDirectory, ListDirectory est probablement en train de démarrer un goroutine pour peupler le canal.

La version canal de ListDirectory a deux autres problèmes :

La solution aux problèmes des deux implémentations est d’utiliser un callback, une fonction qui est appelée dans le contexte de chaque entrée de répertoire lors de son exécution.

Il n’est pas surprenant que c’est ainsi que fonctionne la fonction filepath.WalkDir.

L’exemple précédent montrait l’utilisation d’une goroutine quand elle n’était pas vraiment nécessaire. Mais l’une des raisons principales de l’utilisation de Go est la première classe de fonctionnalités de concomitance des offres du langage Go. En effet, il existe de nombreux cas où vous souhaitez exploiter le parallélisme disponible dans votre matériel. Pour ce faire, vous devez utiliser des goroutines.

Cette application simple sert le trafic http sur deux ports différents, le port 8080 pour le trafic applicatif et le port 8001 pour l’accès au terminal /debug/pprof.

Bien que ce programme ne soit pas très compliqué, il représente la base d’une application réelle.

Il y a quelques problèmes avec l’application telle qu’elle est qui se révéleront au fur et à mesure que l’application grandit, alors adressons-en quelques-unes maintenant.

En divisant les gestionnaires serveApp et serveDebug en leurs propres fonctions, nous les avons découplés de main.main. Nous avons également suivi les conseils d’en haut et nous nous assurons que serveApp et serveDebug laissent leur concours à l’appelant.

Mais il y a quelques problèmes d’opérabilité avec ce programme. Si serveApp revient, main.main reviendra, provoquant l’arrêt du programme et son redémarrage par le gestionnaire de processus que vous utilisez.

Cependant, serveDebug est exécuté dans un goroutine séparé et s’il retourne juste ce goroutine sortira pendant que le reste du programme continue. Votre personnel d’exploitation ne sera pas heureux de constater qu’il ne peut pas obtenir les statistiques de votre application quand il le souhaite parce que le gestionnaire de bogues /debug a cessé de fonctionner depuis longtemps.

Ce que nous voulons nous assurer, c’est que si l’un des goroutines responsables de servir cette application s’arrête, nous fermons l’application.

Maintenant serverApp et serveDebug vérifient l’erreur renvoyée par ListenAndServe et appellent log.Fatal si nécessaire. Parce que les deux maîtres-chiens courent dans des goroutines, nous stationnons la goroutine principale dans une select{}.

Cette approche pose un certain nombre de problèmes :

Ce que nous aimerions vraiment, c’est transmettre toute erreur qui se produit à l’initiateur du goroutine pour qu’il sache pourquoi le goroutine s’est arrêté, qu’il puisse arrêter le processus proprement.

Nous pouvons utiliser un canal pour collecter l’état de retour du goroutine. La taille du canal est égale au nombre de goroutines que nous voulons gérer pour que l’envoi sur le canal fait ne bloque pas, car cela bloque l’arrêt du goroutine, ce qui provoque sa fuite.

Comme il n’y a aucun moyen de fermer en toute sécurité le canal done, nous ne pouvons pas utiliser l’idiome for range pour boucler le canal jusqu’à ce que tous les goroutines aient fait leur rapport, au lieu de cela nous bouclons pour autant de goroutines que nous avons commencé, qui est égale à la capacité du canal.

Maintenant nous avons un moyen d’attendre que chaque goroutine sorte proprement et enregistre toute erreur qu’elle rencontre. Tout ce qu’il faut, c’est un moyen d’acheminer le signal d’arrêt du premier goroutine qui sort vers les autres.

Il s’avère que demander à un http.Server de s’éteindre est un peu compliqué, donc j’ai transformé cette logique en fonction d’aide. L’assistant de service prend une adresse et http.Handler, similaire à http.ListenAndServe, et aussi un canal d’arrêt que nous utilisons pour déclencher la méthode Shutdown.

Maintenant, chaque fois que nous recevons une valeur sur le canal terminé, nous fermons le canal d’arrêt qui fait que tous les goroutines qui attendent sur ce canal arrêtent leur serveur http. Ceci entraînera à son tour le retour de tous les goroutines ListenAndServe restantes. Une fois que toutes les goroutines que nous avons commencé se sont arrêtées, main.main retourne et le processus s’arrête proprement.