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

66

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

Maniero
quelle
13
Ein Experiment wurde einmal mit zwei Personengruppen durchgeführt, die gebeten wurden, in einem festgelegten Zeitrahmen Tontöpfe herzustellen. Gruppe 1 sollte den bestmöglichen Topf herstellen, Gruppe 2 sollte das Gewicht aller produzierten Töpfe messen. Die Qualität der Endtöpfe der Gruppe 2 war höher als die der Töpfe der Gruppe 1. Leider konnte ich die ursprüngliche Quelle dieses Experiments nicht finden, aber der übergeordnete Punkt ist "je höher die Anzahl der Iterationen, desto besser die Qualität". Waren Gruppe 2 Cowboys? Wahrscheinlich.
Adolf Knoblauch
3
"Cowboy Coding" eine schreckliche Wortwahl, wenn sonst nichts. Wenn man sich auf Leute in einem Team bezieht, bedeutet "Cowboy" oft etwas im Sinne von "der Person, die nur ihr eigenes Ding macht und sich nicht darum kümmert, was das für den Rest des Teams bedeutet". Aber die Frage nach dem Wert "weniger Struktur" ist gut.
MIA,
4
Ich denke, Sie sollten Ihre Definition des Cowboy-Programmierens (direkt) in Ihre Frage aufnehmen, da sowohl die Wikipedia-Seite als auch die Antworten darauf gemischt scheinen, was wirklich Cowboy-Codierung ist. Wollen Sie einfach keine Methodik anwenden? Weil viele Leute denken, dass Cowboy-Programmierung überhaupt kein Design macht. Zumindest für mich bedeutete es einfach keinen formalen Prozess - nicht, dass Sie gleich mit dem Programmieren anfangen. Ich denke, da Sie derjenige sind, der die Frage stellt, sollten Sie sie entsprechend dem definieren, was Sie wissen wollten.
Nr. 1
@ n1ck: Danke. Einige Leute springen einfach in die Antworten ein, ohne die Frage zu verstehen. Es ist jetzt zu spät, ändern Sie es würde einige Antworten ungültig machen. Leider haben einige Benutzer die Frage nicht bekommen. Du hast es.
Maniero
Verwendet diese Person kein Versionsverwaltungssystem oder weigert sie sich nur, das Unternehmen zu nutzen?
Thomas

Antworten:

201

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.

Aaronaught
quelle
27
Schön artikuliert.
Brandon
4
+1 für guten Beitrag trotz Widerspruch. Sie sagten, ein Quasi-Ingenieur tue bewusste Entscheidungen, wenn sie gebraucht werden. Oft müssen erfahrene Programmierer mit Kenntnissen die Regeln brechen, die er aufgrund von Einschränkungen kennt und glaubt. Natürlich, wenn ein Programmierer verdammt gut und schnell in seiner Arbeit ist, muss er sich nicht entscheiden, aber nur wenige Profis haben diese Qualität. Wie auch immer, die Frage ist provokativ.
Maniero
14
Das Problem ist, dass zu viele Leute Klebebandprogrammierer werden möchten, ohne zuerst Architekturastronauten und dann Quasi-Ingenieure zu sein, was bedeutet, dass sie für immer Cowboys sind. Ich denke also, ich kann auf diese Liste verweisen und sagen, "es sieht nach einer Karriereentwicklung aus" ... zu schade, dass die Managementtypen AAs für den Höhepunkt halten.
MIA,
19
Ich weiß nicht einmal, wo ich mich auf dieser Liste befinde: S Manchmal kann ich von einem Projekt hören und sofort wissen, wie ich es bauen werde 4, und dann werde ich ernsthafte Analyse-Lähmungen erleiden und die Architektur überdenken. wie 2, dann halte ich YAGNI und darüber nachdenken , Geschäftswert und versuche , pragmatisch zu sein, und wie ein Gefühl , 3und dann ein Chaos wie eines mache ich aufzuwickeln 1.
Carson Myers
14
Ich sollte -1 für den Hinweis geben, dass sich ein hochbezahlter Berater auf dem Niveau eines Klebebandprogrammierers befindet (Hinweis: Die meisten von ihnen sind es nicht, nicht einmal in der Nähe). Aber ich habe dir trotzdem +1 gegeben.
Falcon
47

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.

