Ist "solange es funktioniert" die Norm? [geschlossen]

23

Siehe meine neuere Frage: Geht das Programmieren als Beruf im Wettlauf nach unten?

Mein letzter Laden hatte keinen Prozess. Agile bedeutete im Wesentlichen, dass sie überhaupt keinen Plan hatten, wie sie ihre Projekte entwickeln oder verwalten sollten. Es bedeutete: "Hey, hier ist eine Menge Arbeit. Mach es in zwei Wochen. Wir sind schnell und agil."

Sie haben Sachen veröffentlicht, von denen sie wussten, dass sie Probleme hatten. Es war ihnen egal, wie die Dinge geschrieben waren. Es gab keine Codeüberprüfungen, obwohl es mehrere Entwickler gab. Sie haben Software veröffentlicht, von der sie wussten, dass sie fehlerhaft ist.

Bei meinem vorherigen Job hatten die Leute die Einstellung, solange es funktioniert, ist es in Ordnung. Als ich nach einer Neufassung eines Codes fragte, den ich geschrieben hatte, als wir uns im Wesentlichen mit der Spezifikation befassten, lehnten sie dies ab. Ich wollte den Code umschreiben, da der Code an mehreren Stellen wiederholt wurde, es keine Kapselung gab und die Leute lange Zeit brauchten, um Änderungen daran vorzunehmen.

Mein Eindruck ist also im Wesentlichen: Die Programmierung läuft auf Folgendes hinaus:

  1. Lesen Sie ein Buch über die neuesten Tools / Technologien
  2. Zusammenfassen von Code auf dieser Basis, um das Schreiben von individuellem Code zu vermeiden, da das Unternehmen keinen "benutzerdefinierten Code beibehalten" möchte
  3. Zeigen Sie es und fahren Sie mit dem nächsten Schritt fort, "solange es funktioniert".

Ich habe mir immer gesagt, dass ich beim nächsten Job einen besseren Laden bekomme. Das passiert nie. Wenn dies der Fall ist, fühle ich mich fest. Die Technologien ändern sich immer; Wenn die einzige berufliche Entwicklung darin besteht, das neueste MS Press-Technologiebuch zu lesen, was haben Sie in 10 Jahren aufgebaut, aber oberflächliches Wissen über verschiedene Technologien? Ich mache mir Sorgen um:

  1. Der beste Weg, professionelle Standards zu haben
  2. Wie man in dieser Situation aussagekräftiges Wissen und Erfahrung entwickelt
q303
quelle
3
Welches Land ist das?
3
Unvermeidlicher Dilbert-Verweis: runningagile.files.wordpress.com/2007/11/…
nikie
5
<quote> Agil bedeutete im Wesentlichen, dass sie überhaupt keinen Plan hatten, wie sie ihre Projekte entwickeln oder verwalten sollten. </ quote> Dies ist nicht agil. Das ist nichts.
Martin York
4
@Martin York: Stimmt, aber manche Orte scheinen sich selbst als agil zu bezeichnen, wenn ihnen ein Plan oder eine Spezifikation fehlt. Es ist so, als würde man Cello spielen, ohne zu wissen, wo man die linken Finger auf die Saiten legt und es atonale Musik nennt.
David Thornley
2
Ich denke, die Leute verpassen den Punkt der Frage. Mein Punkt ist die Dynamik, die ich hier beschrieben habe. Sie scheint keine Fertigkeiten zu erfordern oder dazu zu führen, dass Entwickler Fertigkeiten aufbauen. Es scheint zu einem oberflächlichen Wissensstand zu führen, der nicht von Dauer ist. Buchhalter, Anwälte usw. entwickeln Erfahrungen, die ihre Ausbildung wertvoller machen. Angesichts der Dynamik, die ich hier gesehen habe, ist das bei uns nicht der Fall.
q303

Antworten:

8

Sie sind indirekt auf das gestoßen, was meiner Meinung nach der Schlüssel zu einem guten Entwickler ist : die Balance zwischen " solange es funktioniert " und ausgereiftem, elegantem Code.

