Wie verfolgst du, welche Klassen und Funktionen dein Team geschrieben hat?

43

Wenn ich an Code arbeite, stelle ich mich den gleichen Herausforderungen wie meine Teamkollegen, und ich habe einige hilfreiche Funktionen und Klassen geschrieben, und auch diese. Wenn es eine gute Kommunikation gibt, höre ich von etwas Großartigem, das jemand zusammengestellt hat, und sechs Monate später, wenn ich es brauche, kann ich es mir merken und diese Funktion aufrufen, um mir Zeit zu sparen. Wenn ich mich nicht daran erinnere oder nichts davon wusste, werde ich das Rad wahrscheinlich neu erfinden.

Gibt es eine besondere Praxis, solche Dinge zu dokumentieren? Wie machen Sie sie leicht zu finden?

Wenn Ihr Team keine solchen Unterlagen hat, wie können Sie feststellen, ob Ihr Rad bereits vorhanden ist?

BEARBEITEN:

Alle bis auf eine Antwort beziehen sich auf eine ideale Situation. Lassen Sie mich die folgenden Lösungen zusammenfassen: Dokumentation & Kommunikation; Wikis, Stand-up-Meetings usw. Das sind alles großartige Dinge, aber sie setzen voraus, dass Programmierer die Zeit (und die Fähigkeiten) haben, die Dokumentation zu schreiben, an den Meetings teilzunehmen, sich Notizen zu machen und sich an alles zu erinnern.

Die bisher beliebteste Antwort (Calebs) ist die einzige, die von einem Programmierer verwendet werden kann, der nicht in der Lage ist, Dokumente und Besprechungen zu erstellen, und der nur eines tut: Programmieren. Programmieren ist das, was ein Programmierer tut, und ja, ein großartiger Programmierer kann Dokumentation, Komponententests usw. schreiben, aber seien wir ehrlich - die meisten von uns bevorzugen das Programmieren gegenüber dem Dokumentieren. Seine Lösung ist eine, bei der der Programmierer wiederverwendbaren Code erkennt und in eine eigene Klasse oder ein eigenes Repository abruft oder was auch immer. Durch die Tatsache, dass er isoliert ist, wird er auffindbar und erleichtert die Lernkurve für seine Verwendung. und dies wurde durch Programmierung erreicht.

In gewisser Weise sehe ich das so: Ich habe gerade drei Funktionen geschrieben, und mir fällt ein, dass jemand anderes davon wissen sollte. Ich könnte sie dokumentieren, aufschreiben, bei einem Meeting ankündigen usw. - was ich tun kann, aber es ist nicht meine Stärke - oder ... Ich kann sie in eine Klasse extrahieren, sie gut benennen, sie funktionieren lassen eine schwarze Kiste, und kleben Sie es, wo andere Klassendateien gehen. Dann ist eine kurze E-Mail mit der Ankündigung einfach. Andere Entwickler können den Code scannen und besser verstehen als sie eine isolierte Funktion, die in Code verwendet wird, den sie nicht vollständig verstehen - dieser Kontext wird entfernt.

Ich mag das, weil es bedeutet, dass eine Reihe von gut benannten Klassendateien mit gut benannten Methoden eine gute Lösung ist, die durch gute Programmierung erreicht wird. Es sind keine Besprechungen erforderlich, und es wird weniger detaillierte Dokumentation benötigt.

Gibt es weitere Ideen in diesem Sinne ... für isolierte und zeitgemäße Entwickler?

Changokun
quelle
5
Ich würde die Frage erweitern, um sie in größerem Maßstab zu stellen, vielleicht in einem Unternehmen mit mehr als 100 Mitarbeitern, wie Sie dasselbe tun. Welche bewährten Methoden können angewendet werden, um Doppelarbeit zu vermeiden?
Asaf
1
@Asaf - Ich vermute, die richtige Antwort hängt von der Bevölkerungszahl ab - was für einen 5-Personen-Shop funktioniert, funktioniert nicht für 50 und was für 50, funktioniert nicht für 500. Antworten auf alle wären willkommen.
Dan Pichelman
3
Das ist eine tolle Frage!
Rocklan
4
Conways Gesetz : "Organisationen, die Systeme entwerfen ... sind gezwungen, Entwürfe zu produzieren, die Kopien der Kommunikationsstrukturen dieser Organisationen sind".
Mark Rushakoff
2
@nathanhayfield: Das ist eine Lösung, die für 1 Entwickler und zu einem gewissen Grad für 2 Entwickler funktionieren kann, aber nicht für 20 oder 100. Und selbst wenn ich alleine arbeite, ziehe ich es vor, die Hilfsfunktionen thematisch zu trennen.
Doc Brown