Shog9
quelle
Ich habe Probleme +1 für "alte Snackverpackungen, mein Waschbecken voller schmutziger Teller und vor allem mein ungemachtes Bett." Was zum Teufel, +1, weil der Nervenkitzel des Cowboy-Codierens und das Unbehagen, nicht zu wissen, ob man es zurück schaffen kann, zu groß sind, um Zeit mit alberner UML, Design und Spezifikationen zu verschwenden. Sie schreiben ihre Spezifikationen aus meiner Implementierung, NIE anders herum. :: Sarkasmus
Chris
31

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.

Warren Pena
quelle
6
Es gibt immer Ausnahmen. Einige Programmierer sind vielleicht Genies, haben ein fotografisches Gedächtnis, aber wenig Geduld. Andere sind nicht so schnell, aber hartnäckig; Sie schleifen die Aufgabe Byte für Byte ab, bis sie zu ihrer Hündin wird. Es gibt viele Möglichkeiten, ein guter Programmierer zu sein. Vielleicht funktioniert Cowboy-Programmierung für sie. Es funktioniert möglicherweise nicht für den Fragesteller oder viele andere. Warum sollte jemand arbeiten, wenn es auf die Geschwindigkeit und die Qualität der Ergebnisse ankommt? Warum ein Gesetz zum Verbot von Zwölfzylindermotoren verabschieden, wenn man einfach höhere mpg durch Steuergutschrift belohnen kann?
Job
@Job: Ich stimme zu. Jeder hat einen anderen Prozess; Dieser Prozess ist normalerweise nicht erfolgreich, kann aber erfolgreich sein. Ich jedenfalls bin ein berüchtigter Benutzer des Feynman-Algorithmus und mache Schritt 3 so schnell wie möglich, während ich noch in der Zone bin.
Jon Purdy
3
@Job - Es gibt manchmal Ausnahmen. Die Prozentsätze werden schließlich übernehmen. Es kann Ausnahmen geben, wenn sie isoliert von perfektem Code ausgewertet werden (keine Fehler, keine Probleme usw.), aber letztendlich treffen die Gewohnheiten der Cowboy-Codierer ihre Firma (und ihr Team und sie) im Hintern. Sie können vielleicht fünfmal hintereinander beim russischen Roulette gewinnen, aber spielen Sie weiter und mein Geld ist auf der Kugel.
Thomas
2
@Job: Ja, ich stimme bis zu einem gewissen Punkt zu. Aber wenn ich mich weigere, irgendetwas anderes in Betracht zu ziehen (was bedeutet, nicht zu lernen), und wenn ich mich weigere, die Quellcodeverwaltung zu verwenden, sind das zwei große rote Fahnen, die mir sagen: Könnte schnell sein, aber ein wirklich gefährlicher Trottel.
quick_now
1
Die Befolgung eines formalen Prozesses ist nicht die einzige Möglichkeit, Qualitätscode zu schreiben, und garantiert auch keinen Qualitätscode. Ein formaler Prozess ist weniger wichtig, wenn die Arbeit einer Person "lose" mit der Arbeit anderer Personen verbunden ist. Wenn überhaupt, wird die Versionskontrolle wichtiger, da der Prozess informeller wird. Zum Thema "Lernverweigerung" - wie viele schlechte Erfahrungen hat diese Person in der Vergangenheit mit schlechten Prozessen und Systemen gemacht? Inferenz ist unvollkommen, aber es ist im Grunde die einzige Möglichkeit, etwas außerhalb unseres eigenen Kopfes und mit den richtigen (oder eher falschen) Erfahrungen zu verstehen ...
Steve314
29

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.

Brandon
quelle
9
Ich würde Ihre endgültige Liste wirklich nicht als "Cowboy" -Codierung bezeichnen. Es ist eher wie der Inbegriff eines "Klebebandprogrammierers", der von Spolsky verherrlicht wurde. Der Unterschied besteht darin, dass ein Cowboy-Programmierer gerade damit beginnt, Code zusammenzuschleudern, ohne das Gesamtdesign zu beachten. der "Klebeband-Programmierer" macht es irgendwie wieder gut, während er voranschreitet, aber er hat immer noch einen Plan; Er erledigt nur die meiste Designarbeit auf einer intuitiven (und manchmal iterativen) Ebene.
Aaronaught
3
Kunden wollen es nicht unbedingt im Cowboy-Stil, sie wollen es nur billig und schnell. Es liegt dann an uns zu liefern.
@ user1249: Das erinnert mich an das Projektmanagement-Dreieck: billig, schnell, gut - zwei auswählen.
DanMan
Die Annahme, dass die Kunden die Fachautorität sind, ist lächerlich. Natürlich möchte ich, dass die Dinge in Cowboy-Manier gehandhabt werden. Deshalb möchte ich, dass mein Auto schnell und schmutzig gemacht wird, dass mein Haus von Neulingen gebaut wird, die nur mauerartig Zement kleben können, und dass mein Essen zubereitet wird von denen, die das Gesundheitsrisiko ignorieren, weil ich früher esse ...
Henry Aloni
13

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.

