wake-up-neo.net

Ehrlich gesagt, bevorzugen Sie Cowboy-Codierung?

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

Ich weiß, es kommt darauf an. Bitte erläutern Sie, wann Sie das eine oder andere verwenden würden. Bitte sagen Sie, welche Vorteile Sie bei der Cowboy-Codierung sehen.

Siehe über Cowboy-Codierung auf Wikipedia

68
Maniero

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

  1. Cowboy-Codierer oder Nuggets wissen wenig bis gar nichts über Design und sehen es als eine unnötige Formalität. Wenn sie an kleinen Projekten für nichttechnische Interessengruppen arbeiten, kann diese Haltung ihnen für eine Weile gute Dienste leisten. es erledigt Dinge, es beeindruckt den Chef, lässt den Programmierer sich gut fühlen und bestätigt die Idee, dass er weiß, was er tut (obwohl er es nicht tut).

  2. Architektur Astronauten haben die Misserfolge ihrer ersten Wollknäuelprojekte bei der Anpassung an sich ändernde Umstände miterlebt. Alles muss neu geschrieben werden und um zu verhindern, dass ein anderes in Zukunft neu geschrieben werden muss, erstellen sie innere Plattformen und verbringen am Ende 4 Stunden am Tag mit Support, weil niemand sonst versteht, wie man sie richtig einsetzt.

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

    An diesem Punkt verlieben sich viele in Methoden, egal ob Agile, Waterfall, RUP usw. Sie glauben an die absolute Unfehlbarkeit und sogar an die Notwendigkeit dieser Methoden, ohne dies im = zu bemerken aktuell Software-Engineering-Bereich, sie sind nur Werkzeuge, 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 Anhörung der Projektanforderungen, welche Architektur und welches Design sie verwenden werden. Die gesamte Architektur- und Designarbeit findet noch statt, aber sie ist intuitiv und so schnell, dass ein ungeübter Beobachter sie für Cowboy-Codierung halten würde - und viele tun es.

    Im Allgemeinen geht es bei diesen Leuten nur darum, ein Produkt zu entwickeln, das "gut genug" ist, und daher sind ihre Werke vielleicht etwas unterentwickelt, aber sie sind Meilen vom Spaghetti-Code entfernt, der von Cowboy-Codierern erzeugt wird. Nuggets können diese Personen nicht einmal identifizieren, wenn sie über sie erzählt werden, weil für sie einfach nicht alles existiert, was im Hintergrund passiert.

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-Codierung ist keine Wahl, sondern eine Fähigkeitsstufe, und Sie können sich nicht mehr dafür entscheiden, ein Cowboy-Codierer zu sein, als Sie sich entscheiden können Analphabet.

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

Wenn Sie ein Architekturastronaut geworden sind, sind Sie physisch und psychisch unfähig Software ohne Design zu produzieren.

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

Und wenn Sie ein Klebebandprogrammierer sind, gibt es keinen Grund, "Cowboy-Code" zu verwenden, da Sie ein Qualität Produkt genauso schnell erstellen können.

Niemand "bevorzugt" die Cowboy-Codierung gegenüber anderen Methoden, da dies keine Methode ist. Es ist das Softwareentwicklungsäquivalent zum Drücken von Tasten in einem Videospiel. Es ist in Ordnung für Anfänger, aber jeder, der diese Phase überschritten hat, wird es einfach nicht tun. Sie könnten etwas tun, das sieht ähnlich aus, aber es wird nicht dasselbe sein.

204
Aaronaught

Ja.

Ich lasse meine Socken auch lieber auf dem Boden liegen, wo ich sie ausgezogen habe, meinen Schreibtisch mit Ausdrucken und alten Snackverpackungen bedeckt, mein Waschbecken voller schmutzigem Geschirr und mein Bett ungemacht.

Ich betrachte einen im Voraus geplanten Urlaub nicht als einen richtigen Urlaub, eine Mahlzeit, die mit dem Gedanken an die richtige Ernährung gegessen wird, oder einen Aufenthalt auf bekannten Wegen, auf denen man richtig wandern kann.

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 zurück schaffen werde. Und manchmal ist diese Einstellung genau , was erforderlich ist, 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.