Genau wie in der Politik ist es viel einfacher, Ihre Position an einem Ende des Spektrums abzustecken, als eine differenzierte Position in der Mitte einzunehmen. Die Mehrheit der Entwickler, denen ich begegne, fällt in eine von zwei Kategorien: Codierung von Cowboy-Hacks und Architektur-Astronauten. Ich versuche ein Gleichgewicht zwischen den beiden zu finden. Es ist nicht so einfach, wie es sich anhört.

Um Ihre Frage direkter zu beantworten: Ja, ich denke, "solange es funktioniert" ist oft die Norm. Aber sehen Sie es anders: Sie sind in einer hervorragenden Position, um Ihre Kollegen aufzuklären und einige bessere Praktiken vorzustellen. Aber gehen Sie nicht ins Extreme und denken Sie daran, warum wir das alle tun: um die Probleme unserer Kunden zu lösen.

c152driver
quelle
2
+1 Insbesondere für:remember why we're all doing this: to solve our customer's problems.
George Marian
21

>> Bei meinem vorherigen Job hatten die Leute die Einstellung, solange es funktioniert, ist es in Ordnung.

Vielleicht bin ich hier eine Minderheit, aber ich bin der festen Überzeugung, dass es klare Beweise dafür geben sollte, warum wir dies brauchen, um etwas umzuschreiben. Und ich meine nicht so etwas wie "uf, ich mag nicht, wie es codiert wurde" - jeder Entwickler hat seine Vorlieben für den Code. Es sollte einige Probleme mit dem Teil geben, den wir umschreiben möchten:

  • Leistungsprobleme
  • Es wurden mehr Fehler gefunden als in anderen Teilen des Systems
  • Entwickler verbringen mehr Zeit damit, an diesem Teil zu arbeiten
  • etc.
Andrey Taptunov
quelle
7
+1I strongly believe that to rewrite something there should be clear evidence why do we need this
George Marian
3
+1. Die meisten Programmierer scheinen so leidenschaftlich mit dem Code , seiner Schönheit und Reinheit usw. umzugehen, dass sie nicht erkennen, dass der Code eigentlich nur ein Artefakt der Sache ist, die sie entwickeln sollen. Am Ende kommt es nur darauf an, dass es funktioniert. Darum kümmern sich Ihre zahlenden Kunden.
Joonas Pulakka
9
Ich habe kein Problem mit Ihrer Antwort, aber diese Haltung wird vom Management so oft verwendet, um nicht mit allen guten Gründen übereinzustimmen, Code umzuschreiben - "Das ist kein echter Grund", und sie machen weiter.
Nicole
4
@Michael: Refactoring ist extrem wichtig. Und so funktioniert der Code. Und so wird es schnell erledigt, denn sonst gewinnen Ihre Konkurrenten. Es ist auch äußerst wichtig, dies mit begrenzten Ressourcen zu erledigen, da so wenig Geld und so viele andere Dinge zu tun sind. Es gibt eine ganze Reihe von Dingen, die extrem wichtig sind, und im Geschäftsleben geht es darum, einen Ausgleich zwischen ihnen zu finden. Keine leichte Aufgabe, aber die Erfolgreichen wie Google scheinen sich immer der Haltung zuzuwenden , etwas schnell rauszuholen und später zu polieren.
Joonas Pulakka
3
@Joonas Pulakka: Das kommt ganz auf den Markt an. Für Websites ist es oft wichtiger, der Erste zu sein, als das beste Produkt zu haben. Das haben Google und andere getan. Wenn Sie dagegen versuchen, "etwas schnell rauszuholen und später zu polieren", z. B. mit lebenswichtigen medizinischen Geräten, werden Sie Ihr Geschäft wahrscheinlich nicht lange führen.
Nikie
14

Agile ist nicht dafür verantwortlich, dass ein Mensch sich entscheidet, fehlerhafte Software zu veröffentlichen. Menschen sind.