back2dos
quelle
2
Manchmal tut die Wahrheit schlicht und einfach weh ...
ChaosPandion
+1 dafür, dass Teamwork mit solchen egoistischen Leuten unmöglich ist. Auch wenn sie Genies sind, sind Cowboys keine Teamplayer. Sie sind die
Hauptshow
11

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.

Joonas Pulakka
quelle
Ich stelle fest, dass Sie einige berühmte Cowboy-Erfolge erwähnt haben, als Sie über die weitaus zahlreicheren Cowboy-Misserfolge hinweggingen.
Mawg
7

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.

Coder
quelle
9
Ihre Antwort überspringt vollständig den aufschlussreichsten Teil der Frage "Ich habe einen Programmierer, der schnell codiert, indem er die Revisionskontrolle ausschließt ...". Wer die Revisionskontrolle ausschließt und diese Meinung den Nachwuchskräften vorstellt, ist strafbar.
1
@ Jarrod: oder nicht. Es macht wenig Sinn, unvollständigen / fehlerhaften Code zu schreiben.
Denis de Bernardy
1
@Denis - dafür ist meistens eine Branche da. Der Verlauf von Entscheidungen, Änderungen, Fehlern, Sackgassen usw. während der Entwicklung von unvollständigem / fehlerhaftem Code ist IMO ein Teil der Dokumentation dieses Codes und während der Wartung sehr wichtig. Einfacheres Verzweigen und Zusammenführen ist ein guter Grund, Subversion durch ein verteiltes VCS zu ersetzen.
Steve314
@steve: Das würde voraussetzen, dass Sie sich die Protokolle ansehen, bevor Sie eine Codezeile bearbeiten. Ehrlich gesagt kenne ich sehr wenige Programmierer, die das tatsächlich tun ... Und selbst dann (wie ich es tue ...) interessieren sie sich viel weniger dafür, warum dies / das eher als das begangen wurde, als warum es geändert wurde vom ursprünglichen Code.
Denis de Bernardy
@steve: Für einfache Funktionen ist es einfacher, Single Commit mit dem Kommentar "Hinzugefügt Funktion, die Beschleunigungsparameter berechnet" zu verwenden, als Coomits zu haben: "PaternX-Skelett", "Erste Codezeile hinzugefügt", "Fehler behoben", "Andere behoben" Fehler". Es ist einfacher, globale Änderungen des Projekts zu verfolgen, wenn weniger "Noise" -Aufträge vorliegen. Und es gibt Regale, die für unvollständigen Code verwendet werden können, um Datenverlust zu vermeiden.
Coder
6

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.

Neil Butterworth
quelle
Wie benutzt man dein SCHWEIN? In welcher Sprache werden Dialoge beschrieben?
Job
@Job Es ist noch nicht fertig.
Neil Butterworth
Ihre Antwort überspringt vollständig den aufschlussreichsten Teil der Frage "Ich habe einen Programmierer, der schnell codiert, indem er die Versionskontrolle oder die Versionsverwaltung usw. entfernt."
@ Jarrod Versionskontrolle. Nun, wir hatten RCS. Release-Management? Das war eine Investmentbank! Sie schieben Sachen aus der Tür, so schnell Sie es schreiben.
Neil Butterworth
willkommen zurück.
P Shved
5

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

jojo
quelle
2
Auf Kosten einer großen Schlammkugel (meine eigene Antwort ;-))
Denis de Bernardy
4

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 .

GroßmeisterB
quelle
4

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.

gbjbaanb
quelle
+1 Es ist bedauerlich, dass sich "Hacker" dahingehend geändert hat, dass dies gemeint ist. Eine kurze Geschichte von Hackerdom
Gyan aka Gary Buyn
4
Ich würde "Hack" anstelle von "Hacker" sagen.
Mike Sherrill "Cat Recall"
2
Sie sind ein Cowboy, genau wie der OP es behauptet hat. Machen Sie sich keine Gedanken darüber, was ein Hacker ist. Überlassen Sie das den Medien.
ocodo
es könnte sein, dass sie ein "Rockstar" -Programmierer sind ... zu voller Ego und Talent, um sich über die "kleinen Dinge" Gedanken zu machen. Wo ist meine Badewanne voller blauer M & Ms ?! Ich will es jetzt!
gbjbaanb
3

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.

