Kampf gegen technische Schulden als "niedrigster Entwickler"?

Angenommen, Sie arbeiten für ein Unternehmen und entwickeln Software für dieses Unternehmen. Sie haben keine Ahnung von dem großen Bild oder vielleicht geringfügig. Was Sie haben, sind Aufgaben, die Ihnen über das Issue-Tracking-System zugewiesen werden. Sie erhalten Aufgaben, Sie lassen sie so arbeiten, wie sie von der Aufgabe beschrieben werden, und Sie senden sie zurück. Wie das Hinzufügen von 2 ganzen Zahlen:

function add(a,b){return a + b;}

Im weiteren Verlauf des Projekts stellen Sie jedoch fest, dass Sie mit addzunehmender Komplexität feststellen, dass eine Architektur erforderlich sein sollte, die mehr als nur eine Funktion ist, die Parameter hinzufügt und einen Wert zurückgibt. Das wusstest du aber nicht. Zunächst einmal war alles, was sie brauchten, so einfach add. Sie haben nicht erwartet, dass add so komplex wird.

Das Projekt wird mit weiteren Funktionen fortgesetzt, die Sie ursprünglich nicht erwartet hatten. Und am Ende häufen Sie Hacks und Funktionen immer wieder an, um zu vermeiden, dass der vorhandene Code beschädigt oder neu geschrieben wird.

Wie gehen Sie mit diesen Situationen um? Wie bekämpfen Sie technische Schulden als "niedrigster Entwickler"?

Klärung:

• Sie sind der "Implementierer", der niedrigste in der Hierarchie.

• Sie sehen das Problem, haben aber kein Mitspracherecht.

• Ich bezahle nicht die technische Verschuldung oder suche nach Werkzeugen.

• Zum dritten "Duplikat"

  • Refactoring & Rewrite - Sie sind an Ihre Aufgaben gebunden. Sie werden nicht dafür bezahlt, etwas extra zu tun.
  • Architekturübersicht - Sie kennen das Gesamtsystem, aber keine Vorstellung von der Architektur.
  • Code Freeze - Nicht Ihr Anruf. Sie sind kein Management.
  • Modularisierung - Keine Ahnung von Architektur. Module ändern sich, wenn sich die Anforderungen ändern.
  • Automatisierte Tests - Keine vorhanden.

Jedes Mal, wenn Sie so etwas bemerken, geben Sie ein neues Ticket in Ihr Issue-Tracking-System ein.

Machen Sie es sich zur Gewohnheit, Issue Tracker als primäres Werkzeug für die Kommunikation solcher Dinge zu verwenden, da es von dort aus für Ihre erfahrenen Kollegen / Lead / Manager / Mitarbeiter, die für die Nachverfolgung der Probleme in Ihrem Projekt verantwortlich sind, einfach ist, diese auszuwählen, zu bewerten und Prioritäten zu setzen .

Verwenden Sie das richtige Werkzeug für den Job. Ich mache es immer und empfehle nachdrücklich , dasselbe zu tun.

Als Beispiel ist hier ein Ticket, das ich vor ungefähr einem Monat erstellt habe. Nach Abschluss eines bestimmten Features stellte ich fest, dass der Code wesentlich komplizierter wurde als zuvor, aber ich kann diesen Fehler nicht innerhalb der für die Implementierung des Features angegebenen Frist beheben.

(Die Namen der im realen Tracker verwendeten Funktionen, Tickets und Codes sind verdeckt, der Text wird jedoch unverändert kopiert.)

Zusammenfassung: Vereinfachen Sie das Design mitParticularPieceOfCode

Beschreibung:
Im Laufe der Implementierung gemäß TICKET-12345 ist Code, der die Verwendung von enthält ParticularPieceOfCode, etwas kompliziert geworden und war ziemlich schwer zu lesen, zu verstehen und zu warten (siehe Beispielcode-Snippet unten).

Finden Sie einen Weg, um es zu vereinfachen.

Ein Beispiel für Code, der für eine Neugestaltung wünschenswert wäre, finden Sie in ClassName#methodName:

<a piece of code like one behind the right door here:>

FWIW mein Rat gilt unabhängig davon, welches "Level" Sie sind.

