Wann würden Sie einige Ihrer Prinzipien der Softwareentwicklung fallen lassen, um mehr Geld zu verdienen?

Ich würde diese Frage gerne nach draußen werfen, um interessant zu sehen, wo sich das Medium befindet.

Ich gebe zu, dass ich in den letzten 12 Monaten TDD und viele der agilen Werte in der Softwareentwicklung aufgegriffen habe. Ich war so überwältigt, wie viel besser meine Softwareentwicklung wurde, dass ich sie nie aus dem Prinzip fallen lassen würde. Bis ... mir eine vertragliche Rolle angeboten wurde, durch die sich mein Jahresgehalt verdoppelte.

Die Firma, der ich beigetreten bin, folgte keiner bestimmten Methodik, das Team hatte nichts von Code-Gerüchen, SOLID usw. gehört, und ich würde mit Sicherheit nicht davonkommen, Zeit mit TDD zu verbringen, wenn das Team noch nicht einmal davongekommen wäre Unit-Tests in der Praxis gesehen. Bin ich ausverkauft? Nein, nicht vollständig ... Code wird immer "sauber" geschrieben (gemäß den Lehren von Onkel Bob) und die Grundsätze von SOLID werden immer auf den Code angewendet, den ich schreibe, wenn sie benötigt werden. Das Testen wurde für mich eingestellt, das Unternehmen konnte es sich nicht leisten, ein solches Unbekanntes an das Team weitergeben zu lassen, das ehrlich gesagt, auch wenn ich Test-Frameworks erstellt habe, diese das Test-Framework niemals korrekt verwenden / warten würden.

Wenn Sie das als Beispiel nehmen, welchen Punkt würden Sie sagen, sollte ein Entwickler niemals seine handwerklichen Prinzipien fallen lassen, um Geld oder andere Vorteile für ihn persönlich zu erzielen? Ich verstehe, dass dies eine sehr persönliche Meinung darüber sein kann, wie sehr man sich um seine eigenen Bedürfnisse, die geschäftlichen Bedürfnisse und um des Handwerks willen etc. kümmert. Man kann jedoch in Betracht ziehen, dass beispielsweise Tests fallengelassen werden können, wenn das Unternehmen entscheidet, dass sie lieber eine haben Testteam, anstatt Unit-Tests in der Programmierung zu verstehen, wäre das etwas, für das Sie sich vergeben könnten, wie ich es getan habe? Angesichts der Tatsache, dass es etwas gibt, das Sie fallen lassen würden, sollten in der Regel die gleichen Kosten im Geschäft anfallen, die das wettmachen, was Sie fallen lassen - hoffentlich, es sei denn, Sie sind ziemlich darauf bedacht, Ihre eigenen Taschen zu füllen und nicht in der Gemeinschaft oder im sozialen Bereich zusammenzuarbeiten. ).

Verdoppeln Sie Ihr Geld, gehen Sie zurück zu RAD? Oder gehen Sie weiter und suchen Sie jemanden, der Agile macht, und schauen Sie niemals zurück ...

Seit ich vor mehr als 10 Jahren von Unit Tests abhängig war, war ich an den meisten Arbeitsplätzen der erste, der davon gehört hat. Trotzdem schrieb ich meine kleinen Komponententests, wann immer ich konnte, und schätzte die Kosten der Komponententests in meine Aufgaben ein. Wann immer jemand nach meinen Codierungsgewohnheiten fragte, erzählte ich, was ich tat und warum es bei mir funktionierte. Normalerweise waren zumindest einige der Leute interessiert, und irgendwann musste ich Präsentationen zum Thema halten und die Leute betreuen, um ihre ersten Unit-Tests zu schreiben.

Sie müssen nicht gleich am ersten Tag an Ihrem neuen Arbeitsplatz die Leute von der Agilität überzeugen. Befolgen Sie einfach die Prinzipien in Ihrer eigenen Arbeit, so oft Sie können. Wenn Sie es gut machen, liefern Sie besseren Code. Wenn Ihre Mitarbeiter und / oder das Management es bemerken, werden Sie gefragt, wie Sie es tun. Dann kannst du es ihnen sagen.

Aktualisieren

Die meisten erfahrenen Entwickler (und Manager) haben gesehen, wie Trends und Moden kamen und gingen, sodass sie sich nicht über die neuesten Schlagworte aufregen. Wenn Sie jedoch nachweisen können , dass ein bestimmter Ansatz (Werkzeug, Denkweise) tatsächlich in der Praxis funktioniert , werden diejenigen, die sich für ihr Handwerk interessieren, mit ziemlicher Sicherheit aufhorchen und zuhören. Aber wenn Sie keine solchen Leute in Ihrem Team haben, ist es vielleicht an der Zeit, nach einem besseren Ort zu suchen ...

