Wir sind ein agiles Projekt von ungefähr 20 Entwicklern, die in 2-3 Teams organisiert sind, ohne eine Paarprogrammierung, ein bisschen Teamrotation und viele Peer-Reviews. Die meisten von uns sind süchtig nach der "grünen Statusleiste" der IDE-Code-Analyse (die meisten verwenden Idee, einige Eclipse und Netbeans, Resharper ist Idee Funktionalität in der .net Welt).
Wir überlegen, den formellen Standard vollständig fallen zu lassen. Da wir agil sind, versuchen wir alle Dinge, die uns nichts geben, wegzuwerfen, und ehrlich gesagt sitzt es einfach da und sieht aus wie eine Reliquie aus der Vergangenheit.
Das Argument ist, dass die vom regulären Code-Standard erzwungene Codequalität einfach die falsche Metrik ist; Die Platzierung von Zahnspangen hat wenig oder gar nichts mit Qualität zu tun. IDE-Code-Analyse, Findbugs und Peer Reviews schaffen die Qualität, die wir wollen
Wohl haben wir einige "Flur" -Code-Standards, die Sie nicht brechen wollen, wenn Sie erwarten, mit den anderen zu Mittag zu essen (niemand benutzt harte Tabs, wir haben einige Grenzen!)
Sind Code-Standards ein Relikt aus dem Wasserfall Vergangenheit?
P. s. Ich werde diese Sprach-Agnostik nicht markieren, weil ich glaube, dass es einen wesentlichen Unterschied zu dem gibt, was Werkzeuge in Java / C # im Vergleich zu anderen Sprachen tun können.
Bearbeiten: Ich würde die Auswahl externer Bibliotheken nicht als Teil des Code-Standards betrachten. Für die meisten Kernbibliotheken ist dies sicherlich eine zentralisierte Entscheidung.
Persönlich bin ich weniger dagegen da nicht jetzt ein formeller Kodierungsstandard ist, als ich es zumindest unter bestimmten Umständen gewohnt war:
C # / Java - das sind ziemlich viele bekannte Standardkonventionen trotzdem
Kleine Anzahl von Entwicklern (weniger als 10 sagen)
Wenige "Junior" -Entwickler
Ich fühle nicht mehr, dass die formale Standardisierung von Dingen wie die Platzierung von Klammern, Abständen und Einkerbungen so wichtig sind.
Wenn Sie eine relativ große Organisation mit vielen Junior-Entwicklern sind oder eine große gemeinsame Codebasis haben, dann wäre ein formeller Codierungsstandard wahrscheinlich viel wichtiger.
Ich sehe nicht wirklich, dass ein formeller Codierungsstandard oder nicht mit der verwendeten Methode verwandt ist
Statische Analyse und Peer-Review können als Erzwingung verwendet werden, aber Sie brauchen noch einige Standards, mit denen sich das Team einverstanden erklärt.
Außerdem gibt es Low-Level-Mechanismen wie Namenskonventionen und höhere Standards wie die Verwendung bestimmter Bibliotheken, Protokolle und Parallelitätsvereinbarungen. Ich kann nicht sehen, dass 20 Entwickler ihre eigenen Namen für Klassennamen und Methodennamen aufstellen, die für sich selbst konsistent sind.
Wenn aus irgendeinem magischen Grund alle Streitigkeiten im Rahmen von Code-Reviews für Ihr Team friedlich gelöst werden, brauchen Sie vielleicht keine schriftlichen Gesetze; Ein geschriebenes Gesetz verschiebt jedoch das Argument von "A ist besser / schlechter als B" zu "A ist richtig / falsch gemäß der Konvention", was Zeit spart.
Nein, ein Kodierungsstandard ist wichtig. Es geht um die Lesbarkeit und damit um die Überprüfbarkeit des Codes. Das menschliche Gehirn ist sehr gut in der Mustererkennung, und die Platzierung von Klammern ist entscheidend für seine Fähigkeit, die Art von Code, den Sie betrachten, schnell zu erkennen.
Zusätzlich wird ein Codierungsstandard für neue Projektmitglieder benötigt. Vor allem, wenn Sie nicht genug Paarung machen. Es ermöglicht neuen Projektmitgliedern, schneller zu beschleunigen.
Wenn Sie alle die gleichen Dinge tun, halten Sie sich an einen Standard; Sie könnten es also auch kodifizieren - obwohl es nur aus einer kleinen Handvoll Dinge bestehen könnte (wie Leerzeichen, nicht Tabs). Wenn Sie es irgendwo notiert haben, können neue Teammitglieder darauf hingewiesen werden und wissen, was die Erwartungen sind (im Gegensatz zu vermieden werden auf dem Flur und nicht zum Mittagessen eingeladen).
Nur meine zwei Bits. Aber ich denke, Standards bringen einen Wert auf den Tisch.
Ich glaube, dass ein Standard wichtig ist, aber wie formell er definiert werden muss, hängt davon ab, wie gut Ihr Team kommuniziert. Wenn Ihr Team effektiv arbeitet und der überprüfte Code sauber und leserlich ist, können Sie die Formalität wahrscheinlich lockern, aber das vollständige Entfernen wird den neuen Mitgliedern das Leben schwer machen.
Das Hauptziel eines Codierstandards sollte darin bestehen, Erwartungen an die Entwickler in einem Team (insbesondere neue Mitglieder) zu stellen, einige davon können mit statischen Analysewerkzeugen erledigt werden. Wenn diese von Anfang an als Gewohnheit verwendet werden, dann kann dies effektiv sein, andernfalls kann die Bereitstellung eines Dokuments ein guter Ausgangspunkt für neue Entwickler sein. Sie möchten nicht, dass die Standardrichtlinien bei der ersten Codeüberprüfung eine Überraschung darstellen.
Teil dieses Zwecks ist es, sauberen, lesbaren Code zu fördern, indem Entwickler in den von ihnen verwendeten Stil geführt werden (siehe Ссылка ).
Im Laufe der Zeit, wie Sie bereits gesehen haben, wird der Standard zu einer verinnerlichten Verantwortung jedes Entwicklers und verlässt sich weniger auf externe Zeremonien (formelle Dokumentation des Standards).
Sie sollten vielleicht in Erwägung ziehen, den Schwerpunkt des formalen Codierungsstandards auf Probleme mit hartem Format zu reduzieren, z. Klammerplatzierung, Format für Variablennamen usw., die leicht durch statische Analyse und mehr auf Stilrichtlinien, z.B. Benennung, Größe der Methoden \ Klassen, Klarheit des Zwecks usw.
Ein Kodierungsstandard sorgt für Konsistenz. Es erleichtert neuen Teammitgliedern, sich mit der Codebasis vertraut zu machen.
Aber ich glaube nicht daran, irgendein monolithisches Kodierungsstandarddokument zu erstellen, auf das verwiesen werden muss. Ich ziehe es Check und PMD konfigurieren Kodierungsstandard meines Teams. Ich integrieren Kontrollen für beide Werkzeuge in mein Maven Skript zu bauen und die Eclipse-Plug-ins verwenden, um Verletzungen während der Bearbeitung zu markieren.
Sind Code-Standards ein Relikt aus dem Wasserfall Vergangenheit?
Ich glaube nicht. Code-Standards sind ein wichtiger Mechanismus, um eine einheitliche Lesbarkeit des Codes sicherzustellen. Dies ist besonders wichtig, wenn ein neuer / weniger erfahrener Programmierer dem Team mitten im Projekt beitritt.
Das Argument ist, dass die vom regulären Code-Standard erzwungene Codequalität einfach die falsche Metrik ist
Einverstanden. Dies ist ein gültiger Punkt. Die Einhaltung eines gemeinsamen vereinbarten Standards bietet jedoch "nicht greifbare" Vorteile in Form von schnelleren Überprüfungen und allgemeinem Verständnis der Kontrollblöcke. Bei einem unserer Projekte hatten wir einen "flexiblen" Standard für Zahnspangen, der zu einer anderen / ambigen Interpretation führte, die die Leute dazu brachte, sie völlig zu überspringen, wenn sie konnten. Dies erzeugte ein Potential für Fehler, wenn Leute, die davon ausgingen, das gleiche Stück Code änderten.
Kodierungsstandards sind gut, sie sind dort für Einheitlichkeit und Lesbarkeit und für Best Practices, um Fehler zu vermeiden. Review ist auch gut, aus ähnlichen Gründen. Wenn die Entwickler es verinnerlicht haben, ist das gut. Aber was ist, wenn jemand anderes an Bord kommt? Was ist, wenn die Entwickler etwas ähnliches bei einem folgenden Projekt verwenden möchten?
Aber ich glaube, dass die meisten Leute es falsch machen oder zumindest nicht auf dem Laufenden sind, was in diesen Tagen möglich ist.
1) Kaufen, bevor Sie bauen . Sie müssen kein umfangreiches Standarddokument erstellen. Andere haben es schon oft getan. Ein unternehmensweiter Stil ist besser als ein individueller Stil, aber ein branchenweiter Stil ist noch besser. Die Leute, die Sie einstellen, die Auftragnehmer und die Kunden können es auch wissen. Suchen Sie nach einem Industriestandard und übernehmen Sie ihn. Sie "In-House-Stil" könnte nur eine Leseliste gefolgt von einer kurzen Liste von Ausnahmen, Änderungen und Ergänzungen sein.
2) Automatisieren . Verwenden Sie die Werkzeuge, mit denen Stilverletzungen angezeigt werden, und andere potenzielle Probleme, wie z. B. Code zum Ausschneiden und Einfügen. In der .net-Welt können FxCop und StyleCop Standards in hohem Maße durchsetzen.
3) Wisse, welche strengen Regeln sind und welche mehr sind, was du nennen würdest. " Richtlinien als tatsächliche Regeln ". Wisse, welche besser du jedesmal tust, und welche du besser als Standard tust, es sei denn, es gibt einen Grund, nicht . Es gibt eine Fülle von Anleitungen in Büchern und so weiter, aber nicht alles ist immer richtig.
4) Regeln aus Code-Reviews ableiten . wenn etwas mehr als einmal in einem Code-Review auftaucht. Es lohnt sich, es für zukünftige Überprüfungen auf eine Checkliste zu setzen. Sie können "code standard" von "code review common issue checklist" trennen, wenn Sie möchten.
Von einem rein stilistischen Standpunkt aus betrachtet, helfen Code-Standards in dem Sinne, dass jeder Entwickler diesen Stil der Benennung, Einrückung, Klammerplatzierung usw. liest. Es braucht etwas von der kognitiven Last, den Code von jemand anderem zu lesen, und lässt den Code-Prüfer sich auf das konzentrieren, was der Code tatsächlich tut.
Ein interessanter Standard, von dem Ihr Team profitieren könnte, ist ein Glossar . Wie heißen die Dinge (im Team / Projekt)? Haben Sie jemals ein Stück Code neu geschrieben, weil Sie nach "connection" grepped, aber nicht nach "link"? Wenn Sie ein Projektglossar haben, können Sie zusätzlichen Zeit und Aufwand sparen, indem Sie sicherstellen, dass die Benutzer konsistente Namen verwenden.
Wenn Sie keinen Kodierungsstandard haben, verwendet jedes Mitglied des Teams seine eigenen Standards. Folgerichtig wird dein Code unordentlich sein. Unordentlicher Code braucht mehr Zeit zum Lesen. Es ist wie eine schlechte Handschrift zu lesen - es braucht nur mehr Zeit zu lesen.
Tags und Links ide java c# code-review