Ich schlage vor, dass Sie sich mit dem Protokoll des Berichts von Denis Isaev jirfag "Linter in Go. Wie man sie kocht " vertraut machen.
In go 50+ linter: Was ist ihr Gewinn und wie können sie effektiv in den Entwicklungsprozess integriert werden? Der Bericht wird sowohl für diejenigen nützlich sein, die noch keinen Linter verwenden, als auch für diejenigen, die ihn bereits verwenden: Ich werde wenig bekannte Tricks und Praktiken für die Arbeit mit Linter aufzeigen.
Wen kümmert es bitte unter der Katze.
Hallo. Ich heiße Dennis Isaev. Wir werden darüber sprechen, wie man in Go Linters kocht. Der Bericht wird sowohl für Anfänger, die noch keinen Linter verwendet haben, als auch für Profis interessant sein. Ich werde Ihnen einige wenig bekannte Tricks erzählen.
Ein bisschen über mich. Ich bin der Autor des OpenSource-Projekts Golangci-Lint. Arbeitete in mail.ru. Jetzt arbeite ich als TeamLead im Backend von Yandex.Taxi. Mein Bericht basiert auf Erfahrungen mit Hunderten von Golangci-Lint-Benutzern. Wie sie den Linter verwendet haben, welche Schwierigkeiten sie hatten und welche Erfahrungen sie mit der Implementierung von Go-Lintern in mail.ru und Yandex gemacht haben.
Wir werden 5 Hauptthemen im Bericht behandeln.
Ich sehe ziemlich oft, dass Linters überhaupt nicht verwendet werden. Erhöhen Sie Ihre Hände zu denen, die den Linter ausnahmslos in allen Projekten verwenden. Nicht alle.
Sprechen wir darüber, warum sie nicht verwendet werden. Meistens, wenn ich frage, warum ihr es nicht benutzt, sagen sie, dass Linter uns stört. Sie verlangsamen nur die Entwicklung. Es ist nichts Gutes in ihnen. Dies ist teilweise wahr. Wenn Sie die Feinheiten der Abstimmung nicht kennen, können sie wirklich stören. Wir werden etwas später darüber sprechen.
Außerdem denken die Leute oft, dass der Linter nur eine kleine Sache findet, etwas Stilistisches, einige unkritische Fehler, und tatsächlich ist es das nicht wert. Ist es einfacher, Zeit zu verschwenden?
Sofort Gegenbeispiele. Ein Fehler in Docker wurde mit go vet gefunden. Aufruf zum Abbrechen der Funktion vergessen. Aus diesem Grund endet die Hintergrundgoroutine möglicherweise nicht.
Ein Fehler im Etcd-Projekt. Der coole Go-Kritiker Linter stellte fest, dass das Argument strings.HasPrefix verwirrt ist. Die Überprüfung auf das unsichere HTTP-Protokoll funktioniert nicht.
In Go selbst besteht der Fehler darin, dass das i-Element mit dem i-ten verglichen wird, obwohl es mit dem j-ten verglichen werden sollte. Auch von Linter gefunden.
Drei Beispiele in großen OpenSource-Projekten, die von Lintern gefunden wurden. Einige werden fragen: Ok, na und? Er findet einige kritische Fehler. Für einen kritischen Fehler werden 100 unkritische oder falsch positive Ergebnisse gefunden. Ich kann meine empirischen Statistiken angeben: Normalerweise habe ich ungefähr 80 Prozent aller Probleme, die Linters melden: Einige Stilprobleme, z. B. Variablen, werden nicht verwendet, und so weiter, 15 Prozent sind echte Fehler und ungefähr 5 Prozent sind falsch positiv.
Lassen Sie uns nun darüber sprechen, warum Linters benötigt werden. Der wichtigste Bonus ist, dass Linters Zeit sparen. Und Zeit ist Geld. Je früher Sie Fehler finden, desto günstiger kosten sie für Ihr Unternehmen. Auf der Folie finden Sie eine grafische Darstellung der ungefähren Kosten für die Behebung des Fehlers in Abhängigkeit von der Phase, in der er gefunden wurde. Dementsprechend erhöhen sich die Kosten von jeder Phase von der Entwicklung bis zur Produktion um das Dreifache. Finden Sie Fehler frühzeitig, idealerweise in der IDE, und sparen Sie Firmengeld.
Es kommt häufig vor, dass Entwickler in CodeReview einige Probleme melden, die Linters möglicherweise finden. Warum sie das tun, ist unverständlich. Zunächst muss der Autor des Codes warten, bis er CodeReview besteht. Zweitens muss der Prüfer selbst Zeit damit verbringen, mechanische Probleme zu finden. Er konnte Linter das anvertrauen. Wenn ich dies bemerke, erzwinge ich es immer und wir sind uns im Team einig, dass wir die Überprüfung nicht auf alles prüfen können, was der Linter finden kann. Ob wir dem alles vertrauen. Wenn wir außerdem einige Probleme finden, die häufig bei der Überprüfung auftreten und keine Linters enthalten, versuchen wir, Linters zu finden, die sie theoretisch auffangen könnten. Wir verschwenden also keine Zeit mit der Überprüfung.
Linters ermöglichen es uns, irgendwie zu garantieren und eine vorhersehbare Codequalität im Projekt zu haben. In diesem Fall handelt es sich beispielsweise um nicht verwendete Funktionsargumente.
Mit Lintern können Sie kritische Fehler so früh wie möglich finden und CodeReview-Zeit sparen. Stellen Sie gleichzeitig eine gewisse Qualität des Codes für das Projekt sicher.
Go hat über 50 Linters, aber die beliebtesten sind 4. Dies sind die auf der Folie. Sie werden einfach verwendet, weil sie cool sind. Der Rest will sich normalerweise nicht darum kümmern. Jetzt möchte ich anhand von Beispielen zeigen, welche Art von Lintern es gibt. Ich möchte 25 Linter-Beispiele demonstrieren. Jetzt wird es wahrscheinlich das wichtigste im Bericht sein.
Beginnen wir mit Formatierern, die Formatierer prüfen. Gofmt ist im Wesentlichen kein Linter. Aber wir können es als Linter betrachten. Er weiß, wie er uns sagen kann, dass es nicht genügend Zeilenvorschübe gibt, irgendwo zusätzliche Leerzeichen. Im Allgemeinen ist dies der Standard zum Überprüfen und Verwalten der Codeformatierung.
Gofmt hat auch eine wenig bekannte Option -s, mit der Sie Ausdrücke vereinfachen können.
Goimports enthält alles, was gofmt enthält, aber es weiß auch noch, wie man Importe neu anordnet, löscht und die erforderlichen Importe hinzufügt.
Unindent ist ein wunderbarer Linter, der die Verschachtelung von Code verringern kann. In diesem Fall sagt er uns, dass wenn wir die beiden Wenns zu einem kombinieren, die Verschachtelungsebene um eins abfällt.
Betrachten wir Linters, die die Komplexität des Codes überprüfen. Das coolste von ihnen ist Gocyclo. Er ist der langweiligste. Viele hassen ihn. Er überprüft die zyklomatische Komplexität des Codes und schwört, wenn diese Komplexität der Funktion einen bestimmten Schwellenwert überschreitet. Der Schwellenwert ist konfigurierbar. Wenn vereinfacht, ist die zyklomatische Komplexität die Menge an if im Code. Hier ist er zu groß und der Linter schwört.
Nakedret ist ein solcher Linter, der sagen kann, dass Sie return ohne Werte verwenden und es gleichzeitig in einer zu langen Funktion verwenden. Nach dem offiziellen Leitfaden werden solche Rücksendungen nicht empfohlen.
Es gibt eine Gruppe von Linter-Teststilen. Zum Beispiel überprüft gochecknoglobals, ob Sie keine globalen Variablen verwenden. Natürlich müssen sie nicht verwendet werden.
Golint schwört auf dieselbe apiUrl-Variable. Sagt, URL sollte in Großbuchstaben verwendet werden. Seit dieser Abkürzung.
Gochecknoinits stellt sicher, dass Sie keine Init-Funktionen verwenden. Init-Funktionen sollten aus bestimmten Gründen nicht verwendet werden.
Einfacher kühler Linter. Teil von Staticheck oder Megacheck. In sich selbst befindet sich eine Vielzahl von Mustern, um den Code zu vereinfachen. In diesem Fall stellen Sie möglicherweise fest, dass Zeichenfolgen.HasPrefix nicht benötigt wird, da Zeichenfolgen.TrimPrefix bereits die erforderlichen Überprüfungen enthält, und Sie können if entfernen.
Goconst überprüft, ob Ihr Code keine doppelten Zeichenfolgenliterale enthält, die in Konstanten gezogen werden könnten. Die Anzahl dieser Wiederholungen ist konfigurierbar. In diesem Fall zwei.
Misspell Linter, der überprüft, ob der Code in den Kommentaren keine Tippfehler enthält. In diesem Fall enthält die Folie einen Tippfehler des anderen Wortes im Kommentartext. Sie können den Dialekt des Englischen anpassen: Amerikanisch, Britisch.
Deaktivieren Sie den Linter, um sicherzustellen, dass Sie keine unnötigen Konvertierungen durchführen. In diesem Fall ist die Variable bereits vom Typ string. Es macht keinen Sinn, es zu konvertieren.
Lassen Sie uns nun die Linters sehen, die nicht verwendeten Code überprüfen. Der erste ist Varcheck. Es wird nach nicht verwendeten Variablen gesucht.
Unbenutzte können auf ungenutzte Felder von Strukturen schwören.
Deadcode sagt uns, ob ein Typ nicht verwendet wird.
Oder die Funktion wird nicht verwendet.
Unparam kann melden, wenn im Funktionskörper selbst keine Funktionsargumente verwendet werden.
Ineffassign meldet, wenn eine Änderung durch eine Variable im Code nicht weiter verwendet wird. Dies ist entweder das Ergebnis einer Art Refactoring. Irgendwo haben sie vergessen, etwas oder einen Käfer zu reinigen. In diesem Beispiel wird die Anzahl erhöht. Darüber hinaus wird es nicht weiter verwendet. Dies ist einem Fehler sehr ähnlich.
Es gibt eine Gruppe von Linter-Testleistungen. Zum Beispiel sagt uns maligned, dass eine bestimmte testStruck-Struktur durch Neuordnung der Felder in der Größe komprimiert werden kann. Wenn Sie es als Teil von golangci-lint ausführen, gibt es außerdem eine Option, mit der Sie die gewünschte Reihenfolge der Felder sofort drucken können, um sie nicht selbst auszuwählen.
Es gibt so einen coolen gocritic Linter. Er hat viele Schecks drinnen. Einer von ihnen ist riesigParam. Sie weiß, wie sie uns über das Kopieren schwerer Datenstrukturen Bericht erstatten kann. In diesem Fall wird heavyStruct nach Wert kopiert und muss nur als Zeiger übergeben werden.
Prealloc kann uns Stellen im Code finden, an denen wir Slice vorab bereitstellen können. Er findet es so, dass er sucht, wo wir konstante stündliche Iterationen auf Slice durchführen. Und in ihnen hängen Angelegenheiten an. In diesem Fall können Sie die Variable ret für die Länge des Slice ss vorab zuweisen und Speicher und CPU sparen.
Und schließlich Linters, die Fehler finden. Scopelint findet wahrscheinlich, dass der häufigste Fehler für Anfänger darin besteht, die Bereichsvariable einer Schleife als Referenz zu erfassen. In diesem Fall wird die Variable arg loop als Referenz erfasst. Bei der nächsten Iteration wird es bereits eine andere Bedeutung geben.
Staticcheck Früher hieß es Megacheck. Jetzt wurde es umbenannt. Aus diesem Grund gibt es in der Gemeinde so wenig Verwirrung. Staticcheck kann Tonnen von verschiedenen Fehlern finden. Das ist eine wirklich coole Sache. Wie zum Tierarzt gehen. Einer von ihnen auf der Rutsche ist ein Rennen. Natürlich müssen wir sync.WaitGroup erhöhen, bevor wir goroutine eingeben.
Der Tierarzt findet meistens Insekten. In diesem Fall wird die Variable i verglichen, so dass das Ergebnis immer wahr ist. Daher gibt es offensichtlich einen Fehler. Im Allgemeinen sollten Sie immer einen Tierarzt verwenden.
Gosec steht für Go Security. Findet potenzielle Sicherheitsprobleme in Go. In diesem Fall können Benutzerdaten in arg ankommen. Daher kann es den Befehl rm shell infiltrieren. Und hier vielleicht Shell in Aktion zum Beispiel. Ich stelle fest, dass Go-Sicherheit häufig zu falsch positiven Ergebnissen führt. Deshalb schalte ich es manchmal aus.
Errchek findet Orte, an denen wir die Fehlerprüfung vergessen haben. Ein guter, sicherer Programmierstil ist immer überall, um alle Fehler zu überprüfen.
Zwei Linter sollten getrennt vermerkt werden: Staticcheck und Go-Critical. Denn in jedem von ihnen befinden sich Dutzende, wenn nicht Hunderte von Schecks. Probieren Sie sie daher unbedingt aus.
Jetzt haben wir 25 Linter-Beispiele untersucht. Und ich sagte auch, dass wir mehr als 50 Linters in Go haben. Welche verwenden? Ich rate Ihnen, alles maximal zu nutzen. Fügen Sie einfach alle Linters hinzu, die Sie können. Verbringen Sie dann eine Stunde und schalten Sie sie einzeln aus. Schalten Sie diejenigen aus, die Ihnen unbedeutend erscheinen. Beispielsweise werden einige Leistungsoptimierungen gefunden, an denen Sie überhaupt nicht interessiert sind. Sie werden eine Stunde damit verbringen, Ihre eigene Liste von Linter für sich selbst zu erstellen, und Sie können damit weiter leben.
Der vollständige Katalog aller Linters ist über den Link auf der Folie verfügbar.
Lassen Sie uns darüber sprechen, wie man Linter laufen lässt. Manchmal werden Linters mit solchen Makefiles gestartet. Das Problem ist, dass es langsam ist. Es wird alles nacheinander ausgeführt.
Wir können die Ausführung parallel über xargs -P durchführen. Es gibt auch ein Problem. Erstens sind dies nur 4 Linters. Und schon 10 Codezeilen. Was passiert, wenn wir 20 Linters einschalten? Zweitens ist diese Parallelisierung, gelinde gesagt, nicht die optimalste.
Gometalinter kommt zur Rettung. Gometalinter ist ein solcher Aggregator von Lintern, dass es buchstäblich in ein paar Befehlen ausgeführt werden kann. Auf der Folie ähnelt der Befehl zum Starten desselben Linters der vorherigen Folie. Sie müssen jedoch nicht unabhängig installiert und beim parallelen Start nicht schamanisiert werden. Gometalinter parallelisiert bereits alles unter der Haube. Aber er hat ein grundlegendes Problem. Jeder Linter wird als separater Prozess gestartet. Gabelt ihn. Wenn wir das Wissen hinzufügen, dass jeder Linter in sich 80 Prozent der Zeit mit dem Parsen des Codes und nur 20 Prozent mit der Analyse selbst verbringt, stellt sich heraus, dass wir 80 Prozent der Arbeit verschwenden. Und verwenden Sie die Daten nicht wieder. Wir könnten das Programm 1 Mal analysieren und dann 50 Linter füttern.
Glücklicherweise gibt es Golangci-Flusen, die genau das tun. Er analysiert einmal. Einmal tippen. Weitere Analysegeräte laufen darauf. Dadurch funktioniert es viel schneller. Ein ähnlicher Startbefehl auf einer Folie.
Sie können die Grafik auf einem meiner Projekte 30.000 Codezeilen sehen. Ein kleines Projekt und nur 4 Linter. Sie können feststellen, dass es manchmal einen großen Unterschied in der Arbeitsgeschwindigkeit gibt, sowohl zwischen dem sequentiellen Start als auch zwischen Gometalinter und Golangci-Lint. Wenn dieser Linter nicht 4, sondern 20 ist, ist der Unterschied viel größer.
Wichtige Klarstellung zum Gometallinter. Seit dem 7. April erklärt der Autor des Gometalinter-Projekts, dass es veraltet ist. Das Repository wurde archiviert und jedem wird empfohlen, auf Golangci-Lint umzusteigen, da es schneller ist und dort mehr Extras enthält. Zum Beispiel Unterstützung für Go-Module und so weiter.
Neben Performance- und Go-Modulen bietet Golangci-Lint auch Brötchen wie die YAML-Konfiguration, die Möglichkeit, Warnungen irgendwie zu überspringen, sie auszuschließen und so weiter.
Golangci-lint wird mithilfe der Datei golangci-lint.yaml konfiguriert. Ein Beispiel für diese Datei mit einer Beschreibung aller Optionen finden Sie unter dem Link auf der Folie. Betrachten Sie zum Beispiel den Abschnitt Linters-Einstellungen. In diesem Abschnitt werden wir die Konfiguration importieren. Es gibt eine so seltene Option für lokale Präfixe. Darin können Sie den Pfad zum aktuellen Projekt angeben. In diesem Fall beispielsweise github.com/local/repo.
Wenn goimports lokale Importe in github.com/local/repo sieht, wird sichergestellt, dass sie sich in einem separaten Abschnitt befinden.
Damit sie ganz am Ende sind. Damit sind sie von allen externen Importen getrennt. Dies erleichtert die visuelle Unterscheidung zwischen externen und internen Importen. Wenn er bemerkt, dass dies nicht so ist, wird er schwören.
Und wenn Sie auch die Option golangci-lint run --fix verwenden, repariert golangci-lint sie automatisch für Sie und sortiert die Importe neu.
Lassen Sie uns darüber sprechen, was Linters in der Terminologie golangci-lint sind. Linter werden in schnell und langsam unterteilt. Die schnellen werden schnell genannt und mit der schnellen Flagge in der Hilfe markiert. Sie unterscheiden sich darin, dass schnelle Linters eine eher eingeschränkte Darstellung des Programms erfordern, beispielsweise den AST-Baum und einige Typinformationen. Während Kupferlinters noch zusätzlich eine SSA-Übermittlung durch das Programm erfordern und den Cache weniger wiederverwenden. Es gibt nur sechs langsame Linters. Sie sind auf der Folie markiert. In bestimmten Fällen ist es sinnvoll, nur einen schnellen Linter zu verwenden.
Möglicherweise stellen Sie einen Geschwindigkeitsunterschied fest. Es ist enorm dreimal zwischen schnellem Start und langsam. Eigentlich golangci-lint run - schnell werden nur schnelle Linters gestartet.
Über Build-Cache. Es gibt so etwas wie einen Build-Cache. Dies ist der Cache, den die Go-Binärdatei beim Kompilieren des Programms beim Laden von Typen erstellt, damit diese Kompilierung beim nächsten Mal schneller erfolgt. Derselbe Cache wird von Lintern zum Parsen von Programmen zum Erstellen von Typinformationen wiederverwendet. Möglicherweise stellen Sie fest, dass der erste Neustart ziemlich lang ist, wenn Sie den Cache leeren. Und der nächste wird dreimal schneller sein. Achten Sie auf Ihren ersten Start von Linter in Ihrem Projekt. Es wird immer viel langsamer sein.
Hier können Sie den Schluss ziehen, dass es in CI zwischen CI-Starts sinnvoll ist, Ihren Cache wiederzuverwenden. Sie beschleunigen nicht nur Linters, sondern auch das Ausführen von Tests, das Kompilieren und möglicherweise etwas anderes. Ich rate allen.
Ich kann nicht über Go-Analyse sprechen. Dies ist ein neues Framework, das seit Go 1.12 veröffentlicht wurde. Es vereinheitlicht Schnittstellen so, dass Linter einfach zu schreiben, Linter einfach zu bedienen und auszuführen ist. Go-Tierarzt startet 1.12 insgesamt ganz auf Go-Analyse umgestellt. Offensichtlich ist dies die Zukunft. Dass es das gesamte Ökosystem von Go stark verändern wird. Aber im Moment ist es im Allgemeinen ziemlich früh, darüber zu sprechen. Also, was wird als nächstes passieren? Weil ich bei der Go-Analyse nur wenige Linters gesehen habe und fast keiner der vorhandenen noch darauf umgestellt hat.
Wenn Sie eine kurze Schlussfolgerung zum Abschnitt zum Ausführen von Lintern ziehen, empfehle ich jedem, Golangci-Lint zu verwenden. Sie werden schnell und bequem Linters ausführen. Sie müssen nicht mit anderen Anweisungen, Befehlen schamanen.
Lassen Sie uns darüber sprechen, wie Linter im Projekt implementiert wird. Ich denke, dort standen alle, die versuchten, Linters einzuführen, vor einem solchen Problem. Hier haben Sie ein Projekt für eine Million Codezeilen mit Geschichte. Sie haben TeamLead überzeugt, Linters zu implementieren. Starten Sie und sehen Sie eine Million Nachrichten. Verstehen Sie, dass Sie wochenlang keine Zeit haben, sich zu setzen, um alles zu reparieren. Was zu tun ist? Sie können einfach aufgeben und alles aufgeben. Oder Sie können sich etwas einfallen lassen.
Erstens, die einfachste Option, können Sie versuchen, einige Kommentare von Lintern im Text regelmäßig mit der Konfiguration golangci-lint.yaml auszuschließen. Wenn Sie feststellen, dass bei den Kommentaren Linters schwören, diese Kommentare Ihnen jedoch im Allgemeinen egal sind, können Sie sie zu den Ausnahmen hinzufügen.
Kann Wege ausgeschlossen werden. Sie haben beispielsweise ein Verzeichnis eines Drittanbieters und Ihr Code ist nicht vorhanden. Sie müssen es nicht überprüfen. Kann durch Dateinamen ausgeschlossen werden.
Wenn Sie nicht die gesamte Datei ausschließen möchten, können Sie die Funktion mit nolint vor der Funktion ausschließen. Für nolint können Sie über den Doppelpunkt eine Liste von Lintern angeben, für die es als Ausnahme fungiert. Oder nicht anzugeben, dann werden alle Linter ignoriert.
Wann sollte man Nolint überhaupt verwenden? Zum Beispiel verwende ich nolint: deepguard, das Importe erfassen kann, d. H. Importe können nicht verwendet werden. Ich habe den Import der Logrus-Bibliothek verblüfft, um sie nicht versehentlich anstelle meines gewünschten Loggers zu verwenden. Aber in meinem Logger selbst benutze ich Logrus. Daher muss ich nur an einer Stelle im Projekt nur eine Datei aus dem Import erstellen. Ich markiere es mit Nolint.
Angenommen, Sie haben dies alles getan, fügen Sie exclude und nolint hinzu. Wir sehen, dass noch Tausende von Nachrichten übrig sind. Repariere es ein paar Tage. Es gibt einen coolen Hack. Schauen wir uns ein Beispiel an. Es gibt eine main.go-Datei, in der die 5. Zeile vor langer Zeit hinzugefügt wurde, und die 6. Zeile wird erst heute hinzugefügt. Was können wir tun?
Wir können revgrep verwenden. Mit Revgrep können wir eine Git-Revision angeben, nach der wir nach Fehlern suchen müssen. Das heißt, hinterlassen Sie eine Nachricht erst nach einer bestimmten Überarbeitung. Wenn die 6. Zeile nach dem Ursprungsmaster geändert wird, wird sie nur behoben. Und alle vorherigen Nachrichten wird er nicht die 5. Zeile melden. Das ist ein sehr cooler Trick. . . golangci-lint . . , . git hash commit. . . hash commit tag revgrep CI. . . . mail.ru, .
revgrep golangci-lint. --new-from-rev --new. .
. --new. 20 , . . . . . Was zu tun ist? --new-from , . .
. golangci-lint . . . , .
. . -, CI. CI, . go get. . , CI build . . . wget . . , ---enable-all , golangci-lint, , 5 build . . .
Das Coole ist Pre-Commit Hook. Wer verwendet den Pre-Commit-Hook, um Ihre Hände zu heben? Ziemlich wenig. Pre-Commit-Hook ist eine Git-Datei, mit der Sie nach dem Festschreiben beliebigen Code ausführen können. Aber bevor dieses Commit erfolgreich ist. Wenn der Pre-Commit-Hook einen Fehler zurückgibt, schlägt das Festschreiben fehl. In der Regel ist es praktisch, dort Schnelltests, statische Analysen usw. einzubetten. Ich rate jedem, Golangci-Flusen einzubetten. Sie können dies manuell über das Shell-Skript tun. Dies ist über das Pre-Commit-Dienstprogramm möglich. Ein Beispiel für die Einrichtung auf einer Folie. Installiert Pre-Commit mit pip, einem Dienstprogramm zum Installieren von Python-Paketen. pip install pre-commit installiert die Konfiguration. Golangci-lint unterstützt bereits die Integration mit Pre-Commit.
Die Option --fast. Wir kehrten zu ihr zurück. Ich rate jedem, es in der IDE zu verwenden. Im Allgemeinen sollte die IDE natürlich die Integration mit Lintern verwenden. Verwenden Sie die Option --fast, damit Ihre IDE nicht einfriert.
Ich denke das ist ziemlich offensichtlich. In CI müssen Linters eingebettet werden. Wenn Sie sie nicht einbetten, wird es ein klassisches Bild geben: "Lass es uns jetzt hämmern, jetzt haben wir eine Veröffentlichung, nicht vorher." Allmählich werden Sie immer mehr Kommentare haben. Sie hören einfach auf, Linters als Klasse zu betrachten. Daher streng in CI. Darüber hinaus können Sie einfach Linters in CI installieren. Wenn der Build fehlschlägt, klettern wir in das Build-Protokoll und suchen, warum es dort hingefallen ist. Wo ist der Kommentar in welcher Zeile? Dies ist nicht sehr praktisch.
Es gibt einen cooleren Weg. Sie können Linter als Person oder als Prüfer fungieren lassen. Sie können Sie unter github.com, gitlab.com für eine Zeile mit Fehlercode auf Ihrer Pull-Anfrage kommentieren. Linter kann schreiben, dass er ein Problem gefunden hat. Das ist unglaublich cool. Dies spart Zeit beim Code des Autors. Weil Sie nicht in das Build-Protokoll gehen müssen. Außerdem kann eine Person einen Kommentar abgeben, wenn sie dieser Bemerkung des Linter nicht zustimmt. Im Beispiel auf der Folie erfolgt dies mit dem Dienstprogramm reviewdog. Dienstprogramm OpenSource. Sie ist frei. Sie können sich selbst installieren.
Neben Reviewdog gibt es auch Projekte wie GolangCI, Code Climate, Hound. Mit ihnen können Sie diese Linters mit nur einem Klick mit Ihrem OpenSouce- oder privaten Repository verbinden und in Pull Request inline kommentieren. Es gibt immer noch eine coole Sache, SonarQube.
Ich kann goreportcard noch nicht erwähnen. Mit diesem Projekt können Sie einen Bericht in Ihrem Repository erstellen. Sie geben dort Noten ab, geben ein Abzeichen und schreiben, wie gut Ihr Code für ein Dutzend Linter Clean ist. Ich rate auch.
Ich möchte, dass Sie gleich am Montag zur Arbeit kommen und etwas von dem anwenden können, was ich gesagt habe. Hier ist eine Zusammenfassung dessen, was Sie anwenden können. Installieren Sie zuerst Golangci-Lint. Schalten Sie dort alle Linters ein. Dann verbringen Sie 1 Stunde. Schalten Sie während dieser Stunde alle Linters aus, die Ihnen wahnhaft erscheinen. Betten Sie danach golangci-lint in das CI in der IDE ein und konfigurieren Sie den Pre-Commit-Hook. Gleich danach können Sie --new-from-rev konfigurieren und angeben, dass wir beim aktuellen Commit nach Fehlern suchen. Und alle vorherigen Fehler werden später separat behoben. Konfigurieren Sie danach optional den Reviewdog so, dass er Ihnen weiterhin Kommentare zu Ihrem Github oder in Gitlab gibt. Damit steigern Sie die Qualität des Projekts enorm. Begeistern Sie das ganze Team.
Vielen Dank für Ihre Aufmerksamkeit. Meine Kontakte auf der Folie.
Frage: Sagen Sie mir, haben Sie vorgefertigte Konfigurationsdateien, die Sie in Open Access stellen und die Sie einfach herunterladen und verwenden können, um die Tonnen von Golangci-Lint-Einstellungen nicht zu verstehen? Was Sie empfehlen.
Antwort: Gute Idee. Golangci-lint selbst hat bereits eine eigene golangci-lint.yaml, die es verwendet. Sie können es als Ausgangspunkt verwenden.
Frage: Lesen Sie auf der Folie zum Build-Cache den Cache für Module. Im Cache geben Sie den gesamten Modulcache an. Sie können .cache / downloads angeben, dann gibt es einen ziemlich großen Unterschied: 400 Megabyte gegenüber 10. Dies reicht aus, um die Module einfach zu extrahieren. Dies ist jedoch nur möglich, wenn das Modul verwendet wird.
Frage: Werden Sie auch go-Module oder dep unterstützen oder in etwas in einem gehen?
Antwort: Keine Notwendigkeit, die man unterstützt. Jetzt gibt es eine Go-Paketbibliothek. Sie ist mit dem Laden des Quellcodes beschäftigt. Es unterstützt sowohl Module als auch Nichtmodule. Sie wird die Unterstützung für Nicht-Module noch nicht entfernen.
Frage: Planen Sie verschiedene Plugins für die Integration nicht nur mit Travis, sondern auch mit anderen Automatisierungsservern?
Antwort: golangci-lint führt keine Integration durch. Um in CI zu laufen, rufen Sie einfach golangci-lint --run auf.
Frage: Um einige Berichte zu analysieren, zum Beispiel in Jenkins, speichern wir eine HTML-Datei.
Antwort: Es gibt ein Ausgabeformat junit, csv, json xml. All dies kann bereits analysiert werden.
Frage: Wir haben vorher Gometalinter verwendet und es war langsam. Dann wechselten wir zu einem Linter namens Revive. Du hast ihn überhaupt nicht erwähnt. Und ich für meinen Teil bin überhaupt kein Experte in diesem Thema. Ich wusste nichts über deinen Linter, was du erzählt hast. Könnten Sie am Ende schreiben, sagen wir die Profis Ihres Linter oder die Profis der Wiederbelebung.
Antwort: revive ist ein umgeschriebener Golint. Dies ist nur einer der Linter. Es gibt Einstellungen. Er fügte auch ein paar Linter hinzu, ein paar Schecks. Golangci-Flusen sind in sich 30-50 Linter. Dies ist eine Wiederbelebung von anderthalb Linter. Revive ist insofern cool, als es Golint nimmt und es parallel macht. Beleben Sie die Arbeit schneller wieder als Golint. Dies ist jedoch nur ein Linter. Revive kann Teil von Golangci-Flusen sein.
Frage: Sie hatten eine Folie in der Überprüfung der Linters über gocritic: vastParam, die empfohlen wird, um fett gedruckte Strukturen per Zeiger zu übertragen. Dies wird jedoch dazu führen, dass alle diese Strukturen ausschließlich in HEAP zugewiesen werden. Und wird dies nicht zu größeren Problemen als Vorteilen führen? Wenn solche Strukturen zum Beispiel viel übertragen werden.
Antwort: Ich stimme vollkommen zu. Sie sollten diese Warnungen nicht verwenden und sie nicht einfach befolgen. Es kann wie eine vorzeitige Optimierung sein, es kann dem Projekt schaden. Normalerweise schalte ich diese Klasse von Lintern im Allgemeinen aus, wenn ich nicht die Leistung einer kritischen Aufgabe habe. wo ich Schwächen mit dem Profiler finde.
Frage: Ich komme aus Yandex. Wir verwenden Ihren Linter in einem großen Repository. Wir haben festgestellt, dass er bereits sehr schnell für ein großes Repository arbeitet. In nur wenigen Tagen haben sie ein einfaches Dienstprogramm geschrieben, das über go package Pakete findet, die sich seit Einführung des Zweigs vom Assistenten geändert haben, sowie Pakete, die von ihnen abhängen. Und lassen Sie den Linter nur auf ihnen laufen. Und der Lintercheck wurde mehrmals beschleunigt.
Antwort: Vielleicht erstellen Sie eine IDSUE, fügen ein Skript hinzu, und möglicherweise werde ich all dies in Golangci-Lint einbetten.
Frage: Sind für die gefundenen Kommentare Schweregrade geplant, damit einige in den Bericht aufgenommen werden können, der CI-Prozess jedoch nicht gefälscht wird? Zum Beispiel durch den Abschlusscode.
Antwort: Viele Leute haben gefragt und ich werde sofort sagen, dass die Schwierigkeit darin besteht, dass diese Ernsthaftigkeit sie alle unterstützt. Es gibt 3 oder 4 von 30 Linter. Was tun mit Stahl? Unverständlich. Es ist notwendig, ihre Kommentare manuell zu analysieren und sie irgendwie zu markieren. Behandeln Sie falsch positive Ergebnisse. Dies ist in der Regel ein großer Arbeitsaufwand. Ich bin mir nicht sicher, was wann gemacht wird. Es gibt andere Möglichkeiten, um das gleiche Ziel zu erreichen.
Frage: Es gibt Artikel auf dem Hub Genauer gesagt, eine Reihe von Artikeln über C ++ Linter. Das Unternehmen entwickelt dieses Geschäft. Sie verdienen Geld damit. Tatsächlich richtet sich ihre Arbeit oder vielmehr diese Reihe von Veröffentlichungen nicht mehr an Entwickler, sondern eher an diejenigen, die Entwickler verwalten. Dies ist im Wesentlichen reiner Code, Stilisierung. Dies ist unsere Aufgabe, aber auch die Aufgabe von Führungskräften, Teamleitern. Planen Sie, diese Medienreihe hier in großen Mengen solcher Ressourcen bekannt zu machen, damit die Leute sie lesen und dann ihren Teams vorstellen können? Und nicht wir haben von unten geklopft.
Antwort: Ich hatte einen Plan. Danke für das Angebot. Ich hatte vor, einen umfassenden Artikel wie diese Rede zu schreiben, aber dort im Laufe des Jahres ausführlicher und umfassender. Vielleicht schreibe ich auf Russisch und Englisch.