Design Reviews Pre-Implementation Ich gehe davon aus, dass ein gutes Design die Anforderungen eines Projekts besser erfüllt. Code-Überprüfungen während der Implementierung stellen sicher, dass der Coder das Design ordnungsgemäß in tatsächlichen Code übersetzt. Sind Design-Reviews notwendig? Vor- und Nachteile.
Das Beste an Design- / Code-Reviews: Sie müssen über Ihr Design nachdenken.
Wenn Sie wissen, dass Sie Ihren Entwurf oder Code jemandem erklären müssen, werden Sie (wahrscheinlich) vorsichtiger sein, wenn Sie ihn schreiben.
Und natürlich hat der Reviewer vielleicht sogar gute Ideen und Feedback zu Ihrem Design / Code, um ihn zu teilen.
Code-Reviews sind ein guter Weg, um neue Entwickler schneller auf den neuesten Stand zu bringen: Wenn Sie potenzielle Probleme und bessere Lösungen für jemanden in seinem eigenen Code (auf freundliche Art und Weise) aufzeigen, wird er einen besseren Codierungsstil lernen schneller. Natürlich müssten Sie erklären, was die Unterschiede zum besseren Code sind. Nur "Ich mag es besser so" schneidet es nicht.
Ich fange an, Code-Reviews selbst zu lieben - ich bin in einer Senior-Programmierposition und verändere mehr in die Rolle, anderen Programmierern zu helfen, harte Probleme zu lösen, Code-Reviews zu machen, statt zu programmieren (OMG dreh ich in einen Manager).
Versuchen Sie immer etwas von ihnen zu lernen, wenn Sie die anderen überprüfen. Es gibt immer etwas zu lernen, sogar von unserem 7-Tage-Schul-Praktikanten, der ein paar kleine PHP-Sachen programmiert hat, habe ich interessante Möglichkeiten gelernt, Dinge zu tun.
Pros - Design- und Code-Reviews tragen auch dazu bei, die Konsistenz innerhalb eines Teams zu gewährleisten, insbesondere im Umgang mit Junior-Programmierern oder beim Umstieg auf neue Technologien oder Programmiermethoden. (Mein Team ist zu MVP gegangen, aber alle Entwickler haben es auf verschiedene Arten implementiert. Bewertungen waren notwendig, um uns alle auf die gleiche Seite zu bringen)
Nachteile - wenn nicht richtig gemacht, sind sie eine Auspeitschung. Einige Entwickler benutzen sie, um jemanden zu verprügeln, der nicht mit ihnen übereinstimmt. In anderen Fällen werden sie zu einer zeilenweisen Diskussion des Codes anstelle einer übergreifenden Architekturdiskussion. Oder sie werden zu einer Formalität, die nur Arbeit ist.
IMO ...
Design-Reviews sollten stattfinden, bevor der Produktionscode geschrieben wird. Code-Reviews sollten nach dem Schreiben des Codes stattfinden. Sie haben unterschiedliche Zwecke.
Design-Reviews helfen dabei, die Korrektheit, Vollständigkeit und Solidität der vorgeschlagenen Lösung zu überprüfen, während Code-Reviews sicherstellen, dass der Code die Qualitäts- und Code-Standards des Teams erfüllt. Code-Reviews können in fast jeder Phase stattfinden, sobald mit dem Code begonnen wurde; und kann sogar auf einer kontinuierlichen Basis auftreten. Es ist jedoch zu spät, das Design nach Abschluss des Projekts zu ändern.
Designüberprüfungen können nach Abschluss eines Projekts erfolgen, wenn das Ziel der Überprüfung akademisch ist.
$ 0,02
Wir haben gerade angefangen, Design-Reviews zu schreiben und bis jetzt sind sie gut für uns.
Die Hauptgründe, warum wir mit den Bewertungen begonnen haben, sind:
Damit die Entwickler wirklich verstehen, was sie bauen sollen. Wenn sie ihr Design nicht erklären können oder das Design die Anforderungen nicht klar umsetzt, dann haben sie nicht verstanden, was sie tun sollen. In der Vergangenheit war dies ein Problem für uns, wo wir es nur während der QA nach der Codierung abgeholt haben, wenn es repariert wird, verursacht lange Verzögerungen. Die Entwurfsüberprüfung gibt ein frühes Feedback und Änderungen in der Entwurfsphase sind ziemlich einfach.
Training für Nachwuchsentwickler. Oft finde ich ihre Entwürfe zu kompliziert oder verpasst einen wichtigen Aspekt. Die Design Review bietet eine gute Gelegenheit, ihnen zu zeigen, wie sie das Design verbessern können, so dass sie hoffentlich beim nächsten Mal einen besseren Job machen werden. Ohne dieses Feedback erstellen sie weiterhin schlechte Designs.
Es hängt von der Teamgröße, den Fähigkeiten der Teammitglieder und davon ab, wie gut sie sich kennen. Ein kleines Team mit einem hohen Qualifikationsniveau, das schon lange zusammenarbeitet, würde das nicht brauchen und es könnte Zeit verschwenden. In diesem Fall können sie Design- und Coding-Probleme "on-the-fly" durch sofortige Interaktion lösen und nicht auf ein Meeting warten.
Es wird auch für eine bessere Kontinuität und keine Stopp-Starts sorgen.
Bewertungen von perfektem Code und Design bringen wenig Wert, aber sie nehmen auch wenig Zeit in Anspruch, so dass es beim Testen wenig zu verlieren gibt.
Darüber hinaus können Design- und Code-Reviews Ihnen dabei helfen, Ihr Wissen mit dem restlichen Code-Team zu teilen. Es macht den Besitz von Code globaler als individueller, was bedeutet, dass jemand Ihre Aufgaben übernehmen kann, wenn Sie von einem Bus auf dem Weg zur Arbeit getroffen werden oder den Job wechseln.
Bewertungen sind eine großartige Gelegenheit, um sicherzustellen, dass jeder weiß, dass der Code funktioniert. Das ist sehr wichtig, wenn Sie Ihre Mitarbeiter mit Auftragnehmern oder Neueinstellungen ergänzen. Ihr Mangel an Produkterfahrung führt zu einigen Codierungsfehlern, die am besten in Bewertungen erfasst werden.
Wenn Sie eine Rezension halten, müssen Sie auch Ihren Code erklären - es ist erstaunlich, wie viele Probleme ich habe, indem ich anderen den Code erklärt habe.
Wenn Sie sich das V-Modell der Softwareentwicklung ansehen, werden Sie feststellen, dass je weiter Sie von links gehen, desto mehr Geld werden Sie dafür ausgeben, Dinge zu reparieren. Design Reviews sind ein guter Weg, um in den frühen Phasen keine trivialen Fehler zu machen, die zu späteren, teureren Phasen führen.
Ich bin der Meinung, dass Design-Reviews noch wichtiger sind als Code-Reviews. Bei Codeüberprüfungen sollten Sie den Code überprüfen, um sicherzustellen, dass er mit dem Design übereinstimmt, aber dies kann auch mit einer Tracking-Matrix von Design zu Funktionalität erreicht werden (stellen Sie sicher, dass jeder Aspekt des Designs im Code getestet wird).
Für Designs gibt es keine andere Art von Tests (Sie können das Design nicht ausführen) - Sie müssen über eine Matrix verfügen, die Designelemente zurück auf individuelle Anforderungen abbildet. Wenn diese Matrix Löcher aufweist, ist dies nicht der Fall Egal, wie elegant und clever Ihr Design ist, es ist nicht das, was der Kunde wollte.
Lassen Sie mich wissen, wie das funktioniert, wenn Sie es versuchen: -).
Das ist ein gutes Feedback. Ich habe mich auch gefragt, ob Code Reviews eher ein Team oder eine Review / Coder Strategie sein sollten. Ich kann die Vorteile beider sehen. Die Teamstrategie würde definitiv eine Lernerfahrung für das gesamte Team eröffnen, wenn Sie aus jüngeren Entwicklern bestehen. Mehr Experten und Senioren im Team, kann ich sehen, wie die Rezensenten / Coder-Strategie besser funktionieren würde.
Sie sind eine Möglichkeit, Feedback auf strukturierte Art und Weise zu erhalten und die anderen Mitglieder des Teams bei dem zu unterstützen, was Sie tun.
Tags und Links design agile code-review