Frage Wie kann ein guter Entwickler Code mit einem niedrigen Bus-Hit-Faktor erstellen? [geschlossen]


alt text http://www.metrocouncil.org/Directions/transit/images_transit/GoToBus.jpg

Schau dir das Bild oben an. Dies könnte ein Programmierer sein, der von einem Bus getroffen wird. Laut WikipediaIn der Softwareentwicklung ist der "Busfaktor" (oder "Bushitfaktor") eines Softwareprojekts

eine respektlose Messung von   Konzentration von Informationen in a   einzelne Person oder sehr wenige Leute. Das   Busfaktor ist die Gesamtanzahl der Schlüssel   Entwickler, die, wenn sie handlungsunfähig würden,   Wenn Sie von einem Bus angefahren werden, senden Sie die   Projekt in eine solche Unordnung, dass es   wäre nicht in der Lage fortzufahren.

Von einem Bus angefahren zu werden, kostete viele   verschiedene Formen. Dies könnte ein sein   Person, die eine neue Arbeit nimmt, eine   Baby, ändern ihren Lebensstil oder ihr Leben   Status hätte die Auswirkung das gleiche   bewirken.

Oder mit anderen Worten: Wenn der ursprüngliche Entwickler eines Stücks Code jemals von einem Bus getroffen wird, sind Sie geschraubt.

Also, meine Frage ist: Wie kann ein guter Entwickler Code mit einem niedrigen Bus-Hit-Faktor erstellen?

Und wer ist dafür verantwortlich, sicherzustellen, dass die Entwickler, die dazu gebracht wurden, ein wenig Code beizubehalten, es verstehen können?


75
2017-12-30 14:27


Ursprung


Antworten:


Der Verlust eines wichtigen Teammitglieds passiert oft, ob vorübergehend oder dauerhaft. Englisch: www.mjfriendship.de/en/index.php?op...27&Itemid=47 Ob jemand ein langes Mittagessen einnimmt oder die Grippe im Büro herumläuft oder ein Programmierer will Rollenwechsel in der gleichen Firma machen, oder eine schmerzhafte Scheidung durchmachen oder aufhören, um die Welt zu segeln, oder wird auf tragische Weise geschädigt Aussicht auf eine plötzliche und unerwartete Veränderung im Team ist unvermeidlich.

Eines der Attribute eines guten Entwicklers ist, dass sie bestrebt sind, den "Bus-Faktor" ihres Teams zu reduzieren sich selbst machen Weniger wesentlich. Das ist schwer zu tun, wenn du dich unsicher fühlst. EIN Guter Manager schafft die Sicherheit Menschen müssen sich über so etwas entspannen.

Praktiken, ungefähr in der Reihenfolge der Priorität:

  1. Gut durchdachter Code bedeutet, dass deine Absicht in den Code geschrieben ist und Geheimnisse eliminiert.

  2. Gründlich Komponententests dienen sowohl als eine Art Dokumentation als auch als ein Sicherheitsnetz, wenn ein Geheimhalter nicht verfügbar ist. (Das sind sie überprüfbar Dokumentation.)

  3. Paar-Programmierung, insbesondere Promiscuous Paarung, wird Wissen über das Entwicklungsteam verbreiten und Geheimnisse enthüllen.

  4. Versand oft bedeutet, dass, selbst wenn etwas passiert, Ihre Kunden bereits ein aktuelles, funktionierendes Produkt haben und Sie eine bekannte Menge haben, zu der Sie zurückkehren können, wenn es drunter und drüber geht.

  5. Dokumentation, sowohl in Kommentaren als auch anderswo, speichert Ideen und Absichten, die nicht im Code ausgedrückt werden können. Dokumentation ist jedoch teuer in der Erstellung, teuer in der Anschaffung, teuer in der Wartung und oft ignoriert, so dass die anderen Elemente bevorzugt werden.


74
2017-12-30 15:42



Ich würde Code sagen, der hat gute Komponententests. Für den Ersatzentwickler, der dem Projekt beiwohnt und weiß, dass seine Änderungen andere Teile des Systems nicht beschädigen, ist es wichtig.


17
2017-12-30 14:37



Der schwierigste Teil der Wartung IMO weiß nicht, was die Software macht oder wie sie es macht: Sie weiß, was die Software tun soll.

Wenn ich weiß ...

  • Was soll die Software (d. H. Die funktionale Spezifikation ... ich brauche nicht unbedingt die Design-Spezifikation)

  • Wie man baut, wie man läuft und (nach der Funktionsspezifikation) wie man die existierende Software testet

