Umgang mit Mitarbeitern bei der Entwicklung, Beratung nötig [geschlossen]

Ich habe unsere aktuelle Projektarchitektur entwickelt und angefangen, sie selbst zu entwickeln (so etwas wie, revision 40) .

Wir entwickeln ein einfaches U-Bahn-Routing-Framework und mein Design schien sehr gut zu funktionieren. Mehrere Hauptmodelle, entsprechende Ansichten, Hauptlogik- und Datenstrukturen wurden "wie sie sein sollten" modelliert und vollständig vom Rendering getrennt. Der algorithmische Teil wurde ebenfalls implementiert abgesehen von den Hauptmodellen und hatte eine geringe Anzahl von Schnittpunkten.

Ich würde dieses Design als skalierbar, anpassbar, einfach zu implementieren, hauptsächlich auf der Basis der "Black-Box-Interaktion" interagierend und sehr nett bezeichnen.

Nun, was wurde getan:

• Ich habe einige Implementierungen der entsprechenden Schnittstellen gestartet, einige praktische Bibliotheken portiert und Implementierungsstubs für einige Anwendungsteile geschrieben.
• Ich hatte das Dokument, das den Codierungsstil beschreibt, und Beispiele für diesen Codierungsstil (meinen eigenen geschriebenen Code).
• Ich habe die Verwendung von mehr oder weniger modernen C++Entwicklungstechniken erzwungen , einschließlich no-deleteCode (umschlossen mit intelligenten Zeigern) usw.
• Ich habe den Zweck konkreter Schnittstellenimplementierungen und deren Verwendung dokumentiert.
• Unit-Tests (hauptsächlich Integrationstests, da es nicht viel "tatsächlichen" Code gab) und eine Reihe von Verspottungen für alle Kernabstraktionen.

Ich war 12 Tage abwesend .

Was haben wir jetzt (das Projekt wurde von 4 anderen Mitgliedern des Teams entwickelt):

• 3 verschiedene Kodierungs Stile der ganzen Projekt (ich glaube, zwei von ihnen bereit erklärt , die gleiche Art zu verwenden :) , Gleiches gilt für die Benennung unserer Abstraktionen (zB CommonPathData.h, SubwaySchemeStructures.h) , die im Grunde sind Header einige Datenstrukturen zu deklarieren.
• Absoluter Mangel an Dokumentation für die kürzlich implementierten Teile.
• Was ich in letzter Zeit als " single-purpose-abstractionjetzt" bezeichnen konnte, verarbeitet mindestens zwei verschiedene Arten von Ereignissen, ist eng mit anderen Teilen verbunden und so weiter.
• Die Hälfte der verwendeten Schnittstellen enthält jetzt Membervariablen (sic!).
• Rohe Zeigerverwendung fast überall.
• Komponententests deaktiviert, da " (Rev.57) They are unnecessary for this project".
• ... (das ist wahrscheinlich nicht alles) .

Die Geschichte von Commit zeigt, dass mein Design als Overkill interpretiert wurde und die Leute begannen, es mit persönlichen Fahrrädern und neu implementierten Rädern zu kombinieren und hatten dann Probleme , Code-Chunks zu integrieren .

Jetzt - das Projekt macht immer noch nur eine kleine Menge von dem, was es zu tun hat, wir haben schwerwiegende Integrationsprobleme, ich nehme einige Speicherlecks an.

Ist in diesem Fall etwas möglich?

Mir ist klar, dass alle meine Bemühungen keinen Nutzen hatten, aber die Frist ist ziemlich bald und wir müssen etwas tun. Hatte jemand eine ähnliche Situation?

Grundsätzlich dachte ich, dass ein guter (nun, ich habe alles getan, was ich konnte) Start für das Projekt wahrscheinlich zu etwas Schönem führen würde, aber ich verstehe, dass ich falsch liege.

Refactor gnadenlos aus dem Chaos raus!