Das heißt, Sie legen großen Wert auf Qualität, und es ist gut. Ich bin mir sicher, dass Sie ein Perfektionist sind und sich Sorgen um Ihren eigenen Wert machen, wenn Sie nicht mit den neuesten Technologien Schritt halten.

Das Problem ist, dass Perfektionismus zu Aufschub und Aufschub zu Mittelmäßigkeit führt .

Aus diesem Grund wird das Geschäft Prioritäten in Sachen Time-to-Market setzen und Agile einsetzen , um Werte schnell und in vorhersehbarem Tempo zu liefern.

Da Sie die Geschäftsstrategie Ihres Unternehmens nicht beschrieben haben, sollten Sie zunächst Ihren Managern Fragen dazu stellen.

Indem Sie sich an ihren Zielen und Plänen ausrichten (sie haben Sie beauftragt, ihnen beim Erreichen dieser Ziele zu helfen), können Sie besser verstehen, wie Sie dazu beitragen können, anstatt sich auf Ihre eigenen und persönlichen Ziele zu konzentrieren.

Ich bin sicher, wenn Sie versuchen, understandihren Wert zu nutzen, können Sie Ihren Wert teilen, und das ist der Beginn einer fruchtbaren Zusammenarbeit.

Und wenn Sie feststellen, dass sie nicht wissen, was sie tun, können Sie nur aufhören .

George Marian
quelle
2
Diese Zeile gefällt mir besonders:The problem is that perfectionism leads to procrastination and procrastination leads to mediocrity.
George Marian
1
Pierre ist wie die Yoda dieser Seite!
ozz
3

Es hängt alles davon ab, was Sie bauen. Wenn Sie eine Microsite erstellen, die nur für einen Monat online ist, und Sie neun Tage Zeit haben, um sie zu erstellen: Ja, solange es funktioniert, reicht es aus.

Wenn Sie die Fly-by-Wire-Algorithmen für das FA-18-System schreiben, ist es besser, sie so perfekt wie möglich zu erstellen.

So wie es bei den meisten technologischen Antworten der Fall ist ... kommt darauf an.

Jack Marchetti
quelle
2

Es kommt auf das Unternehmen an. Viele Unternehmen haben jedoch ernsthaften Wettbewerbs- und Zeitdruck. Das ist ein typischer Grund. Eine andere wäre eine große Arbeitsbelastung, möglicherweise ohne genügend Personal. (Es gibt einige sehr gute Gründe, unterbesetzt zu sein, die nicht unbedingt die Schuld des Unternehmens sind.) Allerdings konnten einige Unternehmen den Weg aus einer nassen Papiertüte nicht finden.

Ich denke die 80/20 Regel gilt hier. Grundsätzlich müssen Sie sich mit den beschissenen 80% abfinden und sich in die 20% hineinarbeiten. Beachten Sie jedoch, dass auch sie Kompromisse eingehen müssen. In der Wirtschaft spielt es normalerweise keine Rolle, dass Sie es absolut richtig haben. Es ist wichtig, dass Sie es jetzt haben.

George Marian
quelle
2

Wenn die einzige berufliche Entwicklung darin besteht, das neueste MS Press-Technologiebuch zu lesen, was haben Sie in 10 Jahren aufgebaut, aber oberflächliches Wissen über verschiedene Technologien?

Das wäre ziemlich bescheuert, aber in diesem Jahrzehnt gab es möglicherweise einige spektakuläre Misserfolge. Ich habe viele Orte gesehen, an denen ich mich an bestimmte Dinge erinnern kann, die ich an meiner Arbeit dort mochte oder die mir nicht gefielen, und die ich daher in Frage stellen würde, wenn ich sie wieder an meinem neuen Arbeitsplatz hätte. Manchmal gibt es die neue Vorgehensweise, die man ausprobieren sollte, wenn ein Unternehmen versucht, Scrum zu implementieren oder einen Test-Driven Development-Ansatz zu verwenden. Dies sind möglicherweise Gelegenheiten, die jedoch nicht unbedingt als berufliche Entwicklung angesehen werden, da dies nicht in einem formellen Klassenzimmer stattfindet.

