Je vous suggère de vous familiariser avec la transcription du rapport de Denis Isaev jirfag "Linter in Go. Comment les cuisiner".
In go 50+ linter: quel est leur profit et comment les intégrer efficacement dans le processus de développement? Le rapport sera utile à la fois à ceux qui n'utilisent pas encore linter et à ceux qui les utilisent déjà: je vais révéler des astuces et des pratiques peu connues pour travailler avec linter.
Peu importe, s'il vous plaît, sous le chat.
Salut Je m'appelle Dennis Isaev. Nous parlerons de la cuisson des linters dans Go. Le rapport sera intéressant à la fois pour les débutants qui n'ont pas encore utilisé le linter et pour les professionnels. Je vais vous parler de quelques trucs peu connus.
Un peu sur moi. Je suis l'auteur du projet opensource Golangci-lint. A travaillé dans mail.ru. Maintenant, je travaille en tant que TeamLead dans le backend de Yandex.Taxi. Mon rapport est basé sur l'expérience de centaines d'utilisateurs de Golangci-lint. À propos de la façon dont ils ont utilisé le linter, quelles difficultés ils ont rencontrées et l'expérience de la mise en œuvre des linters Go dans mail.ru et Yandex.
Nous couvrirons 5 questions clés dans le rapport.
Je constate assez souvent que les linters n'utilisent pas du tout. Levez la main à ceux qui utilisent le linter dans tous les projets sans exception. Pas tous.
Parlons pourquoi ils ne sont pas utilisés. Le plus souvent, quand je vous demande pourquoi vous n'utilisez pas, ils disent que le linter interfère avec nous. Ils ne font que ralentir le développement. Il n'y a rien de bon en eux. C'est en partie vrai. Si vous ne connaissez pas les subtilités du réglage, elles peuvent vraiment interférer. Nous en reparlerons un peu plus tard.
De plus, ils pensent souvent que le linter ne trouve qu'une petite chose, quelque chose de stylistique, quelques bugs non critiques et en fait cela n'en vaut pas la peine. Est-il plus facile de perdre du temps.
Contre-exemples immédiatement. Un bug dans Docker a été trouvé en utilisant go vet. Appel oublié pour annuler la fonction. Pour cette raison, le goroutine d'arrière-plan peut ne pas se terminer.
Un bug dans le projet Etcd. Le linter-critique cool a trouvé que l'argument strings.HasPrefix est confus. La vérification des moyens pour le protocole HTTP dangereux ne fonctionnera pas.
Dans Go lui-même, le bogue est que l'élément i est comparé par le i-ème, bien qu'il doive être comparé avec le j-ème. Également trouvé par linter.
Trois exemples dans de grands projets open source trouvés par des linters. Certains demanderont: Ok, alors quoi? Il trouve des bugs critiques. Pour un bogue critique, il trouve 100 positifs non critiques ou faux positifs. Je peux donner mes statistiques empiriques: j'ai généralement environ 80% de tous les problèmes signalés par les linters: certains problèmes stylistiques, par exemple, les variables ne sont pas utilisées, et ainsi de suite, 15% sont de vrais bugs et environ 5% sont de faux positifs.
Voyons maintenant pourquoi les linters sont nécessaires. Le bonus le plus important est que les linters font gagner du temps. Et le temps c'est de l'argent. Plus tôt vous trouverez des bogues, moins ils coûteront cher à votre entreprise. Sur la diapositive est un graphique du coût approximatif de la correction du bogue en fonction du stade où il se trouve. En conséquence, à chaque étape du développement à la production, le coût augmente trois fois. Trouvez les bogues tôt, idéalement dans l'IDE et économisez de l'argent à l'entreprise.
Il arrive souvent que sur CodeReview, les développeurs signalent certains problèmes que les linters pourraient trouver. Pourquoi ils font cela est incompréhensible. Tout d'abord, l'auteur du code doit attendre qu'il passe CodeReview. Deuxièmement, l'examinateur lui-même doit passer du temps à trouver des problèmes mécaniques. Il pouvait faire confiance à Linter. Quand je le remarque, je le force toujours et nous convenons dans l'équipe que nous ne pouvons pas examiner les avis pour tout ce qui peut être trouvé par le linter. Que nous fassions confiance à tout cela pour linter. De plus, si nous trouvons des problèmes qui surviennent souvent en revue et qu'il n'y a pas de linters dessus, nous essayons de trouver des linters qui pourraient les attraper en théorie. Nous ne perdons donc pas de temps à revoir.
Les linters nous permettent de garantir en quelque sorte et d'avoir une qualité de code prévisible dans le projet. Par exemple, dans ce cas, ce sont des arguments de fonction inutilisés.
Les linters vous permettent de trouver les bogues critiques le plus tôt possible, ce qui vous fait gagner du temps avec CodeReview. Dans le même temps, garantissez une certaine qualité du code du projet.
Go a plus de 50 linters, mais les plus populaires sont 4. Ce sont ceux de la diapositive. Ils sont utilisés simplement parce qu'ils sont cool. Les autres ne veulent généralement pas s'en occuper. Maintenant, je veux montrer par des exemples quel type de linters existe. Je veux montrer 25 exemples de linter. Maintenant, ce sera probablement l'élément le plus important du rapport.
Commençons par les formateurs qui vérifient les formateurs. Gofmt n'est essentiellement pas un linter. Mais nous pouvons le considérer comme un linter. Il sait comment nous dire qu'il n'y a pas assez de sauts de ligne, quelque part des espaces supplémentaires. En général, c'est la norme pour vérifier et maintenir la mise en forme du code.
Gofmt a également une option -s peu connue, qui vous permet de simplifier les expressions.
Goimports contient tout ce que contient gofmt, mais en plus, il sait toujours comment réorganiser les importations, supprimer et ajouter les importations nécessaires.
Unindent est un merveilleux linter qui peut abaisser le niveau d'imbrication du code. Dans ce cas, il nous dit que si nous combinons les deux if en un, nous aurons alors une baisse du niveau d'imbrication de un.
Prenons les linters qui vérifient la complexité du code. Le plus cool d'entre eux est le gocyclo. Il est le plus ennuyeux. Beaucoup le détestent. Il vérifie la complexité cyclomatique du code et jure lorsque cette complexité de la fonction dépasse un certain seuil. Le seuil est configurable. Si elle est simplifiée, la complexité cyclomatique est la quantité de if dans le code. Ici, il est trop grand et le linter jure.
Nakedret est un tel linter qui peut dire que vous utilisez return sans valeurs et en même temps vous l'utilisez dans une fonction trop longue. Selon le guide officiel, de tels retours ne sont pas recommandés.
Il existe un groupe de style de test de linter. Par exemple, gochecknoglobals vérifie que vous n'utilisez pas de variables globales. Bien sûr, ils n'ont pas besoin d'être utilisés.
Golint jure sur la même variable apiUrl. Dit que l'url doit être utilisée en majuscules. Depuis cette abréviation.
Gochecknoinits s'assure que vous n'utilisez pas les fonctions init. Les fonctions init ne doivent pas être utilisées pour certaines raisons.
Linter cool Gosimple. Partie de staticheck ou mégacheck. À l'intérieur de lui-même contient un grand nombre de modèles pour simplifier le code. Dans ce cas, vous pouvez remarquer que strings.HasPrefix n'est pas nécessaire, car strings.TrimPrefix contient déjà les vérifications nécessaires et vous pouvez supprimer if.
Goconst vérifie que votre code ne contient pas de littéraux de chaîne en double pouvant être extraits en constantes. Le nombre de ces répétitions est configurable. Dans ce cas, deux.
Lintereur mal orthographié, qui vérifie que vous n'avez pas de faute de frappe dans le code dans les commentaires. Dans ce cas, la diapositive contient une faute de frappe du mot else dans le texte du commentaire. Vous pouvez personnaliser le dialecte de l'anglais: américain, britannique.
Unconvert linter, qui vérifie que vous ne faites pas de conversions inutiles. Dans ce cas, la variable est déjà de type chaîne. Il ne sert à rien de le convertir.
Voyons maintenant les linters qui vérifient le code inutilisé. Le premier est varcheck. Il vérifie les variables inutilisées.
Inutilisé peut jurer sur les champs de structures inutilisés.
Deadcode nous indique si un type n'est pas utilisé.
Ou la fonction n'est pas utilisée.
Unparam peut signaler que les arguments de fonction ne sont pas utilisés dans le corps de la fonction lui-même.
Ineffassign signale quand une modification par une variable n'est plus utilisée dans le code. C'est soit le résultat d'une sorte de refactoring. Quelque part, ils ont oublié de nettoyer quelque chose ou un bug. Dans cet exemple, le nombre est incrémenté. De plus, il n'est plus utilisé. Ceci est très similaire à un bug.
Il existe un groupe de performances de test de linter. Par exemple, maligne nous dit qu'une structure testStruck donnée peut être compressée en taille en réorganisant les champs. De plus, si vous l'exécutez dans le cadre de golangci-lint, il dispose d'une option qui vous permet d'imprimer immédiatement l'ordre souhaité des champs, afin de ne pas les choisir vous-même.
Il y a un tel linter gocritique cool. Il a beaucoup de chèques à l'intérieur. L'un d'eux est énormeParam. Elle sait comment nous rapporter la copie de structures de données lourdes. Dans ce cas, heavyStruct est copié par valeur et nous avons juste besoin de le passer comme pointeur.
Prealloc peut nous trouver des emplacements dans le code où nous pouvons pré-déployer la tranche. Il le trouve pour qu'il recherche où nous faisons des itérations horaires constantes sur tranche. Et en eux les affaires s'ajoutent. Dans ce cas, vous pouvez pré-allouer la variable ret pour la longueur des tranches ss et économiser de la mémoire et du CPU.
Et enfin, des linters qui trouvent des bugs. Scopelint trouve probablement que l'erreur la plus fréquente pour les débutants est de capturer la variable de plage d'une boucle par référence. Dans ce cas, la variable de boucle arg est capturée par référence. À la prochaine itération, il y aura déjà une signification différente.
Vérification statique Il s'appelait autrefois megacheck. Maintenant, il a été renommé. Pour cette raison, il y a tellement de confusion dans la communauté. Staticcheck peut trouver des tonnes de bugs différents. C'est vraiment cool. Comme aller vétérinaire. L'un d'eux sur la diapositive est une course. Bien sûr, nous devons incrémenter sync.WaitGroup avant d'entrer dans goroutine.
Go Vet trouve principalement des bugs. Dans ce cas, la variable i est comparée pour que le résultat soit toujours vrai. Par conséquent, il y a évidemment un bug. En général, vous devez toujours utiliser go vet.
Gosec est synonyme de sécurité go. Identifie les problèmes de sécurité potentiels dans Go. Dans ce cas, les données utilisateur peuvent arriver en arg. Par conséquent, il peut s'infiltrer dans la commande shell rm. Et ici peut-être shell en action par exemple. Je constate que la sécurité du go produit assez souvent des faux positifs. Par conséquent, je le désactive parfois.
Errchek trouve des endroits où nous avons oublié la vérification des erreurs. Un bon style de programmation sûr est toujours partout pour vérifier toutes les erreurs.
Deux linter doivent être notés séparément: staticcheck et go-critique. Parce qu'à l'intérieur de chacun d'eux, il y a des dizaines, sinon des centaines de chèques. Par conséquent, assurez-vous de les essayer.
Nous avons maintenant examiné 25 exemples de linter. Et j'ai aussi dit que nous avons plus de 50 lintres à Go. Lequel utiliser? Je vous conseille de tout utiliser au maximum. Incluez simplement tous les linters que vous pouvez. Ensuite, passez une heure et commencez à les éteindre un par un. Désactivez ceux qui vous semblent insignifiants. Par exemple, il trouve des optimisations de performances qui ne vous intéressent pas du tout. Vous passerez une heure et vous créerez votre propre liste de linter et vous pourrez continuer à vivre avec.
Le catalogue complet de tous les linters est disponible sur le lien de la diapositive.
Parlons de la façon d'exécuter linter. Parfois, les linters sont lancés à l'aide de tels fichiers makefile. Le problème est que c'est lent. Tout est exécuté séquentiellement.
On peut faire l'exécution en parallèle via xargs -P. Il y a aussi un problème. Tout d'abord, ce ne sont que 4 linters. Et déjà 10 lignes de code. Que se passe-t-il si nous allumons 20 linters. Deuxièmement, cette parallélisation n'est pas, pour dire les choses modestes, la plus optimale.
Gometalinter vient à la rescousse. Gometalinter est un tel agrégateur de linters qu'il peut fonctionner littéralement dans quelques commandes. Sur la diapositive, la commande pour lancer le même linter est similaire à la diapositive précédente. Mais ils n'ont pas besoin d'être installés indépendamment et n'ont pas besoin d'être chamanisés avec un lancement parallèle. Gometalinter met déjà tout en parallèle sous le capot. Mais il a un problème fondamental. Il démarre chaque linter comme un processus distinct. Le bifurque. Si nous ajoutons à cela la connaissance que chaque linter en lui-même passe 80% du temps à analyser le code et seulement 20% à l'analyse elle-même, il s'avère que nous gaspillons 80% du travail. Et ne réutilisez pas les données. Nous pourrions analyser le programme 1 fois puis alimenter 50 linter.
Heureusement, il y a golangci-lint qui fait exactement cela. Il analyse une fois. Tapez une fois. D'autres analyseurs fonctionnent sur eux. Pour cette raison, cela fonctionne beaucoup plus rapidement. Une commande de lancement similaire sur une diapositive.
Vous pouvez voir le graphique sur l'un de mes projets 30 000 lignes de code. Un petit projet et seulement 4 linter. Vous pouvez remarquer parfois une énorme différence dans la vitesse de travail, à la fois entre le lancement séquentiel et entre gometalinter et golangci-lint. Si ces linter ne sont pas 4, mais 20, alors la différence sera beaucoup plus grande.
Précision importante sur gometalinter. Depuis le 7 avril, l'auteur du projet gometalinter le déclare obsolète. Le référentiel a été archivé et tout le monde est conseillé de passer à golangci-lint, car il est plus rapide, il y a plus de goodies. Par exemple, la prise en charge des modules go et ainsi de suite.
Et en plus des modules de performance et Go, golangci-lint a des chignons comme la configuration YAML, la possibilité d'ignorer les avertissements, de les exclure, etc.
Golangci-lint est configuré à l'aide du fichier golangci-lint.yaml. Un exemple de ce fichier avec une description de toutes les options se trouve sur le lien sur la diapositive. Considérez, par exemple, la section des paramètres de linters. Dans cette section, nous allons passer à la configuration des importations. Il a une option de préfixes locaux si rare. Dans celui-ci, vous pouvez spécifier le chemin d'accès au projet en cours. Dans ce cas, par exemple, github.com/local/repo.
Lorsque goimports voit des importations locales dans github.com/local/repo, il s'assurera qu'elles se trouvent dans une section distincte.
Pour qu'ils soient à la toute fin. Pour qu'ils soient séparés de toutes les importations externes. Cela facilite la distinction visuelle entre les importations externes et internes. S'il remarque que ce n'est pas le cas, il jure.
Et si vous utilisez également l'option golangci-lint run --fix, alors golangci-lint le corrigera automatiquement et triera à nouveau les importations.
Parlons de ce que sont les linters dans la terminologie golangci-lint. Linter sont divisés en rapide et lent. Les rapides sont appelés rapides, marqués du drapeau rapide dans l'aide. Ils diffèrent en ce que les linters rapides nécessitent une représentation assez limitée du programme, par exemple, l'arbre AST et certaines informations de type. Alors que les linters de cuivre nécessitent en outre une soumission SSA par le programme et réutilisent moins le cache. Il n'y a que six linters lents. Ils sont marqués sur la diapositive. Il y a certains cas où il est logique d'exécuter uniquement du linter rapide.
Vous remarquerez peut-être une différence de vitesse. C'est énorme trois fois entre un démarrage rapide et un ralentissement. En fait, golangci-lint run --fast, seuls les linters rapides sont lancés.
À propos du cache de génération. Il existe une chose telle que construire un cache. Il s'agit du cache que le binaire Go crée lors de la compilation du programme lorsque les types sont chargés, afin que la prochaine fois cette compilation soit plus rapide. Le même cache est réutilisé par les linters pour analyser les programmes de construction des informations de type. Vous remarquerez peut-être que si vous videz le cache, le premier nouveau départ sera assez long. Et le prochain sera 3 fois plus rapide. Faites attention à votre premier lancement de linter sur votre projet. Ce sera toujours beaucoup plus lent.
Ici, vous pouvez conclure qu'il est logique dans CI entre les lancements de CI pour réutiliser votre cache. Vous accélérerez non seulement les linters, vous accélérerez également les tests en cours, la compilation et peut-être autre chose. Je conseille à tout le monde.
Je ne peux pas parler d'analyse go. Il s'agit d'un nouveau cadre qui est apparu depuis Go 1.12. Il unifie les interfaces de telle manière que linter devient facile à écrire, linter est facile à utiliser et à exécuter. Go vet démarre la version 1.12 entièrement commutée pour aller à l'analyse. De toute évidence, c'est l'avenir. Qu'il changera considérablement l'écosystème entier de Go. Mais pour l'instant, il est généralement assez tôt pour en parler. Que va-t-il se passer ensuite? Parce que je n'ai vu que quelques linters en cours d'analyse et quasiment aucun des linters existants n'y est encore passé.
Si vous faites une brève conclusion sur la section comment exécuter les linters, alors je conseille à tout le monde d'utiliser golangci-lint. Vous exécuterez rapidement les linters de manière pratique. Vous n'avez pas besoin de chaman avec d'autres instructions, commandes.
Parlons de la façon d'implémenter linter dans le projet. Je pense que tous ceux qui ont essayé d'introduire des linters ont été confrontés à un tel problème. Ici, vous avez un projet pour un million de lignes de code avec historique. Vous avez convaincu TeamLead d'implémenter des linters. Lancez et voyez un million de messages. Comprenez que vous n'avez pas le temps de vous asseoir pendant des semaines pour tout arranger. Que faire Vous pouvez simplement abandonner et tout abandonner. Ou vous pouvez trouver quelque chose.
Premièrement, l'option la plus simple, vous pouvez essayer d'exclure régulièrement certains commentaires de linters sur le texte en utilisant la configuration golangci-lint.yaml. Si vous voyez qu'il y a des linters jurant sur les commentaires, mais que vous ne vous souciez généralement pas de ces commentaires, vous pouvez ajouter des exceptions.
Peut être exclu des façons. Par exemple, vous disposez d'un répertoire tiers et votre code n'est pas là. Vous n'avez pas besoin de le vérifier. Peut être exclu par les noms de fichiers.
Si vous ne souhaitez pas exclure le fichier entier, vous pouvez exclure la fonction avec nolint avant la fonction. Pour nolint, vous pouvez spécifier via les deux points une liste de linters pour lesquels il agit comme une exception. Ou ne pas spécifier, alors tous les linter seront ignorés.
Quand utiliser nolint? Par exemple, j'utilise nolint: deepguard, qui peut capturer les importations, c'est-à-dire Les importations ne peuvent pas être utilisées. J'ai assommé l'importation de la bibliothèque logrus afin de ne pas l'utiliser accidentellement à la place de l'enregistreur souhaité. Mais dans mon enregistreur lui-même, j'utilise logrus. Par conséquent, je n'ai besoin qu'à un seul endroit du projet pour créer un seul fichier à partir de l'importation. Je l'ai marqué avec nolint.
Supposons que vous ayez fait tout cela, ajoutez exclure, affixe nolint. . . . . main.go, 5 , 6 . ?
revgrep. Revgrep git , . . 6 origin master, . , 5 . . . . golangci-lint . . , . git hash commit. . . hash commit tag revgrep CI. . . . mail.ru, .
revgrep golangci-lint. --new-from-rev --new. .
. --new. 20 , . . . . . Que faire --new-from , . .
. golangci-lint . . . , .
Nous avons parlé de l'introduction de linter dans tout projet. Parlons maintenant de la commodité du travail. Tout d'abord, vous devez atteindre la reproductibilité dans CI. Dès que vous ajoutez un linter à CI, vous avez besoin qu'il soit stable. N'allez jamais chercher. Parce qu'il n'est pas versionné. Linter a changé à tout moment, mis à jour et toute votre construction CI a commencé à échouer. J'ai vu cela des dizaines de fois. Utilisez toujours des versions spécifiques. Mieux avec wget le mettre. Elle sera encore plus rapide. De plus, je ne recommande pas l'utilisation de l'option --- enable-all pour linter, car en un jour vous mettez à jour golangci-lint, par exemple, vous obtenez 5 nouveaux linter et tout votre construction commence à échouer. Parce que vous avez accidentellement allumé ces linter. Il est préférable de prescrire explicitement les linters que vous incluez.
Le truc cool, c'est le hook pré-commit. Qui utilise le crochet de pré-validation pour lever la main? Assez peu. Le hook de pré-validation est un fichier git qui vous permet d'exécuter du code arbitraire après avoir effectué la validation. Mais avant que cet engagement réussisse. Si le hook de pré-validation renvoie une erreur, la validation échouera. Il est généralement pratique d'y intégrer des tests rapides, des analyses statiques, etc. Je conseille à tout le monde d'intégrer du golangci-lint. Vous pouvez le faire manuellement via le script shell. C'est possible grâce à l'utilitaire de pré-validation. Un exemple de configuration sur une diapositive. Installe la pré-validation avec pip, un utilitaire pour installer les packages Python. pip install pre-commit installe la config. Golangci-lint prend déjà en charge l'intégration avec le pré-commit.
L'option --fast. Nous sommes revenus vers elle. Je conseille à tout le monde de l'utiliser dans l'IDE. En général, l'EDI, bien sûr, devrait utiliser l'intégration avec les linters. Pour que votre IDE ne se fige pas, assurez-vous d'utiliser l'option --fast.
Je pense que c'est assez évident. Dans CI, les linters doivent être intégrés. Si vous ne les intégrez pas, alors il y aura une image classique: "martelons-la maintenant, maintenant nous avons une version, pas avant cela." Petit à petit, vous aurez de plus en plus de commentaires. Vous arrêtez simplement de regarder les linters en classe. Par conséquent, strictement dans CI. De plus, vous pouvez simplement installer des linters dans CI, avec un échec de construction, nous montons dans le journal de construction, cherchons pourquoi il est tombé là-bas. Où est le commentaire, sur quelle ligne? Ce n'est pas très pratique.
Il y a un moyen plus cool. Vous pouvez faire agir linter en tant que personne, en tant que critique. Ils peuvent vous commenter sur github.com, gitlab.com pour une ligne de code d'erreur sur votre demande Pull. Linter peut écrire qu'il a trouvé un problème. C'est incroyablement cool. Cela fait gagner du temps aux auteurs de code. Parce que vous n'avez pas besoin d'aller dans le journal de build. De plus, une personne peut commenter si elle n'est pas d'accord avec cette remarque du linter. Dans l'exemple de la diapositive, cela se fait à l'aide de l'utilitaire reviewdog. Utilitaire opensource. Elle est libre. Vous pouvez vous installer.
En plus de reviewdog, il existe également des projets tels que GolangCI, Code Climate, Hound. Ils vous permettent de connecter ces linters en un seul clic à votre opensouce ou à vos référentiels privés et de commenter en ligne dans Pull Request. Il y a toujours une chose sympa SonarQube.
Je ne peux pas encore mentionner goreportcard. Ce projet vous permet de créer un rapport sur votre référentiel. Ils y mettent des notes, donnent un badge, écrivent à quel point votre code est bon pour une douzaine de linter propre. Je conseille aussi.
J'aimerais que vous veniez travailler dès lundi et que vous puissiez appliquer quelque chose de ce que j'ai dit. Voici un résumé de ce que vous pouvez appliquer. Installez d'abord golangci-lint. Allumez tous les linters là-bas. Ensuite, passez 1 heure. Pendant cette heure, éteignez tous les linters qui vous semblent délirants. Après cela, incorporez golangci-lint dans le CI, dans l'EDI et configurez le hook de pré-validation. Juste après cela, vous pouvez configurer --new-from-rev et indiquer qu'à partir du commit actuel, nous recherchons des bogues. Et tous les bugs précédents seront corrigés plus tard séparément. Après cela, configurez éventuellement le reviewdog pour qu'il vous commente toujours sur votre github ou dans gitlab. Vous augmenterez considérablement la qualité du projet avec cela. Ravissez toute l'équipe.
Merci à tous pour votre attention. Mes contacts sur la diapositive.
Question: Dites-moi, avez-vous des fichiers de configuration prêts à l'emploi que vous mettez en libre accès et que vous pouvez simplement télécharger et utiliser afin de ne pas comprendre la tonne de paramètres de golangci-lint? Ce que vous recommandez.
Réponse: Bonne idée. Golangci-lint lui-même possède déjà son propre golangci-lint.yaml, qu'il utilise. Vous pouvez l'utiliser comme point de départ.
Question: Sur la diapositive sur le cache de génération, reportez-vous au cache des modules. Dans le cache, vous spécifiez le cache complet des modules. Vous pouvez spécifier .cache / Downloads puis il y aura une différence assez importante: 400 mégaoctets contre 10. Cela suffit pour extraire simplement les modules. Mais ce n'est que si le module est utilisé.
Question: Soutiendrez-vous également les modules go ou dep ou allez-vous dans quelque chose en un?
Réponse: Pas besoin de soutien. Il existe maintenant une bibliothèque de packages go. Elle est engagée dans le chargement du code source. Il prend en charge les modules et les non-modules. Elle ne va pas encore mais supprimer le support pour les non-modules.
Question: Prévoyez-vous de créer divers plugins pour l'intégration non seulement avec Travis, mais aussi avec d'autres serveurs d'automatisation?
Réponse: golangci-lint ne fait aucune intégration. Pour exécuter en CI, il suffit d'appeler golangci-lint --run.
Question: Pour analyser certains rapports, par exemple, dans Jenkins, nous enregistrons un fichier html.
Réponse: Il existe un format de sortie junit, csv, json xml. Tout cela peut déjà être analysé.
Question: nous avons utilisé gometalinter avant et c'était lent. Ensuite, nous sommes passés à un linter appelé revive. Vous ne l'avez pas mentionné du tout. Et pour ma part, je ne suis pas du tout un expert du sujet. Je ne connaissais pas votre linter, que vous disiez. Pourriez-vous écrire à la fin disons les pros de votre linter ou les pros de revive.
Réponse: revive est un golint réécrit. Ceci est juste l'un des linter. Il y a des paramètres. Il a également ajouté quelques linter, quelques chèques. Golangci-lint est en soi 30-50 linter. Il s'agit d'un linter un an et demi. Revive est cool car il prend du golint et le rend parallèle. Relancez le travail plus rapidement que Golint. Mais ce n'est qu'un linter. Revive peut faire partie de golangci-lint.
Question: Vous avez eu une diapositive dans l'examen des linters sur gocritic: énormeParam, qui est recommandé de transférer les structures en gras par pointeur. Mais cela conduira au fait que toutes ces structures seront allouées exclusivement dans HEAP. Et cela ne conduira-t-il pas à des problèmes plus importants que des avantages? Si de telles structures, par exemple, se transmettent beaucoup.
Réponse: je suis tout à fait d'accord. Vous ne devez pas utiliser ces avertissements et ne pas simplement les suivre. Cela peut être comme une optimisation prématurée, cela peut nuire au projet. Je désactive généralement cette classe de linters en général si je n'ai pas les performances d'une tâche critique. où je trouve des faiblesses avec le profileur.
Question: je viens de Yandex. Nous utilisons votre linter sur un grand référentiel. Nous avons remarqué qu'il commençait déjà à travailler très rapidement pour un grand référentiel. En seulement quelques jours, ils ont écrit un utilitaire simple qui, via go package, trouve les packages qui ont changé depuis l'introduction de la branche depuis l'assistant et les packages qui en dépendent. Et exécutez le linter uniquement sur eux. Et la vérification du linter s'est accélérée plusieurs fois.
Réponse: Peut-être que vous allez créer un idssue, attacher un script, et très probablement j'intégrerai tout cela dans golangci-lint.
Question: Des niveaux de gravité sont-ils prévus pour les commentaires afin que certains puissent être inclus dans le rapport, mais cela ne simule pas le processus de CI? Par exemple, via le code d'achèvement.
Réponse: Beaucoup de gens ont posé la question et je dirai immédiatement que la difficulté est que ces niveaux de gravité les soutiennent tous, il y a 3 ou 4 linter sur 30. Que faire de l'acier? Ce n'est pas clair. Il est nécessaire d'analyser manuellement leurs commentaires, de les marquer d'une manière ou d'une autre. Gérez les faux positifs. Il s'agit généralement d'une grande quantité de travail. Je ne sais pas ce que cela fera quand. Il existe d'autres façons d'atteindre le même objectif.
Question: Il y a des articles sur le hub Plus précisément, une série d'articles sur le linter C ++. L'entreprise développe cette activité. Ils en tirent de l'argent. En fait, leur travail, ou plutôt cette série de publications, n'est plus destiné aux développeurs, mais plutôt à ceux qui gèrent les développeurs. Il s'agit essentiellement de code pur, de stylisation. C'est notre tâche, mais aussi la tâche des leaders, des chefs d'équipe. Envisagez-vous de vulgariser cette ligne de médias ici, dans de grandes ressources telles que les gens la lisent puis la présentent à leurs équipes? Et non, nous avons frappé d'en bas.
Réponse: j'avais un plan. Merci pour la suggestion. J'avais prévu d'écrire un article complet comme ce discours, mais là plus en détail et largement tout au long de l'année. J'écrirai peut-être en russe et en anglais.