Hier sollten meiner Meinung nach alle Entwickler auch ein wenig über Projektmanagement Bescheid wissen. Alles ist ein Kompromiss zwischen Zeit, Geld und Ressourcen. Betrachten Sie sich als die Ressource.

In meinen 12 Jahren als Programmierer glaube ich nicht, dass ich jemals ein Projekt abgeschlossen habe und es als erledigt oder in meinem Kopf abgeschlossen empfunden habe. Es gab immer etwas, von dem ich wünschte, ich hätte es besser oder sauberer machen können. Es hat sehr lange gedauert, bis mir klar wurde, dass dies auf diese Kompromisse zurückzuführen ist.

Wenn Sie also darüber nachdenken, einen Job zu wechseln, nur weil die Methoden nicht vorhanden sind, würde ich noch einmal darüber nachdenken, ob ich Sie wäre. Diese Kompromisse sind konstant und gelten für alle Softwareentwickler. Selbst die engagiertesten Spieleentwickler wünschen sich, sie könnten einige Dinge noch einmal machen oder eine andere Methode anwenden, wenn sie eine Chance hätten.

Ich würde sagen, Sie sollten sich Ihre agilen Entwicklungspraktiken ansehen und erkennen, dass Sie dies auch auf Mikroebene tun können. Sicher, Ihre Teamkollegen sind möglicherweise in la-la-land unterwegs und tun, was sie wollen, aber Ihre persönliche Zufriedenheit wird größer sein und Sie werden auf lange Sicht mit Sicherheit besseren Code generieren als sie. Wenn der Manager dann kommt und fragt, warum Ihr Code so viel besser ist, haben Sie die Chance, das Team zu konvertieren :)

Aber wenn du die Leute oder den Job nicht magst, dann weißt du die Antwort schon. Aber ich bezweifle sehr, dass irgendjemand in den Raum kommt und Ihnen sagt, dass Sie beim Codieren keine agilen Entwicklungsprinzipien anwenden sollen, wenn sie schreien.

Lassen Sie niemals etwas fallen, das Sie auf lange Sicht unglücklich macht. Natürlich können Sie im Niemandsland beginnen und versuchen, das Team in Ihre Richtung zu bewegen. Wenn Sie bereit sind, sich die Mühe zu machen und der Job es wert ist, kann dies sogar eine interessante Herausforderung sein.

Aber wenn Sie genau die Dinge verlassen müssen, die die Freude am Codieren (oder irgendeinen Job in dieser Angelegenheit) bewahren, ist meine Erfahrung, dass Sie früher oder später weggehen werden. Ich habe gelernt, dass Frustration niemals unterschätzt werden sollte ...

Die Leute in Ihrem letzten Job wussten bereits von TDD, SOLID usw. Das ist großartig. Ich bin sicher, Sie haben es genossen, dort zu arbeiten und viel gelernt. Jetzt haben Sie die Möglichkeit , diese Konzepte zu vermitteln (und gleichzeitig viel Geld zu verdienen). Nach meiner Erfahrung hat es mir immer geholfen, jemand anderem ein Konzept beizubringen, um es selbst noch detaillierter zu lernen. Seien Sie einfach geduldig und treiben Sie Ihre Konzepte nacheinander voran. Wenn Sie frustriert sind, gehen Sie nach Hause und zählen Sie Ihr Geld. Oder suchen Sie Unterstützung bei SE.

Ich muss zugeben, dass ich in dieser Hinsicht ein bisschen verrückt bin. Was auch immer der Kunde als die richtige Methodik für das Projekt ansieht, ist für mich als Freiberufler in Ordnung. Das bedeutet nicht, dass mir nur Geld am Herzen liegt, aber die Entscheidung darüber, was ich tun und was ich weglassen soll, liegt beim Kunden. Ich würde jedoch schlechte Arbeitsbedingungen (laute, lange Stunden usw.) nicht akzeptieren.

Ich möchte einen ehemaligen Kollegen zitieren. Er sagte, wann immer er einen Job oder ein Teilzeitprojekt sucht, gibt es drei Kriterien, die das Projekt erfüllen muss:

• Es muss Spaß machen, damit zu arbeiten
• Es muss für Ihre Kompetenzentwicklung von Vorteil sein (nicht sicher, ob dies der richtige Weg ist, es auszudrücken)
• Es sollte gut bezahlen

Während ich Ihre Frage lese, erfüllt dieses Projekt nur die letzten Kriterien.

Da Sie TDD (genau wie ich) sehr gemocht haben, werden Sie sich vermutlich täglich umsehen und wünschen, alle Ihre Mitarbeiter hätten die gleiche Einsicht wie Sie. Die ersten Kriterien wären also wahrscheinlich nicht erfüllt.

