Sollten Sie eine gute Dokumentation und sauberen Code schreiben, um den „Bus-Faktor“ zu erhöhen?

48

Eines der Hauptziele von Softwareentwicklungsunternehmen ist die Erhöhung des Busfaktors. Dies wird auch in einem von Google organisierten Vortrag befürwortet .

Das bedeutet, dass Sie alles so codieren und dokumentieren sollten, dass das Projekt fortgesetzt werden kann, wenn Sie morgen mit dem Bus überfahren werden. Mit anderen Worten, Sie sollten sich leicht durch einen anderen Programmierer ersetzen lassen, der ähnliche Fähigkeiten wie Sie besitzt.

Austauschbar zu sein, widerspricht das nicht dem Interesse eines Entwicklers? In dem Buch heißt es in 48 Machtgesetzen in Regel 11, dass Sie versuchen sollten, die Menschen von Ihnen abhängig zu machen, um Macht zu erlangen, was sich dann in monetären Belohnungen niederschlägt.

Abgesehen von dem Szenario, in dem Sie einige Unterlagen für sich selbst benötigen, um ein Projekt nach 6 Monaten Pause fortzusetzen, scheint hier ein klarer Interessenkonflikt zwischen dem Entwickler und dem Softwareunternehmen zu bestehen.

Als Programmierer sollten Sie also wirklich hervorragende Dokumentationen und leicht lesbaren Code für alle schreiben. oder sollten Sie Code und Dokumentation so schreiben, dass sie die Aufgabe erfüllen und Sie sie selbst verstehen können, aber eine andere Person hat möglicherweise Probleme, sie zu verstehen?

siamii
quelle
41
Das Buch von Greene eignet sich für Despoten und Lakaien, die in Lehen Gunst schöpfen. Keine gute Moralphilosophie für Teamwork. Gelinde gesagt! [Beachten Sie, dass Wikipedia dieses Buch unter "Soziopathie" kategorisiert]
Steven A. Lowe
27
Ich würde dich niemals einstellen: D
deadalnix
37
Friedhöfe sind voller unersetzlicher Menschen.
Job
20
Sie möchten niemals unersetzlich sein - wie kommen Sie zu Beförderungen, wenn Sie nicht ersetzt werden können? Wenn Sie nicht genau dort glücklich sind, wo Sie sich gerade befinden, ist der „Bus-Faktor“ immer wichtig.
Dave
11
"Das Buch teilt thematische Elemente mit Niccolò Machiavellis The Prince und wurde mit Sun-Tzu's klassischer Abhandlung The Art of War verglichen." Ich glaube nicht, dass ich mit jemandem zusammenarbeiten möchte, der seinen Arbeitsplatz als eine italienische Politik des 16. Jahrhunderts oder als eine alte chinesische Kriegsführung ansieht.
Cascabel

Antworten:

110

Sie sollten versuchen, unersetzlich zu werden, indem Sie nicht Code schreiben, den niemand versteht, sondern indem Sie mehr Erfahrung und Wissen sammeln als andere. Der erste Weg macht Sie zu einem Entwickler, mit dem jeder nicht zusammenarbeiten möchte, da er befürchtet und es ablehnt, den von Ihnen geschriebenen Code zu pflegen. Auf diese Weise werden Sie zu einem gesuchten Teammitglied, das Manager in ihrem Team haben möchten.

Nach meiner Erfahrung hat sich das Schreiben von sauberem, gut dokumentiertem (und vorzugsweise selbstdokumentierendem) Code immer ausgezahlt. Tatsächlich nutzte ich fast jede Gelegenheit, um anderen zu helfen und sie zu unterrichten (und von ihnen zu lernen, wenn sie etwas besseres wussten), und ich fühlte mich kaum jemals in Gefahr, von jemandem ersetzt zu werden, der weniger fähig war als ich. Tatsächlich half dies normalerweise dem gesamten Team, besser zu arbeiten und Probleme schneller zu lösen, was der Traum eines jeden Managers ist - und ein vernünftiger Manager möchte nicht die Mitglieder eines guten Teams ersetzen.