Nehmen Sie den Codierungsstil, der den größten Teil des verwendbaren Stils ausmacht, und verwenden Sie ihn für dieses Projekt.

Das Schlimmste ist, dass Sie ein Rollback auf Revision 40 durchführen müssen und Ihre Programmierer eine 12-tägige Schulung hatten, die ihnen ein besseres Verständnis des Themas verschaffte.

Wenn Ihre Programmierer so viel über sauberes Codieren lernen müssen, sind die zwölf Tage die geringste Verzögerung, die Sie haben werden.

Um es mit Ihrer Frage zu sagen: "Ich war ein paar Wochen weg und bin nicht einverstanden mit dem, was mein Team getan hat, als ich weg war. Wie kann ich sie dazu bringen, das zu tun, was ich will, wenn ich nicht hier bin?"

Ich sage Ihnen, dass dies kein technisches Problem ist, sondern ein Verwaltungsproblem. Meine Annahme (bitte verzeihen Sie mir, wenn ich mich irre) ist, dass Sie die technische Lösung einer Armee von Schergen diktieren, die aus irgendeinem Grund mit Ihrer Lösung nicht einverstanden oder nicht einverstanden sind oder diese nicht verstehen.

Wenn 12 Tage ausreichen, um Ihrem Design so viel Schaden zuzufügen, muss es einen Grund geben. Ist das Design zerbrechlich? Ist es überentwickelt? oder hat die Mannschaft es einfach aus Trotz getan? Wie sind Ihre Fristen und Lieferungen? Fest? versuchten sie nur, einen zu treffen?

In einem Fall habe ich gesehen, dass der technische Vorsprung dem Spiel so weit voraus war, dass der durchschnittliche Entwickler (ich) nicht mithalten konnte. Der technische Leiter konnte keinen kommerziell brauchbaren Code entwerfen, da er der einzige war, der ihn pflegen konnte. Wenn ein Diplom-Entwickler es nicht warten kann, ist es für die Geschäftswelt zu komplex. In allen anderen Fällen handelte es sich lediglich um einen Mangel an Managementfähigkeiten auf der Managementseite.

Die Teamdynamik ist gebrochen. Sie können (wie von anderen vorgeschlagen) Zeit damit verbringen, das Chaos umzugestalten, und müssen es das nächste Mal wieder tun, wenn Sie sich verabschieden. Möglicherweise müssen Sie Ihre Teammitglieder aufrüsten, aber ich glaube, Sie müssen zuerst die Teamdynamik korrigieren, da sie anscheinend über genügend Fähigkeiten verfügen, um die Arbeit zu erledigen, auch wenn Sie dies für hässlich halten.

Paar.

Was Sie beschreiben, ist eine Menge, es richtig zu machen, technisch gesehen, solo . Ja, Sie haben versucht zu dokumentieren, haben versucht, Standards durchzusetzen - aber Sie haben (anscheinend) nicht kommuniziert.

Nun, Ihr Team hat gerade mit Ihnen kommuniziert, ziemlich durchschlagend. Sie sagten: "Hey, Yippie - du kommunizierst nicht!" Die mächtigste Form der Kommunikation, die ich kenne, ist das Pairing. Paar. Bis sie es bekommen oder bis sie dich überreden, es anders zu machen.

Wie Brooks uns in den letzten 30 Jahren mitteilte, ist die konzeptionelle Integrität der wichtigste Teil jedes Projekts. Für ein nicht triviales und vollständiges Teilsystem sollte genau eine Person zuständig sein, die für das Design verantwortlich ist und die Befugnis hat, die Implementierung zu steuern. An diesem Teil Ihres Projekts ist ein Fehler aufgetreten. Was auch immer es war, die einzige Lösung ist ein Rollback auf den Code im Repository, der vorher existierte. Ein Verlust von 12 Tagen ist nichts im Vergleich zu den Kosten für die Aufrechterhaltung eines defekten Designs. Ich würde auch darüber nachdenken, wie man die an dieser Untersuchung beteiligten Personen von der weiteren Arbeit an dem Projekt entfernen kann, da sie sich als inkompetent erwiesen haben.

