Ich bin ein relativ neuer Entwickler, frisch vom College. Während des Studiums und der anschließenden Arbeitssuche stellte ich fest, dass es viele "moderne" Softwareentwicklungsmethoden gab, denen meine Ausbildung fehlte: Komponententests, Protokollierung, Datenbanknormalisierung, agile Entwicklung (im Vergleich zu generischen agilen Konzepten), Codierungsstil Anleitungen, Refactoring, Code-Reviews, keine standardisierten Dokumentationsmethoden (oder sogar Anforderungen) usw.

Insgesamt habe ich nicht gesehen, dass dies ein Problem ist. Ich hatte erwartet, dass mein erster Job all diese Ideen aufgreift und mir diese bei der Arbeit beibringt. Dann bekam ich meinen ersten Job (Full Stack Web Development) bei einem großen Unternehmen und mir wurde klar, dass wir keines dieser Dinge tun . Tatsächlich bin ich, der am wenigsten erfahrene im Team, derjenige, der die ersten Versuche unternimmt, mein Team mit "modernen" Programmiertechniken auf den neuesten Stand zu bringen.

Zuerst habe ich mit der Protokollierungssoftware (log4J) begonnen, aber dann habe ich schnell meinen eigenen Styleguide geschrieben und ihn dann für den Google Styleguide aufgegeben - und dann festgestellt, dass unsere Java-Webentwicklung handgeschriebene Front-Controller verwendet Unsere Einführung von Spring - aber dann wurde mir klar, dass wir auch keine Komponententests hatten, aber ich lernte bereits Spring ... und wie Sie sehen, wird es allzu schnell überwältigend, besonders wenn es mit normaler Entwicklungsarbeit gepaart wird. Darüber hinaus fällt es mir schwer, in diesen Methoden "Experte" zu werden, um andere darin zu unterrichten, ohne zu viel Zeit einem einzelnen von ihnen zu widmen, geschweige denn allen.

Wie kann ich von all diesen Techniken, die ich in der heutigen Welt der Softwareentwicklung als "erwartet" erachte, sie als neuer Spieler in ein Team integrieren, ohne mich und das Team zu überfordern?

Wie kann ich mein Team dazu bringen, agiler zu werden? ist verwandt, aber ich bin kein Agile-Entwickler wie der Fragesteller hier, und ich betrachte einen viel breiteren Satz von Methoden als Agile.

Es hört sich für mich so an, als würden Sie den Karren vor das Pferd stellen.

Was ist das Hauptproblem, mit dem Ihr Team konfrontiert ist, und welche Technologien könnten Abhilfe schaffen?

Wenn zum Beispiel viele Fehler vorliegen, insbesondere Fehler vom Regressionstyp, kann Unit-Testing ein Ausgangspunkt sein. Wenn Ihrem Team die Zeit fehlt, hilft möglicherweise ein Rahmen (mittel- bis langfristig). Wenn die Leute Schwierigkeiten haben, den Code des jeweils anderen zu lesen, kann das Stylen nützlich sein.

Denken Sie daran, dass der Zweck des Geschäfts, für das Sie arbeiten, darin besteht, Geld zu verdienen, nicht Code zu machen.

Java? Modern?! Sie haben bei der ersten Hürde versagt. Wenn Sie wirklich modern sein und "professionellen Selbstmord" vermeiden möchten, müssen Sie Rust-Code schreiben. Natürlich wird sich nächste Woche alles ändern und Sie müssen noch etwas Neues lernen, um Schritt zu halten!

Oder Sie könnten akzeptieren, dass keine Menge von Modeworttechnologien, -methoden oder -frameworks oder anderen Du Jours die Tatsache ändern wird, dass Sie Qualitätsprodukte entwickeln möchten, die funktionieren. Es spielt keine Rolle, wenn Sie nicht agil sind, wenn Sie die richtige Ausgabe erfolgreich produzieren. Wenn dies nicht der Fall ist, möchten Sie möglicherweise Änderungen vornehmen, aber es besteht die Möglichkeit, dass keine besondere Übung zur Behebung der Probleme erforderlich ist. Sie bleiben menschliche Probleme , die auf verschiedene Arten behoben werden können.