Péter Török
quelle
1
Es ist interessant, dass dies gerade zur Sprache gebracht wird, denn vor ein paar Tagen wurde mir gesagt, wie wertvoll ein paar Diagramme waren, die ich von einem der Projekte gemacht habe, an denen ich gerade arbeite, für Leute, die wahrscheinlich nie mehr arbeiten werden Tippen Sie auf den Code. Das und natürlich, um mir einen Überblick über die verschiedenen Module und deren Interaktion zu verschaffen. Diese Übersicht wird im Moment vielleicht nicht besonders gebraucht, wenn ich alles in frischem Gedächtnis habe, wird aber mit ziemlicher Sicherheit helfen, wenn ich den Code in einem Jahr
überarbeite
2
Einige Leute, die Code geschrieben haben (schlecht, verschleiert), der sie bei meiner Arbeit "unersetzlich" machte, arbeiten hier nicht mehr. Bessere Programmierer sahen ihre Arbeit während der Codeüberprüfung oder der Fehlerbehebung, während sie im Urlaub waren. Sah die "Qualität" ihrer Arbeit, und sie wurden eingemacht.
CaffGeek
44

Wenn Sie Organisationen oder Menschen so transparent manipulieren, sind sie besser dumm oder stecken in einem Stau, der ihnen keine andere Wahl lässt. Ein gut geführter Softwareentwicklungs-Shop würde sich Ihren undurchsichtigen Code und die fehlende Dokumentation ansehen und Sie einfach entlassen, bevor Sie viel Schaden anrichten könnten. Wenn sie schlecht laufen oder andere Entwickler nicht dazu bringen können, für sie zu arbeiten, warum möchten Sie dann eine Sinecure mit ihnen haben?

PS Weder Herr Greene noch Machiavelli haben tatsächlich viel erreicht, außer Bücher zu schreiben, die versuchten, möglichen "harten Männern" der Zeit zu schmeicheln. Nehmen Sie ihren Rat mit einem Körnchen Salz.

Charles E. Grant
quelle
42

Wenn Sie unersetzlich sind, können Sie nicht befördert werden.

James McLeod
quelle
14
Schlimmer noch, wenn Sie jemals demonstrieren, dass Sie den nicht funktionierenden Code anderer Leute verwenden und zum Laufen bringen können, wird es Ihnen nie wieder gestattet sein, an Ihrem eigenen Code zu arbeiten, da es als billiger empfunden wird, die anderen Leute zuzulassen Schruppen Sie einen riesigen dampfenden Haufen aus und lassen Sie dann den riesigen dampfenden Haufen reinigen und polieren.
John R. Strohm
Beste Argumentation aller Zeiten zum Thema
ZJR
2
Klassische Antwort in der Tat.
Sarawut Positwinyu
@ JohnR.Strohm Kumpel !!!! Ich war dort und das fühlt sich so schlecht an. Als vorsichtigerer Ingenieur würde ich mir etwas mehr Zeit für eine Aufgabe nehmen. Also ließ der Manager andere Leute schäbigen Code schnell schreiben und ließ mich ihn dann in einer Codeüberprüfung bereinigen. Ich fühlte mich absolut missbraucht, weil diese Rolle meine Relevanz für das Team wurde, obwohl es nicht das war, was ich wollte. Unnötig zu erwähnen, dass ich das Team verlassen habe, kurz nachdem ich das bemerkt hatte.
DavidXYZ
17

Sie wollen nicht unersetzlich sein. Sie möchten nicht, dass sich die Menschen von Ihnen abhängig fühlen, Sie möchten, dass sie Sie schätzen. Im Allgemeinen möchten Sie sich von Menschen fernhalten, die der Meinung sind, dass auch die Hälfte der Gesetze der Macht auf (berufliche oder persönliche) Beziehungen angewendet werden sollte.
Diese Regeln enthalten Anweisungen, wie eine Win-Lose-Situation erfolgreich hergestellt werden kann. Was Sie wollen, ist eine Win-Win- Situation.
Sobald die Leute anfangen zu fühlen, dass Sie versuchen, sie auf die Seite der Niederlage einer Win-Lose-Situation zu drängen, werden sie sich wehren. Versuche, Gewinn- und Verlustsituationen zu etablieren, führen häufig zu Verlusten, da Sie Ressourcen verschwenden, um Ihren Partner in eine Verlustposition zu bringen, anstatt ihn in den Gesamterfolg Ihrer Partnerschaft zu investieren.

Wenn Sie dies mit Ihren Arbeitgebern tun, werden diese versuchen, Ihnen Maßnahmen aufzuzwingen, um Ihr Wissensmonopol zu verringern. Meist handelt es sich dabei um lächerliche Richtlinien, wie Sie Ihre Arbeit verrichten müssen und damit Ihr Arbeitsleben in eine lebendige Hölle verwandeln. Außerdem rufen sie dich um 3 Uhr nachts an, wenn etwas kaputt geht, weil du die einzige Person bist, die es reparieren kann. Wenn Sie versuchen, Situationen wie Hebeleffekte auszunutzen, kann dies zu Fehlschlägen und Problemen führen.