Antworten:

29

Bibliotheken. Frameworks. Versionskontrolle.

Wenn Sie wiederverwendbaren Code haben, ist das allerletzte, was Sie möchten, dass verschiedene Teammitglieder den Quellcode in ihr Projekt kopieren. Wenn sie das tun, ist die Wahrscheinlichkeit groß, dass sie sich hier etwas ändern und dort etwas optimieren. Bald gibt es Dutzende von Funktionen oder Methoden, die alle den gleichen Namen haben, aber jeweils ein bisschen anders funktionieren. Vielleicht ist es auch wahrscheinlicher, dass der ursprüngliche Autor den Code weiter verfeinert, um Fehler zu beheben, ihn effizienter zu gestalten oder Funktionen hinzuzufügen. Der kopierte Code wird jedoch niemals aktualisiert. Der technische Name dafür ist ein gewaltiges Durcheinander .

Die richtige Lösung besteht darin, das wiederverwendbare Material aus dem Projekt zu ziehen, für das Sie es erstellt haben, und es in einer Bibliothek oder einem Framework in einem eigenen Versionskontroll-Repository abzulegen. Das macht es leicht zu finden, rät aber auch davon ab, Änderungen vorzunehmen, ohne Rücksicht auf alle anderen Projekte, die es möglicherweise verwenden. Sie können mehrere verschiedene Bibliotheken in Betracht ziehen: eine für gut getesteten Code, der sich wahrscheinlich nicht mehr ändert, eine für Dinge, die stabil erscheinen, die jedoch nicht gründlich getestet und überprüft wurden, und eine für vorgeschlagene Ergänzungen.

Caleb
quelle
5
Ich würde auch gerne empfehlen, eine sehr gründliche Reihe von Regressionstests für die wiederverwendbare Bibliothek durchzuführen. Auch wenn die Änderung harmlos erscheint, könnte jemand von diesem Verhalten abhängig sein.
Bobson
2
Ich dachte, der Fachbegriff wäre BBOM .
zzzzBov
2
Ihre Antwort klingt auf den ersten Blick vernünftig und ist es im kleinen bis mittleren Maßstab, aber ich habe auch die Schattenseiten einer Direktive "nicht kopieren" gesehen. Wenn Sie unterschiedliche Teams für unterschiedliche Produkte mit unterschiedlichen Lizenzbedingungen, unterschiedlichen Lebenszyklen und unterschiedlichen Wartungsverträgen haben, ist das allerletzte, was Sie möchten , die verschiedenen Produkte mit einer selbst gebrauten Bibliothek von Code-Snippets zu koppeln, die diesen Wartungsanforderungen nicht entsprechen . Bibliotheken für diese Art von Szenario müssen eine sehr hohe Qualität aufweisen und manchmal ist es für ein Team noch effizienter, den Code zu kopieren und ..
Doc Brown
3
@Caleb: bleib ruhig, lies mein Posting komplett durch. Mein Punkt ist: Das Kopieren von Code von irgendwo anders, das Optimieren und Integrieren in eine Teambibliothek bringt Sie nicht unbedingt auf den "Weg in die Zukunft". Wenn Sie zwei Bibliotheken mit überlappender Funktionalität haben und zwei Teams, von denen jedes für die Aufrechterhaltung ihrer Bibliothek verantwortlich ist, ist die Situation nicht so schlimm. Das ist nicht perfekt, da ein Team vielleicht etwas arbeitet, das andere auch, aber manchmal überwiegt der Vorteil, dass diese Teams unabhängig bleiben, die doppelte Arbeit.
Doc Brown
1
@DocBrown Es gibt Situationen, in denen es notwendig wird, Code zu kopieren, aber das sollte eine bewusste Entscheidung sein und nicht etwas, zu dem Sie gezwungen sind, weil der Code ursprünglich geteilt wurde.
Caleb
13

Ein Ansatz dafür ist, ein Wiki für diesen Zweck einzurichten und einige hochrangige Dokumente darüber zu schreiben, welche wiederverwendbaren Komponenten Sie haben, wie Sie ein Problem gelöst haben usw.

Das Schwierige ist, jeden in Ihrem Team dazu zu bringen, dieses Wiki ständig zu pflegen. Aber jede andere Art von Dokumentation hat das gleiche Problem.

