Was sind die Hindernisse für die Übernahme bewährter Verfahren? Wie können sie überwunden werden? [geschlossen]
22
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?
Was ist der Grund, warum Sie heute sagen können, dass Code schlecht geschrieben ist und nicht, warum er geschrieben wurde?
@ Thorbjørn: Tut mir leid, ich verstehe die Frage nicht?
Kramii Reinstate Monica
@Kramil, haben Sie beim Schreiben des schlecht geschriebenen Codes erkannt, dass er schlecht geschrieben ist, und wenn ja, warum haben Sie ihn so geschrieben? Wenn nicht, was ist passiert, seitdem Sie es jetzt erkennen können, im Gegensatz zu früher.
4
@Kramii, keine "Best Practice" kann jemals einen rationalen, kritischen Gedanken ersetzen. Alle "Best Practices" sind nichts anderes als Werkzeuge, und ihre blinde Verwendung wäre nur schädlich. Es ist dumm, etwas zu befolgen, nur weil es als "Best Practice" angesehen wird, ohne die Gründe dafür zu verstehen. Aber mit einem solchen Verständnis brauchen Sie nicht Ihre "Best Practices" zu befolgen. Daher ist der Begriff "Best Practice" zutiefst fehlerhaft und von Natur aus schädlich.
SK-logic am
Antworten:
29
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 ...
Ich denke, dass dies für etabliertere Programmierer zutrifft, aber ich denke, dass sie nur einen sehr kleinen Prozentsatz derjenigen ausmachen, die nicht nach bewährten Methoden programmieren. Der gesamte Code, den ich gesehen habe und der nicht den bewährten Methoden entspricht, stammt aus zwei anderen Antworten - Zeitmangel und Naivität.
AndrewKS
1
@AndrewKS, das betrifft nicht nur Entwickler, sondern auch Manager und Kunden. In einem guten Entwicklungsteam und -prozess sind die Fristen realistisch und den Entwicklern werden keine Aufgaben zugewiesen, die über ihre derzeitigen Fähigkeiten hinausgehen - zumindest nicht ohne angemessene Betreuung und Überprüfung. Ein Misserfolg ist fast immer ein Zeichen dafür, dass das Management sich weigert, Best Practices zu übernehmen.
Péter Török
Wirklich ein guter Punkt - ich habe in dieser Situation bisher nicht an Nicht-Programmierer gedacht.
AndrewKS
Widerwillen führt oft zu einer gewissen Faulheit, die letztendlich zu Unwissenheit führt.
S.Robins
23
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 .
in der Tat ein guter Weg, um Veränderungen zu bewältigen
Newtopian
Sie müssen vorsichtig mit Bikeshedding sein ! Lass sie nicht ZU involvieren!
Shapr
18
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.
Auch hier ist die Zeit riesig. Mein Chef sagte uns in einer Mitarbeiterbesprechung: "Das Geschäft zahlt sich nicht für großartige Arbeit aus."
Joshua Smith
@ Joshua Smith: wtf !? Ernst? Ich wäre nicht überrascht, wenn sie genau das bekommen , was sie tun bezahlen.
Steven Evers
2
Ich habe oft gesehen, dass wir es uns nicht leisten können, es richtig zu machen. Aber wir können es uns leisten, endlose Zeit damit zu verbringen, das Chaos zu beheben. Welcher Ansatz ist für stundenweise abrechnende Beratungsunternehmen am besten?
BillThor
1
@jwenting: Um meinen früheren Kommentar in einen Zusammenhang zu stellen, habe ich in einer Mitarbeiterversammlung Unit-Tests befürwortet. Derzeit schreiben nur zwei von uns Unit-Tests (und das müssen wir schlau tun). Persönlich betrachte ich Unit-Tests nicht als Gold- und Diamantschmuck.
Joshua Smith
1
@shapr: Das ist eine schreckliche Sache, von einer Firma zu hören, die Raketen und Raketen baut. >: P
Mr. JavaScript
11
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.
+1 und nicht allen Entwicklern wird genug Zeit eingeräumt, um bessere Möglichkeiten zu erlernen oder zu erkunden. Für viele (Management und Entwickler) wird es aufgeschoben, bis es zu einem Hindernis geworden ist, das nicht ignoriert werden kann. In der Zwischenzeit werden Auflösungen nicht oft genug heuristisch vorgenommen. Viele Leute akzeptieren stattdessen eine vorhandene Lösung oder Empfehlung. Diese Praxis beinhaltet Zufall, Annäherung und umgeht einen Großteil des Lernprozesses, der für das Verständnis von entscheidender Bedeutung ist. Nichtverstehen wiederum beeinträchtigt die Fähigkeit, bessere Entscheidungen zu treffen.
Justin
6
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.
Richtig, vor allem die tödliche Kombination aus Ignoranz und Arroganz.
Sklivvz
6
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.
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.)
+1 für die Vorstellung, dass wir dafür bezahlt werden, zuerst Code zu produzieren. Wir haben die zusätzliche Verantwortung, es (subjektiv) wartbar zu machen, zweitens. Immerhin - ich bezahle den Gärtner nicht extra für die Wartung seines Rasenmähers - ist es seine Sache. Wenn er einen guten Job macht und seine Ausrüstung hält, lade ich ihn zurück und gebe ihm mein Geschäft wieder.
Herr JavaScript
4
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.
Ich habe das Programmieren in einer kurzen Sitzung (2 bis 3 Stunden) gelernt. (Eigentlich ein paar Sitzungen mit verschiedenen Sprachen.) Während der Sitzungen wurde sehr guter Code gezeigt und der Grund für das Schreiben des Codes, wie er erklärt wurde, wurde angegeben. Keiner meiner "offiziellen" Sprachkurse kam jemals der Einführung von gutem Code nahe.
BillThor
"Least Resistance" ist ziemlich beschreibend. Erfahrene Programmierer haben nur eine bessere Vorstellung davon, was "geringster Widerstand" über die gesamte Lebensdauer der Anwendung bedeutet.
4
(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.
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! “
Ich bitte die Kunden niemals, Zeit für Unit-Tests bereitzustellen, sondern betrachte dies als Teil des Auftrags. Wenn Sie Ihre Kunden zu Unit-Tests veranlassen, ermutigen Sie sie lediglich, Ihre Arbeit auf kleinstem Raum zu verwalten. Wenn Sie Ihr Auto reparieren lassen, fragen die Mechaniker Sie nicht, welches Werkzeug er verwenden soll, um die Arbeit zu erledigen !! Gleiches gilt für Komponententests. Sie müssen die richtige Balance der Tests beurteilen, die Sie für notwendig halten, um die Arbeit richtig zu erledigen.
Newtopian
Leider sind die besseren Programmiertechniken möglicherweise schneller als die Techniken, deren Verbesserung Sie sich nicht leisten können.
BillThor
2
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.
Antworten:
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:
DeMarco und Lister halten sich weiterhin an das Mantra, bevor sie die Leute auffordern, sich zu ändern:
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.
quelle
Péter Török hat recht, aber einen wichtigen und optimistischen Punkt ausgelassen:
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 .
quelle
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.
quelle
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.
quelle
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.
quelle
Zwei Ursachen
Ignoranz.
Arroganz.
Wie können sie überwunden werden?
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.
quelle
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.
quelle
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.)
quelle
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.
quelle
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 :)
quelle
(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.
quelle
@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! “
quelle
Zwei Teile in den meisten meiner Erfahrungen:
"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.
quelle
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.
quelle
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.
quelle