Ehrlich gesagt, bevorzugen Sie Cowboy-Codierung? [geschlossen]

Die meisten Programmierer, die Methoden verteidigen, die politisch korrekt sind, wie Agile, Waterfall, RUP usw. Einige folgen der Methode, aber nicht alle. Ehrlich gesagt, wenn Sie die Methodik wählen können, würden Sie sicherlich zu den "richtigen" Mainstream-Methodiken wechseln, oder Sie würden die "einfachere" Methodik wie die Cowboy-Programmierung vorziehen? Warum?

Ich weiß, es kommt darauf an. Bitte erläutern Sie, wann Sie den einen oder anderen verwenden würden. Sagen Sie bitte, welche Vorteile Sie bei der Cowboy-Codierung sehen.

Informationen zur Cowboy-Codierung finden Sie auf Wikipedia

Ich denke, fast jeder erfahrene Programmierer hat drei Stufen durchlaufen und einige durchlaufen vier:

1. Cowboy-Programmierer oder -Nuggets wissen kaum etwas über Design und betrachten es als unnötige Formalität. Wenn Sie an kleinen Projekten für nicht-technische Stakeholder arbeiten, kann diese Einstellung für eine Weile hilfreich sein. Es erledigt Dinge, beeindruckt den Chef, gibt dem Programmierer ein gutes Gefühl für sich selbst und bestätigt die Idee, dass er weiß, was er tut (obwohl er es nicht tut).

2. Architektur Astronauten haben das Scheitern ihrer ersten Ball-of-Farn-Projekte erlebt, die sich an veränderte Umstände anpassen. Alles muss neu geschrieben werden, und um zu verhindern, dass in Zukunft ein weiteres Schreiben erforderlich ist , erstellen sie innere Plattformen und verbringen am Ende 4 Stunden pro Tag mit Support, da niemand anderes versteht, wie man sie richtig verwendet.

3. Quasi-Ingenieure verwechseln sich oft mit tatsächlich ausgebildeten Ingenieuren, weil sie wirklich kompetent sind und einige technische Prinzipien verstehen. Sie kennen die zugrunde liegenden Konstruktions- und Geschäftskonzepte: Risiko, ROI, UX, Leistung, Wartbarkeit usw. Diese Menschen sehen Design und Dokumentation als Kontinuum und sind in der Regel in der Lage, das Niveau der Architektur / des Designs an die Projektanforderungen anzupassen.

   An diesem Punkt verlieben sich viele in Methoden, ob sie nun Agile, Waterfall, RUP usw. sind. Sie beginnen an die absolute Unfehlbarkeit und sogar die Notwendigkeit dieser Methoden zu glauben, ohne zu bemerken, dass sie im Bereich der eigentlichen Softwareentwicklung lediglich Werkzeuge sind keine Religionen. Und leider verhindert es, dass sie jemals die letzte Stufe erreichen, nämlich:

4. Klebebandprogrammierer AKA- Gurus oder hochbezahlte Berater wissen innerhalb von fünf Minuten nach Kenntnisnahme der Projektanforderungen, welche Architektur und welches Design sie verwenden werden. Die gesamte Architektur- und Designarbeit findet immer noch statt, ist jedoch auf einer intuitiven Ebene und geschieht so schnell, dass ein ungeübter Beobachter sie für Cowboy-Codierung hält - und viele tun dies auch .

   Im Allgemeinen geht es diesen Leuten nur darum, ein Produkt zu kreieren, das "gut genug" ist, und deshalb sind ihre Arbeiten vielleicht etwas unterentwickelt, aber sie sind meilenweit von dem Spaghetti-Code entfernt, den Cowboy-Codierer produzieren. Nuggets können diese Leute nicht einmal identifizieren, wenn ihnen von ihnen erzählt wird , weil für sie einfach alles, was im Hintergrund passiert, nicht existiert.

Einige von Ihnen werden sich an dieser Stelle wahrscheinlich denken, dass ich die Frage nicht beantwortet habe. Das liegt daran, dass die Frage selbst fehlerhaft ist. Cowboy-Kodierung ist keine Wahl , es ist eine Fähigkeitsstufe , und Sie können sich nicht mehr dafür entscheiden, ein Cowboy-Kodierer zu sein, als Sie sich dafür entscheiden können, Analphabet zu sein.

Wenn Sie ein Cowboy-Programmierer sind, kennen Sie keinen anderen Weg.

Wenn Sie ein Architekturastronaut geworden sind, sind Sie physisch und psychisch nicht in der Lage, Software ohne Design zu produzieren.