Ich benutze es auf Ihrer aktuellen ("niedrigsten") Stufe und ich benutze es jetzt, da meine Stufe ziemlich weit von "niedrigsten" entfernt ist und ich zufriedenstellend "sagen" kann, wie Sie es nennen, und ich werde es verwenden immer egal was.

Denken Sie nur daran, kein Level, egal wie viel Autorität Sie haben, es kann einfach keinen besseren Weg geben.

Wenn Sie "sagen", hey, wir haben ein Problem , es ist nur Luft rasseln. Und selbst wenn Ihr Chef / Ihre Führungskraft zustimmt und sagt, dass Sie Recht haben, haben wir ein Problem , das nichts ändert - es rasselt nur noch einmal in der Luft, und es kann nichts anderes sein.

• ^{Sie denken vielleicht, dass es besser wäre, Ihre Meinung schriftlich (z. B. per E-Mail) mitzuteilen, aber wenn Sie darüber nachdenken, ist dies nicht der Fall. Wenn Ihr Projekt eine erhebliche E-Mail-Aktivität aufweist, geht das Geschriebene verloren und wird einen Monat später lange vergessen.}

Verwenden Sie das richtige Werkzeug für den Job. Issue Tracker ist genau das richtige Werkzeug für den von Ihnen beschriebenen Job .

Sie bemerken das Problem, Sie geben es in ein System ein, das für die Verfolgung dieser Probleme entwickelt wurde, und es kümmert sich bestmöglich um den Rest - einfach, weil es dafür entwickelt wurde :

Computer - Software - Paket , das und unterhält Listen verwaltet Themen , wie von einer Organisation benötigt ... häufig verwendete ... zu erstellen, zu aktualisieren und Entschlossenheit berichtet Kundenprobleme oder sogar Probleme berichtet von dieser Organisation weitere Mitarbeiter ... Ein Problem - Tracking System ähnelt einem " Bugtracker ", und oft verkauft ein Softwareunternehmen beides, und einige Bugtracker können als Fehlerverfolgungssystem verwendet werden, und umgekehrt. Die konsequente Verwendung eines Issue- oder Bug-Tracking-Systems gilt als eines der "Kennzeichen eines guten Software-Teams" ¹ ...

Was auch immer Sie sonst noch für die Kommunikation auswählen möchten, ein Ticket im Tracker zu haben, macht es Ihnen nur einfacher.

Auch wenn Sie es vorziehen, in der Luft zu rasseln : "Ich möchte über TICKET-54321 sprechen ..." ist ein soliderer Ausgangspunkt als "Hören Sie, ich möchte über einen Code sprechen, mit dem ich mich vor einiger Zeit befasst habe ... "Und Sie können die Verweise auf das Ticket sicher per Post weitergeben: Auch wenn die Post verloren geht, bleibt das Problem im Tracker mit allen Details, über die Sie berichten wollten, bestehen.

Was mich an Ihrem Szenario schlecht fühlt, ist genau das, was Sie in der Überschrift und mehrfach im Fragentext geschrieben haben:

Sie sind der niedrigste Entwickler in der Kette

Warum ist dieser Punkt so wichtig? Zunächst einmal und rein technisch gesehen haben Sie sicherlich recht. Sie werden als ein sogenannter "Implementierer" von Dingen eingestellt, eine Arbeiterin, die auf die gegebenen Befehle reagiert.

Aber selbst wenn Sie hinsichtlich des Rangs der niedrigste Entwickler sind, ist dies immer noch nicht ganz richtig. Der Schlüssel hierbei ist zu erkennen, dass Sie sich nur als den niedrigsten Entwickler wahrnehmen . Haben Sie jemals versucht, diese Selbstwahrnehmung zu überwinden und Verantwortung für etwas zu übernehmen ?

Nehmen! Warten Sie nicht, bis Sie jemand zur Verantwortung zieht.

• Sie sehen das Problem, haben aber kein Mitspracherecht.
• Ich bezahle nicht die technische Verschuldung oder suche nach Werkzeugen.
• Sie sind an Ihre Aufgaben gebunden. Sie werden nicht dafür bezahlt, etwas extra zu tun.
• Nicht dein Anruf. Sie sind kein Management.

Typischerweise ist es genau umgekehrt: Sie werden mehr bezahlt und Ihre Meinung wird mehr geachtet, wenn Sie zeigen, dass Sie das Geld wert sind . Es ist "do before have", nicht umgekehrt.

