Schädliche Versuchungen beim Programmieren


97

Nur neugierig, welche Versuchungen beim Programmieren haben sich in Ihren Projekten als wirklich schädlich erwiesen?

Zum Beispiel, wenn Sie wirklich den Drang verspüren, etwas zu tun, und glauben, dass es dem Projekt nützen wird, oder wenn Sie sich einfach dazu verleiten, es zu glauben, und nach einer Woche feststellen, dass Sie keine wirklichen Probleme gelöst haben, sondern stattdessen neue oder neue geschaffen haben Im besten Fall, erfreut Ihr inneres Biest ohne sichtbare Auswirkungen.

Persönlich finde ich es sehr schwierig, schlechten Code nicht umzugestalten. Ich arbeite mit vielen schlechten alten Codes und es braucht einige Atemzüge, um sie nicht zu berühren, wenn ich keine Tests habe, um zu beweisen, dass mein Refactoring nichts kaputt macht.

Ein weiterer Dämon für mich in der Benutzeroberfläche: Ich kann buchstäblich Stunden damit verbringen, das UI-Layout zu ändern, nur weil es mir Spaß macht. Manchmal sage ich mir, ich arbeite an der Benutzerfreundlichkeit, aber die Wahrheit ist, ich liebe es, Knöpfe zu bewegen.

Was sind deine Programmierdämonen und wie vermeidest du sie?


19
Ich finde es witzig, dass niemand in der Lage war, den zweiten Teil Ihrer Frage zu beantworten - "[und] wie vermeiden Sie sie?".
Craige

3
Hat jemand bemerkt, dass dies den ganzen Tag die Hauptfrage bei SE war?
msarchet

+1 für "... stundenlanges Ändern des UI-Layouts ..." Ich tappe zu oft in dieser Falle.
25.

Antworten:


67

Vorzeitige Verallgemeinerung ist mein großer Bugaboo; Anstatt das vorliegende Problem zuerst zu lösen und zu warten, bis tatsächlich eine Lösung für den allgemeinen Fall erforderlich ist, gehe ich immer dem allgemeinen Fall nach und schreibe eine Tonne Code, der komplexer ist, als er sein muss.

Aktualisieren:

Eine ausführliche Beschreibung finden Sie unter " Sin # 1 - Vorzeitige Generalisierung ".


6
Ich hasse es, wenn Architekturastronauten das tun!
ozz

13
Oh, die Freude an metafactoryfactories :(

+1 "Eine Studie mit großartigen Designern ergab, dass sie alle gut darin waren, Veränderungen zu antizipieren" (Code Complete 2). Es ist gut zu wissen, welche Veränderungen wahrscheinlich sind. Dann können Sie entscheiden, ob durch eine frühzeitige Lösung des allgemeineren Falls etwas erreicht werden kann - ob dies später Zeit spart. Manchmal ist es das nicht wert, es wäre genauso einfach, den Code später zu ändern.
MarkJ

1
Haben Sie schon vom YAGNI- Prinzip gehört?
Oscar Mederos

1
Diese. Ich habe die Schuld auf die Tatsache gelegt, dass das Erstellen von hübschem, verallgemeinertem und wiederverwendbarem Code sehr befriedigend ist, insbesondere, wenn das Problem selbst nicht sehr herausfordernd ist und / oder nur eine Aufarbeitung dessen ist, was Sie zuvor getan haben. Beispiel: Generische CRUD-Datenbankoperationen (Benutzeroberfläche, Reaktion auf Benutzeraktionen, Durchführung von Aktionen mit einer Datenbank usw.).
Cthulhu

197

"Wir werden darauf zurückkommen und es später beheben. Wir brauchen es jetzt nur noch!"


16
Das ist der absolute Teufel.
Alesplin

6
Ich würde dir dafür +100 geben, wenn ich könnte. "Später" PASSIERT NIE. Mach Sachen gleich beim ersten Mal richtig oder gar nicht.
quick_now

12
Ist das nicht die Ergänzung, wenn man Stunden damit verbringt, schlechten Code umzugestalten? Wir können die Welt in Programmierer aufteilen, die "es später beheben", aber nicht, und Programmierer, die versuchen, es beim ersten Mal richtig zu machen, verbringen dann Stunden damit, "schlechten Code umzugestalten".

6
Umformulieren Sie dies zu "Wir werden wiederkommen und diese nächste Iteration reparieren " und es klingt so viel strukturierter
Chris S

4
Das musst du machen. Wenn Sie Ihre ganze Zeit damit verbringen, es perfekt zu machen, wird es niemals versandt. Beenden Sie das Projekt, dann polieren.
Zan Lynx

105

Die Frist ist soooooo weit weg, ich habe mehr als genug Zeit, um das zu tun. Warum also nicht ein bisschen im Internet surfen?


72
ersetze "web" durch "programmers.stackexchange.com" :)
davidhaskins