hotpaw2
quelle
4
Es wird behauptet, dass ein Team mit einem großen Programmierer (oder mehr) bessere Ergebnisse erzielt als ein Team mit einer noch größeren Anzahl durchschnittlicher Programmierer, die mit einer durchschnittlichen Geschwindigkeit codieren - bis der große Programmierer den Sattel, das Pferd und das Programm verlässt und nimmt Ihr Code mit ihnen. Wie gut sehen diese Ergebnisse dann aus?
Thomas
Die Annahme ist nicht unbedingt richtig. Das Einhalten eines Termins für eine Konferenz oder eine andere Ausstellung Ihres Produkts kann ebenfalls äußerst wichtig sein.
1
@Thomas: Risikofaktoren kürzen sich in beide Richtungen. Der Typ, der alle Gehaltsschecks finanziert, könnte aus der nächsten Finanzierungsrunde ausscheiden, wenn nicht einmal ein zusammengehackter Proof-of-Concept früh genug erscheint. Wie gut sehen deine langsamen Pferde jetzt aus? Alle technischen Entscheidungen sind Glücksspiele. Platziere deine Chips.
hotpaw2
@ hotpaw2 - Das Glücksspiel ist, ob die (potenziellen Terminal-) Kosten für die Cowboy-Codierung anfallen, bevor Sie Ihre Finanzierung erhalten können. Im Allgemeinen ist meine Wette gegen Cowboy-Codierung (und das wird länger dauern). Oh, du könntest mich 1/10 oder sogar 1/5 schlagen. Aber insgesamt gesehen kosten Cowboy-Programmierer Jahr für Jahr mehr, als Sie gewinnen.
Thomas
1
@ Thorbjørn Ravn Andersen, @ hotpaw2 - Hier spielt sich eine andere Dynamik ab. Ein Programmierer, der gewillt ist, risikoreiche Techniken zu verwenden, wenn nicht sogar, wenn diese Risiken nicht erforderlich sind, wird im Allgemeinen an anderer Stelle riskantere Entscheidungen treffen. Das heißt, ihre Entscheidung gegen die Quellcodeverwaltung weist auf ein riskanteres Verhaltensmuster hin, das sie und ihr Unternehmen letztendlich beißen wird. Selbst bei einem Glücksspiel kann man manchmal das Haus schlagen, aber irgendwann schlagen die Prozentsätze einen nieder.
Thomas
3

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.

Aaronaught
quelle
2

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.

Rechnung
quelle
2

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.

MIA
quelle
1

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.

Klaim
quelle
1

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.

Randall Schulz
quelle
2
Häufig müssen Sie das Problem lösen, um herauszufinden, wie es zu lösen ist ...
1

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.

Jerry Sarg
quelle
1

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.

sunwukung
quelle
Ja, und es ist möglich (wahrscheinlich?), Dass einige Cowboy-Codierer nicht so großartigen Code liefern.
Bernard Dy
1

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.

Eran Galperin
quelle
0

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.

CesarGon
quelle
-1: Sie müssen auch im besten Interesse derjenigen handeln, die Ihren Gehaltsscheck ausstellen.
Jim G.
@ Jim: Ich schreibe den Gehaltsscheck. Deshalb habe ich das Vorrecht, Mitglieder des Teams zu entlassen. Vielleicht war Ihre Ablehnung etwas voreilig. :-)
CesarGon
Wir sind Ingenieure und tragen Verantwortung gegenüber Kunden und Anwendern. - Manchmal verlangt der Kunde ein schnelles Versanddatum. Hervorhebung: Manchmal ist das schnelle Versanddatum nicht verhandelbar.
Jim G.
@Jim: Das weiß ich sehr gut, nachdem ich drei Unternehmen gegründet habe. Trotzdem, keine Cowboy-Codierung, vielen Dank. Wie ich bereits sagte, haben wir eine Verantwortung gegenüber dem Kunden und den Benutzern, und ich war immer in der Lage, dieses Engagement mit soliden Ingenieurspraktiken und ohne Cowboys in Einklang zu bringen.
CesarGon
0

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.

Bernard Dy
quelle
0

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.

programmx10
quelle
0

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

Aaron Anodide
quelle
Ich stimme zu, es sei denn, es handelt sich um eine Ad-hoc-Lösung, die nie wieder berührt werden muss. Es ist wichtig, ein Muster zu haben, da es nicht nur darum geht, dass es funktioniert it
programmx10