Was sind die Hindernisse für die Übernahme bewährter Verfahren? Wie können sie überwunden werden? [geschlossen]

Wir haben alle viel schlecht geschriebenen Code gesehen (und die meisten von uns haben ihn geschrieben). Warum? Was bringt uns dazu, eher schlechte als gute Praktiken anzuwenden?

Die naheliegendste Antwort (für mich) ist "Ignoranz", aber ich bin mir sicher, dass dies nicht der einzige Grund ist. Welche anderen gibt es? Was können wir tun, um die Versuchung zu überwinden, schlechten Code zu schreiben?

Widerstand zur Aenderung.

Das ist der Hauptgrund für Ignoranz, schlechtes Management usw.

Kapitel 30 der Peopleware 2nd Edition widmet sich diesem Thema. Und es zitiert aus einem Buch eines anderen ziemlich bekannten Beraters, das allerdings etwas früher geschrieben wurde:

Und es sollte bedacht werden, dass nichts schwieriger zu handhaben, zweifelhafter am Erfolg oder gefährlicher zu handhaben ist, als sich an die Spitze der Einführung neuer Aufträge zu setzen. Denn der Einführer hat alle, die von den alten Befehlen profitieren, als Feinde, und er hat lauwarme Verteidiger in allen, die von den neuen Befehlen profitieren könnten.

Niccolo Machiavelli: Der Prinz (1513)

DeMarco und Lister halten sich weiterhin an das Mantra, bevor sie die Leute auffordern, sich zu ändern:

Die grundlegende Reaktion auf Veränderungen ist nicht logisch, sondern emotional.

Der Veränderungsprozess ist selten ein direkter und reibungsloser Übergang von den gegenwärtigen suboptimalen Bedingungen in die neue, verbesserte Welt. Für jede nicht triviale Veränderung gibt es immer eine Phase der Verwirrung und des Chaos, bevor der neue Status Quo erreicht wird . Das Erlernen neuer Werkzeuge, Prozesse und Denkweisen ist schwierig und erfordert Zeit. Während dieser Übergangszeit sinkt die Produktivität, die Moral leidet, die Menschen können sich beschweren und wünschen, wenn es nur möglich wäre, zu den guten alten Methoden zurückzukehren. Sehr oft tun sie das auch bei allen Problemen, weil sie das Gefühl haben, dass die guten alten bekannten Probleme besser sind als die neuen, unbekannten, frustrierenden und peinlichen Probleme. Dies ist der Widerstand, der taktvoll und sanft überwunden werden muss, um erfolgreich zu sein.

Mit Geduld und Ausdauer gelangt das Team schließlich vom Chaos zur nächsten Stufe, Praxis und Integration. Die Leute, die mit den neuen Werkzeugen / Prozessen nicht ganz vertraut sind, fangen an, sich darauf einzulassen. Es kann positive "Aha" -Erfahrungen geben. Und nach und nach erreicht das Team einen neuen Status quo.

Es ist wirklich wichtig zu erkennen, dass das Chaos ein wesentlicher, unvermeidlicher Bestandteil des Veränderungsprozesses ist . Ohne dieses Wissen - und ohne die Vorbereitung darauf - kann man beim Erreichen der Chaos-Phase in Panik geraten und sie mit dem neuen Status Quo verwechseln. Anschließend wird der Veränderungsprozess abgebrochen und das Team kehrt in seinen früheren miserablen Zustand zurück, aber mit noch weniger Hoffnung, jemals etwas zu verbessern ...

Als Referenz wurden die oben beschriebenen Phasen ursprünglich im Satir Change Model (benannt nach Virginia Satir ) definiert.

Péter Török hat recht, aber einen wichtigen und optimistischen Punkt ausgelassen:

• Die Menschen mögen vielleicht Veränderungen, an denen sie beteiligt sind, aber sie mögen fast nie Veränderungen, die ihnen einfach "zustoßen"

Also engagieren Sie sich, lassen Sie sie Ideen einbringen, lassen Sie sie einen Anteil daran schaffen, und es wird nicht so schmerzhaft sein

Hinweis: Dies ist für die Programmierung insofern relevant, als viele technisch erfolgreiche Softwareprojekte fehlschlagen, weil die Benutzer sie ablehnen .

Die Zeit scheint groß zu sein, in der ich arbeite.

ZB: Warum sollten Sie Unit-Tests durchführen, wenn Sie mehr Code schreiben müssen, und daher länger brauchen, um ein abrufbares Produkt zu erhalten? Kunde x will es jetzt! Code schneller!

(Das hört natürlich nicht gut auf)