1
Gibt es noch etwas im Internet, das es wert ist, gelesen zu werden? Ich hatte vergessen, dass es noch etwas gab!
James McLeod

3
aka 'Verdammt du, Minecraft'
Johnc

1
@ David, das ist nur der Ausgangspunkt im Web - Frage ist, wie weit Sie kommen ...

Ich würde sagen, dies ist aufgrund von Agile nicht mehr so ​​gültig.
Vartec

103

"Dies ist nur ein wegwerfbarer Proof-of-Concept-Code. Wenn sie ihn mögen, werde ich ihn wirklich gut machen."


13
Dies wird als schnelle Anwendungsentwicklung bezeichnet. und es funktioniert nie in einem Geschäftsumfeld. :)
John Kraft

12
Es ist lustig, dass es für mich umgekehrt ist - ich kann mich einfach nicht zum Wegwerfen von Code zwingen, selbst wenn es genau das ist, was erforderlich ist.
Dan

6
Ich arbeite in der Finanzbranche und RAD ist immer noch sehr erfolgreich, insbesondere in Sachen VBA / Excel. Es gibt jedoch ein Händchen dafür, RAD muss nicht schlampig bedeuten.
Ian

5
Und manchmal endet die Anwendung, die Sie zwei Jahre lang perfektioniert haben, als Wegwerfcode, weil jemand höher auf der Leiter entschied, "oh, das können wir nicht" oder eine andere Version von "egal".
Netzteil

12
Diese. Ich: "Dies ist nur mein Proof-of-Concept. Wenn es Ihnen gefällt, schreiben wir die Produktionsversion." Manager: "Ihre Version funktioniert, wir versenden sie!" Ich: "Nun, es deckt nicht alle Verwendungszwecke ab, die Sie bereits verschickt haben, oder?"

74
  1. Refactoring eines Teils des Codes wenige Tage vor der Veröffentlichung.
  2. Internet: Die größte Ablenkung von allen.
  3. Neue Technologie : Ich kann mich nicht von neuen Technologien abbringen lassen.
  4. Optimieren: Optimieren, optimieren. .. und mehr Optimieren
  5. Perfektion : Noch nie mit dem Code zufrieden gewesen.
  6. TODO: Zeitmangel, der niemals gemacht wird.
  7. Zeitschätzung: Viele PMs verstehen dies nicht als "Schätzung". Sie nehmen als Tatsache.
  8. Versprechen: Zu viele Versprechen geben.

1
Hat einmal an einem Projekt gearbeitet, bei dem 100 Personen in einem großen Raum waren und nur 2 gemeinsam genutzte PCs über Internet verfügten. Die Produktivität war sehr hoch. Das Management gab allen das Internet und fragte sich, warum sich die Arbeitsleistung halbierte.
quick_now

2
In Bezug auf die Zeitschätzung ... nehmen so viele Manager dies als Ausgangspunkt für Verhandlungen (wie das Aushandeln eines Preises). Diejenigen, die es für falsch halten, aber tatsächlich überdurchschnittlich gut ...
dbkk

@quickly_now Das Ausschneiden des Netzes funktioniert wahrscheinlich für alltägliche Aufgaben wie Dateneingabe oder Routinekorrekturen, bei denen Sie nichts nachschlagen müssen. Für viele ungewöhnliche Dinge (z. B. das Nachschlagen von API-Dokumenten / Beispielcode) ist Google Ihr Freund - es dauert fünfmal länger, bis Sie es selbst herausfinden. Auch wenn Menschen nicht motiviert sind und abgelenkt werden möchten, werden sie Wege finden.
dbkk

@dbkk - ja bis zu einem gewissen Punkt. Es war alles in Ada, es gab keine APIs, die nachgeschlagen werden mussten, es war auf spezielle Hardware und nationale Sicherheit klassifiziert. Es war auch ein Alptraum, nicht klassifizierte Maschinen mit Internetverbindung in diese Umgebung zu bringen.
quick_now

55

Wenn es vorhandene Frameworks und Bibliotheken gibt, müssen Sie versuchen, alles im eigenen Haus zu erstellen.