Ich kenne verschiedene Orte, an denen das "solange es funktioniert" gemeinsam mit verschiedenen Cowboy-Codierungsstrategien üblich ist. In ein paar Start-ups habe ich diese Art von Mentalität gesehen, die sinnvoll sein kann, wenn das Unternehmen so jung ist, dass es immer noch versucht, die Idee herauszuspülen, was es wirklich zu tun versucht. In anderen Unternehmen, in denen ich gearbeitet habe, gab es mehr Prozesse und eine Reife, die recht gut sein kann, aber nicht unbedingt leicht zu finden ist, fürchte ich. Einige Orte hatten Prozesse, die ich sehen und gehen musste: "Ich mag das. Ich werde das für spätere Arbeitssituationen in Erinnerung behalten", und andere, wo ich hingehen würde: "Ich mag das wirklich nicht. Ich werde es bemerken um dies in Zukunft zu vermeiden. "

JB King
quelle
2

Ich arbeitete eine Weile in einem Geschäft wie diesem, gerade an dem Punkt, an dem es sie einholte. Es gab zwei oder drei Jahre alte Anwendungen mit bekannten Fehlern, die buchstäblich nicht behoben werden konnten. Stellen Sie sich eine 4.000 Zeilen lange Schleife mit einer laufenden Berechnung für Layoutbreiten und -höhen vor. Das Reparieren eines Codeteils zur Behebung eines Problems in einer Instanz würde zu zwanzig Problemen an anderer Stelle führen, da frühere Entwickler ähnliche Probleme durch willkürliche Anpassung der Berechnungsergebnisse mit magischen Zahlen behoben hatten. Der Code konnte nicht als etwas anderes als giftig beschrieben werden.

Endlich wurde mir ein neues Projekt übergeben, von dem mein Chef sagte, ich könne diesen vorhandenen Code verwenden, um mit Layouts umzugehen. Irgendwie überzeugte ich ihn, dass ich es "ändern" sollte, damit er mir etwas mehr Zeit gab. Ich nutzte die Zeit, um stattdessen eine gut gestaltete Bibliothek zu schreiben, die das Layout unterstützt. Die Lösung von Fehlern in diesem neuen Projekt hat buchstäblich 10 Sekunden gedauert. Ich konnte Probleme identifizieren, bevor ich mir den Code ansah, um festzustellen, was schief gelaufen ist.

Ich dachte, dies würde einen Wendepunkt für meinen Manager bedeuten, aber alles, was ich bekam, war ein Klopfen auf den Rücken.

Seitdem arbeite ich für einen anderen Laden und hier ist es besser. Der Punkt ist, Sie können ihre Meinung nicht ändern. Geh einfach woanders arbeiten.

Spencer Ruport
quelle
2
Einverstanden ... Es hat keinen Sinn, die Meinung anderer an einem Ort zu ändern, an dem Sie arbeiten, es sei denn, Sie wurden als Senior- / Lead-Entwickler hinzugezogen, wo sie dies von Ihnen erwarten. Ich habe das Gefühl, ich arbeite an dem Ort, an dem Sie beschrieben haben, an dem Sie zuerst gearbeitet haben, und ich bin bereit, das Schiff zu hoffentlich grüneren Weiden zu befördern
programmx10
Gleiche Sache; Ich finde immer Jobs mit ignoranten Mitarbeitern, die buchstäblich nicht in der Lage sind, die Dinge richtig zu machen, und wenn ich versuche, bessere Wege zu erklären, bekomme ich einfach das "Huh?" schau mal oder entschuldige, warum sie das nicht können (z. B. wir haben keine Zeit, Code umzugestalten, es muss gemacht werden), also ändert sich nichts und ich bin frustriert, mit schlecht geschriebenen Sachen umgehen zu müssen.
Wayne Molina
1