Wenn Sie ein Quasi-Ingenieur (oder ein professioneller Ingenieur) sind, ist es eine bewusste Entscheidung, ein Projekt mit geringem oder gar keinem Konstruktionsaufwand abzuschließen (normalerweise aufgrund absurder Fristen), die gegen die offensichtlichen Risiken abgewogen und unternommen werden muss erst nach Zustimmung der Stakeholder (in der Regel schriftlich).

Und wenn Sie ein Klebebandprogrammierer sind, dann gibt es keinen Grund zum "Cowboy-Code", weil Sie ein Qualitätsprodukt genauso schnell erstellen können .

Niemand "bevorzugt" Cowboy-Codierung gegenüber anderen Methoden, da dies keine Methode ist. Es ist das Software-Entwicklungsäquivalent zum Mischen von Knöpfen in einem Videospiel. Für Anfänger ist es in Ordnung, aber jeder, der über diese Stufe hinausgegangen ist, wird es einfach nicht tun. Sie könnten etwas tun, das ähnlich aussieht, aber es wird nicht dasselbe sein.

Ja.

Ich ziehe es auch vor, meine Socken auf dem Boden zu lassen, wo ich sie ausgezogen habe, meinen mit Ausdrucken und alten Snackverpackungen bedeckten Schreibtisch, mein mit schmutzigem Geschirr gefülltes Waschbecken und mein ungemachtes Bett.

Ich halte einen Urlaub, der im Voraus geplant wurde, nicht für einen richtigen Urlaub, eine Mahlzeit, die mit dem Gedanken an eine richtige Ernährung zubereitet wird, oder für einen Aufenthalt auf bekannten Wegen, um richtig zu wandern.

Ich mag es, Spaß zu haben, überrascht zu sein, neue Dinge zu lernen, Fehler zu machen und nie ganz sicher zu sein, ob ich es wieder schaffen werde. Und manchmal ist genau diese Einstellung erforderlich, um ein Projekt auf den Weg zu bringen ...

... aber meistens ist es einfach unverantwortlich. Wenn der Tanz endet, wird der Pfeifer bezahlt ... Vergiss das auf deine Gefahr.

Du bist genau richtig. Dieser "Cowboy-Programmier" -Ansatz bringt möglicherweise die erste Überarbeitung des Codes schneller heraus, aber diese Zeitersparnis geht mehr als verloren, dank:

• Zusätzliche Bugs
• Zusätzliche Zeit benötigt, um die Fehler zu finden, die Sie ohnehin gehabt hätten
• Sie müssen Ihren Code zurückentwickeln, um sich daran zu erinnern, was Sie getan haben, als Sie in sechs Monaten eine Änderung vornehmen mussten
• Zusätzliche Zeit für die Schulung zusätzlicher Entwickler, die an Ihrem Code arbeiten müssen
• Sie haben kein Änderungsprotokoll, auf das Sie zurückblicken können, wenn Sie eine Änderung vornehmen, die etwas kaputt macht
• Ohne Module können Sie diese problemlos in späteren Projekten wiederverwenden
• Und weiter und weiter und weiter

Wie Neil Butterworth in seiner Antwort erwähnt hat, muss man manchmal das tun, was man tun muss. In der Regel ist es jedoch eine sehr schlechte Angewohnheit, Code so schnell wie möglich und ohne Zeitaufwand für die Quellcodeverwaltung, Muster, Dokumentation usw. auszugeben.

Gut für Sie, wenn Sie Ihre Mitarbeiter analysieren und überlegen, ob ihre Gewohnheiten nützlich oder schädlich sind, anstatt blindlings so zu handeln, wie sie es tun.

Es kommt wirklich auf die Frage an, ob Sie die Dinge richtig umsetzen können, ohne dass eine straffe Struktur vorhanden ist und viel Zeit für die Planung aufgewendet wird.

Ich werde hier etwas rauswerfen, das wirklich unbeliebt ist: Kunden wollen im Allgemeinen, dass die Dinge auf Cowboy-Art und Weise gehandhabt werden .

Das heißt, sie möchten verlangen, dass etwas erledigt wird, dass jemand darauf springt, es ausführt und es dort rausholt. Keine Projektverwaltung, Besprechungen, Telefonkonferenzen oder Formulare. TU es einfach. Ich hatte noch nie einen Kunden, der sagte: "Hey, das war ein bisschen zu schnell für unseren Geschmack. Wir würden uns freuen, wenn Sie beim nächsten Mal einen kleinen Wasserfall oder etwas anderes hineinstecken würden."