Die Friedhöfe sind voller unverzichtbarer Männer.
- Gaulle, Charles De

Also schneiden Sie den Mist und machen Sie Ihre Arbeit richtig. Wenn nicht für irgendetwas anderes, dann für Sie, weil Sie wahrscheinlich die arme Seele sind, die in 2 Jahren einige Änderungen am Code vornehmen muss.

back2dos
quelle
Ich habe festgestellt, dass jedes Mal, wenn ich versuche, eine Win-Win-Situation herzustellen, die Menschen gewinnen und überlegen erscheinen wollen. Es ist fast wie in diesem Buch darüber, wie Mafia funktioniert: Wenn Sie einen Kollegen als gleichwertig behandeln, geht er ziemlich bald davon aus, dass er Ihnen überlegen ist. Es funktioniert mit dem Grafikdesigner, der gerade drei Jahre lang das College verlassen hat - je mehr ich ihn respektierte, desto mehr behandelte er mich wie Dreck. Und jetzt scheine ich zuerst überlegen zu sein und mehr Leute respektieren mich. Es ist seltsam. Aber Unterschied Ort sollte eine andere Kultur haben. Ich arbeite in den Silicon Valley Startups.
2.
1
@ 動靜 能量: Das klingt eher nach Sieg oder Niederlage. Der Punkt der Win-Win-Situation ist nicht, bedingungslos für alle da zu sein. Wenn Sie das Gefühl haben, jemand behandelt Sie wie Schmutz, sollten Sie offen, klar und vernünftig darauf eingehen. Es kann leicht gezeigt werden, dass, wenn sich jemand in Ihrem Team wie ein Arschloch verhält, dies der Gesamtleistung des Teams nicht zuträglich ist.
back2dos
Ist "verlieren-gewinnen" eine besondere Situation im "gewinnen-gewinnen" oder "gewinnen-verlieren" -System? Ich kann nicht viele Informationen finden ... aber beachten Sie, dass nicht alles auf der Welt Win-Win sein kann. Der Mitarbeiter, der der Direktor oder der Teamleiter sein möchte, wird es definitiv nicht zu einer Win-Win-Situation bringen. Oder die Mitarbeiter, die als Superstar auftreten oder eine Beförderung oder eine Gehaltserhöhung erhalten oder seinen "Architektentitel" schützen möchten oder nicht vor dem einjährigen Ausübungsdatum der Aktienoption entlassen werden möchten, sehen dies definitiv nicht als "win-win", wenn er dich runter bringen muss. Jetzt möchte ich noch nicht einmal in eine Situation geraten, in der es
ums Verlieren geht
Der Grund ist, wenn er mich zuerst wie Dreck behandelt, werde ich ihn wahrscheinlich etwas hassen und es wird danach keine gute Beziehung sein. Wenn ich überlegen bin und er mich ein wenig respektiert, kann die Beziehung ohne das Auf und Ab besser weitergehen. Aber es stimmt, ich fand heraus, dass man im Silikontal, wenn man "akzeptiert" und "tolerant" ist, zu einer Fußmatte wird, auf die man gerne tritt. Also auf jeden Fall angemessen zurückschlagen oder ihn wissen lassen, dass es Konsequenzen gibt.
2.
@ 動靜 能量: Bitte folge dem Link in meinem Beitrag. In Ihrem Fall sollten Sie offen für Win-Win oder No-Deal eintreten. Oft werden alle Arten von Interaktionen zu Kämpfen, wenn es sich lohnt, über die Art und Weise zu diskutieren, wie Interaktionen angegangen werden. Es ist so einfach wie: "Ich würde es vorziehen, wenn unsere Beziehung eine Zusammenarbeit statt eines Wettbewerbs ist, und ich bin bereit, entsprechende Verpflichtungen einzugehen. Wenn Sie das nicht als Option sehen, seien Sie ehrlich genug, um es mir jetzt zu sagen. Wenn Sie es versuchen um mich damit zu überlisten, werde ich deine Eier abreißen. " Obwohl Sie vielleicht das letzte Bit umformulieren möchten;)
back2dos
15

Die negativen Reaktionen sind angesichts der überdurchschnittlichen Anzahl von Programmierern, die diese Site anzieht, nicht allzu überraschend. Talentierte Menschen müssen im Allgemeinen nicht auf diese Art von Taktiken zur Absicherung durch Verschleierung zurückgreifen. Aber ich arbeitete bei einem Fortune 500-Automobilzulieferer mit einigen weniger talentierten Entwicklern, die sich kleine Lehen ausgedacht hatten, die sie eifrig bewahrten, indem sie umfangreiche Dokumentationen für die horrenden Schnittstellen erstellten, die sie entworfen hatten.