Ich habe immer noch die Hoffnung, dass es in der Wirtschaft eine Art Evolutionsprozess gibt, der solche Unternehmen früher oder später aus dem Geschäft wirft. Aber vielleicht bringt das hohe Tempo des technologischen Fortschritts zu viele neue Nischen hervor, sodass selbst schwache Konkurrenten immer noch genug "Lebensmittel" finden können.

Wenn Sie Ihre Chancen erhöhen möchten, an einem guten Ort zu arbeiten, suchen Sie nach einem Unternehmen, dessen Produkte an viele Kunden verkauft werden, anstatt alle paar Wochen etwas Neues zu schreiben. Es sollte mehr Interesse geben, eine gute Codebasis zu haben und neue Funktionen hinzuzufügen, ohne den vorhandenen Code ständig zu beschädigen.

thorsten müller
quelle
1

Erinnert mich an meinen Hauptkollegen vom College. Er besuchte eine VLSI-Designklasse und fand für seine ersten Hausaufgaben ein Bauteil, das in der Größenordnung von Mikrometern Breite und einer Meile Länge lag. Die Simulationen verliefen einwandfrei.

Seine Antwort an seine Kritiker lautete: "Ich weiß nur, dass meine Scheiße funktioniert."

Job
quelle
1

Eine recht gute Norm ist das Pareto-Prinzip

Ich habe Erfahrung aus einem Projekt mit 80-20 Regel und es hat sehr gut funktioniert. Ich denke, Antworten auf diese Frage "Wo ziehen Sie die Grenze für Ihren Perfektionismus?" Können ebenfalls hilfreich sein.

Der Begriff "Pareto-Prinzip" kann sich auch auf die Pareto-Effizienz beziehen. Das Pareto-Prinzip (auch als 80-20-Regel bekannt, das Gesetz der Lebensnotwendigen und das Prinzip der Faktor-Sparsity) besagt, dass bei vielen Ereignissen etwa 80% der Auswirkungen auf 20% der Ursachen zurückzuführen sind. Der Denker der Unternehmensführung, Joseph M. Juran, schlug das Prinzip vor und benannte es nach dem italienischen Ökonomen Vilfredo Pareto, der 1906 feststellte, dass 80% des Landes in Italien im Besitz von 20% der Bevölkerung waren. Er entwickelte das Prinzip, indem er beobachtete, dass 20% der Erbsenschoten in seinem Garten 80% der Erbsen enthielten. Im Geschäftsleben ist dies eine gängige Faustregel. zB "80% Ihres Umsatzes kommen von 20% Ihrer Kunden". Mathematisch gesehen muss, wenn etwas unter einer ausreichend großen Gruppe von Teilnehmern geteilt wird, eine Zahl k zwischen 50 und 100 vorliegen, so dass "k% von (100 - k)% der Teilnehmer genommen wird". Die Anzahl k kann von 50 (bei gleicher Verteilung, dh 100% der Bevölkerung haben gleiche Anteile) bis fast 100 (wenn eine kleine Anzahl von Teilnehmern fast die gesamte Ressource ausmacht) variieren.Die Zahl 80% ist mathematisch nichts Besonderes, aber viele reale Systeme haben irgendwo in dieser Region ein mittleres Ungleichgewicht in der Verteilung. Das Pareto-Prinzip ist nur tangential mit der Pareto-Effizienz verbunden, die ebenfalls von demselben Ökonomen eingeführt wurde. Pareto entwickelte beide Konzepte im Kontext der Einkommens- und Vermögensverteilung in der Bevölkerung.

Link zur Quelle

Amir Rezaei
quelle
Das ist großartig, aber wie hängt es mit der Frage zusammen? Wollen Sie damit sagen, dass 20% der Arbeitsplätze 80% der schlechten Software generieren?
Kirk Broadhurst
Nein, wenn Software zu 80% funktioniert, ist das in Ordnung. Die akzeptierte Fehlerrate beträgt 20%.
Amir Rezaei
0