... dann ist das das Wichtigste. Andere Dokumentation (z. B. "Design": die beschreibt, wie die funktionale Spezifikation von der Software implementiert wird) könnte auch schön sein, aber es ist vergleichsweise optional und weniger wichtig als die oben genannten.

Die meisten Entwickler beantworten Ihre Frage mit "Kommentaren im Code, gut benannten Bezeichnern, Quellcodeverwaltung usw.". ... aber ich denke, das ist wichtiger "als Entwickler, wenn Sie Software schreiben, die keine geschriebene funktionale Spezifikation hat, dann schreiben Sie ein bisschen funktionale Spezifikation, um mit Ihrer Software zu gehen." Ein FS wird nützlich sein, bevor jemand versucht, die Software zu warten: Es wird für QA nützlich sein, die wissen wollen, wie man die Software testet.

Und wer ist dafür verantwortlich, sicherzustellen, dass die Entwickler, die dazu gebracht wurden, ein wenig Code beizubehalten, es verstehen können?

Typischerweise ist dies der Teamleiter des neuen Entwicklers (d. H. Der Senior-Programmierer, der den existierenden Code bereits kennt); aber wenn dies nicht gelingt (wenn es keinen solchen Teamleiter gibt), kann es sich um einen Manager (Produkt- oder Projektmanager oder "Freisetzungsingenieur") handeln, wenn dieser Manager weiß, wo er die funktionalen Spezifikationen der Software finden und Anweisungen erstellen kann.


14
2017-12-30 14:47



Regelmäßige Peer-Code-Reviews helfen. Dies bedeutet, dass mindestens eine weitere Person über jede Codezeile hinweggesehen haben muss und dass sie angefordert haben sollte, dass sie bei Bedarf zur besseren Übersicht geändert wird.

Ich bemühe mich ständig um klare Code-Klarheit, die zukünftigen Entwicklern helfen sollte. Es gibt jedoch Gelegenheiten, wo Sie nicht helfen können, aber Code zu schreiben, der ein bisschen stumpf ist. In diesem Fall sammle ich das Team für 30 Minuten zusammen, um eine High-Level-Idee zu durchlaufen, wie der Code funktioniert, wenn nicht eine vollständige Erklärung.

Eine Reihe von Komponententests hilft auch anderen Entwicklern, Code zu ändern, da sie dann wissen, wenn sie eine Änderung vornehmen, die einen Teil des Systems unterbricht. Wenn sie gut geschrieben sind, können sie auch erklären, wie Teile des Systems durch Benennung und nicht durch reinen Code funktionieren sollen.


12
2017-12-30 14:32



Während ich als Student Programmierer an meiner Universität arbeitete, während meines Undergraduate my Bustrefferfaktor musste eng verwaltet werden. Ich arbeitete an großen Projekten, aber meine Beschäftigung dort war nur bis zum Tag meines Abschlusses. An diesem Punkt müssten andere Programmierer in der Abteilung mein Projekt abholen und von dort aus verwalten. Das habe ich mit Eimern Dokumentation geschafft. 

Seit dem Tag, an dem ich mit diesem Job angefangen habe, habe ich mein Bestes getan, um meine Spezifikationen, meinen Code und andere Unterlagen so aktuell und sauber wie möglich zu halten, damit jeder kompetente Mitarbeiter innerhalb weniger Tage ein solides Verständnis meiner Arbeit erlangen konnte (mit oder ohne meine Hilfe). Jedes meiner Projekte würde ein entsprechendes Confluence-Wiki enthalten, in dem ich alle Dokumente, Diagramme, Spezifikationen und kleine Leckerbissen für andere Entwickler aufbewahre.

Es hilft auch, wenn Sie einen guten sauberen Codierungsstil haben. Wenn Ihr Code sinnvoll ist und die Augen schont, sollten andere Programmierer nach Ihrem unglücklichen Busunfall in der Lage sein, ihn abzuholen.


10
2017-12-30 14:38



Es sollte immer Doppelspurigkeiten in einer Organisation geben.

So wie Sie Ihre Festplatte immer sichern würden (richtig ???), wollen Sie nicht, dass eine Person der alleinige Besitzer wichtiger Informationen ist. Eine Möglichkeit, dies zu verringern, besteht darin, dass Programmierer zusammenarbeiten.

Was Sie als das "Bus" -Problem erwähnen, ist praktischerweise das "Was ist, wenn Joe wegzieht / beschließt aufzuhören" Faktor. Im Allgemeinen ist die Beschäftigung nach Belieben, und jeder kann jederzeit gehen.

Eine widerstandsfähige Organisation kann sich nicht auf einen einzelnen Entwickler verlassen, der über alle wichtigen Kenntnisse verfügt.