Eine Sache, die ich für den Anfang tun würde, ist, ein gutes Codeüberprüfungstool zu bekommen, das den fehlerhaften Code markiert und dokumentiert, warum es fehlerhaft ist und (konzeptionell) wie es gemacht werden sollte. Soweit ich weiß, wird eine Menge Schlimmes getan, und es wäre eine Menge Arbeit, dies zu überprüfen. Angenommen, Sie sind der einzige, der Fehler im Code feststellt, ist es möglicherweise nicht möglich, alles selbst zu überprüfen. Sie können jedoch die schlimmsten Verstöße markieren und sie in Einträge in Ihrem Fehlerverfolgungssystem umwandeln, die der Person zugewiesen sind, die den entsprechenden Code geschrieben hat.

Der beste Anreiz für das Schreiben von Qualitätscode besteht darin, zu wissen, dass Sie in Zukunft verfolgt werden, wenn Sie dies nicht tun. Ihre Mitarbeiter scheinen sich nicht darum zu kümmern, daher ist es die beste Medizin, sie zu veranlassen, die falschen Teile selbst zu überarbeiten und zu lernen.

Zu gegebener Zeit können Sie andere Teile des Codes, die problematisch sind, erneut aufrufen und dem ursprünglichen (schlechten) Autor erneut zuweisen. Nach einer Weile werden sie beim ersten Mal die Vorteile einer guten Arbeit erkennen.

Ich gehe davon aus, dass Sie ein Rollback zu Ihrer Originalversion nicht für eine Option halten - mit anderen Worten, trotz des schlechten Codes, den Ihre Kollegen geschrieben haben, haben sie einige Funktionen hinzugefügt, und der Nettowert der aktuellen Version ist höher als der des Originals. Ich gehe auch davon aus, dass Sie, auch wenn dies nicht der Fall ist, kein politisches Kapital haben, um dieses Rollback durchzuführen und sie dazu zu bringen, den Code neu zu schreiben (da nur sehr wenige Menschen auf dem Planeten über ein solches Kapital verfügen). Dies und vieles mehr ist die Komplexität der Beurteilung einer Situation, die ich selbst nicht erlebe, aber ich hoffe, dass meine zwei Cent geholfen haben.

Eine Sache, die ich nicht erwähnt habe, die aber in letzter Zeit aufgetaucht ist, wo ich arbeite, sind die Probleme von "Entwicklersilos" und "Buy-In".

Am Anfang meines aktuellen Projekts habe ich eine Kernbibliothek entworfen, die im Wesentlichen von mir selbst stammt. (Ähnlich wie bei Rev. 40). Dann, als ich es fertig hatte, stellte ich mich dem Rest des Teams vor und sagte jedem, dass er damit beginnen könne. Was in den folgenden Monaten passierte, war, dass die Leute immer wieder dasselbe implementierten, was sich bereits an anderen Orten in dieser Bibliothek befand. Der CTO (der aktiv codiert) weist darauf hin, dass es vom Rest des Teams nie ein Buy-in für die Architektur / Design / öffentlichen Schnittstellen der Bibliothek gegeben habe.

Nun, wir haben gerade eine umfassende Überarbeitung dieser Bibliothek durchgeführt, die das gesamte Design vermutlich verbessert hat, um besser zu dem zu passen, was wir gerade tun, aber wieder nahm ein Entwickler die Bibliothek als ihr einziges Projekt und arbeitete mehrere Wochen daran dann präsentierte es einfach. "Voila! Hier ist es! Ist es nicht hübsch?"

Jetzt, da ich die neue Version verwenden muss und das gleiche Problem vorliegt, hasse ich es, wie er es getan hat. Und er hat Dinge ausgelassen, die notwendig waren, weil er nicht mit anderen zusammengearbeitet hat, während er daran arbeitete. Also wieder beginne ich, dasselbe Material an anderen Orten zu implementieren und für das zu arbeiten, was ich tun muss.