Team-Methoden und -Strukturen sind so konzipiert, dass sie das Spielfeld eines Projekts ausgleichen und unterschiedliche Ebenen von Entwicklern auf derselben Seite erreichen, die für dieselben Ziele auf dieselbe Weise arbeiten.

Die erfolgreichen "Cowboys", mit denen ich gearbeitet habe, sind in der Lage:

• Identifizieren Sie den einfachsten Weg, um etwas schnell umzusetzen
• Wissen, an welcher Stelle es kaputt gehen wird
• Schreiben Sie sauberen, lesbaren und einfachen Code
• Sagen Sie voraus, wie die Benutzer es verwenden, missbrauchen und zerstören werden
• Skaliere es / abstrahiere es an den richtigen Stellen und gehe nicht als Architektur-Astronaut drauf
• Wissen, wo und wie mit Randfällen und Ausnahmen umgegangen wird

Menschen wie diese erzielen wirklich gute Ergebnisse mit sehr geringem Management- und Strukturaufwand, aber sie sind selten.

EDIT: Als zukünftige Referenz ist meine Antwort für eine andere Frage, die in dieser Frage zusammengefasst wurde. Es ist hier ziemlich fehl am Platz, aber das war nicht mein Anruf.

Sie ist einfach faul, arrogant, ignorant und extrem egoistisch. Dieses Verhalten ist rücksichtslos.

Ich meine, es ist nicht so, dass sie eine unkonventionelle oder vielleicht veraltete Methodik anwendet. Sie benutzt einfach bewusst keine . Keine Standards. Keine Qualitätssicherung. Nein, überhaupt nicht. Woher erwartet sie Softwarequalität? Bäume?
Es ist lustig, dass sie die Erfahrung der Leute, die Sie zitieren, leugnet, wenn sie es ganz offensichtlich nicht hat. Die Angabe überprüfbarer und relevanter Argumente zur Infragestellung ihrer Behauptungen ist gültig. Aber nur zu versuchen, sie zu diskreditieren, indem man ihre Erfahrung leugnet, ist nicht so.

Der wichtigste Punkt ist jedoch: Wie viel Zeit benötigt die Versionskontrolle?
Wenn sie nicht überzeugt werden kann, die 5 Sekunden von Zeit zu Zeit zu investieren, sollten Sie sie zu ihrem Chef bringen. Die Versionskontrolle ist nicht optional. Punkt.

Und sobald sie die Versionskontrolle verwendet, können Sie leicht nachverfolgen, welche Fehler sie eingeschleppt hat. Und lassen Sie sie reparieren. Es ist ihr Chaos, warum solltest du es aufräumen? Wenn sie denkt, dass ihre Herangehensweise besser ist, dann lass es sie tun - den ganzen Weg .
Vorausgesetzt, sie schafft es tatsächlich (in angemessener Zeit), haben Sie immer noch ein Problem: Eine Zusammenarbeit mit ihr ist nahezu unmöglich. Und dies ist etwas, das Sie lösen müssen, indem Sie sie entweder überzeugen (was unwahrscheinlich klingt), sie verlassen (um Ihrer Firma willen) oder verlassen (um Ihrer Gesundheit willen).
Aber ihr Scheitern ist weitaus wahrscheinlicher und sollte definitiv Ihren Standpunkt beweisen. Und dann fängt sie an, sich an bewährte Praktiken zu halten, wie es viele Menschen mit viel Erfahrung tun.

Es kommt ganz darauf an, ob ich alleine oder im Team arbeite.

Wenn ich in einem Team arbeite, sind einige Konventionen und Vereinbarungen erforderlich - jeder im Team muss sich an einen allgemein vereinbarten Standard halten, um auf das gemeinsame Ziel hinzuarbeiten, damit seine Bemühungen vereinbar sind.

Aber wenn ich alleine arbeite, dann möchte ich natürlich Cowboy werden. Alle großartigen Kreationen der Welt wurden von einem einzigen Geist erfunden, oder höchstens von zwei, die im Cowboy-Stil arbeiten. Nur um ein paar zu nennen:

• Klassische Mechanik? Cowboy Isaac Newton, spätere Ergänzungen von Leibniz, Lagrange, Hamilton.
• Flugzeug? Cowboys Wright.
• Relativitätstheorie? Cowboy Albert Einstein.
• Grundlagen der Computerwissenschaft? Cowboy Alan Turing.
• Transistor? Cowboys Walter Brattain und John Bardeen.

Teams sind gut darin, inkrementelle Verbesserungen vorzunehmen und neue Systeme basierend auf bewährten Rezepten relativ schnell zusammenzustellen (vorausgesetzt, sie werden gut geführt), aber es ist selten, von einer tatsächlichen Erfindung eines Teams zu hören. Teamarbeit und die dafür erforderlichen Methoden haben ihre Tugenden, aber auch das Cowboy-Coding.