Die ganze Aufgabe eines Mannes bestand darin, den Code für ein Modul zu verwalten, das zwei völlig getrennte Subsysteme überbrückt und es den Modulen auf jedem System ermöglicht, über einen UART zu kommunizieren. Im Grunde war es die serielle Programmierung 101. Anstatt nur eine allgemeine Schnittstelle zu erstellen, die ungefähr so ​​aussah:

  int sendData (int targetModule, void * data, size_t byteCount);
  int recvData (int sourceModule, void * data, size_t maxBytes);

Er erstellte separate Opcodes für jede einzelne Nachricht , die zwei miteinander kommunizierende Module aneinander senden möchten. Das bedeutete, dass sein Modul über jede Nachricht Bescheid wissen musste und jedes Mal aktualisiert werden musste, wenn eine Nachricht hinzugefügt oder geändert wurde. Sprechen Sie über unangemessene Intimität!

Die Sache ist, dass dieser Typ ein Word-Dokument geführt hat, das alle Opcodes / Nachrichten ordentlich auflistet und es nach Bedarf sorgfältig aktualisiert. Es wurde sein ganzer Job . Einige Male in der Woche sandte er eine neue Revision an alle Menschen, die das Pech hatten, ihn auf ihrem kritischen Pfad zu haben. Und dies wurde als "professionell" angesehen, da das Management es liebte , Dokumentation zu sehen. Ein bisschen bringt mich dazu, für die Automobilindustrie zu weinen.

Ich denke, mein Punkt ist: Manchmal kann das Schreiben von Dokumentation mittelmäßige Programmierer schützen . Manager können oft nicht zwischen einem guten und einem schlechten Design unterscheiden, und viele sind gezwungen, technische Entscheidungen mit begrenzten Informationen zu treffen. Es ist unglaublich stressig für sie. Es kann sehr beruhigend sein, ein Word-Dokument mit Dutzenden ordentlich formatierten Tabellen zu sehen - auch wenn das, was darin beschrieben wird, eine grundsätzlich schlechte Idee ist.

ausweichen
quelle
Eine interessante Perspektive.
Scribu
Dies ist nicht nur auf die Automobilindustrie beschränkt. Ich denke, dass jede große Organisation, die nicht im Bereich Software / Technologie selbst tätig ist, sondern Softwareentwickler (unter anderem IT-Personal) beschäftigt, mehr oder weniger darunter leidet.
CraigTP
Ich glaube an den Wert von Dokumentation, aber Dokumentation ist nicht das, was den Job dieses Mannes schützt. Er ist nur wegen inkompetentem Management und Selbstgefälligkeit da. Es ist erstaunlich, dass niemand 90 Minuten an seinem Tag gebraucht hat, um ein Memo mit dem Titel zu schreiben: Wie man Millionen von Dollar spart UND ein besseres Produkt baut. Vielleicht ist dies einer der Gründe, warum sich Unternehmen wie GM und Chrysler in sehr tiefen, sehr teuren Löchern befanden.
Caleb
1
@Caleb: In jeder großen Organisation bleibt keine gute Tat unbestraft. Es ist viel einfacher, anderen ihr Lehen zu gestatten und ein Lehen für sich selbst zu schaffen, wenn Sie können.
Gilbert Le Blanc
3
@Caleb: Wir kommen aus dem Thema heraus, aber ich und andere wie ich haben beschlossen, die menschliche Natur nicht zu bekämpfen. Sie können in einer kleinen (<20) Informationstechnologiegruppe eine Leistung erbringen, aber sobald Sie 100 oder mehr Softwareentwickler erreicht haben, ist Ihre Organisation ein Lehen, ganz gleich, ob Sie es mögen oder nicht.
Gilbert Le Blanc
14

Austauschbar zu sein, widerspricht das nicht dem Interesse eines Entwicklers?

Ich hasse es, es dir zu brechen, aber jeder ist austauschbar. Sicher, manchmal kann es eine leichte Herausforderung sein, Sie zu ersetzen (wenn Sie erfahren und klug genug sind), aber es ist Lichtjahre von unmöglich.

Der Weg, wirklich ein wertvolles Gut für Ihren Arbeitgeber zu sein (nicht nur der aktuelle Arbeitgeber, sondern jeder Arbeitgeber), besteht darin, die Fähigkeit zu demonstrieren, Code so einfach zu schreiben, dass jeder, der den Code liest, ihn lesen und dokumentieren kann (kurze Einarbeitungszeit) den Code (jeder kann sich einen Überblick über Ihre Systeme verschaffen, ohne sich mit Code befassen zu müssen).