Lange Rede, kurzer Sinn - Wenn Sie möchten, dass die Codequalität steigt und konsistent bleibt, sollten Sie das gesamte Team zusammenbringen, um Standards, Stile usw. festzulegen. Darüber hinaus wird jederzeit jemand eine Grundlage oder ein Kernstück Ihres Codes erstellen Anwendung, würde ich vorschlagen, dass die verantwortliche Person das gesamte Team bei der Gestaltung der Klassen usw. führt, so dass am Ende des Tages das gesamte Team in die gesamte Anwendungsarchitektur einkaufen muss. Wenn sie wissen, wie der Code eines anderen Teammitglieds funktioniert, ist es weniger wahrscheinlich, dass sie ihn erneut auf eine für sie geeignete Weise implementieren.

Sind Sie der leitende Entwickler (oder einer der leitenden Entwickler) in diesem Team? In diesem Fall müssen Sie einige Schulungsseminare zu Best Practices abhalten. Sie sollten wahrscheinlich einen Großteil der geleisteten Arbeit zurücknehmen, ein Meeting mit Ihrem Team abhalten und den richtigen Weg erläutern, um die erforderlichen Funktionen so zu implementieren, dass das vorhandene Design beibehalten wird.

Angesichts der knappen Frist müssen Sie den Code möglicherweise so wie er ist versenden und nach Ihrer Veröffentlichung überarbeiten (umschreiben?).

Es hört sich auch so an, als müssten Sie einige gängige Code-Praktiken definieren und durchsetzen. Haben Sie an Ihrem Arbeitsplatz einen Code-Überprüfungsprozess durchgeführt? Wenn nicht, ist es jetzt an der Zeit, einen zu implementieren. Code-Reviews sind übrigens eine großartige Möglichkeit, um neuere Entwickler über bewährte Vorgehensweisen zu informieren.

BEARBEITEN:

Ich bin kürzlich in eine ähnliche Situation geraten. Das Management meiner Firma bestand darauf, dass wir Vertragsentwickler einsetzen, um einen Großteil unserer Bewerbung zu schreiben. Der Code, den sie produzierten, war schrecklich (um es freundlich auszudrücken), aber wir waren gezwungen, ihn zu verwenden. Bis heute habe ich 80% des Codes umgeschrieben, den die Auftragnehmer für uns geschrieben haben. Es war voller Fehler und unmöglich, mit neuen Funktionen zu erweitern. In ein paar Monaten wird mein Team alles neu geschrieben haben, was das Geld, das in die Auftragsentwicklung investiert wurde, effektiv zur Verschwendung macht.

Schlechter Code kostet wirklich Geld, darüber sollten Sie mit Ihren Managern sprechen, da Sie wahrscheinlich deren Hilfe benötigen, um Codierungsstandards zu implementieren und durchzusetzen.

Sie haben sich bemüht, aber es ist Tatsache, dass niemand das Sagen hat . "Aber ich bevorzuge meinen Codierungsstil", keine Scheiße. Ich möchte den ganzen Tag an meinen persönlichen Projekten arbeiten und werde trotzdem bezahlt.

Hoffentlich können Sie dies den Mächten vorstellen und ihnen zeigen, was hätte gegen die Wild-West-Show getan werden können, die zwei Wochen andauerte. Es scheint, als müssten Sie etwas aus der Tür holen, aber weiterhin das Problem fehlender Kontrollen und Konsistenz verfolgen.

Konzentrieren Sie sich auf die wenigen, die zu Ihrem Plan gehörten, und unternehmen Sie alles, um sie dazu zu bringen, dieses Durcheinander zu beheben und sie in zukünftigen Projekten in Ihr Team aufzunehmen. Möglicherweise müssen Sie den Rest ablehnen, wenn sie ihn nicht zusammenbringen können.