Dies ist auch auf schlechtes Management und mangelnde Wirtschaftlichkeit zurückzuführen, da die Kunden nicht genug Geld verlangen, um sich die Zeit zu nehmen, um es richtig zu machen.

Trotz der massiven Beweise für das Gegenteil sind die Menschen in der Regel sehr rationale Wesen. Der Grund, warum Menschen keine Best Practices wie TDD anwenden, ist, dass sie nicht glauben, dass es sich lohnt. Entweder sie denken, dass die Praktiken in der Tat nicht am besten sind; und dass es sie tatsächlich mehr kosten wird, als es sie retten wird. Oder sie denken, dass der Nutzen so gering ist, dass die Kosten der Veränderung den winzigen Nutzen überwiegen. Unter dem Strich ist das Problem der Best Practices ein Problem des Endergebnisses.

Wenn Sie ein Change Agent sein möchten, müssen Sie nachweisen, dass die Wahrnehmung des Endergebnisses fehlerhaft ist. Sie müssen zeigen, dass die beste Vorgehensweise wirklich die beste ist . Dass die Vorteile sofort und signifikant sind . Sie müssen zeigen, dass die Lernkurve klein genug ist, um auszuhalten, und dass zumindest einige der Vorteile sofort einsetzen.

Wie zeigst du das? Indem Sie die Best Practice selbst übernehmen! Nichts dient dazu, andere besser zu überzeugen als Ihr eigenes Verhalten. Wenn Sie sich an die bewährten Methoden halten und dies deutlich machen, werden andere erkennen, dass Sie die wirtschaftliche Analyse durchgeführt und die gegenteilige Entscheidung getroffen haben. Das wird sie dazu bringen, ihre Entscheidung zu überdenken. Sie werden dies privat tun und es zuerst nie zugeben. Aber jeder, der sieht, dass Sie diese bewährte Methode anwenden, wird seine Position erneut überprüfen.

Das ist das Beste, worauf Sie hoffen können. Wenn die beste Praxis ist eine bewährte Methode, dann wird der Rest automatisch folgen. Oh, es wird nicht schnell gehen und es wird viele Probleme geben. Der Übergang wird langsam und fleckig sein; und du wirst viele Enttäuschungen erleben. Der Übergang wird aber auch unaufhaltsam und unvermeidlich sein. Es könnte eine Generation dauern, aber die beste Praxis wird gewinnen.

Fragen Sie sich als Beweis, wann Sie das letzte Mal jemanden gesehen haben, der goto benutzt hat.

Es ist das Ergebnis des Nichtwissens oder des Denkens, dass man die ideale Methode kennt. Die Leute entscheiden sich nicht dafür , Code schlecht zu schreiben. es geht eher darum, es nicht besser zu wissen. " Naivität " im Gegensatz zu " Ignoranz " wäre ein besseres Wort.

Die einfachste Möglichkeit, sich an bewährte Verfahren zu halten, besteht darin, anzuerkennen, dass es (höchstwahrscheinlich) eine bessere Möglichkeit gibt, den soeben geschriebenen Code zu schreiben, und dann zu lernen, was dieser „bessere Weg“ ist.

Zwei Ursachen

• Ignoranz.

• Arroganz.

Wie können sie überwunden werden?

• Anreize.

Bis Manager (dh die Leute den Kauf der Entwickler-Fähigkeit) kann erfordern Best Practices im Rahmen der Lieferung von Software, nichts möglicherweise ändern. Viele Organisationen sind eindeutig schizophren: Sie bilden Entwickler in verschiedenen Technologien aus und fordern dann nicht getestete Software oder ein nicht testbares Design. Oder schlimmer.

Best Practice ist für mich eine Software, die ein Team von 8 Leuten geschrieben hat. Wir hatten keine schriftlichen Anforderungen, Code-Überprüfungen, Unit-Tests, Format-Release-Dokumente. Keine Endbenutzertests, keine der Aussagen, die wir hätten machen sollen. Der Code war gehetzt, fehlerhaft und einfach unmöglich zu pflegen. Es wurde 3 Jahre nach der Veröffentlichung weggeworfen, es war so schlimm. Also, was war so toll daran? Zwei Jahre nach der ersten Entlassung verschwand der Firmeninhaber (der die Entwicklung mit einer Hypothek auf sein eigenes Haus finanziert hatte) mit 30-40 Millionen Dollar in seiner Gesäßtasche.

Wir verlieren oft die Tatsache aus den Augen, dass wir (meistens) hier sind, um Software zu entwickeln, die Geld für das Geschäft verdient. Unternehmen bieten uns nicht die Möglichkeit, Software mithilfe von "Best Practice" zu entwickeln. Sie dienen dazu, Geld zu verdienen.