Tatsächlich ist es heutzutage eine schwierige Aufgabe, eine gute Codedokumentation zu haben, sodass Sie sich von anderen abheben können.

Sauberer und gut dokumentierter Code ist es auch wert, in einen Lebenslauf aufgenommen zu werden (zumindest greifbare Ergebnisse davon, dh "wir konnten nneue Entwickler mit minimalem Ramp-Up und Unterstützung aufgrund meiner Dokumentation gewinnen"), bei dem es um Hinterlist geht selbst "unersetzlich" ist nicht.

Demian Brecht
quelle
-1: Ich hasse es, es dir zu brechen, aber jeder ist austauschbar. - Ja, aber manche Leute sind schwieriger zu ersetzen als andere.
Jim G.
10

Austauschbar zu sein, widerspricht das nicht dem Interesse eines Entwicklers?

Kommt darauf an, was die Interessen dieses Entwicklers sind. Wenn Sie eine Person sind, die es in einem einzigen Job für Ihre gesamte Karriere aushalten möchte, sind Sie für ein Unternehmen, das Inkompetenz belohnt und gutes Geld verdient, absolut unverzichtbar.

Aber was passiert, wenn die Firma zusammenbricht, wahrscheinlich weil sie zu viele solche Leute eingestellt hat? Wohin gehst du als nächstes? Was ist, wenn sie dich fragen, warum du 15 Jahre im selben Job geblieben bist? Und so weiter.

Betrachten Sie es jetzt anders: Wie viele Entwickler haben ihre Arbeit verloren, weil sie Code geschrieben haben, den jeder lesen kann?

Die einzige Wahrscheinlichkeit dafür besteht darin, dass das Unternehmen in Schwierigkeiten gerät und Mitarbeiter entlassen werden. In diesem Fall sollten Sie besser aussteigen und auf die bevorstehenden Interviews gut vorbereitet sein. Außerdem ist Ihr Gewissen völlig frei - Sie hinterlassen keinen unerklärlichen Code, den Sie zu Ihrem eigenen Vorteil geschrieben haben.

Ich weiß nicht, welche Art von Person Sie sind, aber das dient meinen Interessen besser.

Persönlich denke ich, dass eine meiner größten Stärken darin besteht, meinen eigenen Job zu automatisieren. Was glaubst du, neigt ein Unternehmen dazu, zu denken, wenn ich meine eigenen Anforderungen übererfüllt habe? Denken sie "ok, wir werden ihn jetzt los" oder denken sie "warum versetzen wir ihn nicht in eine andere Rolle und lassen ihn es wieder tun"?

pdr
quelle
9

Austauschbar zu sein, widerspricht das nicht dem Interesse eines Entwicklers?

Sie haben recht, aber ich denke, Sie haben die Bedeutung von austauschbar falsch verstanden. Ich konnte 1000 Entwickler finden, die hektischen Code schreiben, undokumentiert, der sich schnell in ein nicht zu wartendes Chaos verwandeln kann.

Ein Entwickler, der nicht nur stabile Programme, sondern auch sauberen Code erstellt, eine informative Dokumentation erstellt und die Kontinuität des Projekts sicherstellt, das ist nicht nur unersetzlich, sondern auch von unschätzbarem Wert .

rahmu
quelle
7

Ich werde diese Frage aus einer anderen Perspektive angehen, da es bereits mehrere ausgezeichnete Antworten gibt.

Überlegen Sie, was passiert, wenn Sie kleine Spiele spielen, indem Sie versuchen, sich selbst "unersetzbar" zu machen, ohne dass andere Leute lernen, wie Ihr Code funktioniert. Sie bleiben im selben Job und pflegen Ihre eigenen Probleme, solange das Unternehmen Sie toleriert. Und das ist das beste Szenario, das schlechteste Szenario ist, dass andere, talentiertere und ethisch korrektere Ingenieure und Manager in Ihrem Unternehmen die Hindernisse sehen, die Ihre schlechten Praktiken dem Unternehmen auferlegen, und sie beschließen, etwas dagegen zu unternehmen: Sie zu entlassen und neu zu schreiben alles von Grund auf neu. Es wurde getan. In der Tat ist es eine ziemlich häufige Sache.