46
Shog9

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

  • Zusätzliche Fehler
  • Zusätzliche Zeit benötigt, um die Fehler zu finden, die Sie sowieso gehabt hätten
  • Sie müssen Ihren Code zurückentwickeln, um sich daran zu erinnern, was Sie getan haben, wenn Sie in sechs Monaten eine Änderung vornehmen müssen
  • Zusätzliche Zeit für die Schulung zusätzlicher Entwickler, die an Ihrem Code arbeiten müssen
  • Sie haben kein Revisionsprotokoll, 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 ohne Zeitaufwand für Quellcodeverwaltung, Muster, Dokumentation usw. zu veröffentlichen.

Gut für Sie, wenn Sie Ihre Mitarbeiter analysieren und überlegen, ob ihre Gewohnheiten nützlich oder schädlich sind, anstatt blind zu tun, was sie tun.

31
Warren Pena

Dies hängt wirklich von der Frage ab, ob Sie die Dinge korrekt implementieren können, ohne dass eine enge Struktur vorhanden ist und viel Zeit für die Planung aufgewendet wird.

Ich werde hier etwas rauswerfen, das wirklich unbeliebt sein könnte: Kunden wollen im Allgemeinen, dass die Dinge auf Cowboy-Art gehandhabt werden.

Das heißt, sie möchten verlangen, dass etwas erledigt wird, und dass jemand darauf springt, es ausführt und es dort herausbringt. Kein Projektmanagement, Besprechungen, Telefonkonferenzen oder Formulare. TU es einfach. Ich habe noch nie einen Kunden sagen lassen: "Hey, das wurde für unseren Geschmack etwas zu schnell gemacht. Wir würden uns freuen, wenn Sie beim nächsten Mal einen kleinen Wasserfall oder etwas anderes hineinstecken würden.".

Teammethoden und -strukturen dienen dazu, die Wettbewerbsbedingungen eines Projekts zu verbessern und unterschiedliche Entwicklerebenen auf derselben Seite zu erreichen, die auf dieselbe Weise für dieselben Ziele arbeiten.

Die erfolgreichen "Cowboys", mit denen ich gearbeitet habe, können:

  • Identifizieren Sie den einfachsten Weg, um etwas schnell zu implementieren
  • Wissen, an welchem ​​Punkt es brechen wird
  • Schreiben Sie sauberen, lesbaren und unkomplizierten Code
  • Sagen Sie voraus, wie die Benutzer es verwenden, missbrauchen und brechen werden
  • Skalieren Sie es/abstrahieren Sie es an den richtigen Stellen und gehen Sie nicht auf Architekturastronauten
  • Wissen, wo und wie mit Edge-Fällen und Ausnahmen umgegangen wird

Leute wie diese erzielen wirklich großartige Ergebnisse mit sehr wenig Verwaltungs- und Strukturaufwand, aber sie sind selten.

29
Brandon

EDIT: Zum späteren Nachschlagen ist meine Antwort für eine andere Frage, die in diese zusammengeführt wurde. Es ist hier ziemlich fehl am Platz, aber das war nicht mein Anruf.


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

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

Der wichtigste Punkt ist jedoch: Wie viel Zeit benötigt die Versionskontrolle?
Wenn sie nicht überzeugt sein kann, ab und zu die 5 Sekunden 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 eingeführt hat. Und lassen Sie sie sie reparieren. Es ist ihr Durcheinander, warum solltest du es aufräumen? Wenn sie denkt, dass ihr Ansatz besser ist, dann lass sie es tun - den ganzen Weg.
Vorausgesetzt, sie kann es tatsächlich (innerhalb angemessener Zeit), haben Sie immer noch ein Problem: Teamwork 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 lassen (um Ihrer Firma willen) oder gehen (um Ihrer Gesundheit willen).
Aber ihr Versagen ist weitaus wahrscheinlicher und sollte definitiv Ihren Standpunkt beweisen. Und dann wird sie anfangen, sich an Best Practices zu halten, wie es viele Leute mit viel Erfahrung tun.

13
back2dos

Es hängt ganz davon ab, ob ich alleine oder im Team arbeite.