7
2017-12-30 14:33



Source Control und gut durchdachter und kommentierter Code sind der Schlüssel.

Die Verantwortlichen dafür sorgen nicht wirklich dafür, dass alle am Code beteiligt sind. Die Dev-Manager und die PMs sind diejenigen, die sie genau im Auge behalten sollten, aber die Geschäftsleitung muss Richtlinien erstellen, um sie zu unterstützen und Ressourcen zur Verfügung zu haben, um sicherzustellen, dass mehrere Personen mit überlappenden Wissensgebieten arbeiten können.


4
2017-12-30 14:34



Die Paarprogrammierung mindert dieses Risiko in hohem Maße. Wenn Sie das nicht können (viele von uns haben nicht den Luxus, bei jedem Projekt zusammenzuarbeiten), können Sie regelmäßige Peer Reviews planen und Ihren Code dokumentieren wenn du gehstim Gegensatz zur Dokumentation am Ende.


3
2017-12-30 14:52



Debugging ist schwer. Also, wenn Sie es sind   so geschickt wie möglich zu codieren   zu dumm sein, den Code zu debuggen.

  • Einfacher Code verbessert die Wartbarkeit
  • Codeüberprüfungen zur Vereinfachung
  • Projektmanager tragen Verantwortung

3
2017-12-30 14:33



Das c2 Wiki hatte einen Artikel mit einem Namen in der Art von "Traue keinem Entwickler für einen Monat in einem Raum". Der Bezug wurde auf Projektpläne mit Werbebuchungen wie "Implementieren System, Fred, sechs Wochen", wo Projektmanagement besteht aus Gesprächen wie "Wie geht es Fred? Sind wir noch für sechs Wochen in Ordnung?" und Fred sagte: "Ja, ich glaube wir sind zu 80% da."

Eine gesunde Busnummer ist ein Nebeneffekt einer Kultur, die das "Entwickler in einem Raum für einen Monat" -Syndrom vermeidet. Ich denke, es ist eher ein kulturelles als ein technisches Problem - eine Busnummer ist ein Attribut einer Organisation und nicht einer Codebasis - und die Standards müssen von oben nach unten festgelegt werden. Merkmale dieser Kultur umfassen:

  • Allgemein bekannte organisatorische Ziele und Geschäftsprozesse, so dass Entwickler etwas anderes als eine eng-technische Perspektive für die Entscheidungsfindung haben, und dass sie einen Rahmen haben, um Vor- und Nachteile mit nicht-technischen Interessengruppen zu diskutieren.
  • Konkrete Zieleinstellung und überprüfbare Fortschrittsindikatorenabstrakte Substantive wie "das System" zu vermeiden, dem jeder seine eigene Bedeutung beilegt, verbale Berichte von "fast fertig" oder "zu 80% erledigt" bedeuten nicht sichtbar gemacht, Alarmglocken gehen aus, wenn ein paar Tage vergehen ohne objektiven Fortschritt von einem Entwickler (neue Tests bestanden, neue Demoversion, etc.).
  • Auditing und Rechenschaftspflicht: Sie sind nicht nur dafür verantwortlich, Ihre Arbeit zu erledigen, Sie sind auch dafür verantwortlich, Ihren Kollegen Rechenschaft abzulegen. Es wird nicht kritisiert, Rechenschaft abzulegen, es ist ein Mittel der Unterstützung und eine Möglichkeit, Ihr Wissen in die Organisation einzubringen.
  • Neugierde, Bereitschaft, Kollegen zu unterstützen. Probleme mit der Busnummer werden oft dadurch verschärft, dass andere Entwickler nicht bereit sind, ihrem Bus-Crash-gefährdeten Kollegen zu helfen, falls sie sich mit den ausgedehnten Verantwortlichkeiten dieses Kollegen und den alten Wartungsaufgaben infizieren.
  • Informell Kanäle für Probleme und Zweifel (Zum Beispiel, Kollegen haben zusammen Mittagessen), und formale Prozesse für die Protokollierung und Eskalation von Problemen.

3
2018-01-13 02:52



In der Reihenfolge der Wichtigkeit (offensichtlich ist dies meine eigene Meinung):

  • Klar benannte Objekte, Variablen und Funktionsnamen
  • Kommentare löschen
  • Quellcodeverwaltung
  • Codeüberprüfungen
  • Angemessene Bug-Tracking-Software, mit tatsächlichen Notizen über das, was passiert ist.
  • Dokumentation wo nötig (aber nur wo nötig; zu viel macht es nur schwer zu finden, was Sie brauchen)

Und die dafür verantwortliche Person? Du natürlich.


3
2017-12-30 14:58