6
Gelegentlich werden die vorhandenen Frameworks und Bibliotheken von IT Legal als Verboten in großen roten Buchstaben gekennzeichnet.
Christopher Mahan

22
Und natürlich das Gegenteil: Verwenden eines unbekannten Frameworks oder einer Bibliothek und davon ausgehen, dass es das tut, was Sie benötigen, und alles reibungslos verläuft.
Carson63000

"Aber es wird nur eine Woche dauern, um zu schreiben, und unser Framework wird genau das tun, was wir wollen. Das kostenlose Online-Framework ist wahrscheinlich voller Fehler."

2
@Christopher: Dann wäre das ein guter Grund, es erneut zu implementieren (oder eine andere Bibliothek mit akzeptabler Lizenz zu finden). Aber zu oft ist der Grund für die Neuimplementierung nur NIH ...
Donal Fellows

@Carson: +1 :-)
Macke

48

Meine wiederkehrenden Dämonen: Vorzeitige Optimierung und Überentwicklung.

Und ich kann sie immer noch nicht 100% vermeiden ...


10
+1 für Überentwicklung. Ich habe einmal ein komplettes "Konfigurationsframework" mit "Konfigurationsparameter-Adaptern" für INI-Dateien, XML-Dateien, Datenbanktabellen und Netzwerk-Sockets geschrieben (weil jeder einen Konfigurationswebdienst hosten möchte, oder?)
TMN

8
Vorzeitiges Over-Engineering?
Christopher Mahan

@ Chris "vorzeitige Überentwicklung" gilt jedoch auch. Es wurde auch in anderen Antworten erwähnt . Ich weiß, es ist einer meiner Flüche.
Matthew Scharley

Wie wäre es mit einem vorzeitigen überoptimierten Mega-Engineering ...
Newtopian

4
Das ist meins. Ich gebe der Geschäftsführung die Schuld, mir freie Hand zu lassen und mir keine Termine für bestimmte Komponenten zu geben.
Cthulhu

46

Übermäßig optimistische Schätzungen

Wenn Ihr Manager Sie anstarrt und Sie das brennende Gefühl verspüren, eine niedrigere Schätzung abzugeben, als Ihr Bauch es Ihnen sagt ... tun Sie es nicht!

Immerhin ist Ihr Darm wahrscheinlich schon zu niedrig!


13
Wenn sie dich fragen, ob es wirklich so lange dauern wird, sag einfach Ja und setz dich dann in die Stille, bis sie die Unbeholfenheit spüren ...
PeterAllenWebb

4
Mein College-Professor sagte mir einmal: "Finde deine beste Schätzung heraus und verdopple sie dann." Es hat bisher für mich funktioniert.
zzzzBov

2
Versuchen Sie alternativ den SMBC-Ansatz .
Detly

4
Einer meiner alten Chefs hat die Schätzungen der Entwickler verdreifacht und dann mit den Kunden eine Verdoppelung ausgehandelt. Kunden dachten, sie hätten einen Deal, Entwickler hätten die Zeit, die sie brauchten, auch wenn sie es nicht wussten. Win-Win!
DaveE

2
Evidence-based Scheduling könnte bei diesem Problem Abhilfe schaffen
Rei Miyasaka

33

Verwenden einer Technologie / eines Werkzeugs / einer Sprache in Ihrem Projekt, nur weil Sie es gerade gelernt haben.

Um zu beweisen, wie gut Sie als Entwickler sind.

Code, den Sie geschrieben haben, gehört Ihnen.


Wenn ich es nur jedes Mal, wenn ich es tat, verbessern könnte. Zum Glück erwies sich die Hälfte der Lösungen als ziemlich gut. Die Hälfte tat es nicht.
Dan

Oder eine, die du noch gar nicht gelernt hast. Vergiss nur nicht, deine Sporen anzuziehen, denn es wird eine lange Fahrt.
Evan Plaice

32

Ich mache einfach eine Pause und schaue auf stackoverflow.com;)


2
Ich liebe es immer, wenn Stackoverflow die Antwort auf eine dieser Fragen ist
Bill Leeper

31

Die schlimmste Versuchung:

Oh, na ja ... ich denke, ein kleiner Trick / Hack / Fix wird nicht schaden.

Ratet mal, es tut weh. :)

gehe zu


11
"Gateway-Korrekturen"
Mark C

4
Die Verwendung einer gotoAnweisung führt zu einem Raptorangriff.
Maxpm