Wenn ich in einem Team arbeite, sind einige Konventionen und Vereinbarungen erforderlich - jeder im Team muss einige gemeinsam vereinbarter Standard, um auf das gemeinsame Ziel hinzuarbeiten, damit ihre Bemühungen vereinbar sind.

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

  • Klassische Mechanik? Cowboy Isaac Newton, spätere Ergänzungen aus Leibniz, Lagrange, Hamilton.
  • Flugzeug? Cowboys Wright.
  • Relativitätstheorie? Cowboy Albert Einstein.
  • Grundlagen der Computer? 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 ziemlich schnell zusammenzustellen (vorausgesetzt, sie werden gut geführt), aber es kommt selten vor, dass ein Team tatsächlich erfindet. Teamarbeit und die erforderlichen Methoden haben ihre Tugenden, aber auch die Cowboy-Codierung.

11
Joonas Pulakka

Kommt auf das Problem an. Ein guter leitender Entwickler schreibt sehr kompakten, einfachen und robusten Code, der sehr stabil ist und alle Best Practices verwendet, ohne Seiten mit Dokumentationen und Tonnen verschiedener Muster und Paradigmen durchzublättern. Er wird aber 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 Mannmonate von Grund auf benötigt. Wenn es sich jedoch um ein Plugin handelt, ein einfaches Tool, das Sie in 2 Stunden schreiben können. Diese Funktion führt einige Konvertierungen durch und ist nicht für die Wiederverwendung vorgesehen. Design und Muster sind 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 der leitenden Entwickler verarbeitet wurde.

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

7
Coder

Es hängt von den Umständen ab. Beispielsweise bestanden mehrere elektronische Börsen nach einigen katastrophalen Handelsskandalen darauf, dass allen Trades Auto-Trading-Flaggen 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önnte man nicht handeln. Unter solchen Umständen gehen alle guten Praktiken an der Tafel vorbei - Sie müssen nur (wie wir früher sagten) "hacky, hacky, hacky" sagen. Unter diesen Umständen ist das schnelle und genaue Schreiben von Code der Schlüssel. Zumal es keine Testsysteme gab.

6

Aus meiner Erfahrung heraus ist Cowboy-Codierung MIT Quellcodeverwaltung der beste und fehlerfreieste Weg, um große Softwaresysteme zu entwickeln.

5
jojo

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

Wie Sie bemerkt haben, geht beim Debuggen Zeit für Design, Organisation und Kontrolle verloren. Und oft bei der Suche nach der tatsächlich ausgelieferten Code-Version. Wenn Sie es überhaupt finden können!

Ich finde, diese Art von Person ist zu sehr in sich selbst verwickelt, denke, sie ist zu gut, um mit den „Einschränkungen“ zu arbeiten, unter denen andere leiden müssen, und kümmere mich nicht um sie, und das verliert noch mehr Zeit als der Rest der Menschen Team muss nach ihnen aufräumen. Sie sind auch nicht zu sehr in den Fehlerbehebungsprozess involviert (dies ist eine Aufgabe des Wartungsentwicklers, die weit unter den Fähigkeiten und dem Talent des Codierers liegt).

Es mag also anderswo ein gängiger Ansatz sein, aber bei mir (und ich bin ein erfahrener Programmierer, der Tendenzen zu diesem Ansatz hat, ähm) leiden wir nicht darunter. Es ist nicht so, dass wir eine Menge Prozesse und Verfahren fordern, aber wir bestehen auf einem Minimum an Organisation und Quellcode-Kontrolle (was ehrlich gesagt blutig östlich und verdammt nützlich ist!)

Kent Beck et al. Sind alle Fachleute, die sahen, dass die alten prozessgeladenen Methoden an sich schlecht waren. Deshalb haben sie neue Methoden entwickelt, um das Codieren zu organisieren und es dennoch handwerklicher zu gestalten, und dann allen anderen davon erzählt darüber - durch die Veröffentlichung von Büchern (wie haben Sie es damals noch vor dem Internet gemacht?)

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

