beste Möglichkeit, OOP / OOD einem Team erfahrener C ++ - Ingenieure vorzustellen


17

Ich bin auf der Suche nach einem effizienten Weg, der sich auch nicht als Beleidigung herausstellt, um bestehenden Teammitgliedern OOP-Konzepte vorzustellen. Meine Teamkollegen sind nicht neu in OO-Sprachen. Wir arbeiten schon lange mit C ++ / C #, daher ist die Technologie an sich bekannt.

Ich sehe mich jedoch um und ohne großen Aufwand (meist in Form von Code-Reviews) scheint es, dass wir C-Code produzieren, der sich zufällig in Klassen befindet. Das Prinzip der einmaligen Verantwortung, Abstraktionen oder Versuche, die Kopplung zu minimieren, um nur einige zu nennen, werden kaum angewendet. Ich habe Klassen gesehen, die keinen Konstruktor haben, aber jedes Mal, wenn sie instanziiert werden, memset auf 0 setzen.

Aber jedes Mal, wenn ich OOP aufrufe, nickt jeder und macht den Eindruck, dass er genau weiß, wovon ich spreche. Die Konzepte zu kennen ist gut, aber wir (einige mehr als andere) scheinen es sehr schwer zu haben, sie anzuwenden, wenn es darum geht, tatsächliche Arbeit zu liefern.

Codeüberprüfungen waren sehr hilfreich, aber das Problem bei Codeüberprüfungen besteht darin, dass sie erst nachträglich auftreten, sodass es so aussieht, als würden wir den gerade geschriebenen Code am Ende umschreiben (meistens umgestalten, aber immer noch viel Zeit in Anspruch nehmen). Auch Code-Reviews geben nur Rückmeldungen an einen einzelnen Ingenieur, nicht an das gesamte Team.

Ich spiele mit der Idee, eine Präsentation (oder eine Serie) zu machen, und versuche, OOP erneut aufzurufen, zusammen mit einigen Beispielen für vorhandenen Code, der besser hätte geschrieben und überarbeitet werden können. Ich könnte einige wirklich alte Projekte gebrauchen, die niemand mehr besitzt, so dass zumindest dieser Teil kein heikles Thema sein sollte. Wird dies jedoch funktionieren? Wie ich bereits sagte, haben die meisten Leute C ++ schon lange gemacht, also denke ich, dass a) sie dort sitzen und darüber nachdenken, warum ich ihnen Dinge erzähle, die sie bereits kennen, oder b) sie es möglicherweise als Beleidigung ansehen, weil ich es bin Ich sage ihnen, dass sie nicht wissen, wie sie ihre jahrelange, wenn nicht jahrzehntelange Arbeit verrichten sollen.

Gibt es einen anderen Ansatz, der ein breiteres Publikum erreichen würde als ein Code Review, der sich aber gleichzeitig nicht wie ein Strafvortrag anfühlt?

Ich bin kein frischgebackener Student, der utopische Ideale für perfekt gestalteten Code hat, und das erwarte ich auch von niemandem. Der Grund, warum ich das schreibe, ist, dass ich gerade eine Rezension von einer Person gemacht habe, die tatsächlich ordentliches High-Level-Design auf Papier hatte. Wenn Sie sich jedoch Klassen vorstellen: A -> B -> C -> D, implementieren im Code B, C und D alle fast dieselbe öffentliche Schnittstelle, und B / C verfügt über One-Liner-Funktionen, sodass die oberste Klasse A absolut funktioniert Die gesamte Arbeit (bis hin zur Speicherverwaltung, zum Parsen von Zeichenfolgen, zum Einrichten von Verhandlungen ...) erfolgt hauptsächlich in 4-Mongo-Methoden und ruft in jeder Hinsicht fast direkt D auf.

Update: Ich bin ein Tech Lead (6 Monate in dieser Rolle) und habe die volle Unterstützung des Gruppenleiters. Wir arbeiten an einem sehr ausgereiften Produkt und die Wartungskosten lassen sich auf jeden Fall bekannt geben.



3
Sind Sie in irgendeiner Weise ihr Vorgesetzter oder Chef? Wenn nicht, haben Sie Unterstützung durch den technischen Direktor, der der Chef von Ihnen allen ist? Wenn Sie nur einer der Jungs sind und die Entwicklung seit Jahren stetig und produktiv ist, ohne tiefe OOP-Designs zu verwenden, müssen Sie die Programmierer davon überzeugen, dass funktionierender Code nicht funktioniert, und das Management, dass Sie nichts verschwenden Geld besser ausgegeben, Code zu generieren.
Patrick Hughes

Nachdem ich diesen Beitrag verfasst habe, tauchte ein verwandter Link auf, der meiner Situation sehr ähnlich ist: programmers.stackexchange.com/questions/43214/… . Ich mache mir genau das gleiche Sorgen. Das Problem ist, dass ihr Team 2 Entwickler hatte und ich das definitiv mit Code-Reviews schaffen konnte. Ich bin auf der Suche nach einem Ansatz, der mit unserer Teamgröße (10+) zusammenarbeitet. Ich kann einfach nicht mit jedem Entwickler einzeln kommunizieren, wie ich möchte.
DXM