Kommt auf das Problem an. Ein guter leitender Entwickler wird sehr kompakten, einfachen und robusten Code schreiben, der sehr stabil ist und alle Best Practices verwendet, ohne Seiten mit Dokumentationen und Tonnen von verschiedenen Mustern und Paradigmen durchzublättern. Aber er wird auch wissen, wann er es sich leisten kann, solche Dinge zu tun.

Ich wäre schockiert, wenn er ein neues Problem annehmen und anfangen würde, eine Anwendung zu entwerfen, die von Anfang an Mannmonate erfordert. Wenn es sich jedoch um ein einfaches Plug-in-Tool handelt, das Sie in 2 Stunden schreiben können, eine Funktion, die einige Konvertierungen vornimmt und die nicht für die Wiederverwendung gedacht ist, sind Design und Muster eigentlich nur gut, um Zeit zu verschwenden.

Ich denke auch, dass ein großer Teil des Designs bereits in einem Hintergrund-Thread irgendwo im Kopf des leitenden Entwicklers verarbeitet wurde.

Sie müssen sich Sorgen machen, wenn der leitende Entwickler beginnt, Klassen eines komplexen Systems oder neue Anwendungen von Grund auf neu zu erstellen, und dies ohne Planungsschritt.

Das hängt von den Umständen ab. Beispielsweise bestanden mehrere elektronische Börsen nach einigen katastrophalen Handelsskandalen darauf, dass allen Geschäften Flaggen für den automatischen Handel hinzugefügt wurden. Und das musste für alle Handelssoftware innerhalb einer Woche sein. Ich meine, es musste getan werden - wenn die Flagge nicht da wäre, könntest du nicht handeln. Unter solchen Umständen werden alle guten Praktiken vom Vorstand übernommen - Sie müssen nur (wie wir früher sagten) "hacky, hacky, hacky". Und unter diesen Umständen ist das schnelle und genaue Schreiben von Code der Schlüssel. Zumal es keine Testsysteme gab.

Nach meiner Erfahrung ist Cowboy-Codierung mit Quellcodeverwaltung die beste und fehlerfreieste Möglichkeit, große Softwaresysteme zu entwickeln.

Ich denke, einer der Kommentatoren hatte Recht - es geht nur um die Ergebnisse.

Wenn die Person ein gutes Produkt herstellen kann - etwas, das das tut, was es tun soll, und das wartbar und zuverlässig ist -, was ist dann wichtig, wenn formale Methoden oder Prozesse befolgt werden? Prozesse sind großartig, um die Qualität eines Bodens zu gewährleisten. Wenn jedoch bereits jemand über diesem Boden arbeitet, fügen die Prozesse nichts in die Gleichung ein. Heutzutage scheinen zu viele Entwickler der Meinung zu sein, dass der Sinn der Programmierung darin besteht, sich an Prozesse zu halten, anstatt ein gutes Produkt zu produzieren .

Diese Art von Person wird als Hacker bezeichnet und ist normalerweise kein komplementärer Begriff für den professionelleren unter uns.

Wie Sie bemerkt haben, geht beim Debuggen die Zeit verloren, die bei der Entwicklung, Organisation und Kontrolle gespart wurde. Und oftmals wurde herausgefunden, welche Codeversion tatsächlich ausgeliefert wurde. Wenn du es überhaupt finden kannst!

Ich finde, diese Art von Person ist zu sehr in sich selbst verwickelt, denkt, dass sie zu gut ist, um mit den "Einschränkungen" zu arbeiten, die andere leiden müssen, und kümmert sich nicht darum, und das verliert noch mehr Zeit als der Rest der anderen Team muss nach ihnen aufräumen. Sie sind auch nicht zu sehr in den Fehlerbehebungsprozess involviert (das ist eine Aufgabe des Wartungsentwicklers, weit unter den Fähigkeiten und Talenten des Programmierers).

Vielleicht ist es anderswo eine übliche Vorgehensweise, aber bei mir (und ich bin ein erfahrener Programmierer, der zu dieser Vorgehensweise neigt, ähm) leiden wir nicht darunter. Es ist nicht so, dass wir eine Menge Prozesse und Prozeduren fordern, aber wir bestehen auf einem minimalen Organisationsaufwand und einer Quellcodekontrolle (was ehrlich gesagt verdammt nützlich ist!)