Hier ist ein Aufsatz von einem wirklich aufschlussreichen Schriftsteller. Es behebt Ihr Problem nicht, gibt Ihnen aber ein paar Einblicke, warum es so ist, und vielleicht ein paar Tipps, wie Sie professionell damit umgehen können.

4
gbjbaanb

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

Wenn die Person ein gutes Produkt produzieren kann - etwas, das das tut, was es tun soll, und wartbar und zuverlässig ist - was ist dann wichtig, wenn formale Methoden oder Prozesse befolgt werden ? Prozesse sind großartig, um einen Boden in Qualität 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 zu denken, dass der Punkt der Programmierung darin besteht, sich an Prozesse zu halten, im Gegensatz zu Produzieren ein gutes Produkt.

4
GrandmasterB

Vielleicht finden Sie einen Einblick in meine Antwort auf Ehrlich gesagt, bevorzugen Sie Cowboy-Codierung? Das Problem ist, dass "Cowboy-Codierung" für verschiedene Menschen verschiedene Dinge bedeutet und für das ungeübte Auge nicht sofort offensichtlich ist. welche Version du siehst.

Wenn jemand ein Problem untersuchen und sofort damit beginnen kann, schnell und genau Code auszugeben, ist dies kann das Zeichen eines Meisteringenieurs, der alles tausendmal zuvor gesehen hat und bereits das Beste weiß Weg, um das Problem zu lösen.

Oder es kann das Zeichen eines Rangamateurs sein.

Ich werde Ihnen eines sagen: Die Weigerung, Versionskontrolle zu verwenden oder Tests zu schreiben, weil sie zu "akademisch" sind, ist definitiv nicht ein "älterer" oder sogar entfernt professioneller Ansatz. Sie werden niemals so etwas in einem großen Software-Shop wie Microsoft oder Google sehen und werden es wahrscheinlich auch in den meisten Startups oder einigermaßen ausgereiften Unternehmensteams nicht sehen.

Die Risiken sind einfach zu groß. Was ist, wenn Ihr PC über Nacht stirbt? Tschüss 3 Jahre Produktivität. Okay, Sie erstellen Backups. Was passiert dann, wenn Sie eine größere Änderung vornehmen, feststellen, dass sie völlig falsch war, und sie zurücksetzen müssen? Dies passiert sogar den erfahrensten und talentiertesten Entwicklern, weil die Anforderungen falsch sind. Wenn Sie keine Versionskontrolle durchführen, drehen Sie einfach Ihre Räder im Schlamm. Ich war einmal dort und würde nie zurückkehren.

Es gibt einfach keine Entschuldigung - das Einrichten eines Repositorys dauert 10 Minuten und das Festschreiben 10 Sekunden. 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 (beachten Sie die Hauptstadt A), aber manchmal müssen Sie wirklich nur die Ärmel hochkrempeln und anfangen, den verdammten Code zu schreiben. Ich habe Leute und Teams mit "Analyse-Lähmung" gesehen, und die Produktivität ist wirklich sichtbar. Aber die Entlassung der grundlegenden Werkzeuge unseres Fachs wie Revisionskontrolle und Tests ist wirklich der Clou für mich; Diese Person gehört nicht in eine leitende Position.

3
Aaronaught

Die einzige wichtige Tatsache sind die langfristigen Produktergebnisse des Teams.

Es wird behauptet, dass ein Team mit einem großartigen Programmierer (oder mehr) 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 regulären Programmierer nicht haben (für einen bestimmten Termin oder eine bestimmte Spezifikation), und das Team mit dem Cowboy sogar ein paar Mannwochen/Monate damit verbringen muss, das Chaos des Cowboys zu beseitigen, könnten sie immer noch mit dem enden besseres Ergebnis früher.

Wenn das Team mit dem Cowboy das Chaos auch nach vielen Monaten/Jahren nicht bereinigen (dokumentieren, debuggen, integrieren, warten) kann, hat der vom Cowboy geschaffene Fortschritt dem Team keinen langfristigen Vorteil verschafft.

Entscheiden Sie, welche und optimieren Sie den Kader des Teams.

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

3
hotpaw2