Was professionellen Selbstmord betrifft, wenn Sie wissen, was Sie tun und flexibel sind, brauchen Sie keines der genannten Dinge. Die Leute werden weiterhin neue Wege finden, um die alte Arbeit zu erledigen, und Sie werden immer aufholen. Oder Sie können einfach alle Techniken verwenden, die Ihr aktuelles Unternehmen verwendet, unabhängig davon. Wenn Sie Ihr Unternehmen wechseln, lernen Sie einfach die Techniken, die sie verwenden, und wenden sie an.

Zu viele Kinder hängen an all den neuen Werkzeugen, die sie verwenden könnten, und vergessen, dass diese Werkzeuge für Anfänger wertlos sind. Lernen Sie die Übung zuerst, sobald Sie ein erfahrener Entwickler sind, können Sie anfangen, die Entwicklungspraktiken mit "coolen neuen Dingen" zu "reparieren", aber bis dahin werden Sie hoffentlich bemerkt haben, dass sie bei weitem nicht so wichtig sind, wie Sie derzeit denken, und Nur zu verwenden, wenn sie wirklich gebraucht werden.

Viele Unternehmen stecken so fest; Es könnte Sie sogar überraschen, dass einige Ihrer Entwicklerkollegen Autodidakten sind und Entwickler ohne jeglichen formalen Hintergrund wurden. Diese Entwickler sind oft besser in ihrer Arbeit, da sie motiviert sind, neue Fähigkeiten zu erlernen und erfolgreich zu sein, anstatt einfach die Arbeit zu erledigen. Leider kann dies auch bedeuten, dass sie zwar hervorragend programmieren können, sich jedoch möglicherweise der Vorteile dieser Praktiken nicht bewusst sind. Tatsache ist, dass dies Best Practices sind, keine gängigen Praktiken. Die besten verwenden sie, aber sie sind nicht unbedingt Voraussetzung für den Erfolg, sie sind einfach Werkzeuge, um den Erfolg zu erleichtern.

Sie haben vollkommen recht, es wird überwältigend sein, alles auf einmal zu implementieren. Sie werden sich wahrscheinlich selbst (und möglicherweise Ihr Team) verbrennen, wenn Sie versuchen, dies zu tun, was zukünftige Anstrengungen zur Einführung neuer Methoden / Technologien demotivieren wird. Das Beste , was wie dies in einer Situation zu tun ist , wählen Sie einSache (Protokollierung ist wahrscheinlich ein guter Anfang, da Sie wahrscheinlich einen schwierigen Weg vor sich haben, um Fehler zu finden, ohne sich zu protokollieren, und es wird sicher Fehler geben) und sprechen Sie mit dem Team darüber. Sie müssen dies nicht im Alleingang umsetzen. Sie können die Vor- und Nachteile viel besser mit dem Team (und Ihrem Chef, der unbedingt an Bord sein MUSS) besprechen und einen Plan für dessen Umsetzung ausarbeiten. Es muss so schmerzfrei wie möglich sein (denken Sie daran, dass Sie den Leuten sagen, dass sie jetzt zusätzlich zu dem, was sie bereits tun , zusätzlichen Code schreiben müssen).

Und lassen Sie mich noch einmal sagen, stellen Sie sicher, dass Ihr Chef einkauft . Das ist entscheidend; Sie werden wahrscheinlich feststellen, dass die Geschwindigkeit von Fixes / Releases langsamer wird, wenn Sie neue Dinge implementieren. Der Punkt ist, dass Sie im Voraus bezahlen, um auf der ganzen Linie zu sparen; Sie MÜSSEN das verstehen und auf Ihrer Seite sein. Wenn Sie sie nicht an Bord bekommen, kämpfen Sie bestenfalls in einem verlorenen Kampf, und im schlimmsten Fall werden Sie von ihnen als aktiv sabotiert betrachtet (fragen Sie mich, woher ich das weiß).

