Also habe ich angefangen, für ein großes Unternehmen zu arbeiten, eines mit drei Buchstaben im Namen, und sie versuchen, agil zu werden, haben aber Tonnen von Prozessen, die ich nicht für agil halte.
Das, was mich am meisten beschäftigt, sind Code-Reviews. Mein letzter Job war bei einem Startup, von dem ich sagen würde, dass es das agilste Entwicklungsteam ist, von dem ich je gehört habe.
Mein Argument ist jedenfalls, dass Code Reviews eine Zeitverschwendung bei der iterativen oder agilen Entwicklung sind, bei der die UX / UI extrem / intensiv ist (denken Sie an die Perfektion von Apple / Steve Jobs). Vielleicht kann jemand hier helfen zu verstehen, bevor sie mich feuern?
Hier ist mein Entwicklungsprozess und der bei meinem letzten Start ... sehr agil.
Wir erledigen die frühe Feature-Arbeit, um Entwicklungsaufgaben / Aufgaben zu sortieren. Wir verspotten einige Versionen und präsentieren sie Benutzern, Teams und dem Marketing, um Feedback zu erhalten. Wir machen dann eine weitere Mockup-Iteration, um eine Runde von denselben Stakeholdern wie oben zu gewinnen. Dann teilen wir die Arbeit auf und legen los. Wir haben Meilensteine und Termine zu erfüllen, aber wir verstopfen weiter. Wir haben währenddessen keine Code-Bewertungen. In den Wochen unserer Entwicklung haben wir mehrmals erneut Sitzungen mit den Stakeholdern abgehalten, um zu prüfen, ob die vereinbarten Features / Funktionen / UX / UI noch immer gut und zielgerichtet sind.
Gegen Ende des achtwöchigen Iterationszyklus beginnt die Qualitätssicherung mit dem Testen. Dann wenden wir uns an Alphanutzer und schließlich an Betanutzer. Während der Alpha- und Beta-Phase gehen Entwickler die neuen und älteren Funktionen durch und nehmen täglich oder stündlich iterative Änderungen an der Benutzeroberfläche vor, um die Benutzeroberfläche zu verbessern. Eine Funktion, die in dieser Version entwickelt wurde, wurde in den letzten vier Wochen möglicherweise noch dreimal geändert, um sie zu verbessern und zu perfektionieren, oder um ein paar kleine Funktionen hinzuzufügen (z. B. um die Komponente etwas schlauer oder schlauer zu machen). Manchmal können die Änderungen oberflächlich sein, was bedeutet, dass keine CRUD-Operationen geändert oder modifiziert werden, sondern dass sich nur die gesamte Benutzeroberfläche ändert.
Wäre Code-Reviews bei dieser Art von Entwicklungsprozess, extrem agil, keine Zeitverschwendung? Das heißt, wenn ich einen anderen Entwickler oder zwei meinen Code überprüfen ließ, dieser Code sich dann aber noch dreimal ändert, bevor er veröffentlicht wird, verschwenden wir aufgrund all der UI / UX-Verbesserungen nicht unsere Zeit für die ersten drei Überprüfungen des Codes Code als dieser Code / Komponente / UI verschrottet wurde?
Wir hatten nie viele Qualitätsprobleme mit diesem Prozess und ja, wenn ein Entwickler das gesamte Wissen hinter sich gelassen hat, fanden wir immer kluge Entwickler, die es aufgreifen und übernehmen konnten.
Und ja, wir haben viele Tester, weil sie möglicherweise drei- oder viermal nachprüfen müssen. Lassen Sie sich auch nicht auf die Frage ein, warum sich die Benutzeroberfläche / UX geändert hat. So wird es gemacht. Deshalb gewinnt die App Unmengen von Auszeichnungen für die Benutzeroberfläche / UX und die Benutzer werden für die töten App. Der Gedanke ist, wenn ich eine Verbesserung von 2% in etwas erreichen kann, weil ich eine zusätzliche Stunde Zeit habe, dann mache ich es. Benutzer werden glücklicher sein, was bedeutet, mehr $ oder Benutzer. Und ja, unsere Benutzer sind damit einverstanden, dass sich die App ständig ändert, weil dies seit dem ersten Tag so ist, damit sie es nicht als schlecht oder negativ ansehen.
Hoffe, dass dieser Beitrag nicht so pompös rüberkommt, aber ich kann einfach nicht sehen, dass Code Reviews keine Verschwendung sind. Möglicherweise haben 2% unseres gesamten Codes im überprüften Code Fehler. In jeder Version finden wir möglicherweise 3 Bugs über die Codeüberprüfung. Am Ende sind es also 40 Stunden Code-Review pro Entwickler und Release (4 x 40 = 160 Stunden), um 3 bis 5 Bugs zu finden? Die Chancen stehen gut, dass 50% dieser 3 bis 5 Bugs ohnehin von QA entdeckt wurden. Wäre es nicht besser, diese 40 Stunden pro Entwickler damit zu verbringen, eine neue Funktion hinzuzufügen oder die vorhandenen zu verbessern?
quelle
Antworten:
Es gibt ein paar Dinge, die Code-Reviews für Sie tun können, und einige Dinge, die sie nicht können. Die Argumente zugunsten von Code - Reviews:
Viele agile Prozesse gehen diese auf unterschiedliche Weise an:
Im Wesentlichen gibt es andere Möglichkeiten, sich um die potenziellen Gewinne zu kümmern, die Sie normalerweise bei Peer Reviews erzielen würden. Meine persönliche Erfahrung mit Peer Reviews ist, dass sie sehr ineffiziente Mechanismen sind und keine Bugs oder größere Designfehler finden können. Sie haben jedoch ihren Platz in einigen Teams, und bei Projekten, bei denen Agilität (aus welchen Gründen auch immer) nicht möglich ist, sind sie durchaus erforderlich.
quelle
Sind Code-Überprüfungen nur zum Auffinden von Fehlern gedacht? Du scheinst zu glauben, dass das wahr ist und ich nicht.
Ich würde argumentieren, dass Codeüberprüfungen sich mehr auf die kollektive Eigentümerschaft des Codes beziehen, sicherstellen, dass das Wissen in mehreren Köpfen vorhanden ist, und andere darauf vorbereiten, den Code zu erben, was sowohl für neue Funktionen als auch für Fehler gelten könnte. Ich mag Code-Reviews, um das System ein wenig zu überprüfen und auszugleichen, da man nie weiß, wann jemand eine Idee hat, wo etwas neu geschrieben werden kann, um die Konventionen beizubehalten.
quelle
Die Paarprogrammierung ist die XP-Antwort auf Codeüberprüfungen. Im Wesentlichen wird jede Codezeile beim Schreiben überprüft. Es sind Code-Reviews, die bis zum Äußersten gehen.
quelle
Codeüberprüfungen und -tests erkennen häufig nicht die gleichen Arten von Fehlern, und Fehler, die durch die Codeüberprüfung entdeckt wurden, lassen sich wahrscheinlich leichter beheben, da die Position des Fehlers bekannt ist.
Sie können nicht wissen, ob der Code fehlerfrei ist, nur weil er den Test mit keinem aufgezeichneten Code besteht. "Testen kann nur das Vorhandensein von Fehlern beweisen, nicht das Fehlen." (Dijkstra?)
Die Codeüberprüfung behält auch den gleichen Codestil bei und kann Stellen finden, an denen der Code nicht gut ist, aber momentan funktioniert. Das spart Wartungskosten auf der Straße.
Auch die Anforderungen eines Großkonzerns und eines Startups sind unterschiedlich. Startups scheitern normalerweise und müssen schnell gehen. Große Unternehmen legen viel mehr Wert darauf, Dinge richtig und nicht so schnell wie möglich zu machen. Möglicherweise bevorzugen Sie es, bei Startups zu arbeiten, als bei großen Unternehmen. Dies ist jedoch kein Grund, Startup-Strategien einzuführen, bei denen sie nicht passen.
quelle
Stellen Ihre Code-Reviews immer nur UI / UX-Änderungen bereit? Ich würde behaupten, dass dies keine Codeüberprüfung ist, sondern ein Usability-Test. Bei Code-Überprüfungen geht es viel mehr darum, die Probleme aufzudecken, die Benutzer / Tester / Unternehmen / was auch immer niemals sehen, weil sie im Code enthalten sind. Der Hinweis ist genau dort im Namen.
Jetzt stimme ich Ihnen zu, dass irgendwo eine Linie gezogen werden muss. Überprüfen Sie 4 Iterationen derselben UI-Änderung? Oder durchlaufen Sie vier Iterationen davon, wobei jede den Code möglicherweise weniger wartbar macht? Ich würde sagen, versuchen Sie beide Ansätze zu messen und die richtige Balance für Ihr Team zu finden, aber geben Sie die Codeüberprüfung nicht vollständig auf.
Auch wenn eine Codeüberprüfung niemals ein Problem aufwirft, hat sie einen Vorteil, den Sie selten bemerken, bis sie nicht vorhanden ist: Jeder Codeteil wird von zwei Entwicklern geprüft, sodass zwei Entwickler wissen, was die Änderung war und was damit erreicht werden sollte . Einer von ihnen wird am nächsten Tag krank und hat eine Woche frei, der andere kann alle dringenden Arbeiten abholen.
quelle
Ich stimme eher zu, dass der Besitz von kollektivem Code und die Paarung mit TDD und CI die agilen Gegenmittel gegen formelle Codeüberprüfungssitzungen sind.
Sogar unter UP / Spiral war ich kein großer Fan eines bestimmten Prozessschritts, nämlich der "Codeüberprüfung", denn es scheint mir, dass die Probleme, die es wahrscheinlich findet, später gefunden werden, als wenn die gleiche Energie stattdessen in einige im Voraus investiert würde Zusammenarbeit und einige einfache Automatisierung.
Ich hatte das Gefühl, weil es Folgendes gab: - Einige gemeinsame Überprüfungen des Designs (in der Regel in UML auf einem Whiteboard ausgedrückt) bedeuteten, dass große Designprobleme oder die schlechte Verwendung von APIs usw. festgestellt wurden, bevor viel Code geschrieben wurde. - FxCop, CheckStyle, FindBugs (oder ähnliches) laufen zusammen mit automatisierten kontinuierlichen Integrations-Builds, um Namen, Stil, Sichtbarkeit, Code-Duplizierung usw. zu erfassen.
Wir konnten früher scheitern und schneller Rückmeldungen erhalten, als dies durch eine nachgelagerte Codeüberprüfung möglich gewesen wäre.
Ich sage nicht, dass es Zeitverschwendung ist, sich hin und wieder zu setzen und einen Blick auf Ihre Codebasis zu werfen, aber die Codeüberprüfung ist ein wichtiger Schritt, um etwas Erledigtes aufzurufen durch bessere Inspektion / Zusammenarbeit vorgelagert vermieden werden.
quelle
Eines der Hauptziele, das ich von Code Reviews erwarte, ist es, die Pflege des Codes zu vereinfachen. Codeüberprüfungen sollten jedem helfen, klaren Code zu schreiben, der den guten Codierungsstandards angemessen entspricht. Vor allem in großen Unternehmen wird der meiste Code häufig gewartet. Die Rückzahlung für wartbaren Code sollte vor der Freigabe des Codes beginnen und danach fortgesetzt werden.
Codeüberprüfungen an und für sich sollten niemals zu Codeänderungen führen. Wenn die Codeüberprüfung anzeigt, dass Änderungen erforderlich sind, führt die Implementierung der Änderung zu einer Änderung des Codes.
Der Codestatus kann sich infolge der Überprüfung ändern, dies sollte jedoch für die von Ihnen genannten Probleme größtenteils unerheblich sein.
Wenn die Codeüberprüfung zu mehreren Codeänderungen führt, ist in Ihrem Entwicklungsprozess ein Fehler aufgetreten. Angesichts der Anzahl der Tester, die Sie haben, kann es sein, dass Sie es über die Mauer werfen und die Tester die Problemmentalität finden lassen.
Die Dinge sollten im abgeschlossenen Zustand an die Tester gehen. Das Testen sollte so weit wie möglich automatisiert werden, damit die Tester nicht immer wieder dieselben Tests durchführen.
UI / UX erfordert einige Testzeit, aber Design- / Entwicklungsexperten am Front-End sollten dies reduzieren. Es erfordert auch ein Gesicht vor dem Bildschirm. In allen Anwendungen, mit denen ich gearbeitet habe, war dies jedoch ein relativ kleiner Teil des Codes.
Die Kosten für die Implementierung von Änderungen (einschließlich Fehlerkorrekturen) steigen in der Regel in jeder Phase. Das Auffinden von Fehlern in der Entwicklung ist im Allgemeinen günstiger als das Beheben von Fehlern nach dem Testen.
quelle