Überlegen Sie nun, was passiert, wenn Sie guten Code und gute Dokumentation schreiben. Sie erstellen eine Komponente oder ein System, das gut funktioniert, das nach einer Weile im Betrieb reibungslos funktioniert und kaum überprüft werden muss. Die Wartung ist mit geringem Aufwand verbunden. Sie können dann zu größeren und besseren Projekten übergehen und einen soliden Sieg verbuchen. Die Leute werden Sie für gute Arbeit anerkennen und Ihre Meinung respektieren. Sie haben die Möglichkeit, in der Nahrungskette aufzusteigen und aussagekräftigere Entscheidungen zu treffen, wichtigere und effektivere Arbeiten auszuführen oder Projekte auf einer höheren Ebene zu verwalten. Ihre Karriere wird sich verbessern, Sie werden befördert, Sie werden mehr Geld verdienen, Sie werden von Ihren Kollegen anerkannt und anerkannt, Sie werden mehr und mehr Erfolge von immer wichtigeren Projekten zu Ihrer Erfolgsbilanz hinzufügen.

Welche Route würdest du bevorzugen?

Keil
quelle
4

Wenn Sie die einzige Fehlerquelle sind, wird Ihr Kunde (oder Arbeitgeber) wahrscheinlich versuchen, Sie zu ersetzen. Es gibt immer einen Punkt, an dem es weniger kostspielig ist, Software zu ersetzen als zu warten, egal wie wichtig es scheint. Es gibt einen Grund, warum IT zu den auslagerungsfähigsten Berufen zählt.

Auf der anderen Seite bietet Ihnen der Austausch mehrere unschätzbare Vorteile:

  • Urlaub machen können
  • nicht auf Abruf sein
  • Freiheit zu gehen und an einem neuen und spannenden Projekt zu arbeiten
Domchi
quelle
-1: Wenn Sie die einzige Fehlerquelle sind, wird Ihr Kunde (oder Arbeitgeber) wahrscheinlich versuchen, Sie zu ersetzen. - Nach meiner Erfahrung nicht. Bitte siehe @evadeflow Antwort.
Jim G.
3

Wenn Sie nicht 5 Minuten damit verbringen, eine kurze Dokumentation zu schreiben, müssen Sie eine Stunde lang nachlesen und den Leuten erklären, wann sie Ihren Code verwenden müssen.

Noch schlimmer könnte es sein, Tage auf der Suche nach einem neuen Job zu verbringen, da Ihr Chef herausgefunden hat, dass Sie keinen wartbaren Code schreiben.

Pubby
quelle
3

Ausgezeichnete Dokumentation wird mit Refactoring / Evolutions irgendwann überholt sein, und es ist wirklich zeitaufwändig, sie auf dem neuesten Stand zu halten.

Clean Code + Unit Test> hervorragende Dokumentation

xsace
quelle
1
Einverstanden. Ich kann Ihnen nicht sagen, an wie vielen Projekten ich gearbeitet habe, an denen alle im Team (einschließlich mir) entschieden haben, dass wir diesmal "richtig machen" und Doxygen oder CppDoc verwenden, um alles zu dokumentieren und auf dem neuesten Stand zu halten. Datum. Es ist noch nicht passiert. Da die Projektpläne so sind, wie sie sind, würden die Dokumentfolgen in Bezug auf den Code unweigerlich nicht mehr synchron sein, und unsere Testabdeckung wäre minimal oder nicht vorhanden. Jetzt neige ich dazu, Darts auf jeden zu starren, der die Verwendung von Sauerstoff vorschlägt, und sie zu bitten, mir zuerst seine Tests zu zeigen. Dokumentation für Code ohne Tests ist nur eine Packung Lügen.
Evadeflow
Dies ist eine Art Nebensache - gute Unit-Tests sind Dokumentation. Sie befürworten nur eine bestimmte Art von sauberem, dokumentiertem Code und sagen nicht, dass dies nicht getan werden sollte.
Cascabel
2

Die Antwort auf Ihre Frage lautet "Ja". Ja, Sie sollten eine gute Dokumentation und sauberen Code schreiben. Wenn man absichtlich etwas anderes tut, zeigt sich ein Mangel an Integrität, der, obwohl er in der Geschäftswelt zunehmend vorherrscht, nicht plötzlich eine "gute" Sache ist.

Niemand ist unersetzlich. Menschen, die eine Situation herstellen, in der sie glauben, sie seien geneigt, den schwierigen Weg herauszufinden, den sie nicht gehen. Das Herstellen einer Co-Abhängigkeit für sich selbst ist kontraproduktiv, da es Sie und nicht nur Ihren Arbeitgeber einschränkt.

Versuchung
quelle
2

Eines der Hauptziele von Softwareentwicklungsunternehmen ist die Steigerung ihres Busfaktors

Falsche Prämisse. Die Hauptziele eines Softwareentwicklungsunternehmens (jedenfalls jedes, bei dem ich gearbeitet habe) sind es, die bestmögliche Software zu entwickeln und Geld zu verdienen, nicht unbedingt in dieser Reihenfolge. Die Reduzierung des "Busfaktors" ist nur eine Möglichkeit, um Geldverluste zu vermeiden.