Wenn Sie diese Elemente auf den Tisch gebracht haben, besprechen Sie sie mit dem Team, planen Sie, wie sie implementiert werden sollen, und führen Sie die Schritte 2, 3, 8 usw. einfacher durch. Darüber hinaus besteht für das Team und Ihren Chef das Potenzial, Respekt für Sie zu gewinnen, da Ihre Vorschläge umgesetzt und als Mehrwert anerkannt werden. Toll! Stellen Sie einfach sicher, dass Sie flexibel bleiben: Sie drängen hier gegen die Trägheit, und Änderungen sind nicht einfach. seien Sie bereit, langsam klein zu machenÄnderungen vornehmen und sicherstellen, dass Sie den Fortschritt und den erzielten Wert nachverfolgen können. Wenn Sie die Protokollierung in einem neuen Prozess implementieren und dadurch in drei Wochen Stunden beim Auffinden eines Fehlers einsparen können, sollten Sie eine große Sache unternehmen! Stellen Sie sicher, dass jeder weiß, dass das Unternehmen nur XXX $ gespart hat, indem Sie rechtzeitig das Richtige tun. Wenn Sie dagegen einen Pushback erhalten oder eine knappe Frist haben, sollten Sie das Problem nicht erzwingen. Lassen Sie die neue Änderung für den Moment gleiten und kreisen Sie zurück. Sie werden niemals gewinnen, wenn Sie versuchen, das Team dazu zu zwingen, etwas zu tun, das sie nicht tun möchten, und Sie können sicher sein, dass das erste, was sie vorschlagen, die neue "zusätzliche" Arbeit ist (wie das Schreiben von Protokollen oder das Folgen von Aufgaben) ein Styleguide, anstatt es einfach zum Laufen zu bringen.

Ich hoffe, Sie haben die Themen Ihren Mitarbeitern nicht so vorgestellt, wie Sie es in Ihrem Beitrag getan haben. DAS wäre professioneller Selbstmord.

Das erste Problem ist, dass Sie versuchen, einer Gruppe von Programmierern Technologien und Methoden beizubringen, mit denen Sie noch keine Erfahrung haben, die vielleicht ein wenig veraltet sind, aber die Arbeit "erledigen". Die Möglichkeiten dieser Fehlzündung sind endlos und werden Ihren Mitarbeitern wahrscheinlich viel Freude bereiten. Es ist interessant und bewundernswert, dass Sie sich und Ihre Abteilung verbessern möchten, aber Begriffe wie "Speerspitze" vermeiden. Mit freundlichen Grüßen, verwenden Sie dieses Wort nicht.

Überprüfen Sie als Nebenproblem, ob Sie Arbeiten ausführen . Ich arbeite seit langer Zeit als einzelner, selbstlernender Programmierer, und ich weiß, wie einfach es ist, die eigentliche Arbeit beiseite zu legen, um vielversprechende Rahmenbedingungen, Technologien und dergleichen zu erkunden. Stellen Sie sicher, dass Ihre Leistung innerhalb der erwarteten Parameter liegt (nein, niemand kümmert sich darum, dass Sie 20 Stunden lang nach Spring forschen, wenn der Bericht, den Sie angefordert haben, nicht fertig ist).

Von allen oben genannten, vermeiden die Lehrer zu sein (es sei denn , es auf ein Feld / Tech , in dem Sie tatsächlich genug Erfahrung haben verwandt ist). Eine neutralere Darstellung würde die Vorteile von beispielsweise automatisierten Tests aufzeigen und das Management entscheiden lassen, wer die Vor- und Nachteile dieser Praktiken untersuchen möchte.

Um diese "Best Practices" vorzustellen, gibt es zwei Möglichkeiten, sie Ihrem Team zu erklären:

• Weil ich sage, dass dies die besten Praktiken sind, und das ist genug.
• Weil sie nützlich sind und helfen, Probleme zu lösen.