Die meisten "Best Practice" -Praktiken verbessern die Gewinne nicht. Diejenigen, die dies tun, sollten und werden, sind weit verbreitet. Deshalb wird "Best Practice" nicht praktiziert.

Akzeptables Risiko

Bist du noch nie ein Risiko eingegangen und hast auf etwas gespielt? Es gibt eine Zeitkrise, so dass Sie es mit der Absicht arbeiten lassen, es später umzugestalten (anstatt es früher umzugestalten). Das ist eigentlich eine gute Praxis für einige Leute.

Irgendwann wirst du oft genug verbrannt und änderst deine Wege. Denken Sie an all die 'Best Practices', die es gibt. Kannst du ihnen die ganze Zeit folgen? Widersprechen sich irgendwelche? Sie möchten nicht jeden Ausreißer zeitraubend behandeln.

Wenn ich fehlerhaften Code schreibe, der funktioniert, und niemand ihn jemals wieder ansieht, gilt er dann immer noch als fehlerhaft? (Bitte, lasst uns die philosophische Debatte nicht ruinieren, indem wir darüber streiten, was 'schlechter Code' ist.)

IME ist eine Kombination dessen, was andere gesagt haben. Ignoranz ("Ich habe bisher nur DataSets verwendet, warum sollte ich mich mit diesem LINQ-Material beschäftigen?", Zeitmangel ("Der Chef möchte, dass es so schnell wie möglich erledigt wird, wir können nicht viel Zeit dafür aufwenden"), Mangel des Verstehens ("Was ist falsch daran, meinen gesamten Code im Code-Behind zu schreiben?") tragen alle dazu bei.

Die Ironie, die ich sehe, ist, wenn Sie diesen Weg erst einmal beschritten haben, dass Sie sich nur noch tiefer verspotten. Wenn Sie jetzt Abstriche machen und den gesamten Code für eine App in die ASPX-Dateien werfen, können Sie ihn später nicht mehr reparieren. Neue Dinge werden immer wieder auf dich geworfen, was bedeutet, dass du sie schnell erledigen musst, was bedeutet, dass du nur den gesamten Code in der ASPX-Datei wegwerfen musst (schwöre, dass du es eines Tages reparieren wirst), usw. usw. Es ist ein Niemals -Endende Spirale, weil man die Entwicklung nicht mehr aufhalten kann und sagt, dass Dinge zuerst repariert werden müssen.

Oft wurde Entwicklern einfach nicht die bessere Vorgehensweise oder, was noch wichtiger ist, die Vorteile der Verwendung einer besseren Vorgehensweise gezeigt (ich beginne aus verschiedenen Gründen, den Begriff "Best Practices" nicht mehr zu verwenden).

Es gibt eine Theorie, dass Entwickler "absichtlich faul" sind. Mit anderen Worten, sie tendieren dazu, den Weg des geringsten Widerstands zu wählen.

Wenn Sie ihnen schnell die Vorteile einer besseren Praxis (wie TDD oder sagen wir, nach den SOLID-Prinzipien) zeigen und feststellen, dass sie tatsächlich ein besserer (aber immer noch "fauler") Entwickler sind, werden Sie feststellen, dass der Widerstand schmilzt Weg.

Es ist eine Frage der Erziehung :)

(Mangel an) Wissen und Fähigkeiten + Zeit zum Investieren

Ich bin überrascht, dass niemand anderes dies herausgebracht hat, aber vielleicht ist es für mich offensichtlich, weil ich so viel als Einzelprogrammierer gearbeitet habe und niemand (außer Stack) zu dem ich gehen kann, wenn ich mit etwas zu kämpfen habe. Ich kenne 'bessere' Techniken - wie TDD - aber oft verstehe ich sie nicht gut genug, um sie zu verwenden, und es fällt mir schwer, gute Informationen zu finden, mit denen ich anfangen kann, sie zu verwenden. Wiederum am Beispiel von TDD verstehe ich die grundlegende Bedeutung davon - Tests erstellen, die sicherstellen, dass Ihr Code ein bestimmtes Ergebnis liefert - aber tatsächlich implementieren?

Abgesehen von der Tatsache, dass XCode heutzutage integrierte Unit-Tests hat, habe ich keine Ahnung, wo ich anfangen soll. Behaupte ich, dass die Ansicht X-Schaltflächen enthält, nachdem ich eine Routine ausgeführt habe, um sie zu erstellen? Wie wäre es, wenn Sie behaupten, dass meine UIViews nach dem Aufrufen des Drehen-Tags entsprechend neu angeordnet wurden?

Heck, wie schreibe ich überhaupt einen Unit-Test in XCode? Das ist etwas anderes, was ich zum Lernen brauche.

@Zues und @Joshua Smith