Gesetz 11 Lerne, Menschen von dir abhängig zu machen.

Was bedeutet das für dich?

Möchten Sie, dass sich die Menschen auf Sie verlassen, weil Sie sie so untergraben haben, dass sie nur mit Ihrer Hilfe vorankommen können? Oder möchten Sie, dass sich die Menschen auf Sie verlassen, weil Sie intelligent und aufschlussreich, zuverlässig, vertrauenswürdig und in der Lage sind, anderen zu helfen, ihre Arbeit auch besser zu machen? Möchten Sie, dass Ihre Kollegen ohne Ihre Hilfe schlecht aussehen, oder möchten Sie, dass sie Sie dafür schätzen, dass sie gut aussehen?

Es ist dein Anruf.

Caleb
quelle
1

(unter der Annahme von Produktionscode)

Ich neige dazu, ein bisschen weiter zu gehen. Ich habe darüber geschrieben, Programme "idiotensicher" zu machen, aber ich qualifiziere das nicht immer: Ich schreibe viel Code, den andere Leute nicht sehen oder mit dem sie nicht arbeiten werden (zumindest ist dies die Erwartung, wenn es geschrieben wird). ichIch bin der Idiot, vor dem ich mich in diesem Fall zu verteidigen versuche. Es ist eine gute Sache, wenn Ihr Programm Probleme für Sie erkennt und das Problem so stark vereinfacht wurde, dass es offensichtlich ist, dass ein Fehler vorliegt und dessen Ursache. Die Wahrheit ist, dass Implementierungsdetails offensichtlich sind, wenn Sie ein Programm schreiben (es sei denn, Sie implementieren es vorzeitig), aber sie sollten für Clients abstrahiert und fehlerresistent sein (selbst wenn eine Modullokalität vorhanden ist). Der Grund dafür ist, dass Programme sehr komplex werden. Manchmal kann man Probleme trennen, aber nicht die ganze Zeit. Wenn Sie Ihre Komponenten sehr streng, einfach, gut gekapselt und idiotensicher halten, sind sie in der Regel gut skalierbar und die meisten Fehler werden vor dem Versand erkannt. Es ist einfacher, die Programme wiederzuverwenden, und Sie haben mehr Vertrauen und eine einfachere Zeit, die Programme wiederzuverwenden. Diese komplexen Programme, die Sie schreiben, werden erst nach einiger Zeit komplexer (auch für Sie). Wenn Sie es in 6 Monaten lesen, kann das Verstehen und Debuggen im Vergleich zur idiotensicheren Version absurd lange dauern. Wenn eine Komponente eine Unterbrechungsänderung einführt, kann sie ansonsten für eine lange Zeit unentdeckt bleiben. Programme sind komplex; Sie können dieser Realität nicht entkommen, aber Sie können sie idiotensicher machen, was Ihr Leben viel einfacher macht, wenn etwas schief geht oder wenn es wiederverwendet oder verändert werden muss. Daher bedeutet der idiotensichere Ansatz, dass Ihre Software auch von Ihren Junioren oder neueren Mitarbeitern im Team verstanden, wiederverwendet oder gewartet werden kann (nicht nur von jemandem, der so gut / erfahren ist wie Sie). Ersatz ist ein besonderes Anliegen: Wenn die Leute gerne mit Ihren Programmen arbeiten, leisten Sie gute Arbeit. Sorgen Sie sich nicht um Ersatz. Sicher, ich könnte mir Szenarien einfallen lassen, in denen unverständliche Programme Ihren Job retten könnten, aber das Schreiben eines guten Programms, das andere verwenden und warten können, ist eindeutig das geringere Übel (siehe die Resopns der anderen). Wenn ich mich dabei ertappe, etwas zu schreiben, das nicht idiotensicher ist, versuche ich, das zu beheben.

Abgesehen von dem Szenario, in dem Sie einige Unterlagen für sich selbst benötigen, um ein Projekt nach 6 Monaten Pause fortzusetzen, scheint hier ein klarer Interessenkonflikt zwischen dem Entwickler und dem Softwareunternehmen zu bestehen.

Sie haben wirklich keine Ahnung, was Sie manchmal gedacht haben, als Sie inaktive Implementierungen erneut durchgesehen haben. Wenn Sie wirklich erfahren sind, ist das Problem einfacher, weil Sie sich mehr auf etablierte Methoden oder Ansätze verlassen können, die Sie verwenden. Dies setzt jedoch voraus, dass diese Methoden unveränderlich sind. Auch wenn die Dokumentation nachlässt, müssen Sie in Ihren Implementierungen immer noch defensiv sein (z. B. wissen Sie besser, als in diesem Szenario NULL zu übergeben - testen Sie diese Bedingung).