Kent Beck et al. Sind alle Fachleute, die sahen, dass die alten, prozesslastigen Methoden an sich schlecht waren. Sie entwickelten neue Methoden, um das Codieren zu organisieren und es dennoch handwerksorientierter zu halten, und erzählten dann allen anderen davon - indem sie Bücher veröffentlichten ( wie sonst hast du das damals vor dem internet gemacht?)

Du hörst dich so an, als hättest du es richtig gemacht - akzeptiere keine schlechte Übung, nur weil jemand anderes es nicht hacken kann. Ihr Teamleiter oder Manager sollte sich mit diesem "Rockstar" schwer tun, aber wenn das nicht der Fall ist, hindert Sie das immer noch nicht daran, das Richtige zu tun. Akzeptiere nur keine beschissenen Übungen von ihr, wenn sie es vermasselt (und das wird sie!), Dann lass sie es aufräumen. Sie halten an bewährten Methoden fest (und Sie wissen, was sie sind), ohne sie zu Lasten Ihrer Codierungsproduktivität übernehmen zu lassen, und Sie sind gut für die Zukunft.

Hier ist ein Aufsatz von einem wirklich einsichtigen Schriftsteller. Es behebt Ihr Problem nicht, gibt Ihnen jedoch einige Einblicke in die Funktionsweise und möglicherweise einige Tipps, wie Sie es professionell angehen können.

Die einzige wichtige Tatsache sind die langfristigen Produktergebnisse des Teams.

Es wird behauptet, dass ein Team mit einem oder mehreren hervorragenden Programmierern bessere Ergebnisse erzielt als ein Team mit einer noch größeren Anzahl durchschnittlicher Programmierer, die mit einer durchschnittlichen Rate codieren.

Wenn der Cowboy Dinge produziert, die die normalen Programmierer (für einen bestimmten Termin oder eine bestimmte Spezifikation) nicht haben und das Team mit dem Cowboy sogar ein paar Mannwochen / -monate damit verbringen muss, das Chaos des Cowboys aufzuräumen, haben sie möglicherweise immer noch das besseres Ergebnis früher.

Wenn das Team mit dem Cowboy das Durcheinander auch nach vielen Mannmonaten / -jahren nicht bereinigen (dokumentieren, debuggen, integrieren, warten) kann, hat der von ihm geschaffene Fortschritt dem Team auf lange Sicht keinen Vorteil verschafft.

Entscheide welche und optimiere den Kader des Teams.

Nicht jeder Programmierer arbeitet (oder sollte arbeiten) auf die gleiche Weise, solange das Endergebnis gut ist.

Vielleicht finden Sie einen Einblick in meine Antwort auf Frankly. Bevorzugen Sie Cowboy-Codierung? Das Problem ist, dass "Cowboy-Codierung" für verschiedene Personen unterschiedliche Bedeutungen hat und für das ungeübte Auge nicht sofort ersichtlich ist, welche Version Sie sehen.

Wenn sich jemand ein Problem ansieht und sofort schnell und genau mit der Codebearbeitung beginnt, ist dies möglicherweise das Zeichen eines Meistertechnikers, der es tausendmal zuvor gesehen hat und bereits weiß, wie das Problem am besten gelöst werden kann.

Oder es kann das Zeichen eines Amateurrangs sein.

Ich werde Ihnen eines sagen: Die Ablehnung der Versionskontrolle oder das Schreiben von Tests, weil sie zu "akademisch" sind, ist definitiv kein "vorrangiger" oder sogar professioneller Ansatz. Sie werden so etwas niemals in einem großen Softwarehaus wie Microsoft oder Google sehen und wahrscheinlich auch nicht in den meisten Startups oder einigermaßen ausgereiften Unternehmensteams.

Die Risiken sind einfach zu groß. Was ist, wenn Ihr PC über Nacht stirbt? Tschüss 3 Jahre Produktivität. Okay, so machen Sie Backups; Was passiert dann, wenn Sie eine größere Änderung vornehmen, erkennen, dass sie völlig falsch war, und sie rückgängig machen müssen? Dies passiert selbst den erfahrensten und talentiertesten Entwicklern, da die Anforderungen falsch sind. Wenn Sie keine Versionskontrolle betreiben, drehen Sie einfach Ihre Räder im Schlamm. Ich war schon einmal dort und würde nie zurückkehren.

Es gibt einfach keine Entschuldigung - es dauert 10 Minuten, um ein Repository einzurichten, und 10 Sekunden, um ein Commit auszuführen. Es macht vielleicht 1% Ihrer gesamten Entwicklungszeit aus. Tests können, wenn Sie es eilig haben, leicht auf 20 bis 30 Minuten pro Tag reduziert werden und sind dennoch einigermaßen nützlich.