Von den Mitarbeitern in meinem Team erwarte ich genau Folgendes: Verantwortungsbewusstsein für das Projekt oder Produkt, das wir aufbauen möchten, und für alle damit verbundenen Prozesse. Wenn mich jemand in meinem Team beeindruckt, indem er Verantwortung übernimmt, z. B. Verbesserungen vorschlägt oder sogar anfängt, Dinge selbst zu verbessern, werden diese Menschen befördert.

Um es anders auszudrücken: Niemand befördert Arbeitsbienen, Menschen, die passiv auf die ihnen übertragenen Aufgaben warten, es fehlt ihnen der kleinste Anstoß zur Initiative, " weil sie nicht dafür bezahlt werden ", und sie jammern schließlich, dass sie nie eine Chance hatten.

Natürlich hängt all dies wieder von der Kultur Ihres Unternehmens ab, auf die sich Joel in den von Arthur verknüpften "Two Stories" bezieht. Wenn die Unternehmensleiter wirklich so dumm sind, ihre eigenen Mitarbeiter daran zu hindern, Fortschritte zu erzielen, ist die Fluktuationsrate wahrscheinlich bereits sehr hoch, und es kann an der Zeit sein, daraus Schlussfolgerungen zu ziehen. Ist dies jedoch nicht der Fall, liegt das eigentliche Problem möglicherweise bei Ihnen.

Du bist ein Profi. Ihr Arbeitgeber hat Sie engagiert, um professionell zu sein. Behandeln Sie Ihre Bedenken also genauso, wie Sie möchten, dass Fachleute, die Sie einstellen, ihre berufliche Meinung vertreten . Insbesondere erwarten Sie von anderen Fachleuten notwendige Optimierungen und Korrekturen auf dem Weg, vorausgesetzt, diese Optimierungen erhöhen nicht unerwartet die Kosten.

Nehmen Sie zum Beispiel an, Sie bringen Ihr Auto zu einem Mechaniker, um eine Lampe ersetzen zu lassen. Der Mechaniker bemerkt vier Dinge:

1. Der Draht zur Lampe ist ausgefranst und gefährlich. Es kann jedoch gekürzt werden, ohne die Kosten merklich zu erhöhen. Sie würden erwarten, dass er ein paar Minuten braucht, um den Draht abzuschneiden, möglicherweise ohne es überhaupt zu bemerken.
2. Ein Bolzen ist lose. Es hat nichts damit zu tun, er hat es nur zufällig gesehen. Es ist 20 Sekunden seiner Zeit, den notwendigen Fahrer zu ergreifen und ihn festzuziehen; Man würde also erwarten, dass er es tut.
3. Das Gehäuse der Lampe weist Risse auf, wodurch die Lampe klappert. Es ist teuer zu ersetzen. Und es ist nicht wesentlich. Also ruft er Sie an, um danach zu fragen - wenn Sie "nein" sagen, gibt er eine schriftliche Empfehlung für Ihre Besuchszusammenfassung ab.
4. Unter dem Auto befindet sich eine angemessene Menge Bremsflüssigkeit. Er sollte und kann sogar von einem Fachmann verlangt werden, Sie daran zu hindern , das Auto zu benutzen, bis Sie jemandem erlauben, das Leck zu reparieren.

Jedes dieser Szenarien, und ich bin mir sicher, andere, weisen Parallelen in der Softwareentwicklung auf - insbesondere, wenn Sie sich selbst als Profi jeglichen Niveaus betrachten . Als Profi besteht Ihre Aufgabe, mit sehr wenigen Ausnahmen, darin, das Endziel zu erreichen, das Produkt gemäß Ihrem fachlichen Verständnis auf eine bestimmte Art und Weise zu verbessern .