Ja, ich stimme manchmal zu, dass Zeit und Budget einige Einschränkungen sind, die es Ihnen nicht erlauben, jedes bekannte Prinzip der „besseren Programmierung“ in ein Programm zu integrieren.

Sie wissen, dass die aktuelle Aufgabe viel robuster erledigt werden kann, wenn Sie nur etwas mehr Zeit hätten. Nur sehr wenige Kunden (vor allem, wenn sie ihre erste iPhone-App oder ihre erste maßgeschneiderte Business Intelligence-Software erhalten) verstehen, dass Sie bereits erledigte Vorgänge erneut implementieren, weil Sie einen besseren Weg gefunden haben, dies zu tun.

Gleiches gilt für Unit-Tests. Leider muss ich noch einen Kunden treffen, der bereit ist, Budget für diese bereitzustellen. Die typische Antwort lautet wie folgt: „Automatisierte Regressionstests OK Ich verstehe, aber Komponententests? Dafür haben wir keine Zeit! Wir müssen es schnell auf den Markt schaffen! “

Zwei Teile in den meisten meiner Erfahrungen:

• Zeit
• genug Leute zu finden, um zu vereinbaren, welche Praktiken für die aktuelle Situation am besten sind

"Best Practices" sind in vielen realen Situationen SEHR subjektiv. Wenn die eine Hälfte des Teams versucht, eine Menge SOLID & TDD zu machen, während die andere Hälfte 60-Stunden-Wochen arbeitet, um die Laufzeiten hier und da mit allen Mitteln zu verkürzen, weil Sie über den Punkt hinaus sind, an dem es zu spät ist Wenn Sie etwas überarbeiten, das nicht rechtzeitig für Ihre nächste Veröffentlichung erscheint, werden Sie nicht sehr weit kommen.

Auch wenn Sie im gesamten Team nicht allzu viele Meinungsverschiedenheiten feststellen, ist es eine große Anstrengung, eine formelle Einigung, Dokumentation und Schulung in Bezug auf die Richtlinien zu erzielen, die Sie befolgen möchten. Dies ist aus geschäftlicher Sicht ein großer Block unproduktiver Zeit, den Sie sorgfältig rechtfertigen müssen.

Manchmal werden Sie feststellen, dass Gewohnheit auch einen wichtigen Beitrag zum Schreiben von schrecklichem Code leistet.

Sie sind möglicherweise ein sehr erfahrener Programmierer und kennen sich mit den aktuellen Best Practices der Branche aus. Verdammt, Sie könnten sogar der Experte für solche Dinge sein. Die Erfahrung zeigt mir, dass solche Leute nicht oft schrecklichen Code schreiben, und es dennoch leicht sein kann, auf alte Gewohnheiten zurückzugreifen und etwas zu tun, von dem Sie wissen, dass es gegen die Regeln verstößt, einfach weil es sich sicher und bequem anfühlt. In solchen Fällen sind Ignoranz und Arroganz und all die anderen Fingerzeig-Adjektive, die Sie sich ausdenken, nicht wirklich wichtig. Es ist nicht unbedingt so, dass solche Programmierer besonders schlecht darin sind, was sie tun (obwohl dies häufiger der Fall ist), oder sogar, dass sie ein schreckliches Durcheinander verursachen wollen.

Es ist bedauerlich, dass ich persönlich mehr Zeit erlebt habe, als ich zählen möchte, als einige wirklich talentierte Leute bloßen Müll rausgeschmissen haben, weil ihre Finger und ihr Gehirn ein paar Monate lang mit dem Auto gearbeitet haben. Hier häufen sich meistens Anzeichen von Burn-out, Trauer und Stress. Manchmal ist es wirklich blinde Angewohnheit, sie durch die täglichen Bewegungen zu tragen. Es ist etwas, worauf ich achten muss, um nicht zu riskieren, gefährdete Personen unnötig zu kennzeichnen.

Nur ein paar Denkanstöße für diejenigen von uns, die es einfacher finden, einfach zum negativen Ergebnis zu springen ... obwohl Sie leider öfter Recht haben als nicht.

Niemand zeigt Interesse, für ein Projekt mit dem Titel "Etwas überarbeiten" zu bezahlen. Es muss ein paar Worte geben, die die Geschäftsinteressen ansprechen. Wörter wie Erneuern, Wiederbeleben, Total Remake, Lebenszyklus-Upgrade usw. funktionieren an meinem Arbeitsplatz. Fast alle von ihnen haben Refactoring als Hauptbestandteil des Projekts.

Leider geschieht Arbeit dank des Wirtschaftskillers nur, wenn sie bezahlt wird. Auch wenn es nur darum geht, das Geschäftsvermögen langfristig zu retten.