Wann ist der gemeinsame Codebesitz nützlich?

Question

Ich habe in letzter Zeit an mehreren Projekten gearbeitet, die die Idee des geteilten Codebesitzes gefördert haben. Manchmal schien dies die Codeverbesserung und -verbesserung zu beschleunigen. Zu anderen Zeiten schien es ein Grund des Ego-Treibens zu werden, wobei Veränderungen vorgenommen wurden, um Individuen zu unterstützen, die Stile, bevorzugte Technologien oder einfach eine Demonstration von Macht/Intellekt kodierten.

Wie kann Shared Code Ownership implementiert werden, um die Fallstricke zu vermeiden und dennoch die Vorteile zu nutzen? Können zu viele Köche die Brühe verderben?

Answer 1

Codierungsstandards können sicherlich hilfreich sein, insbesondere wenn sie durch Richtlinien für die fortlaufende Integration und/oder Kontrolle der Quellcodeverwaltung unterstützt werden.

Definieren Sie zuerst die Standards und lassen Sie das Team sich darauf einigen (Management bricht die Verbindungen).

Zweitens, verwenden Sie automatisierte Tools (vorzugsweise mit IDE-Hooks), um Code-Formatierung zu behandeln.

Drittens, verwenden Sie automatisierte statische Analysetools, um die Konformität zu überprüfen. Diese können über die Validierung von Formatierungen und die Überprüfung von Codekomplexitätsmetriken, Namenskonventionen, Best Practices usw. hinausgehen. Die besseren können an die Regeln Ihres Teams angepasst werden. Suchen Sie nach Möglichkeiten, um unangemessene Warnungen über Metadaten (z. B. Attribute) zu unterdrücken. Die meisten Regeln haben Ausnahmen und Sie möchten das "Rauschen" von Fehlalarmen ausblenden.

Viertens: Integrieren Sie die statische Analyse in Ihr Quell-/Versionskontrollsystem, damit es beim Check-in ausgeführt wird. Einige Systeme erlauben das Ablehnen von Check-Ins, die keine Richtlinien bestehen. Eine weitere Option (die sich nicht gegenseitig ausschließt) besteht darin, einen Continuous Integration Server einzurichten, der beim Einchecken automatisch erstellt wird. Es kann eine statische Analyse ausführen und alle Entwickler auf Fehler hinweisen.

Answer 2

Ich habe einen gemeinsamen Code gefunden, der gut funktioniert, wenn er mit Richtlinien zur Fehlerverfolgung und -kodierung kombiniert wird. Dh Leute arbeiten an Problemen (die während Dev-Meetings vergeben werden), die den Code von irgendjemandem beinhalten können und viele "Stil" -Fragen, die in den Richtlinien angesprochen werden. Dies scheint ziemlich effektiv zu sein und scheint nicht das Problem zu haben, dass Sie erwähnt haben, dass Leute den Code ohne guten Grund ändern.

Answer 3

• Kommunikation durch Paarung, Tests und sauberen Code: Wenn Sie nicht viel Zeit technische Dokumente zu schreiben haben oder wenn das System so viel verändert kann man nicht mit der Notwendigkeit halten zu schreiben technische Dokumente.

• Agile Teams haben keine "Architektenfigur", die exakt bestimmt, wie alles zusammenpasst. Agile Teammitglieder haben eine viel demokratischere Sicht auf Dinge und Design ist kollaborativ. Dies bedeutet mehr Kommunikation und eine Art und Umfang der Kommunikation, die nur durch schriftliche Dokumente schwer aufrechtzuerhalten wäre. (Um nicht zu sagen Sie nicht Dokumente müssen - aber die Pairing-face-to-face und gemeinsamer Einfluss auf Richtung erforderlich ist.)

• Gemeinsames Eigentum für verteilte Teams geeignet ist, die eine gemeinsame Kern Codebasis teilen müssen . In einem verteilten Team, an dem ich arbeitete, schickten wir Remote-Mitarbeiter zu unserem Hauptquartier, um uns mit dem gemeinsamen Code zu verbinden, damit sie an entfernten Standorten genügend Wissen und Selbstvertrauen gewinnen konnten, während die ursprünglichen Autoren des Codes darin schlafen eine andere Zeitzone. Ergebnis: weniger Wartezeiten für Remote-Experten.