Mit dem ersten Argument ist es unwahrscheinlich, dass sie Ihnen Aufmerksamkeit schenken, es sei denn, Sie sind der Chef oder ein sehr hochrangiges Mitglied des Teams. Und "Ich habe ein Buch von Knuth gelesen, das das sagt", oder "die Jungs von der SE sagen das", machen auch keinen Eindruck ("die Jungs arbeiten hier nicht, also wissen sie nicht wirklich, was für diesen IT-Shop gut ist "). Sie haben ihre Methoden, Routinen, Prozeduren und Dinge "mehr oder weniger" funktionieren. Warum also den Aufwand und die Risiken von Veränderungen auf sich nehmen?

Für den zweiten Ansatz muss die Erkenntnis vorliegen, dass ein Problem vorliegt . Damit:

• Schieben Sie nicht Tag und Nacht, um automatische Tests durchzuführen. Warten Sie, bis ein Update einige Funktionen nicht mehr unterstützt und das Team Überstunden machen muss, um das Problem zu beheben, und schlagen Sie dann vor, ein automatisiertes Testsystem zu erstellen.
• Fragen Sie nicht nach Code-Reviews. Warten Sie, bis sich Joe in einem längeren Urlaub befindet und Sie das Modul ändern müssen, das nur Joe kennt, und zeigen Sie Ihrem Chef, wie viel Zeit beim Versuch, Joes Code zu verstehen, verloren gegangen ist.

Natürlich wird der Wandel langsam und fortschreitend sein (in einem großen Unternehmen mehr). Wenn Sie in fünf Jahren die Codeüberprüfung und das automatisierte Testen einführen können, sollten Sie sich zu einer gelungenen Arbeit beglückwünschen. Vergessen Sie jedoch, es sei denn, es gibt aufgrund äußerer Ursachen eine vollständige Neufassung, jede Fantasie, die den Kern-IS auf etwa Spring umstellt ( Joel erklärte dies besser, als ich es jemals könnte, noch bevor Sie geboren wurden ¹ ). In dieser Zeit könnten Sie höchstens Spring in die Liste der unterstützten Plattformen aufnehmen, um unkritische Systeme zu schreiben.

Willkommen in der Welt der Unternehmens-IT, Junge! :-p

¹ : Ok, vielleicht übertreibe ich ein bisschen, aber nicht zu viel.

Sie sollten mit dem Buch Working Effectively with Legacy Code von Michael Feathers beginnen. In der Einleitung des Buches heißt es: "Es geht darum, ein verwickeltes, undurchsichtiges, verschlungenes System Stück für Stück und Schritt für Schritt langsam und schrittweise in ein einfaches, gut strukturiertes und gut gestaltetes System umzuwandeln." Er beginnt meistens mit automatisierten Tests, damit Sie sicher umgestalten können (Sie werden wissen, wenn Sie etwas kaputt machen), und er enthält viele Strategien, um schwierigen Code automatisiert zu testen. Dies ist nützlich für jedes Projekt, das sich noch in der Entwicklung befindet. Sobald Sie eine Grundordnung erstellt haben, können Sie sehen, von welchen anderen modernen Technologien Ihr Projekt wirklich profitieren könnte - aber gehen Sie nicht davon aus, dass Sie alle benötigen.

Wenn Sie ein neues Framework (oder etwas anderes) aus beruflichen Gründen erlernen möchten, anstatt dass Ihr aktuelles Projekt es tatsächlich benötigt, sollten Sie es in einem persönlichen Projekt verwenden (in Ihrer Freizeit).

Quellcodeverwaltung.

Sie haben es hoffentlich nicht erwähnt, weil es bereits vorhanden ist, aber falls nicht, beginnen Sie dort.

Die Quellcodeverwaltung ist das größte Problem, außer in seltenen Fällen, in denen pathologisch etwas anderes erforderlich ist.

Und Sie können alleine anfangen, wenn sich zunächst niemand anmeldet.

Eine direkte Antwort

Andere Antworten sind gute „Metapunkte“ für die Annahme besserer Praktiken. Um Ihnen jedoch einige direkt relevante Hinweise zu geben, folgt eine grobe Reihenfolge der bewährten Praktiken, die Ihr Team (oder ein beliebiges Team) (zuerst) annehmen sollte:

1. Quellcodeverwaltung
2. Issue Tracking (Projekt- und Aufgabenmanagement)
3. Automatisierte Builds ¹
4. Automatisierte Bereitstellungen

^{1 _{Eine sehr ähnliche Vorgehensweise besteht darin , das Einrichten der Build- und Entwicklungsumgebung für jede App oder jedes Softwareprojekt, die bzw. das Sie entwickeln oder verwalten, zu automatisieren oder zumindest zu dokumentieren . Es ist viel weniger nützlich, weil Sie dies (hoffentlich) selten oder selten tun.}}

Alles andere

Sie erwähnen einige andere bewährte Methoden - "Komponententests, Protokollierung, Datenbanknormalisierung, ... Refactoring, ... Dokumentation" - aber all diese Methoden können und sollten schrittweise und schrittweise übernommen werden. Keiner von ihnen müssen auf einmal angenommen werden , und Sie werden sie wahrscheinlich besser annehmen überhaupt von ihnen sorgfältig und achtsam Annahme.

Die vier oben aufgeführten Praktiken werden auch das Übernehmen und Experimentieren mit neuen Praktiken so einfach wie möglich machen. Beispielsweise können Komponententests in Ihre automatisierten Builds integriert und Dokumentationen als Teil Ihrer automatisierten Bereitstellungen veröffentlicht werden.

Einige der anderen Praktiken, die Sie erwähnen - "Agile Entwicklung, ... Coding-Style-Guides, ... Code-Reviews, ... standardisierte Dokumentationsmethoden" und Frameworks (z. B. Spring) - sind wirklich optional oder von zweifelhaftem Wert. Und das gilt für viele (die meisten?) Möglichen Praktiken, die Sie entdecken oder denen Sie begegnen werden.

Agile Entwicklung ist offensichtlich keiner anderen Methodik überlegen. Und viele Leute (einschließlich ich) haben schreckliche Erfahrungen damit gemacht. Aber viele Leute mögen es wirklich (oder lieben es) auch. Versuch es!

Das Codieren von Styleguides kann hilfreich sein, insbesondere bei großen Projekten oder in großen Teams, aber es ist auch eine Menge Arbeit, um diese Richtlinien durchzusetzen , und das ist möglicherweise nicht die beste Nutzung der Zeit , die derjenige verwendet, der dies tut.

Code-Überprüfungen können auch sehr hilfreich sein - haben Sie Ihre Kollegen gebeten, Ihren Code zu überprüfen? Denken Sie daran, dass Sie keinen formellen Prozess benötigen, um bewährte Verfahren einzuführen!

Die Dokumentation ist großartig - haben Sie überhaupt welche? Wenn ja, gut für dich! Stehen Sie vor einer Menge zusätzlicher Arbeiten, die durch (mehr) "standardisierte" Dokumentation verhindert werden könnten? Wenn ja, dann lohnt es sich wahrscheinlich, das zu tun. Wenn Ihre Software jedoch von einer kleinen Gruppe von Personen verwendet wird, benötigen Sie möglicherweise keine Dokumentation. (Oder Sie können die Dokumentation direkt in Ihre Software integrieren. Das ist immer meine Präferenz.)

Frameworks sind ... ein (sehr scharfes) zweischneidiges Schwert. Eine gut gekapselte und gut gewartete Lösung für eine Nicht-Kernfunktion Ihrer Software ist großartig ... bis es nicht so ist. Ich bin mir nicht sicher, was "handgeschriebene Front-Controller" genau sind, aber es gibt keine offensichtliche Erklärung, warum sie dem Code, der Spring nutzt, unterlegen sind. Haben Sie darüber nachgedacht, die gemeinsame Logik in all diesen Controllern in Ihr eigenes internes Framework zu integrieren? Das Übernehmen von Spring und das Umschreiben des gesamten vorhandenen Codes kann ein immenses Umgestaltungsprojekt sein (oder, wahrscheinlicher, das Umschreiben), und dies ist möglicherweise nicht die beste Änderung, die Sie an Ihrem Code vornehmen können . Natürlich sollten Sie nicht die gesamte Software schreiben, die Sie verwenden - Frameworks (und Bibliotheken) sind großartig!Aber vielleicht müssen Sie Spring (oder eine Alternative) nicht verwenden, um großartige (oder gute) Web-Apps zu schreiben.