Ich bin kein Fan von Agilen Methoden (beachte das A), aber manchmal muss man wirklich nur die Ärmel hochkrempeln und anfangen, den verdammten Code zu schreiben. Ich habe Leute und Teams mit "Analyse-Lähmungen" gesehen, und die Produktivität ist wirklich sichtbar. Aber die Entlassung der grundlegenden Werkzeuge unseres Fachs wie Revisionskontrolle und Tests ist für mich wirklich der Ausschlag. Diese Person gehört nicht in eine leitende Position.

Ja, aber Sie müssen erkennen, wann Sie es NICHT tun müssen.

Auf etwas Kleinem geht es Ihnen wahrscheinlich gut, aber wenn Sie etwas Komplexes, Gefährliches, Eingeschränktes usw. haben, müssen Sie in der Lage sein, zu erkennen, wann ein korrektes Design die zusätzliche Zeit wert ist.

Ich denke auch, Sie sollten Aaronaughts Antwort auf jeden Fall überdenken. Cowboy bedeutet für verschiedene Menschen verschiedene Dinge.

Wenn ich an "traditionelle" Methoden denke, denke ich, dass "das Management nicht weiß, wie man Entwickler versteht, und statt in die Entwicklerwelt einzusteigen und genug zu verstehen, um zu wissen, was vor sich geht, bringen sie die Entwickler in ihre Welt".

Grundsätzlich denke ich, wenn ich an "Agil" denke, dass Sie "das tun, was Sie tun müssen, um die Ineffizienzen zu minimieren, die durch die Zusammenarbeit mehrerer Personen hervorgerufen werden." Also ich bin fest im Lager , dass „es gibt nicht so etwas wie THE Agile Methodology , nur eine Reihe von Werten und Prinzipien“.

Mit anderen Worten, es gibt Dinge, die Sie in einem sehr großen Projekt tun müssen, und es gibt Dinge, die Sie in kleinen Projekten tun müssen, und es gibt Dinge, die Sie in beiden Projekten tun müssen.

Zum Beispiel hätte ich nicht mehr als den einfachsten Rückstand für ein Projekt, an dem ich gerade arbeite ... Es wäre nur eine To-Do-Liste. Wenn wir zu zweit wären, hätte ich diese Liste wahrscheinlich geteilt, aber in einem sehr einfachen Format (wahrscheinlich nur eine Notiz, die in unserem Code-Repository gespeichert ist). Sobald ich 3 oder 4 habe, suche ich nach einer Art Workitem-System.

Nur beim Prototyping von sehr einfachen Features.

Sobald dies erledigt und der richtige Weg erwogen wurde, habe ich den Code fallen lassen und werde ernst.

Ich habe es einmal bei einem echten Projekt gemacht (zu der Zeit, als wir es Samurai-Programmierung nannten, nach der Samurai-Tailor-Skizzenserie in Saturday Night Live), und zu meinem Erstaunen hat es gut geklappt. Natürlich war das, womit ich angefangen habe, Müll, daher bestand nur ein geringes Risiko, es noch schlimmer zu machen.

Ich bin jedoch ein "ordentliches" Wesen und mag den "Shoot-from-the-Hip" -Entwicklungsstil nicht.

Auf der anderen Seite ist ein stark prozesslastiger Modus operandi auch nicht nach meinem Geschmack. Ich plane einfach gerne, bevor ich handeln kann.

Alles in allem bin ich der Meinung, dass der Umfang des angemessenen formalen Prozesses stark von der Größe (Größe des Codes, Dauer des Projekts, Anzahl der Entwickler, Art der Anforderungen usw.) des Projekts abhängt. Ich möchte, dass Menschen, die Software für Avionik- oder biomedizinische Geräte entwickeln, strenge und strenge Kriterien auferlegt werden, z. B. dass bei Spielen die Nachteile von Fehlern weitaus geringer sind, sodass die Kosten und die Belastung durch strenge und methodische Entwicklungspraktiken nicht wirklich hoch sind gerechtfertigt.

Es hängt (stark) von der Größe des Projekts ab. Auf der einen Seite ein ordentliches Ergebnis , das Sie benötigen , um haben ein Design. Auf der anderen Seite, wenn das Projekt klein genug ist, um das gesamte Design zu konzipieren (das meiste davon sowieso), ohne es aufzuschreiben, Diagramme zu zeichnen usw., dann geht es Ihnen wahrscheinlich genauso gut ohne die zusätzliche Arbeit von dokumentiere alles was du tust.