1
@ Maxpm: Gutes Denken! Inbegriffen.
Goran Jovic

1
@ Mark C, was ist ein Gateway-Fix? Mein gøøgle-fu ist nicht gut genug.

1
@ Thorbjørn Ravn Andersen: de.wikipedia.org/wiki/Gateway_drug_theory
Jimmy


23

Feature Creep

Erstellen Sie einen Plan, halten Sie sich daran und implementieren Sie ihn. Und dann geh zurück und füge die Sachen hinzu, nach denen die Leute fragen.

Ich habe das immer und immer wieder gesehen. Sie setzen sich, erarbeiten das Design und beginnen mit der Programmierung. Die Benutzer hören verwirrten Unsinn darüber, dass ihr Lieblingsfeature "fehlt", und beginnen, Lobbyarbeit dafür zu betreiben. Ihr Chef verlangt, dass Sie es in der 11. Stunde hinzufügen, dass es die Bereitstellung verschlechtert, dass es überall Fehler verursacht und dass Sie 3 Monate später, wenn sich alle beruhigt haben, aufgefordert werden, es zu entfernen, da niemand herausfinden kann, warum Sie es einsetzen Das beschissene Retro-Feature überhaupt! Könnten Sie nicht sagen, dass der Rest des Designs es sinnlos machte?


Lassen Sie die Spezifikation ungefroren und offen als Zugeständnis, weil der erste PM (der jetzt gefeuert wurde) nichts über Softwareentwicklung wusste und einen völlig unrealistischen Release-Zeitplan entwarf. Schlimmste Idee überhaupt.
Evan Plaice

20
  1. Weitere Funktionen hinzufügen

  2. Der Wettbewerb hat diese Funktion. Dies ist ein Muss, daher mehr Programmierung als Strategie, Positionierung usw. zu analysieren.

  3. Die Konkurrenz hat diese Funktion NICHT. Das ist also ein Unterscheidungsmerkmal, daher mehr Programmieren als Strategie, Positionierung usw. analysieren.

  4. Ein Geschäftsproblem mit mehr Programmierung lösen. Bessere Kenntnisse in der Verwaltung des Linux-Servers, auf dem Ihre Website gehostet wird, lassen sich nicht durch die Programmierung weiterer Funktionen erlangen. Manchmal muss man nur lernen, das Problem zu beheben, anstatt das Ganze in C # .Net neu zu codieren

  5. Lösen eines Marketingproblems mit mehr Programmierung. Missbrauch von Seth Godins Purple Cow-Konzept, dass Sie indirekt ein Marketingproblem lösen, indem Sie mehr Funktionen in Ihr Produkt programmieren, um es zu einer "Purple Cow" zu machen. Manchmal ist es nur ein mutiertes Monster.

  6. Lösen Sie ein Produktivitätsproblem, indem Sie mehr programmieren, und argumentieren Sie, dass die Zeit, die Sie für das Schreiben dieses Skripts aufgewendet haben, in Zukunft in Stunden gespart wird, anstatt wirklich wichtige Dinge zu programmieren

  7. Planen Sie zu codieren, aber noch nicht zu codieren, weil Sie "es richtig machen" möchten

  8. Codierung einer schmutzigen Version und Versprechen, dass Sie sie "später verbessern" werden, aber nie zurückgegangen sind, um sie "besser zu machen"

  9. Kein Mockup oder Sitemap zu machen, weil es "so lästig" ist. Ich kann nur die Seiten der Wettbewerber für Modelle scannen und die Sitemap "später" freihändig zeichnen, was niemals der Fall ist. Und dann programmiere ich gleich die erste Seite, die ich mir vorstelle.

Geständnis: Ich habe persönlich die Fehler 1, 3, 7, 8 gemacht. Ich habe auch 2, 4, 5, 6 gemacht, aber mir oft vorgemacht, dass ich das nicht getan habe.

Ich behebe gerade 9.

BEARBEITEN Wusste nicht, dass die Frage nach Lösungen verlangt.

1) Weitere Funktionen hinzufügen Tu es einfach nicht. Arbeiten Sie mit Ihrem Unternehmen, Marketing, Gründern, Beratern usw. zusammen und reduzieren Sie Ihre Bewerbung auf eine Sache.

Lesen Sie über Twitter, Groupon usw., wie sie die Dinge einfach auf eine Sache reduzieren, die zu ihrem Erfolg geführt hat.