Antworten:


5

Warum entwickeln Sie kein kurzes Training in den SOLID- Prinzipien und geben Ihnen dieses Training? In meiner jetzigen Organisation hat es anscheinend ganz gut geklappt, und ich finde, dass es Spaß macht, kurze Trainings zu geben (für alle Beteiligten).

Bei meiner Schulung habe ich einige Zeit gebraucht, um nach pathologischen "schlechten" Beispielen im vorhandenen Code (verschiedener Projekte) zu suchen, und diese in der Präsentation Schritt für Schritt anhand der Prinzipien überarbeitet. Dies hat gezeigt, dass

  1. Es ist nicht so schwer, diese Refactorings durchzuführen
  2. Es dauert nicht lange
  3. Das Endergebnis (sorgfältig ausgewählt ;-)) ist deutlich besser als der Originalcode.

5

Codeüberprüfungen waren sehr hilfreich, aber das Problem bei Codeüberprüfungen besteht darin, dass sie erst im Nachhinein auftreten.

Bei einem Projekt haben wir Überprüfungen durchgeführt.

15 Minuten. An der weißen Tafel. Sprechen Sie vor dem Codieren durch das Design.

Der wichtigste Teil ist die Planung der Entwurfsprüfung vor jeglichen Implementierungsarbeiten.

Wir hatten auch "Critical Design Reviews", die eine große, schweißtreibende Sache waren. Sie beinhalteten viele Dokumente und eine lange Präsentation. Sie waren schwer einzuplanen und wurden fast immer erst nach Beginn der Codierung herausgeschoben, wodurch sich ihr Wert auf Null verringerte.

Informelle Entwurfsprüfungen - vor dem Codieren - ohne Druck - ohne Dokumentation - ermöglichen eine bessere Diskussion darüber, wie Verantwortlichkeiten zugewiesen werden und wie Objekte zusammenarbeiten.


Ja, wir entwerfen bereits Reviews genau so, wie Sie sie beschrieben haben. Das Problem sind mittelgroße Aufgaben. Wenn die Aufgabe groß genug ist, nehme ich mir im Allgemeinen die Zeit, um ein erstes Klassendiagramm zu erstellen, das dann vom Team verfeinert wird. Wenn die Aufgabe klein ist, ist das vorhandene High-Level-Design bereits gut genug. Für mittelgroße Aufgaben kann ich jedoch nicht genügend Gedanken in das Design einbringen, sodass die Grundregel lautet: "Benutze bestes Urteilsvermögen und folge OOP". Wenn ich diese Aufgaben selbst erledigen würde, würde ich mit dem Codieren beginnen und dies mit kontinuierlichem Refactoring und ...
DXM

... lassen Sie den Code entscheiden, wie das endgültige Design aussehen soll. Wenn ich diese Aufgaben jedoch einigen Teammitgliedern überlasse, finde ich in der Codeüberprüfung manchmal Dinge wie das, was ich in meinem ersten Beitrag beschrieben habe.
DXM

1
@DXM: Was? Du machst sie? Oder sie nicht tun? Wenn groß, dann machen Sie keine Design-Reviews - Sie machen Design für jemand anderen - wer lernt, wenn Sie Design machen? Wenn klein, dann machen Sie keine Designüberprüfungen - das "vorhandene Design ist gut genug" - wer lehnt es ab, wenn Sie Design ignorieren? Wenn es sich um ein Medium handelt, entwerfen Sie nicht und überprüfen auch nicht deren Entwürfe? Es hört sich nicht so an, als würden Sie tatsächlich Design-Reviews durchführen. Warum sagst du, dass du bist und gibst dann drei Beispiele, wo du nicht bist?
S.Lott

@Lott: Nach dem Nachdenken über Ihre Antwort ist meine einzige Schlussfolgerung, dass Sie absolut Recht haben. Ich denke, ich hätte sagen sollen, dass ich genau diese Idee mindestens acht Mal angesprochen habe und alle waren sich einig, aber wenn ich auf den Rhythmus zurückblicke, auf den wir uns festgelegt haben, machen wir eigentlich nichts davon. Ich würde das gerne weiter diskutieren, aber ich wurde bereits von Mods diszipliniert, weil ich eine Diskussion auf einer ausschließlich Q & A-Seite geführt habe. Könnten wir ins Gespräch kommen? Ich möchte die Situation näher erläutern und vielleicht Ihr Gehirn (oder jemand anderes, der mitmachen möchte) ein bisschen auswählen. Noch nie geschwatzt, weißt du wie es funktioniert?
DXM

@ DXM: Chat ist trivial. Und nicht zu hilfreich. Wenn Sie weitere Fragen haben, die detaillierter sind als diese erste Frage, sollten Sie diese detaillierteren Fragen stellen. Das ist der Punkt. In einigen Fällen läuft "weitere Diskussion" auf "Ich mag Ihre Antwort auf meine Frage aus den folgenden Gründen nicht ..." hinaus, was irgendwie albern ist. Eine Antwort nicht zu mögen ist einfach keine Antwort zu mögen und erfordert keine Diskussion. In einigen Fällen läuft die Diskussion auf "Meine Frage ist nicht vage, Sie können einfach nicht lesen." Wirklich nicht hilfreich. Stelle deine Fragen. Als Fragen.
S.Lott