• Sie bauen etwas, das erfordert mehrere verschiedene Arten von Know-how, und kein einzelnes Teammitglied ist ein Experte in all diesen Bereichen.

• Das Projekt integriert zwei oder mehr komplexe Subsysteme und Experten in jedem Subsystem ist ungleich verteilt unter Teammitgliedern.

• Die Implementierung erfolgt durch einen Subunternehmer, aber eine andere Gruppe wird das System übernehmen und pflegen. Beide Parteien müssen zusammenpassen und die Richtung beeinflussen, damit dies nachhaltig ist.

Answer 4

Geteiltes Eigentum hat viele Vorteile. Unten sind die idealisierten Punkte, aber Sie können einen langen Weg in Richtung zu ihnen, besonders wenn ein Team im Laufe der Zeit zusammen strickt:

Viele Gehirne sind besser als einer. Codierer erkennen oft Fehler oder stellen Kuriositäten in ihrem Code einander gegenüber und verbessern so die Robustheit des gesamten Codes. Betrachten Sie es als kontinuierlichen Peer-Code-Review.

Geringeres Risiko, kritisches/wertvolles Wissen zu verlieren, wenn ein Entwickler von einem Bus angefahren wird oder zurücktritt.

Wenn ein Entwickler eine Woche im Urlaub ist, müssen Sie nicht eine Woche warten, bis der Fehler behoben ist. Oder Sie müssen einem wütenden Programmierer nicht erklären, warum Sie sich mit "seinem" Code herumärgern, während sein Rücken gewendet wurde.

Verbreitet das Produktwissen im gesamten Team. Ein Typ, der eine Bibliothek anruft, wird weniger Fehler machen, wenn er tatsächlich an dem Code in der Bibliothek arbeitet und ihn gut versteht. Ein Typ, der eine Blackbox anruft, von der er nichts weiß, wird länger brauchen und mehr Fehler machen.

Spreads coding Wissen im ganzen Team. Jeder lernt Tricks und Muster von anderen (sogar Spitzenprogrammierer können manchmal etwas lernen, was sie von einem Junior nicht kannten)

Gleicht den Codierungsstil aus - Leute haben Egos und neigen dazu, religiöse Kriege anzufangen, aber wenn sie an der Die gleiche Codebase und der Manager erzwingen die Codierungsstandards und greifen ein, um "Kämpfe" über Stil unter Kontrolle zu halten, nach einer Weile fängt das Team an, als zusammenhängende Gruppe zu arbeiten, die Codequalität steigt und die Kämpfe hören auf zu passieren.

Hilft jedem, sich als Teil eines Teams zu fühlen, mit keinen losen Kanonen. Es gibt keine Primadonnas und jeder fühlt sich gleich und ihr Input ist wertvoll und wertvoll - das bedeutet ein besseres Selbstwertgefühl. Wenn das Team ein Ziel erreicht, fühlen sich alle gut, und wenn das Team scheitert, spürt niemand das volle Gewicht der individuellen Verantwortung.

Programmierer kommunizieren mehr, was zu einem besseren Teamgeist und einer größeren Bereitschaft, anderen zu helfen, führt.

Es verbessert die Codequalität, weil Programmierer wissen, dass andere ihren Code lesen werden, so dass sie dazu neigen, alles in einem viel aufgeräumteren Zustand zu lassen, um Peinlichkeiten zu vermeiden. Sie wissen auch, dass sie ihren Code für andere leicht verständlich machen müssen, damit sie anfangen, Code für andere zu schreiben, anstatt Code für sich selbst zu schreiben.

Mögliche Nachteile können sein:

• Fights und religiöse Kriege um kleinere Meinungsverschiedenheiten über Codierstil oder Implementierungsansätze
• „Zu viele Köche verderben den Brei“ - manchmal die beste Art und Weise zu halten Ein Design, das sauber und fokussiert ist, hat nur eine Person, die es beherrscht. Das heißt nicht unbedingt, dass sie die ganze Arbeit erledigen, solange alle Teammitglieder die Vision verstehen und dem Entwurf des Architekten folgen. Code-Reviews können hier sehr mächtig sein.
• Nicht alle Programmierer sind gleich. Es kann frustrierend sein, wenn Ihr Team in der Lage ist, guten, sauberen Code zu liefern, aber vielleicht ist eine Person nicht in der Lage, die Qualität zu erreichen, die der Rest des Teams liefert. Dies kann Unzufriedenheit erzeugen und ein Team spalten, da sie das Gefühl haben, dass ihre wunderbare Schöpfung korrumpiert wird.
• Programmierer, die einfach keine Teamplayer sein wollen oder sich besser fühlen als die anderen, können sehr störend sein.