Als Programmierer sollten Sie also wirklich hervorragende Dokumentationen und leicht lesbaren Code für alle schreiben. oder sollten Sie Code und Dokumentation so schreiben, dass sie die Aufgabe erfüllen und Sie sie selbst verstehen können, aber eine andere Person hat möglicherweise Probleme, sie zu verstehen?

Ich empfehle den idiotensicheren Ansatz, der noch klarer und fehlerresistenter ist als der Busfaktor-Ansatz. Schreiben Sie Ihre Programme und Dokumentationen so, dass sie von jemandem außerhalb des Projekts leicht verstanden werden - es ist auch gut für Sie. Dadurch erhöhen Sie Ihren Wert für Ihr Unternehmen und Ihr Team, sie möchten Sie nicht ersetzen.

Justin
quelle
1

Sie haben das Spiel grundlegend falsch verstanden. Das Spiel besteht nicht darin, weiterhin die alten Dinge zu tun, die Sie zuvor getan haben, sondern für den gesamten Code verantwortlich zu sein, den Sie geschrieben haben, weil ihn sonst niemand bekommt. Das Spiel besteht darin, ein Projekt abzuschließen und mit dem nächsten fortzufahren. Dabei bleibt Code übrig, den andere in Ihrer Abwesenheit leicht verstehen und bearbeiten können, sodass Sie neue Dinge tun und mehr und andere Aufgaben übernehmen können. Ihre Prämisse funktioniert nur, wenn Sie glücklich sind, immer wieder das Gleiche zu tun, ohne die Chance zu haben, etwas zu lernen oder sich zu verbessern.

Tvanfosson
quelle
1

Ich werde auch darauf hinweisen, dass Sie, wenn Sie nicht die Gelegenheit haben, sich diesen Code sehr oft anzuschauen, in sechs Monaten Probleme haben werden, ihn herauszufinden, wenn Sie ihn absichtlich verschleiern.

HLGEM
quelle
0

Ich dokumentiere den kleinen Code, den ich schreibe, nicht damit andere ihn lesen können, sondern damit ich ihn in 3 Monaten lesen kann! Es geht darum, die Wartung zu vereinfachen. Wenn Sie für den Code verantwortlich sind, den Sie geschrieben haben, und Sie keine Fehler beheben können, die später auftauchen, möchten Sie, dass er gut dokumentiert ist ... Es spielt keine Rolle, wie ersetzbar Sie sind, wenn Sie nicht in der Lage sind um deinen Job zu machen!

Seamus
quelle
-1: Warum streben Sie keinen selbstdokumentierenden Code an? Im Gegensatz zu bestenfalls überflüssiger Dokumentation und im schlimmsten Fall zu Dokumentation, die sehr schnell veraltet sein wird? Bitte siehe @xsAce Antwort.
Jim G.
0

Jeder "unersetzliche" Computerfachmann, mit dem ich das Pech hatte, zu interagieren, wurde ersetzt, zum großen Teil, weil sie versuchten, die Ressourcen ihrer Arbeitgeber als Geiseln zu nehmen. Wenn mir Leute berichten, dass ihre Zeit zu wertvoll ist, um Dokumente zu "verschwenden", ersetze ich sie so schnell wie möglich.

Es scheint, dass wenn ein angehender Mitarbeiter die 48 Gesetze der Macht als ethisch oder moralisch akzeptabel ansieht, es Ihnen ohne sie besser geht.

John Percival Hackworth
quelle
-1: Wenn mir Leute berichten, dass ihre Zeit zu wertvoll ist, um Dokumente zu "verschwenden", ersetze ich sie so schnell wie möglich.
Jim G.
@ Jim G: Schön. Ich gehe davon aus, dass Sie Ihre Zeit als zu wertvoll erachten, um Dokumente zu verschwenden ...
John Percival Hackworth
0

Wenn Sie WIRKLICH unersetzlich sein möchten (was Sie vielleicht nach dem Lesen aller Antworten noch einmal überdenken möchten ...) - warum sollten Sie aufhören, den Code nicht zu dokumentieren?

Es gibt eine wirklich hervorragende Anleitung zum Schreiben von nicht wartbarem Code, die Sie unbedingt lesen sollten: http://thc.org/root/phun/unmaintain.html

Genießen! (Ich habe ganz sicher ...)

yonix
quelle
Es gibt auch "Refuctoring" :)
CraigTP