Wenn ich an "traditionelle" Methoden denke, denke ich, dass "das Management nicht weiß, wie man Entwickler versteht. Anstatt in die Entwicklerwelt zu kommen und genug zu verstehen, um zu wissen, was los ist, lassen sie die Entwickler in ihre Welt kommen".

Wenn ich an "Agile" denke, denke ich grundsätzlich: "Sie tun, was Sie tun müssen, um die Ineffizienzen zu minimieren, die durch die Zusammenarbeit mehrerer Personen entstehen." Ich bin also fest im Lager, dass "es keine DIE Agile Methodik , nur eine Reihe von Werten und Prinzipien ".

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

Zum Beispiel hätte ich nicht mehr als die einfachsten Rückstände für ein Projekt, an dem ich selbst arbeite ... Es wäre nur eine To-Do-Liste. Wenn wir zu zweit sind, würde ich diese Liste wahrscheinlich gemeinsam nutzen, 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.

2
MIA

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

Bei kleinen Dingen geht es Ihnen wahrscheinlich gut, aber wenn Sie etwas Komplexes, Gefährliches, Eingeschränktes usw. haben, müssen Sie erkennen können, wann ein richtiges Design die zusätzliche Zeit wert ist.

Ich denke auch, dass Sie Aaronaught's Antwort auf jeden Fall durchdenken sollten. Cowboy bedeutet für verschiedene Menschen verschiedene Dinge.

2
Bill

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 - passiert das bereits, oder ist das 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 Erfahrung. Es ist durchaus üblich, keinen formellen Prozess für jemanden zu haben, der auf dem Gebiet der Probleme sehr erfahren ist. Wenn Sie ein Problem Dutzende Male gelöst haben, benötigen Sie keinen formalen Prozess, um eine ähnliche Lösung erneut zu formulieren.

Ein formaler Prozess befasst sich mit dem Design 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 im Namen des Entwicklers geradezu rücksichtslos 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 „gut genug“ -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 nie auftreten werden. Mit der Erfahrung bekommt man ein gutes Gefühl dafür, wie man das sehr schnell macht.

1
Eran Galperin

Es scheint zwei Lager zu geben - diejenigen, die Ergebnisse bevorzugen, und diejenigen, die Prinzipien bevorzugen. Ich falle in letzteres.

Ich bin ein mittelmäßiger, aber wohl gewissenhafter Programmierer - mein Hauptanliegen beim Codieren, darüber hinaus die Arbeit zu erledigen, ist, dass ich jedem helfe, der 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 vielleicht haben eine Hotrod in Ihrem Team - aber was passiert, wenn sie ein paar Wochen Urlaub nehmen und Sie gebeten werden, ihre Arbeit zu debuggen oder Dinge hinzuzufügen? Letztendlich sind Cowboy-Programmierer keine Teamplayer. Sie können großartigen Code erstellen, aber wenn das Team von ihnen abhängt, ist dies gefährlich.

1
sunwukung

Nur beim Prototyping sehr einfacher Features.

Sobald ich fertig bin und über den richtigen Weg nachgedacht habe, lasse ich den Code fallen und werde ernst.

1
Klaim

Ich habe es einmal bei einem echten Projekt gemacht (zu der Zeit, als wir es Samurai Programming nannten, nach der Samurai Tailor-Serie von Skizzen in Saturday Night Live), und zu meinem Erstaunen hat es gut geklappt. Ich habe natürlich mit Müll angefangen, daher bestand nur ein geringes Risiko, dass es noch schlimmer wurde.

Ich bin jedoch im Herzen "ordentlich" und mag den Shoot-from-the-Hip-Entwicklungsstil nicht.

Andererseits ist ein stark prozessgeladener Modus Operandi auch nicht nach meinem Geschmack. Ich plane einfach gerne, bevor ich handle.

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 die Software für Avionik- oder biomedizinische Geräte entwickeln, z. Bei Spielen gibt es beispielsweise weitaus weniger Nachteile bei Fehlern, sodass die Kosten und die Belastung durch strenge und methodische Entwicklungspraktiken nicht wirklich gerechtfertigt sind.

1
Randall Schulz

