Sollte der Codierungsstandard / -stil durch den Continuous Integration Server erzwungen werden, auf dem statische Analysetools (z. B. PMD, StyleCop / FxCop) ausgeführt werden und der Build fehlschlägt, wenn die Standards nicht befolgt werden? Welche Arten von Regeln sollten nicht verwendet werden, um den Build fehlzuschlagen?
Antworten:
Codierungsstandards sollten aus einem bestimmten Grund vorhanden sein ... und die Nichteinhaltung sollte überprüft werden.
Es sollten jedoch nicht alle Verstöße als Fehler betrachtet werden - so wie es nicht alle Verstöße gegen die Kompilierung sind. Wo Sie die Linie ziehen, muss eine Firma und eine Werkzeugentscheidung sein.
Zum Beispiel definiert MISRA seine Regeln als "Erforderlich" und "Empfehlung". Ich würde empfehlen, dass Advisories den Build fortsetzen.
Es ist nicht völlig unbekannt und Sie werden wissen, ob es für Sie funktioniert, wenn Sie es ausprobieren. Es gibt einige Schritte, die Sie vorher unternehmen könnten.
Zunächst sollte das Team gemeinsam über die Standards entscheiden. Dann sollten Tools wie ReSharper verwendet werden, um Entwicklern mitzuteilen, ob sie sich nicht an Standards halten. Das Durchführen von Peer Reviews zu jeder Aufgabe könnte weiter helfen.
Nachdem diese Schritte ausgeführt wurden, könnte erwogen werden, Codierungsstandardprüfungen an den CI-Server zu senden. Es sollte jedoch immer noch überlegt werden, ob es sinnvoll ist, einen Build Break zu haben, um die Kodierungsstandards nicht einzuhalten. Das Risiko ist, dass Sie viele fehlerhafte Builds haben, was die Bedeutung von fehlerhaften Builds beeinträchtigen könnte.
Anstatt die Erstellung zu unterbrechen, können Sie die Tools ausführen und sie Berichte erstellen lassen. Wenn sich die Anzahl der Verstöße gegen die Kodierungsstandards zu erhöhen scheint, können Sie das Team zusammenbringen und herausfinden, warum dies geschieht.
Sollte der Codierungsstandard / -stil durch den Continuous Integration Server erzwungen werden, auf dem statische Analysetools (z. B. PMD, StyleCop / FxCop) ausgeführt werden und der Build fehlschlägt, wenn die Standards nicht befolgt werden?
Diese kontinuierlichen Integrationsprüfungen müssen sehr, sehr schnell sein. Jegliche signifikanten Verzögerungen führen dazu, dass Ihre Programmierer sich verpflichten und den Überblick über ihren Denkprozess verlieren, während sie auf die Ergebnisse warten. Machen Sie es länger und sie werden sich verpflichten und eine Tasse Kaffee trinken oder sich mit ihren Büromitarbeitern über die neueste verpfuschte Leistung eines Sportteams unterhalten. Diese Verzögerungen sind äußerst kontraproduktiv. Einige Dinge sollten am besten dem nächtlichen Build oder der Codeüberprüfung überlassen werden.
Welche Arten von Regeln sollten nicht verwendet werden, um den Build fehlzuschlagen?
Zunächst die subjektiven. Wie setzen Sie die Regel "Code muss selbstdokumentierend oder gut kommentiert sein" durch? Die Regel "Keine magischen Zahlen"? Das sind Dinge, die am besten der Codeüberprüfung überlassen bleiben.
Eine weitere Kategorie sind Verstöße gegen die Regeln, denen bereits ein Verzicht gewährt wurde. Bei jeder größeren Codebasis wird es unvermeidlich einige Codestücke geben, bei denen eine Verletzung des Standards genau das Richtige ist.
Im Rahmen eines Plans zur Verbesserung der Softwarequalität haben wir kürzlich eine Reihe von Code-Sniffs codiert, die in unseren Erstellungsprozess integriert werden sollen.
Wir bauen viel, da es für eine PHP-Anwendung keine wirkliche Kompilierung gibt, ist der Build wirklich ein Unit-Test / eine statische Analyse / ein Runner, und wir können es uns leisten, ein paar Zyklen damit zu verbringen.
Wir hatten einige Probleme mit der Codequalität und einigen älteren Code mit vielen Problemen.
Ausgehend davon, dass das Festschreiben ignoriert wird, wenn es nicht fehlschlägt, haben wir damit begonnen, Festschreibungen gegen unseren 'gewünschten' Codierungsstandard zu bestätigen und fehlgeschlagene Festschreibungen mit Fehlern, die nicht dem Standard entsprachen.
Die Wartung wurde gestoppt, selbst die einfachste Behebung einer älteren Komponente erforderte vom Entwickler die Neuformatierung großer Mengen von Quellcode, und der Build wurde mehrmals abgebrochen. Unnötig zu erwähnen, dass wir die Fehler in Warnungen geändert haben, und jetzt sind sie ignoriert und "größtenteils" sinnlos.
Also würde ich das sagen (aus harter Erfahrung gelernt).
Stellen Sie sicher, dass der Standard Ihrer Codebasis nahe genug an dem Standard liegt, den Sie erzwingen, damit Sie nicht von Entwicklern verlangen, dass sie die Codevolumen sofort neu formatieren. Oder .. Sie sind auf den Mehraufwand vorbereitet und rechnen damit.
Da wir ein kleines Team mit einem großen Lieferbedarf sind, konnten wir es uns nicht leisten, das Team auf einen großen Umstrukturierungsvorgang umzustellen. Unsere Kodierungsstandards werden jetzt hauptsächlich manuell überprüft, und das Erbe wird im Rahmen eines kontinuierlichen Verbesserungsplans neu geschrieben.
Als ich sagte, dass die Warnungen "größtenteils" sinnlos sind, verwenden wir sie jetzt zum Aufzeichnen von Statistiken, mit denen wir KPIs messen können, die sich weiter verbessern sollten.
Wenn wir die Code-Sniffs erneut erzwingen, beginnen wir mit Light und führen jeweils ein paar Sniffs ein, bis der Standard erzwungen ist.
Es wird von Ihrem endgültigen Ziel und Ihrer Strategie abhängen .
Das Erzwingen aller guten Standards im CI-Server scheint sehr lukrativ zu sein. Für das große Entwicklerteam (mit mehr als 6 Entwicklern) ist dies jedoch möglicherweise nicht praktikabel, wenn dies bei jedem Commit zum Server durchgeführt wird. Das Warten auf die Antwort Ihres Servers nach dem Festschreiben sollte NICHT lange dauern. Dies kann möglicherweise zu Ausfallzeiten führen.
Es ist jedoch absolut legitim, ein Commit zu blockieren, wenn der Code (der tatsächlich gesetzte Change) Abhängigkeitsprobleme aufweist oder nicht kompiliert werden kann. Fehlerhafter Code aufgrund des Code-Layouts und einiger Namenskonventionen kann jedoch zu schwerwiegend und keine wesentliche Einschränkung für die Commit-Regeln des CI-Servers sein.
Es ist jedoch sehr wahrscheinlich, dass es hilfreich ist, wenn es während des abendlichen Builds angewendet wird.
Darüber hinaus können Re-Factoring-Tools die Implementierung und das Erlernen von Standards unterstützen - wie die Verwendung von Resharper oder JustCode durch Entwickler.