Schauen Sie sich in dem Team um, zu dem Sie gehören. Können Sie Beweise dafür finden, dass testgetriebene Entwicklung oder Datenbanknormalisierung die Qualität der von Ihnen geschriebenen Software verbessern oder die Produktivität der Mitarbeiter steigern?

Haben Sie versucht, mit einem der Entwicklungsleiter oder dem Entwicklungsleiter darüber zu sprechen? Ein wirklich informeller Chat wäre ein guter Anfang. Was lässt Sie denken, dass die Leute über Ihnen nicht die gleichen Ideen hatten, sie aber nicht umsetzen können / wollen, weil das Geschäft es nicht zulässt?

Ich halte es für einen guten Weg, mit gutem Beispiel voranzugehen. Die Leute sind viel weniger widerstandsfähig, wenn jemand anderes die Arbeit bereits erledigt hat und ihnen zeigen kann, wie man sie repliziert. Führen Sie TDD in ein Projekt ein, an dem Sie arbeiten. Bitten Sie den Rest des Teams oder sogar ein paar andere um eine Präsentation und zeigen Sie ihnen, was Sie getan haben. Was @DrewJordan über das Einsteigen vom Chef gesagt hat, ist wichtiger, als Sie sich wahrscheinlich vorstellen.

Finde einen Fehler. Beheben Sie einen Fehler. Zeigen Sie das Update.

Nehmen wir zuerst die Normalisierung *. Und in der Tat würde ich vorschlagen, dass Sie es zuerst nehmen, weil ein Mangel an Normalisierung wahrscheinlich zu fehlerhaften Daten führt, die sonst nicht existieren könnten, während der Rest Fälle sind, in denen bewährte Methoden wahrscheinlich helfen könnten, aber es schwieriger ist, "Fehler" zu sagen A wurde dadurch verursacht, dass die Richtlinie X nicht befolgt wurde ". Wenn Sie eine Datenbank haben, die nicht normalisiert ist, haben Sie einen Ort, an dem Daten inkonsistent sein können.

Es ist eine gute Wette, dass Sie in der Lage sind, einen tatsächlichen Fall inkonsistenter Daten zu finden. Sie haben jetzt zwei Dinge gefunden:

1. Ein Fehler in Ihren Daten.

2. Ein Fehler in Ihrem Datenbankschema.

Sie wussten tatsächlich zuerst über den zweiten Fehler Bescheid, aber der erste Fehler ist leichter nachweisbar und verursacht auch ein echtes Problem, das theoretisch nicht möglich ist.

Leider ist einer der wahren Gründe, sich der Normalisierung denormalisierter Datenbanken zu widersetzen, dass die Frage, was mit solchen fehlerhaften Daten zu tun ist, nicht immer einfach ist, aber Sie werden einen tatsächlichen Fehler gefunden haben.