Fast jeder hat genug Horrorgeschichten gehört, um zu erkennen, dass der Versuch, ohne eine klare Vorstellung davon, was Sie tun und wohin die Dinge gehen, ein Rezept für eine Katastrophe ist. Viel seltener wird darauf hingewiesen, dass das Gegenteil ebenso katastrophal sein kann. Zum Beispiel schreiben die meisten von uns routinemäßig kleine Werkzeuge in den Programmierprozess. Das Schreiben einer vollständigen Spezifikation, Tests und Dokumentation lohnt sich oft nicht. Es gibt eine Schwelle, unterhalb derer sich eine Produktivitätssteigerung nicht lohnt - Menschen mögen es oft nicht, das Rad neu zu erfinden, aber in einigen Fällen ist es einfacher, es neu zu erfinden, als es zu vermeiden.

In Fällen wie diesen, was oft ist ist sinnvoll , eine Bibliothek productizing diese leicht zu machen Aufgaben wie. Dadurch wird der Front-End-Code häufig so trivial, dass das Schreiben (oder Ändern) von Code für die gewünschten Aufgaben einfacher ist als das Heraussuchen, wie ein vollständiges Programm für die gewünschten Aufgaben erstellt werden kann. Betrachten Sie zum Beispiel Gnu Indent mit seinen über 50 verschiedenen Flags, von denen viele auf subtile Weise interagieren. Die einzig sinnvolle Wahl ist also, 1) es überhaupt nicht zu verwenden oder 2) zu entscheiden, was es Ihnen gibt anstatt zu versuchen, das zu bekommen, was Sie ursprünglich wollten.

Es scheint zwei Lager zu geben - diejenigen, die Ergebnisse befürworten, und diejenigen, die Grundsätze befürworten. Ich falle in letzteres.

Ich bin ein mittelmäßig , aber wohl gewissenhaft Programmierer - mein Hauptanliegen bei der Codierung, über den Job zu erledigen, ist , dass ich helfen , wer auch immer meinen Code verwendet , um ihre Arbeit zu erledigen. Ich kann nicht sagen, dass ich das immer erreicht habe - aber das ist mein Ziel.

Sicher, Sie haben vielleicht einen Hotrod in Ihrem Team - aber was passiert, wenn sie ein paar Wochen Urlaub haben und gebeten werden, ihre Arbeit zu debuggen oder Sachen hinzuzufügen? Letztendlich sind Cowboy-Programmierer keine Teamplayer. Sie machen vielleicht großartigen Code, aber wenn das Team von ihnen abhängt, ist das gefährlich.

Ich habe das Gefühl, dass Ihre Abneigung gegen ihren Stil dazu führt, dass Sie ihn leicht falsch darstellen. Sie sagen, der Cowboy-Ansatz wird beim Debuggen bezahlt - geschieht dies bereits, oder ist dies Ihre Annahme, wie es ausgehen wird?

Faire Offenlegung - Ich bin selbst ein leitender Entwickler und verzichte oft auf einen formalen Prozess für Design und praktische Erfahrungen. Es ist durchaus üblich, für jemanden, der in der Problemdomäne sehr erfahren ist, keinen formellen Prozess zu haben. Wenn Sie ein Problem Dutzende Male gelöst haben, brauchen Sie keinen formalen Prozess, um eine ähnliche Lösung erneut zu formulieren.

Ein formaler Prozess befasst sich mit der Gestaltung von Code - ich verstehe nicht, warum mehr Fehler eingeführt werden sollten, weil ein formaler Prozess fehlt. Das einzige große Problem, das ich in Ihrem Konto gelesen habe, ist, dass die Revisionskontrolle nicht verwendet wird - was nicht nur egoistisch, sondern ausgesprochen rücksichtslos im Namen des Entwicklers ist. Verpflichtet sie sich überhaupt nicht oder nur nicht nach einem Muster, das Ihnen gefällt?

Keine formale Herangehensweise an das Design zu haben, ist in meinem Buch keine „Cowboy-Codierung“ (es wird jedoch keine Revisionskontrolle verwendet). Die Erfahrung sollte genau dafür genutzt werden - um die Zeit zu verkürzen, die für die Entwicklung einer „ausreichend guten“ Lösung erforderlich ist. Denken Sie daran, dass Sie die Probleme, die Sie derzeit haben, lösen und den Code leicht ändern müssen, und nicht für zukünftige Szenarien entwerfen müssen, die möglicherweise niemals auftreten werden. Mit der Erfahrung bekommt man ein gutes Gefühl dafür, wie man das sehr schnell macht.

Nein niemals.