1. Wenn der Fix trivial ist, unabhängig davon, ob er in Beziehung steht oder nicht, führen Sie den Fix durch.
2. Wenn der Fix nicht trivial und unnötig ist, geben Sie eine formelle Empfehlung unter Verwendung des von Ihnen vereinbarten formellen Kommunikations- / Problemverfolgungsmechanismus ab.
3. Wenn festgestellt werden kann, dass das Update zur Ausführung der Hauptaufgabe erforderlich ist, die Kosten jedoch unerwartet erhöht, teilen Sie die Bereichsänderung mit.
4. Wenn das festgestellte Problem eine ernsthafte Bedrohung für den Erfolg des Projekts darstellt, machen Sie dies deutlich. Formal. Wenn ethische Bedenken bestehen, dass das Problem nicht behoben werden kann (z. B. bei Gesundheits-, Notfall- oder Transportsystemen), bestehen Sie darauf, das Problem zu beheben, bevor das Produkt versendet wird (benachrichtigen Sie die Medien oder Behörden, falls dies ethisch erforderlich ist).

Sie tun dies auf die gleiche Weise, wie ein Angestellter in einer Anwaltskanzlei gegen unethisches Verhalten vorgeht, ein Fast-Food-Arbeiter gegen unhygienisches Verhalten oder ein Parkaufsichtsbeamter gegen Korruption bei der Polizei.

1. Sei ein gutes Beispiel. Erstellen Sie, soweit möglich, sauberen und vernünftigen Code. Wenn Sie die Wahl haben, wählen Sie diejenige, die Ihren Anforderungen mit weniger Nachteilen entspricht. (Seien Sie sich bewusst, dass technische Schulden nicht anders sind als Hypothekenschulden - es ist nicht unbedingt eine schlechte Sache, sie zu haben.)
2. Teilen Sie Ihre Bedenken mit . Sie sollten jemanden haben, entweder einen Teamleiter oder einen Kunden oder Architekten, der die eigentliche Verantwortung für die Verwaltung der technischen Schulden und die Zuweisung der Ressourcen Ihres Unternehmens trägt. Wenn Sie etwas sehen, von dem Sie glauben, dass es schlecht ist, teilen Sie ihnen Ihre Besorgnis mit. Schreiben Sie es schriftlich (dh per E-Mail), wenn Sie nicht sicher sind, dass sie Ihre Eingabe verstehen, beantworten und anerkennen.
3. Stress nicht. Technische Schulden verursachen selten das Scheitern eines Unternehmens am Arbeitsplatz. Solange Sie Ihre Bedenken mitgeteilt haben und Ihre Arbeit erledigen, sind Architekturprobleme wie technische Schulden buchstäblich nicht Ihr Problem. Ja, sie mögen Sie betreffen, aber sie sind nicht mehr Ihre Sorge, als dass die Wiederwahl eines Sheriffs die Sorge eines jungen Polizeibeamten ist.

addNehmen Sie sich in dem von Ihnen bereitgestellten Beispiel mit einer Funktion , bei der ein vollständiger Funktionsschleicher aufgetreten ist, ein paar Minuten Zeit, um zu skizzieren, was die Funktion verbessern würde. Senden Sie das an denjenigen, für dessen Implementierung Sie eine Genehmigung benötigen, und fahren Sie fort.

Angenommen, Ihr Unternehmen wird von äußerst kompetenten Mitarbeitern geführt und ist ordnungsgemäß strukturiert. Entweder wird Ihr Anliegen an den richtigen Systementwickler weitergeleitet, um eine Entscheidung zu treffen, oder es wird Ihnen Spielraum für die Umsetzung Ihres Vorschlags eingeräumt. Als Nachwuchsentwickler würde ich mir mehr Gedanken darüber machen, wie Ihr Unternehmen funktioniert, als über technische Schulden - und wenn Sie erstere kennen, sollte es naheliegend sein, mit letzteren umzugehen.

Ich habe noch nie von einer Organisation gehört, die nicht wollte, dass ihre Mitarbeiter daran teilnehmen. Sie sagen, dass Sie nur für die Ausführung der Aufgaben bezahlt werden. Ich bezweifle aufrichtig, dass Sie die richtigen Aufgaben vor Augen haben. Weil du dafür bezahlt wirst, gute Software zu schreiben.

Übernehmen Sie diese Verantwortung. Lehnen Sie das Hinzufügen von Funktionen ab, wenn Sie die Basis nicht unterstützen können. Beraten Sie den Kunden mit Ihrem Fachwissen. Treten Sie jetzt auf die Bremse, bevor es zu spät ist und Sie das gesamte Projekt wegwerfen müssen, da es nicht mehr gewartet werden kann.