Wenn Sie denken, dass es nur funktioniert, wenn Sie große Unternehmen aufbauen möchten, überlegen Sie es sich noch einmal. Strg + F für diese Zeile "Je mehr Funktionen ich zur Software hinzufüge, desto schlechter wird sie verkauft. (Dies ist für die meisten Softwareentwickler natürlich höchst uninteressant.)" In diesem Link

2) Der Wettbewerb hat diese Funktion. Das ist also ein Muss

Siehe Lösung 1

3) Der Wettbewerb hat diese Funktion NICHT. Das ist also ein Unterscheidungsmerkmal

Siehe Lösung 1

4) Ein Geschäftsproblem mit mehr Programmierung lösen.

Wenn Sie jemanden einstellen müssen, der Sie unterrichtet, berät oder es für Sie erledigt und dann dokumentiert, wie er es getan hat, damit Sie es beim nächsten Mal selbst tun können. TU ES EINFACH!! Schreiben Sie den Code nicht um, geben Sie GO nicht weiter und sammeln Sie keine 200 US-Dollar.

5) Lösen eines Marketingproblems mit mehr Programmierung.

Wenn die Leute nicht verstehen, was Sie verkaufen, ist dies ein Marketingproblem. Kehren Sie zu Lösung 1 zurück und drehen Sie.

6) Lösen eines Produktivitätsproblems mit mehr Programmierung

Warten.

Warten Sie, bis Sie das Gefühl haben, dass Ihre Produktivität länger als 2 Wochen unter einem bestimmten Produktivitätsproblem gelitten hat, und dies wird in angemessenem Umfang weitere 2 Wochen dauern.

Bewerten Sie nun den Zeitaufwand für die Programmierung eines Skripts zur Behebung dieses Problems. Denken Sie daran, Ihre schlechteste Schätzung zu nehmen und mit 2 zu multiplizieren.

Multiplizieren Sie Ihre Schätzung mit Ihrem Stundensatz.

Überprüfen Sie nun alternative Lösungen: lagern Sie aus, kaufen Sie eine Lösung von der Stange, tun Sie nichts dagegen usw

Wählen Sie die kostengünstigste Lösung.

Bleibe dabei.

7) Planen Sie zu codieren, aber noch nicht zu codieren, weil Sie "es richtig machen" möchten

Geh trainieren. Sie werden einen Ansturm von Endorphinen spüren, der Ihren Arsch motiviert und Sie dazu bringt, zu handeln. Ich weiß das, weil ich gerade 5x5 Bankdrücke und 5x5 Kniebeugen gemacht habe.

8) Eine schmutzige Version codieren und versprechen, dass Sie "es später besser machen", aber nie zurückgehen, um "es besser zu machen"

Richten Sie in GTD ein Tickler-Dateisystem ein. und aggressiv verfolgen. Befolgen Sie alle Versprechen an sich und andere.

9) Nicht ein Modell oder eine Sitemap zu machen, weil es "so lästig" ist.

Geben Sie 75 USD für eine Balsamiq Mockups Desktop Edition aus. Ich weiß das, weil ich es vor 3 Wochen gekauft habe. Es hat mich dazu gebracht, meine Mockups zu überarbeiten, weil ich mich wie ein Künstler, Architekt und Visionär fühle, obwohl mein Zeichnen in der realen Welt scheiße ist. Die in Balsamiq verwendete Schriftart erinnert Sie unbewusst daran, dass dies nur ein Modell ist, das nicht in Stein gemeißelt ist, was Ihnen in RAD hilft.

EDIT beenden


+ 1'ed diese Antwort, aber ich fand es ein bisschen schwer zu lesen. Ich verstehe den Kontext der ersten 9 Punkte nicht wirklich. Würde es Ihnen etwas ausmachen, dies zu klären? Trotzdem gute Arbeit.

@MattFenwick Hallo, danke für deine +1. Die Punkte 1 bis 5 gelten normalerweise für das Szenario, in dem ein zu verkaufendes Produkt erstellt wird. Sie können es jedoch auch für Szenarien anwenden, in denen Ihre Tendenz, die beste Antwort zu finden, zu umfangreichen Recherchen zum Stand der Technik führt. Zum Beispiel in der Forschung.
Kim Stacks