Ich mache immer eine Anforderungsanalyse, denke über Architektur nach, entwerfe die Details und programmiere dann. Auch wenn ich alleine zu Hause für ein persönliches Projekt arbeite.

Und ich würde sofort einen Entwickler in meinem Team entlassen, wenn er / sie im Cowboy-Stil arbeiten würde. Wir sind Ingenieure und tragen Verantwortung gegenüber Kunden und Anwendern.

Ich denke nicht, dass Cowboy-Codierung ein vorrangiger Ansatz ist.

Wie andere bereits gesagt haben, besteht eine echte Gefahr darin, die Versionskontrolle zu verwerfen. Das Überspringen von Dokumentation und Analyse kann auch bedeuten, das Risiko einzugehen, dass etwas geliefert wird, das der Benutzer nicht möchte. Nur meine Meinung, aber ich glaube nicht, dass Sie vom "Programmierer zum Entwickler" wechseln, wenn Sie nur Cowboy-Code verwenden.

Es gibt jedoch Ausnahmen wie die, die Neil Butterworth erwähnt. Und in diesen Situationen hätte ich lieber einen erfahrenen Senior-Entwickler, der die Cowboy-Codierung übernimmt.

Cowboy-Programmierung ist ein ziemlich sicherer Weg, eine große Schlammkugel zu erschaffen . Was, so unangenehm es auch klingt, dazu neigt, ...

Ich denke, neuere Programmierer neigen dazu, einige Cowboy - Codierungsaufgaben zu erledigen, wenn sie Aspekte eines Projekts / eines Bereichs übernehmen, mit denen sie möglicherweise nicht viel Erfahrung haben, oder wenn sie versuchen, aufgrund des Drucks eines Chefs usw Ich weiß, dass ich diesen Weg auf jeden Fall ein paar Mal gegangen bin, weil ich das richtige Muster nicht kannte und mich einfach "durchgeschlagen" habe.

Der Unterschied zwischen mir und der Person, über die Sie sich beschweren, besteht darin, dass ich in der Regel bald feststellen muss, dass ich es hätte besser machen und besser warten können, und dass es mich in der Regel anspornt, mehr zu lernen und meine Fähigkeiten zu verbessern (durch Lesen von Büchern / Artikeln im Internet) Gegenstand). Wenn ich zurückgehe, um einige dieser gehackten Lösungen zu debuggen, empfinde ich es normalerweise als einen Schmerz und es trägt mehr dazu bei, dass ich lernen möchte, wie man es "richtig" macht. Ich denke, diese Person, die Sie beschreiben, ist im Grunde genommen auf einer infantilen Ebene der Selbstreflexion festgefahren, und es scheint nicht so, als würde ich mit jemandem arbeiten wollen, mit dem das eigene Ego die Verbesserung seiner Fähigkeiten als Softwareentwickler behindert.

Ich finde deinen Beitrag interessant. Ich habe oft Ansichten mit Ihrem Thema geteilt, und sie hat das Gefühl, dass überformalisierte Methoden ersticken. Wie jemand anderes bemerkt, ist es durchaus möglich, wenn sie ein Genie ist und eine Vielzahl von mentalen Notizen gleichzeitig nachverfolgen kann, ohne zu vergessen oder verwirrt zu werden, einen monolithischen Teil des verschachtelten Codes beizubehalten und ihn dazu zu bringen, erstaunliche Dinge mit völlig undurchsichtigen Veränderungen zu tun . Es gibt ein gewisses geistiges Glück, das in die Gehirne der Menschen gelangt, die das können - es ist, als ob Sie ein Gott eines kleinen Universums in Ihrem Kopf wären.

Kluge Arbeitgeber haben jedoch auf die harte Tour gelernt, dass nur der ursprüngliche Autor jemals etwas tun kann, das sich für diesen Code lohnt. Wenn der Programmierer weitermacht, verschwendet er eine Menge Geld, indem er herausfindet, dass die einzige Möglichkeit darin besteht, neu zu schreiben (ich dachte früher, das bedeutete Totalverlust, aber mir ist heutzutage klar, dass man das eigentliche Ergebnis von nicht zerstört iterative Entwicklung auf der Ebene der externen Funktionalität).

Persönlich würde es mir nichts ausmachen, jemanden wie diesen im Team zu haben, denn in einer Krise könnten sie etwas tun, an das sonst niemand denkt.

Sei auf der anderen Seite deine eigene Person und entscheide selbst, wie die Antwort auf deine Frage lautet, denn das Einzige, was sicher ist, ist, dass niemand es herausgefunden hat, wenn es darum geht, Software zu erstellen. Es ist eines der Dinge, die es zu einem interessanten Gebiet machen ...