Ein Teil Ihres Codes ist möglicherweise auch gut genug, um in eine wiederverwendbare Bibliothek gestellt zu werden. Dies erleichtert auch das spätere Auffinden des Codes.

Doc Brown
quelle
5
Ein Wiki ist nicht der richtige Weg, um Code zu verbreiten. Es ist eine großartige Möglichkeit, über Code zu kommunizieren , aber (siehe meine Antwort) Sie möchten nicht, dass Leute etwas Größeres als einen Ausschnitt aus einem Wiki kopieren und in ihr Projekt einfügen.
Caleb
@Caleb die Kommunikation ist der schwierige Teil
jk.
@jk - Die Kommunikationsprobleme verschärfen sich, wenn Sie nicht über die in C
JeffO vom
3
@Caleb: Bei der Frage des OP ging es nicht um die Verbreitung von Code, sondern darum, zu kommunizieren und ihn später zu finden.
Doc Brown
@DocBrown Auch in diesem Fall eignen sich Wikis hervorragend für die Kommunikation, und deshalb sind wahrscheinlich Tools wie GitHub bereits integriert. Aber das, was das Auffinden von Code erleichtert, ist nicht, dass es in einem Wiki erwähnt wird, sondern dass es an einem bekannten Ort aufbewahrt wird. Das könnte ein Wiki sein, aber wenn es sich um Code handelt, den die Leute tatsächlich verwenden werden (im Gegensatz zu einer Reihe von Ausschnitten, die eine Lösung darstellen), sollte es sich um eine Bibliothek handeln, die baubar, testbar und welche kann einbezogen werden, ohne die Anzahl der Stellen zu multiplizieren, an denen es früher oder später aktualisiert werden muss.
Caleb
7

Hier ist meine Erfahrung, in einem Unternehmen mit 700 Mitarbeitern in Teams mit 2 bis 20 Mitarbeitern zu arbeiten.

Auf Teamebene

Wir haben jeden Tag "Stand-up-Meetings" für ca. 15-20 Minuten. Wir können schnell allgemein bekannt werden, wie "Ich habe diese Funktion gestern ausgeführt, sie ist so schwer".

Wir haben auch ein Wiki pro Projekt. Das heißt, wir können (technische) Informationen über das, was im Projekt gemacht wird, teilen, einschließlich benutzerdefinierter Klassen / Funktionen, die eingebaut wurden.

Auf Agenturebene

Auf Agenturebene haben wir 4 Tools:

  • Ein weiteres Wiki. Es ist hauptsächlich dazu da, uns Informationen über Hardware und andere Dinge zu geben. Manchmal verwenden wir es jedoch, um technische Informationen zu teilen, die überprüft werden sollen, bevor sie auf Unternehmensebene platziert werden.
  • Wöchentliche Treffen. Sie wissen hauptsächlich über den Fortschritt jedes Teams / Projekts Bescheid, aber da wir größtenteils Technikbegeisterte sind, können wir coole Dinge ansprechen.
  • Mailingliste. Wir haben ein Mailing mit allen Mitarbeitern der Agentur. Viele coole Sachen / lustige Sachen / nützliche Sachen kommen dort durch.
  • VCS-Repository. Jede Agentur hat ihr persönliches Repository, in dem wir kleine Projekte haben, meist Module, die wir in verschiedenen Projekten verwenden.

Auf Unternehmensebene

Auf Unternehmensebene ist es besser organisiert.

Das Wiki auf "Agentur-Ebene" ist eigentlich Teil des Firmen-Wikis.

Und das Wiki wird dann nach Technologien aufgeteilt. So kann jeder es verbessern, durchsuchen und dem Wiki im Grunde ein Leben geben.

Es gibt auch Mailinglisten, die wir abonnieren können. Jeder in der Agentur kann abonnieren, und die meisten Leute folgen mindestens einer oder zwei Technologien. Tatsächlich folgen die meisten Leute 5-10 von ihnen.

Und das VCS ist natürlich das beste Code-Sharing-System.

Fazit

Zusammenfassend lässt sich sagen, dass es keine eindeutige Lösung gibt. Wissensaustausch war schon immer ein großes Thema und wird es wahrscheinlich auch bleiben. Es gibt viele Lösungen, um Wissensdatenbanken zu erstellen , und wahrscheinlich passt eine auf Ihre Rechnung. Aber einige Leute versuchen , noch besser KB zu bekommen , da die aktuellen Lösungen sind nicht immer sehr klug.