Dies hängt (stark) von der Größe des Projekts ab. Einerseits müssen Sie ein Design haben, um ein anständiges Ergebnis zu erzielen. Auf der anderen Seite, wenn das Projekt klein genug ist, dass Sie das gesamte Design konzipieren können (das meiste davon sowieso), ohne es aufzuschreiben, Diagramme zu zeichnen usw., dann sind Sie wahrscheinlich ohne diese zusätzliche Arbeit von genauso gut dran alles dokumentieren, was Sie tun.

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, einzuspringen, 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 während des Programmierprozesses. Das Schreiben einer vollständigen Spezifikation, Tests und Dokumentation lohnt sich oft nicht. Es gibt eine Schwelle, unterhalb derer sich die Produktisierung 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 solchen Fällen lohnt es sich oft , eine Bibliothek zu erstellen, um Aufgaben wie diese zu vereinfachen. Dadurch wird der Front-End-Code oft so trivial, dass das Schreiben (oder Ändern) von Code, um das zu tun, was Sie wollen, einfacher wird, als herauszufinden, wie ein vollständiges Programm das tun kann, was Sie wollen. Betrachten Sie zum Beispiel gnu indent mit seinen über 50 verschiedenen Flags, von denen viele auf verschiedene subtile Arten interagieren. Die einzig vernünftige 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.

1
Jerry Coffin

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

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

Ja, 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.

0
Bernard Dy

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 hat, ist es durchaus möglich, einen monolithischen Teil des verschlungenen Codes beizubehalten und erstaunliche Dinge mit völlig undurchsichtigen Änderungen zu tun, wenn sie ein Genie ist und gleichzeitig eine Vielzahl von mentalen Notizen verfolgen kann, ohne zu vergessen oder verwirrt zu werden . Es gibt ein gewisses geistiges Glück in den Gehirnen von Menschen, die das können - es ist, als wäre man ein Gott eines kleinen Universums in Ihrem Kopf.

Kluge Arbeitgeber haben jedoch auf die harte Tour gelernt, dass niemand außer dem ursprünglichen Autor jemals etwas tun kann, das sich für diesen Code lohnt. Wenn der Programmierer weitermacht, verschwendet er am Ende viel Geld, um herauszufinden, dass die einzige Möglichkeit darin besteht, neu zu schreiben (ich dachte früher, dass dies einen Totalverlust bedeutet, aber mir ist heutzutage klar, dass Sie das eigentliche Ergebnis von nicht zerstören 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.

Auf der anderen Seite, seien Sie Ihre eigene Person und entscheiden Sie selbst, wie die Antwort auf Ihre Frage lautet, denn das einzige, was sicher ist, ist, dass niemand es herausgefunden hat, wenn es um das Erstellen von Software geht. Es ist eines der Dinge, die es zu einem interessanten Gebiet machen ...

0
Aaron Anodide

Cowboy-Programmierung ist ein ziemlich sicherer Weg, um einen großen Schlammball zu erstellen. Was, so unangenehm es auch klingt, neigt dazu zu liefern ...

0

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

Der Unterschied zwischen mir und der Person, über die Sie sich beschweren, besteht darin, dass ich normalerweise bald darauf merke, dass ich es besser hätte machen und wartbarer machen können, und es spornt mich normalerweise an, mehr zu lernen und meine Fähigkeiten zu verbessern (indem ich Bücher/Artikel auf der Website lese Gegenstand). Wenn ich zurückkehre, um einige dieser gehackten Lösungen zu debuggen, empfinde ich es normalerweise als schmerzhaft und es trägt mehr dazu bei, dass ich lernen möchte, wie man es "richtig" macht. Ich denke, diese Person, die Sie beschreiben, steckt im Grunde genommen auf einer kindlichen Ebene der Selbstreflexion fest und es scheint nicht jemand zu sein, mit dem ich arbeiten möchte, wenn ihr eigenes Ego die Fähigkeit zur Verbesserung ihrer Fähigkeiten als Softwareentwickler behindert.

0
programmx10

Nein niemals.

Ich mache immer Anforderungsanalysen, denke über Architektur nach, entwerfe die Details und codiere dann. Auch wenn ich zu Hause alleine 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 haben eine Verantwortung gegenüber dem Kunden und den Benutzern.

0
CesarGon