Zweitens: Wenn Sie TDD-Projekte verfolgen und vielleicht mehr Erfahrung mit dem Aufbau agiler Teams sammeln möchten, hilft Ihnen die Arbeit an diesem Projekt nicht, diese Fähigkeiten zu stärken. Daher wird wahrscheinlich auch die zweite nicht erfüllt.

Wenn ich also persönlich in Ihrer Position wäre und nicht in der Lage wäre, TDD in das Unternehmen einzuführen, würde ich woanders hinschauen.

Noch nie.

Das Leben ist zu kurz (besonders wenn man älter wird), um Dinge zu tun, die man hassen wird.

Natürlich wird es dadurch schwieriger, den Arbeitsplatz zu wechseln, und es gibt weniger Arbeitsplätze.

Aber zumindest riecht nur der alte Code schlecht. (Und ich habe Autonomie, so dass wir vernünftige Dinge tun können, wie eine Woche damit zu verbringen, Compiler-Warnungen aus der alten Codebasis zu entfernen ....)

Kurz gesagt, die Entwicklungsmethodik gehört nicht zu Ihnen. Es ist keine Relgion und es ist nicht wer du bist. Es ist ein Werkzeug. Tun Sie, was Ihnen gesagt wird, wie Ihnen gesagt wird, und verdienen Sie das zusätzliche Geld. Tausende von Systemen wurden entwickelt und laufen heute ohne TDD, Code Smell usw. In wenigen Jahren wird niemand mehr wissen, was diese Begriffe bedeuten, da Methoden häufiger ein- und ausgehen als ein Stadtbus. Arbeite hart, wie dir gesagt wird, und nimm das Geld, das immer und überall geschätzt wird :)

Stellen Sie sicher, dass die Arbeit mit dem neuen Team eine gute Investition Ihrer Zeit ist.

Vielleicht arbeiten sie effizienter als bisher? In diesem Fall ist die Zusammenarbeit mit ihnen eine großartige Lernerfahrung für Sie (daher eine gute Investition).

Andererseits sind die Methoden des neuen Teams für Sie möglicherweise von geringem Wert (zu viel "Cowboy-Codierung" usw.). In diesem Fall ist das zusätzliche Geld wahrscheinlich nicht wert (es sei denn, es ist ein Startup vor dem Börsengang oder etwas Außergewöhnliches). Du wirst wahrscheinlich nicht viel lernen ... und du riskierst das Ausbrennen.

Ich würde nicht irgendwo arbeiten, wo ich nicht so arbeiten könnte, wie ich wollte. Damit meine ich, dass ich nicht mikromanagt werden möchte.

Ich arbeite unter der Annahme, dass ich gut in dem bin, was ich tue, und wenn Sie mir einige Aufgaben geben, werde ich sie effizient und effektiv erledigen. Wie ich sie implementiere, liegt bei mir, sofern ich nicht gegen Ihre Code-Richtlinien und -Muster verstoße. Das ist der spaßige Teil meines Jobs.

Wenn ich jede Klasse, die ich schreibe, einem Komponententest unterziehen wollte, könnte dies ein Problem sein, aber das Schreiben von Komponententests ist im Allgemeinen in Ordnung, vorausgesetzt, ich halte die Fristen ein. Ich gehe davon aus, dass ein TDD-Befürworter argumentieren würde, dass das Schreiben von Unit-Tests die Produktivität tatsächlich steigert (später usw.). Wenn ich an deiner Stelle wäre, würde ich schreiben einige Unit - Tests , die mich retten wird einige Zeit auf der Bahn (vermutlich weniger Fehler, leichter Korrekturen). Wenn Sie diese eingesparte Zeit wieder in weitere Tests investieren, erhöht sich die Zeitersparnis. Schließlich können Sie sich mit einem Lächeln zurücklehnen, wenn Sie eine fantastische Reihe von Tests haben, und Ihre Codeänderungen nach einer neuen elften Stunde problemlos überprüfen Anforderung kommt herein.

Wenn ich das nicht könnte, dann weiß ich nicht, ob ich dort arbeiten möchte.

Was ich sage, ist, dass ich denke, dass es in diesen Angelegenheiten ein Geben und Nehmen geben sollte - ein bisschen Verhandlung. Je mehr sie mich bezahlen, desto weniger nicht-monetäre Nettigkeiten erwarte ich. Aber ich brauche immer ein gewisses Maß an Autonomie und Selbstachtung, besonders wenn ich mich nicht weigern muss. Ich werde jedes andere Prinzip fallen lassen, solange ich ein bisschen Autonomie habe. Was wie eine verrückte Methode aussieht, ist vielleicht das Beste, was Sie jemals gemacht haben!