Als ich nach einer Neufassung eines Codes fragte, den ich geschrieben hatte, als wir uns im Wesentlichen mit der Spezifikation befassten, lehnten sie dies ab. Ich wollte den Code umschreiben, da der Code an mehreren Stellen wiederholt wurde, es keine Kapselung gab und die Leute lange Zeit brauchten, um Änderungen daran vorzunehmen.

Nichts für ungut, aber als Manager habe ich diese Aussage irgendwo gelesen:

"Als ich darum bat, zweimal bezahlt zu werden, um einen Code umzuschreiben, den ich bereits geschrieben habe, wollte meine Firma nicht bezahlen. Ich wollte das zusätzliche Geld, um das Durcheinander zu beseitigen, das ich beim ersten Schreiben gemacht habe, und mein Kollegen waren sauer auf mich, weil sie ihr Leben schwer gemacht haben. "

Wenn es sich um Ihren eigenen Code handelt, über den Sie sich beschweren, haben Sie nicht viel zu tun.

AKTUALISIEREN

Ich verstehe, dass dieser POV unbeliebt ist. Aber ich glaube auch nicht, dass dies in Widerspruch zu den Verantwortlichkeiten und Einstellungen eines professionellen Entwicklers steht.

Wenn Sie zunächst sauberen Code schreiben (und es gibt eine Vielzahl von Gründen dafür - unabhängig davon, ob Sie glauben, dass Ihr Code in der Produktion verwendet wird oder nicht), tritt dieses Problem viel seltener auf.

Wenn Sie sauberen Code und Refactoring-Zeit in Ihre Schätzungen einbeziehen, haben Sie auch den Zeitplan, um die Codebasis sauber zu halten. Wenn Sie aufgrund des Termindrucks nicht die erforderliche Zeit haben, sollten Ihre künftigen Schätzungen aufgrund des Umgangs mit den entstandenen technischen Schulden steigen.

Ihre zukünftigen Schätzungen (oder Ungewissheiten in Bezug auf Ihre Schätzungen) geben Ihnen die Möglichkeit, sich für ein Umschreiben einzusetzen (wenn Ihr Manager Sie bittet, den Prozess zu beschleunigen). Wenn nicht, akzeptieren Sie, dass das Unternehmen Ihren Kostenvoranschlag akzeptiert hat und lieber die laufenden Kosten als einen Ersatz übernimmt. Das ist eine rein geschäftliche Entscheidung - keine technische.

Denken Sie daran, die Zeit zum Aushandeln von Zeitplänen liegt vor dem Schreiben des Codes - nicht danach. Nachdem der Code geschrieben wurde (und "funktioniert"), möchten Kunden, Manager und Führungskräfte keine weitere Rechnung für "Wartung" sehen, die sich den ursprünglichen Kosten nähert oder diese übersteigt. Wenn Ihnen das Geschäft so am Herzen liegt, wie Sie es für richtig halten, können Sie es jederzeit umschreiben - genau darum bitten Sie das Geschäft.

Aus der Sicht Ihres Managers bringt Sie der Zeitplan für das Umschreiben dazu, seinen Arsch aufs Spiel zu setzen. Wenn Sie nicht liefern oder die Produktivität um so viel steigern, wie Sie sagen, dann ist er derjenige, der die Tasche in der Hand hält. Im Vergleich zu der relativ geringen Unannehmlichkeit, Ihnen zuzuhören, raten Sie, welche er bevorzugen wird.