Die Punkte 6-9 betreffen eher die neurotischen Tendenzen eines Programmierers. Ich habe irgendwo gelesen (kann es nicht finden), dass ein Designer immer ein Problem mit einer Designlösung angeht. ein Vermarkter mit einer Marketinglösung; und ein Programmierer mit einer Codelösung. Ja, das gefürchtete "Wenn Sie einen goldenen Hammer haben, sehen Sie nur das Nagelsyndrom". Dies wird besonders deutlich in Punkt 6) Lösen eines Produktivitätsproblems mit mehr Programmieraufwand
Kim Stacks

@ MattFenwick Entschuldigung, wenn Sie mit meinem Namen verwechselt wurden. Ich habe meinen Spitznamen geändert, nachdem ich diese Antwort geschrieben habe. Ich sehe, dass Ihr Hintergrund eher in der Forschung liegt. Meine Antwort beruht weitgehend auf meiner Erfahrung bei der Entwicklung von Lösungen für den Verkauf. Aber ich bin mir sicher, dass es gewisse Ähnlichkeiten zwischen meiner und Ihrer Arbeit gibt, da wir beide programmieren.
Kim Stacks

17

Ein paar Biere helfen mir, besser und länger zu arbeiten.


11
Warten Sie ... Sie meinen es nicht? ( xkcd.com/323 )
Craige

4
@Craige: Nach 21 Jahren Erfahrung mit dem Trinken und 20 Jahren Erfahrung als professioneller Software-Ingenieur arbeite ich immer noch am Kalibrierungsteil.
Adam Crossland

4
@adam, hast du ein Jahr lang getrunken, um Ingenieur zu werden?

17
Wenn Sie beim Trinken von Bier codieren, können Sie beliebte soziale Netzwerke erstellen, die in ein paar Jahren Milliarden wert sein werden. Es ist wahr, ich habe das in einem Film gesehen.
Janosrusiczki

1
@Kitsched: Ja! Vor allem, wenn Sie das bereits vorhandene Design einer anderen Person zum Abzocken haben.
Mason Wheeler

16

"Ja, ich kann dieses gigantische Durcheinander von 2000 Linien Spaghetti an einem Tag umgestalten ..."


13
Alternativ: "Der Neue [der absolut nichts über die Software oder die Struktur ihres Codes weiß] tut nichts, er kann es reparieren". Bonuspunkte, wenn der Typ noch nie die Sprache verwendet hat, in der der Code geschrieben ist.
Wildpeaks

16

"Dafür komme ich ohne einen Test aus. Es ist zu schwer zu testen."

und es ist böser Bruder,

"Ich muss einen Test dafür haben, egal wie schwer der Test zu schreiben oder zu verstehen ist."


2
Wenn ein Test schwer zu schreiben ist, programmieren Sie ihn möglicherweise nicht richtig :)
Merlyn Morgan-Graham

2
@ Merylyn Morgan-Graham, ganz richtig. Es gibt jedoch einige Bereiche, z. B. Parallelität, die nur schwer zu testen sind.
Wayne Conrad

1
@Merlyn: Wenn Sie einen Befehlssimulator schreiben, um einen Kontextwechsel an den richtigen Stellen zu erzwingen, sind Sie beim Testen der Parallelität wahrscheinlich viel zu weit gegangen. :)
Zan Lynx

1
@Zan: Ich stimme zu - an dem Punkt, der erforderlich ist, würde ich auf Entwickler zurückgreifen und versuchen, sie dazu zu bringen, ihren Code umzugestalten und mich verspotten zu lassen. Ich arbeite gegen Hochsprachen, bei denen wir uns Big-O ansehen, Engpässe optimieren, die Parallelität hauptsächlich aus Gründen der Datenintegrität und nicht der Rohgeschwindigkeit berücksichtigen und versenden müssen (und oft keine davon, weil sie einfach schnell genug ist) Box).
Merlyn Morgan-Graham

15

Aufschub und optimistische Aufgabenschätzung sind meine größten Sünden.

Stretching, Liegestütze oder Klimmzüge (oder jede andere körperliche Betätigung) für die erste und pessimistische Stimmung, bevor die Schätzung für die zweite gegeben wird.


Klarstellung ... Mit "optimistischer Aufgabenschätzung" meinen Sie das "Shit Easy Syndrome", oder? :)
Evan Plaice

@Evan Scholle - genau. Zum Beispiel "Oh, es ist so trivial" und googelt dann jeden Buchstaben Ihres Codes, nachdem Sie mit dem eigentlichen Codieren begonnen haben.
Nikita Barsukov

13

"Es ist viel einfacher , die Funktionalität von Grund auf neu zu implementieren, als den vorhandenen Code zu verstehen."