(Beachten Sie jedoch, dass es Gründe gibt, aus denen man manchmal absichtlich Daten denormalisieren kann. Verwechseln Sie nicht das Verstoßen gegen die Regel mit der Unkenntnis der Regel. Wenn Sie eine Tabelle normalisieren, die absichtlich denormalisiert wurde, um die Suche zu beschleunigen, haben Sie gewonnen Auch hier sollte das Denormalisieren sehr aufwendig sein. Wenn die denormalisierte Tabelle also nicht automatisch auf der Grundlage des Inhalts normalisierter Tabellen erstellt wird, sind noch Fortschritte zu verzeichnen.

Stellen Sie sie im Übrigen vor, wenn sie kurzfristig helfen, um sie später langfristig weiter auszubauen. Wenn Sie beispielsweise einen kleinen Code zum Erstellen erhalten, schreiben Sie einen Komponententest dafür. Besser noch, wenn Sie einen zu behebenden Fehler erhalten, schreiben Sie einen Komponententest, der aufgrund des Fehlers fehlschlägt. Wenn Sie den Fehler behoben haben, erwähnen Sie die Tatsache, dass der Fehler durch das Schließen der Fehler behoben wird (oder senden Sie eine E-Mail, die besagt, dass der Fehler behoben ist , oder Wasauchimmer).

* Übrigens nicht sehr modern. Der Grund ist es genannt wird , Normalisierung und nicht Normalisieren oder etwas anderes ist, dass es an der Zeit , ein aktueller Witz zu halten -ization am Ende der Dinge Spaß des Namen von Richard Nixons zu machen Vietnamization Politik.

Ich werde gegen den Strich gehen und sagen: Finde einen neuen Job, nachdem du einige Zeit in diesem verbracht hast, um deinen Lebenslauf ein wenig zu erstellen. Streben Sie ein Jahr oder so an. Obwohl es sich bei vielen Dingen um Modewörter handelt, sind Probleme wie das völlige Fehlen von Komponententests für einen einzelnen Entwickler nicht zu bewältigen. Wenn die dort arbeitenden Programmierer keine Lust zum Testen haben, werden Sie nie etwas kaufen und möglicherweise sogar Ihre Position gefährden im Unternehmen, indem man die Leute dazu bringt, Sie als blasenhart zu betrachten. Sie müssen an einem Ort sein, an dem Sie sich beraten lassen können, und nicht versuchen, die Kultur in Richtung Grundkompetenz zu treiben.

Es gab viele Vorschläge zur Verbesserung des Programmierparadigmas . Die heißesten Schlagworte scheinen nun agiles Programmieren und objektorientiertes Arbeiten zu sein. Oder sind Sie? Beide sind im Vergleich zu vor fünf Jahren erheblich zurückgegangen.

Sie können sich ziemlich sicher sein, dass mit jeder Methode das gleiche Endergebnis erzielt werden kann: Sie können den Ingenieuren helfen, wirtschaftlich ein Endprodukt zu produzieren, das gut genug ist.

Es ist ein Paradigma , das kontrovers in den 1960er Jahren eingeführt wurde: die strukturierte Programmierung : nur „high level“ verwenden Konstrukte wie while, for, repeat, if/ then/ else, switch/ caseAussagen anstelle der stark frequentierten gotoAussage , die standardmäßig akzeptiert worden war. Es gibt immer noch Debatten darüber, ob gotoeine legitime Verwendung überhaupt möglich ist.

Ich akzeptiere, dass gotoes eine gute Sache ist, den Gebrauch zu minimieren , aber wie bei allen guten Dingen ist es möglich, zu weit zu gehen.

Sie erwähnen agileMethoden als etwas Positives. Ich war ungefähr sechs Monate lang in einem Entwicklungsteam, das absichtlich einem vorgeschriebenen agilen Regime folgte. Ich fand es genauso wie aufgeklärte Projektmanagementmethoden vor Jahrzehnten, nur dass alles umbenannt wurde. Vielleicht können Unternehmen durch das Bündeln und Wiederverkaufen von Ideen für die Kommunikation von jemandem ihren Lebensunterhalt verdienen und sich gut fühlen, wenn sie die neuen Kleider des Kaisers "sehen" .

Die wertvollste Lektion von Agile, die vor langer Zeit bekannt war, ist, dass Flexibilität, um einen besseren Weg zum fertigen Produkt zu finden, eine gute Sache ist und die Fähigkeit, diesen Weg zu finden, von jedem kommen kann - nicht nur vom oberen Management.

Aus einem Schreiben des Anti-Goto-Rädelsführers Edsger Dijkstra:

Die Kunst des Programmierens ist die Kunst, Komplexität zu organisieren, die Vielfalt zu meistern und das Chaos der Bastarde so effektiv wie möglich zu vermeiden.

-Dijkstra, in: Dahl, Dijkstra & Hoare 1972, pg. 6. (siehe Seite 6 hier .)