4

Ich gehe davon aus, dass Sie jünger sind als einige der Entwickler, aber weiter oben in der Nahrungskette.

Es besteht die Gefahr, dass die „erfahrenen Ingenieure“ das Richtige tun - oder da es sich um ein ausgereiftes Produkt handelt, das es möglicherweise schon seit Jahrzehnten gibt, war es das Richtige.

Älterer Code wurde in der Regel so optimiert, dass er auf der Hardware der damaligen Zeit schnell ausgeführt werden kann. Dies bedeutet unter anderem, die Vererbung zu reduzieren und Funktions- / Methodenaufrufe für triviale Operationen zu vermeiden.

Compiler sind im Laufe der Jahre viel intelligenter geworden, sodass nicht alles, was früher zutrifft, jetzt zutrifft. Beispielsweise kann ein Compiler eine kleine Funktion inline setzen.

Möglicherweise besteht ein Weg vorwärts darin, einen anderen Ansatz zu wählen - bitten Sie die Entwickler, zu erklären, wie / warum ihre Methode besser ist als die Theorie, die Ihnen beigebracht wurde - und ehrlich zu sein.


0

Würde die Forderung nach Komponententests mit einer 100% igen Zweigabdeckung für jede neue / geänderte Methode nicht zu einer Minimierung der Kopplung zwischen den Methoden führen.


UT ist eine gute Idee, aber ich bin nicht überzeugt, dass dies das gewünschte Ergebnis bringen würde. Außerdem ist eines der Grundprinzipien von OO, dass eine Kopplung zwischen Funktionen unvermeidbar ist. Sie sollten diese also explizit machen und diese gekoppelten Funktionen in einer einzigen Klasse gruppieren.
MSalters

Ich bin damit einverstanden, dass "jede Kopplung zwischen Funktionen unvermeidbar ist". Gutes Design reduziert jedoch die Anzahl der anderen Funktionen, mit denen jede Funktion gekoppelt ist. (Eine Klasse ist nur ein Mittel zu diesem Zweck)
Ian

0

Vielleicht möchten Sie das Buch "Design Patterns" von der Gang of Four abholen. Es ist nicht spezifisch für C ++, sodass Sie das C ++ - Wissen Ihrer Kollegen nicht offen kritisieren, wenn Sie darauf verweisen. Gleichzeitig werden Themen angesprochen, die Sie für relevant halten. Außerdem wird das Buch weithin als relevant akzeptiert, sodass es nicht einfach als theoretisch oder unpraktisch abgetan werden kann.

Bedenken Sie andererseits, dass C ++ weder im Design noch in der Praxis eine reine OO-Sprache ist. Die gesamte Konstruktor- / Memset-Story klingt, als ob Sie RAII einführen sollten. Dies ist überhaupt keine OO-Technik, sondern C ++ -spezifisch. Die relevanten Bücher sind (More) Effective C ++ und (More) Exceptional C ++.


2
Die Autoren stellen jedoch klar fest, dass Design Patterns keine Einführung in OOP / OOD im Allgemeinen sind! Das Publikum sollte zuerst mit den Techniken vertraut sein, die OOP anbietet, bevor es in einen Hardcode-Entwurfsmusterkatalog eintaucht! "Head First Design Patterns" bietet eine gute Einführung.
Falcon

2
Aus der OP-Beschreibung geht hervor, dass sie OOP / OOD kennen, sie verwenden es einfach nicht (möglicherweise aus Angst, es wäre zu kompliziert). In diesem Fall kann ein Buch, das erklärt, warum es nützlich ist, am besten als Codebeispiele dienen.
Wildpeaks

@wildpeaks: Das OP ist das Gegenteil. Sie kennen OOP / OOD nicht. Sie programmieren OOP auf prozedurale Weise. Sie brauchen etwas, um sich mit den Designtechniken vertraut zu machen, und das GoF-Buch passt nicht in dieses Szenario.
Falcon

Ich bezog mich auf die Sätze But every time I bring up OOP, everyone always nods and makes it seem like they know exactly what I'm talking aboutund My teammates are not new to OO languages, aber ich kann sehen, dass es in der Tat ein bisschen vage ist, da sie möglicherweise nur darüber lügen, OOP zu kennen, wenn OP mit ihnen darüber spricht.
Wildpeaks

1
@MSalters - Vorwort zu Design Patterns: "Dieses Buch ist keine Einführung in objektorientierte Technologie oder Design. Viele Bücher leisten bereits gute Arbeit. In diesem Buch wird davon ausgegangen, dass Sie mindestens eine objektorientierte Programmiersprache beherrschen und Sie sollte auch Erfahrung im objektorientierten Design haben. " Dieses Buch entspricht nicht den Anforderungen. Sie sollten etwas OOD-Zeug für Anfänger lesen.
Falcon
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.