2
Ja, c2.com/cgi/wiki?RewriteCodeFromScratch behauptet, dies sei eines der "Dinge, die Sie niemals tun sollten".
David Cary

Die Arbeit an Open Source hilft dieser Tendenz. Ich habe Patches persönlich angesehen, bevor ich sie gesehen habe, und dann meine eigene Implementierung geschrieben, um festzustellen, dass sie nahezu identisch mit dem Patch war (auch nachdem ich meinen Code verbessert / überarbeitet hatte). Es ist lustig, wie das funktioniert.
Evan Plaice

10

Eine massiv schädliche Versuchung, unter der das Projekt, an dem ich arbeite, gelitten hat, ist der "Inner Platform Effect". Dies ist ein Ansatz, den die Architekten, die es längst nicht mehr gibt, in ihrer unendlichen Weisheit niedergelegt haben und der ein Projekt hervorgebracht hat, das etwa 20 Millionen Dollar pro Jahr generiert, dessen Aktualisierung und Wartung jedoch 60 Millionen kostet (grobe Zahlen, aber das ist die Größenordnung) von dem Problem).


10

NIH - hier nicht erfunden

Es fällt mir wirklich schwer, Lösungen von Drittanbietern eine faire Chance zu geben. Jeder sollte natürlich skeptisch gegenüber Lösungen von Drittanbietern sein, die nicht auf ihn zugeschnitten sind, aber es fällt mir schwer, zu 100% objektiv zu sein.

Die Zeitersparnis kann so groß sein , dass auch wenn in 9 von 10 die Lösung von Drittanbietern vermieden werden soll, muß ich die , objektiv sein genug , um zu erkennen , eine , die funktioniert.


1
Ich verstehe deinen Standpunkt und muss die ganze Zeit damit leben. Ich bin manchmal genau der gegenteiligen Meinung, bis zu einem Punkt, an dem es eine Antwort direkt neben Ihrer verdient. Es fällt mir jedoch schwer zu glauben, dass ich in einer Woche besser abschneiden kann als eine Gruppe von Experten, die sich seit Jahren damit befassen. Natürlich müssen Sie sicherstellen, dass die Personen, die hinter diesen Dritten stehen, tatsächlich Experten sind. Eine gute Untersuchung der Umgebung des Bauteils trug wesentlich dazu bei, die richtige Wahl zwischen Übernahme und Codierung zu treffen.
Newtopian

1
@Newtopian der "richtige" weg ist definitiv irgendwo in der mitte. Mein Problem mit Bibliotheken von Drittanbietern ist nicht, ob ich es besser kann als ein Expertenteam mit monatelanger oder wochenlanger Zeit, sondern dass ich selten , vielleicht nie eine Bibliothek finde, die genau das ist, was wir brauchen. Es gibt immer Anpassungsmöglichkeiten, und dann stelle ich oft fest, dass ich und andere so viel Zeit damit verbringen, als eine Lösung zu schreiben, die genau das ist , was wir brauchen.
Nicole

Ich selbst, der vom anderen Ende des Spektrums kam, war nur neugierig zu wissen, wie Sie es geschafft haben, dieses "nur mittlere" Ergebnis zu erzielen, wenn überhaupt. War auch neugierig, was Sie dazu bringt, Dritte nicht zu benutzen, um zu verstehen, was mich dazu bringt, sie zu überbeanspruchen, da ich sicher bin, dass beide gleichermaßen die Produktivität beeinträchtigen.
Newtopian

@Newtopian macht meine obige Erklärung Sinn, warum? Mein Versuch, die Mitte zu erreichen, ist einfach, objektiver zu sein, wenn ich nach Lösungen von Drittanbietern suche.
Nicole

9

Entwerfen, Codieren und / oder Testen von Einheiten anhand der gelieferten "Beispieldaten", anstatt eine Kopie der tatsächlichen Datenbank des Kunden zu analysieren. Die Frist war kurz und sie sagten immer wieder, es komme, aber es geschah nie. Als es eingesetzt wurde, war die Explosion spektakulär. Wirklich, wer hätte erwartet, dass ein Kunde 3 Elternkunden hat.

Ich werde nie wieder ein Projekt starten, bis ich eine Kopie der realen Daten habe.


Wenn es noch kein Produkt gibt, müssen dann Daten kopiert werden?
Svish

Wenn keine Daten vorhanden sind, ist immer Papier vorhanden. Firmenunterlagen würden auch hier helfen.
burnt_hand

9