Mark Brackett
quelle
2
Beachten Sie, dass "im Wesentlichen die Spezifikation erkunden." Wenn Sie mir als Manager eine detaillierte Spezifikation zur Verfügung stellen und ich eine Neufassung vornehmen muss, ist dies meine Schuld. Wenn Sie KEINE Spezifikation angeben und diese während des Schreibens weiterentwickeln, muss ich umgestalten, da ich in früheren Teilen des Codes nicht alle Anforderungen gekannt habe.
q303
8
Ich möchte diese Antwort so sehr ablehnen, dass es weh tut. Aber ich kann nicht ... das ist WIRKLICH, wie Manager denken. Es ist Aufgabe des Entwicklungsteams, dies in Begriffen zu formulieren, die Manager akzeptieren können. Das Sagen von "umschreiben", obwohl das Ding funktioniert, wird jedes Mal Marks Reaktion auslösen. Vielleicht ist das Sprichwort "verfestigen" oder "stabilisieren" oder "beenden" weniger irritierend. Manager müssen erkennen, dass sie mit unvollständigem Code in die Produktion gegangen sind, und es liegt an ihnen, ob sie den Job beenden möchten; Es liegt an den Entwicklern, sie von den Kosten zu überzeugen, die entstehen, wenn sie dies nicht tun.
Jeff Knecht
1
@ Jeff - genau richtig! Ein weiser Kollege sagte einmal zu mir: "Gib ihnen nicht die Gelegenheit zu sagen, es kommt darauf an, wie du die Frage formulierst."
ozz
2
Ihre Position als Manager funktioniert, bis der ursprüngliche Entwickler das Unternehmen verlässt. Jemand anderes muss dann seinen Code abholen und entweder a) zehnmal so lange an Änderungen arbeiten, wie sie hätten vorgenommen werden sollen, oder b) Änderungen hervorrufen, die schreckliche Fehler verursachen. Dann ist es kein Kodierer, der sich über seinen Code beschwert. Es handelt sich um einen neuen Entwickler, der sich über Probleme beschwert, deren Lösung Sie verhindert haben, wenn sie leichter hätten behoben werden können. Die Idee, dass Entwickler austauschbare "Ressourcen" sind, ist eine sehr naive Sichtweise.
Ant
0

Wenn Sie einen solchen Job bekommen, konzentrieren Sie sich einfach darauf, jedes Mal besseren Code zu schreiben, anstatt zurückzugehen und alten Code neu zu schreiben. Es gibt noch einen Qualitätsbereich, in den Sie beim Zusammenkleben von Paketen von Drittanbietern einsteigen können.

Wenn Sie Zeit haben und den Code einer vorhandenen, von Ihnen verwalteten Komponente verbessern möchten, können Sie dies nicht einfach tun, ohne um Erlaubnis zu bitten, solange das funktioniert, was Sie tun? Berücksichtigen Sie die Zeit in Ihren Schätzungen für das nächste Projekt, in dem die Komponente verwendet wird.

Wenn Sie bei der Programmierung auf niedrigerer Ebene keine Lernzufriedenheit mit Ihrer Arbeit erzielen können, ist es vielleicht an der Zeit, sich ein Open-Source-Projekt anzusehen?

John Bickers
quelle
Typischerweise ist ein Hauptgrund dafür, dass die Leute vorhandenen, hässlichen Code nicht gerne anfassen, dass er durch viele Iterationen von Bugfixes / Bandaids funktioniert. Es neu zu schreiben - ohne Erlaubnis - ist wie all diese Fehlerbehebungen rauszuwerfen. Sie tauschen kampferprobten Code gegen etwas Neues aus der Fabrik aus. Ich würde das nicht tun, ohne um Erlaubnis zu bitten.
Kirk Broadhurst
0

q303, Ich fand Ihre Frage interessant und fand, dass Sie diese Frage des Programmierers vielleicht lesenswert finden, wie Sie Manager davon überzeugen können, dass Entwickler technische Probleme angehen .

Ich denke allgemein, ja, das ist die Norm. Verstehen Sie, dass funktionierende, aber nicht optimale Software viel besser ist als nicht funktionierende Software. Es gibt auch das Argument, dass die Definition von "Arbeiten" auf der Grundlage der Wahrnehmung und der Vorurteile jedes Einzelnen variieren könnte. Wenn Sie ein neues System implementieren, gibt es immer jemanden, der sagt, das alte System sei besser. Und wenn Sie mit einem Entwickler sprechen, wird er oder sie wahrscheinlich nur ungern zugeben, an beschissener Software gearbeitet zu haben.

Bernard Dy
quelle