Florian Margaine
quelle
Ich bin der Meinung, dass die Schlussfolgerung nichts weiter als "Wiki, Wiki, Wiki, Wiki, Wiki" sagen sollte, aber im Ernst, eine gute Antwort, ein internes Wiki kann gut sein, um Details auf höherer Ebene oder das Nutzungsalter zu beschreiben, ganz zu schweigen davon durchsuchbar zu sein ist eine gute Zeitersparnis.
RhysW
6

Nun, es kommt alles auf die Kommunikation an.

Wikis sind großartig und du solltest auf jeden Fall eines installieren und benutzen. Ein gutes Intranet für interne Programmierer ist gut, wenn die Leute es lesen und aktualisieren. Sie sprechen also tatsächlich über ein Problem mit den Leuten dort. Sie können wöchentliche "Team Update" -Treffen vorschlagen, bei denen sich alle treffen und einen Überblick über die aktuellen Arbeitsabläufe geben. Die technischen Leiter (zumindest!) Sollten sich treffen und darüber plaudern, was jedes Team tut. Informelle "Brown Bag" -Sessions sind großartig, planen sie zur Mittagszeit und bringen die Leute zum Reden.

Sie benötigen auch eine Möglichkeit, Code freizugeben, zu verpacken, zu versionieren und zu verteilen. Es wäre einfacher, wenn Sie ein wirklich gut verwaltetes Quellcode-Repository hätten, das gut in "gemeinsame" und Projektordner unterteilt ist.

Wenn nichts dergleichen getan wird, sprechen Sie Ihren Chef an, erklären Sie, wie das Unternehmen davon profitiert, und schlagen Sie einen Weg vor :)

Rocklan
quelle
1
Ich würde das "gemeinsame" Konzept in Ihrer Antwort ein wenig weiter oben erläutern.
JeffO
4

Code-Überprüfungssitzungen können helfen. Wenn sich Ihr Team regelmäßig trifft, um zu besprechen, was entwickelt wurde, kann die Person, die eine Lösung gefunden hat, den anderen zeigen, wie sie diese verwendet. Wenn jemand einen Punkt anspricht, an dem er festhält, können andere Teammitglieder einen Ansatz vorschlagen, der die Wiederverwendung vorhandener Komponenten erhöht.

Daenyth
quelle
1
Dann 4 Jahre und 600 Funktionen später, wenn Sie sich an diese eine Funktion erinnern möchten, die einige Zeit gemacht wurde? Ein Teil des OP-Problems bestand darin, sich an all die Dinge zu erinnern, die geschaffen worden waren, während dies zunächst gut ist und sich über einen Zeitraum von vielleicht ein oder zwei
Monaten
2

Der beste Weg, um mit so etwas umzugehen, ist eine Repository-Struktur, die einige einfache Konventionen enthält, sodass ich als Programmierer doXYZungefähr weiß, wo ich nach dieser Funktion suchen sollte , wenn es eine Funktion gibt . Unabhängig davon, ob Sie Namespaces, Verzeichnisse, Module, Plugins oder Pakete verwenden, sollte Ihr Code modular aufgebaut sein, damit sich Funktionen, die dasselbe tun oder auf dieselben Datenquellen zugreifen, größtenteils an derselben Stelle befinden.

Jonathan Rich
quelle
0

Idealerweise sollte bei jedem Einchecken neben dem Autor mindestens eine weitere Person eine Codeüberprüfung durchführen. Der Codeüberprüfungsprozess kann dazu beitragen, das Problem des Eincheckens vieler doppelter Methoden zu verringern. Natürlich sind Sie auf das Wissen der Überprüfer angewiesen.

TL; DR: Code-Überprüfungen für jeden Check-In.

Carolyn
quelle
2
Versteh es nicht. Werden Sie getesteten und funktionierenden Code wegwerfen, nur weil er wie ein Duplikat in einer Codeüberprüfung aussieht? Die Frage war, wie vermieden werden kann, dass der doppelte Code überhaupt geschrieben wird. Eine Sitzung wie @ daenyths Antwort scheint besser zu sein.
Adrianm
Wenn ein Rezensent mir sagt, ich füge Code hinzu, der die Funktionalität dupliziert, und ich schaue und stelle fest, dass sie richtig sind. (Ich würde wahrscheinlich auch prüfen, ob meine Implementierung besser ist, und in diesem Fall prüfen, ob ich die andere Implementierung umgestalten kann, anstatt eine neue hinzuzufügen.)
Carolyn,