Die Es gibt Gotta eine Bibliothek sein, dass irgendwo tut Syndrom.

eng verwandt mit

Der Plugin Fetisch


2
Ich scheine immer in der Lage zu sein, die Bibliothek zu finden, die "es tut". Mein Problem ist oft, sie dazu zu bringen, wie beworben zu arbeiten. :(
Ben L

Leicht zu findende Bibliothek - Schwer zu findende Bibliothek mit integrierten Unit-Tests
burnt_hand

8

Perfektionismus tötet; wahrscheinlich der Hauptgrund, warum Projekte nicht erfolgreich sind.


Ich denke, es ist möglich, dass dies zutrifft, aber ich war noch nie an einem Projekt beteiligt, das aus diesem Grund gescheitert ist oder sogar verspätet war.
PeterAllenWebb

Hängt davon ab, wie Sie Perfektion definieren und auf welcher Ebene Sie sie anstreben.
Svish

7

Na ja, manchmal treibt mich das Programmieren zur Flasche.


7

Umschreiben statt umgestalten.


Zustimmen. Wenn Sie bereit sind, sich auf den für ein Neuschreiben erforderlichen Aufwand festzulegen, ist es fast IMMER besser, eine Umgestaltung vorzunehmen. Es wird immer noch länger dauern, als Sie dachten, aber Sie führen das Refactoring schrittweise durch, oder? Sie können aufhören, bevor es "perfekt" ist.
PeterAllenWebb

1
als folge .... wieder woanders schreiben statt re-factoring. Unsere Codebasis hat so viele verschiedene Implementierungen der gleichen Dinge, dass es unmöglich ist, irgendeine Art von Konsistenz zu erzielen.
Newtopian

6

Ich denke, es muss einen besseren Weg geben, dies zu tun. Ich werde mich nicht mit etwas zufrieden geben, das "gut genug" sein könnte. Ich nehme nichts weniger als Perfektion! In der Regel wird dies vermieden, indem Sie mit anderen Personen sprechen, die ein Problem aus einer anderen Perspektive betrachten oder eine Lösung aus einem anderen Blickwinkel sehen.


5

Alles auf den Punkt zu automatisieren kostet mehr Zeit für die Wartung der Werkzeuge als für die eigentliche Arbeit.

Lösung: Finden Sie wie bei der Codeoptimierung zunächst Produktivitätsengpässe und beheben Sie diese erst, nachdem Sie sie entdeckt haben, mit einer guten Automatisierung .


Im Prinzip kann ich dem zustimmen, aber in der Praxis habe ich noch nie eine übermäßige Automatisierung gesehen. Trotzdem könnte das nur meine Erfahrung sein.
PeterAllenWebb

4

Was sind deine Programmierdämonen?

Abgesehen von dem, was einige von anderen erwähnt haben.

Priorisierung : Ignoriere die Arbeit mit hoher Priorität in Bezug auf das Projekt und arbeite zuerst an anderen Dingen im Projekt, weil sie interessanter sind!

Wie vermeidest du sie?

Mit etwas mehr Selbstdisziplin. Im Ernst, Selbstdisziplin und Selbstmotivation, das Richtige zu tun, helfen, die meisten dieser "Dämonen" zu vermeiden.


3

Wir haben noch keine Genehmigung vom Kunden erhalten, aber die Deadline rückt näher. Hier sind einige vorläufige Kompositionen, damit Sie anfangen können ...

Später, nachdem Sie das Projekt so erstellt haben, dass es mit den Kompositionen übereinstimmt ...

Oh, hier sind die Revisionen des Kunden, er möchte nur ein paar Kleinigkeiten ändern *

(* Hauptfunktionalität ist völlig anders)

Dann überarbeiten Sie Ihren Originalcode weiter, basierend auf dem fehlerhaften Originalmodell, anstatt einfach von vorne zu beginnen, da Sie unter dem Druck einer kurzen Frist stehen und davon ausgehen, dass dies die letzten Überarbeitungen waren.

Ich werde die ganze Zeit von diesem gebissen. Es ist schwer zu vermeiden, als Webentwickler. Mein bester Rat ist, mehr Zeit zu investieren, damit Sie die Änderungen richtig vornehmen können.


2
Nehmen Sie eine Richtlinie an, bei der Sie erst mit der Entwicklung beginnen, wenn Sie die Unterschrift eines Kunden haben.
Ben L

1
@Ben: Wenn das nur unter unserer Kontrolle wäre!
Sevenseacat
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.