Ich würde sagen, in all diesen Fällen werden die Dinge in der Regel besser, wenn Sie diese Leute dazu bringen, den Besitz zu teilen. Manchmal nicht schnell genug, aber wenn du einem Einzelgänger erlaubt, ein Einzelgänger zu bleiben, wird er nie lernen, ein Teamplayer zu sein. Wenn du schwache Jungs aus dem Team lässt, wie werden sie lernen und ihre Fähigkeiten stärken? Wenn jemand schlechte Kommunikationsfähigkeiten hat, wie hilft ihm das Isolieren? Letztendlich brauchen Sie ein eingespieltes Team, das alle ein umfassendes Verständnis für die Codebasis hat und die Mitglieder in kleinen Fachbereichen auf Distanz halten.

Answer 5

Ich denke, die Korrekturen sind:

• Coding Standards beseitigt Ästhetik Kämpfe und hat zahlreiche weitere Vorteile.
• gemeinsame Verpflichtungen, wenn jemand Änderungen, die nicht das Design nicht verbessert oder einige erforderliche Funktionalität dann das Team sie umsetzen sollte darauf anrufen. Schließlich, wenn Sie putzen Zeit posting eher als in Richtung des Ziels gehen Sie Auswirkungen auf die Teams Leistung. Peer-Druck kann dann seinen Lauf nehmen.

Sie sollten auch selbst beurteilen. Es gibt eine natürliche Tendenz zu glauben, dass Handlungen, mit denen man nicht einverstanden ist, irrational sind. Oft fehlt es einfach an den Erfahrungen, die den anderen motivieren, und manchmal muss man seine eigenen Ego-Investitionen hinter sich lassen.

Answer 6

Ich hatte sowohl gute als auch schlechte Erfahrungen mit geteilten Code-Besitz.

Es fühlt sich gut an, wenn:

• -Code von mehreren Personen genutzt wird, wie utilites und Schnittstellen.
• Programmierer haben vergleichbare Qualifikation und Kenntnisstand.
• Alle Besitzer brauchen etwas aus dem gemeinsamen Code.

Es fühlt sich schlecht, wenn:

• -Code nicht stabil ist (wenn oder Refactoring Prototyping). Der Besitzer sollte es zuerst stabilisieren.
• Erzwungen als eine Politik. Das Team wird es simulieren und den Vollstrecker hassen.
• Code ist schlecht geschrieben. Es muss behoben werden, nicht geteilt werden.

In der Regel ist das gemeinsame Eigentum von allem keine gute Idee. Besser teilen, wenn es sich natürlich anfühlt, und Code für sich behalten, wenn nicht.

Answer 7

Auf der anderen Seite: -

• -Code im Rahmen der geteilten Eigentum ist nur so gut wie das schwächste Team-Mitglied/Rezensent
• Ein schwaches Teammitglied eine schlechte öffentliche Struktur einführen können, die irrevertable wird, weil ein unveränderliches externes System wird davon abhängig, bevor es entdeckt wird. In der realen Welt habe ich gesehen, dass dies zu oft passiert ist.
• Nebenbei bemerkt, wird ein gottähnliches Orakel fast immer aufgabenkritische, zeitabhängige, braun-stinkende Zeug-Hits-die-Spinning-Ding-Probleme in einem Bruchteil der Zeit vieler Jacks-of- All-Trades.

Shared Code Eigentum funktioniert nur, wenn alle im Team hoch qualifizierter ist, und macht nicht schlecht Anrufe, durch Wissenslücken. Mit anderen Worten, jeder im Team muss ein Experte für den gesamten Code sein und die Auswirkungen, die seine Änderungen auf Systeme haben, die aus einer engen Sicht der Aufgabe nicht sichtbar sind, vollständig verstehen.

Answer 8

Sie sollten dies lesen. Code-Besitz ist nicht so gut wie Sie denken.

https://medium.com/@billjordan1/the-quiet-crisis-unfolding-in-software-development-cffbdafbf450#.ldlpppzh2