it-swarm.dev

Schädliche Versuchungen beim Programmieren

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

Zum Beispiel, wenn Sie wirklich den Drang verspüren, etwas zu tun, und Sie glauben, dass es dem Projekt zugute kommt, oder wenn Sie sich einfach dazu verleiten, es zu glauben, und nach einer Woche stellen Sie fest, dass Sie keine gelöst haben ) echte Probleme, aber stattdessen neue geschaffen oder im besten Fall Ihr inneres Tier ohne sichtbare Auswirkungen erfreut.

Persönlich fällt es mir sehr schwer, schlechten Code nicht umzugestalten. Ich arbeite mit viel schlechtem Legacy-Code und es dauert einige tiefe Atemzüge, um ihn 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 Layout der Benutzeroberfläche zu ändern, nur weil es mir Spaß macht. Manchmal sage ich mir, ich arbeite an der Benutzerfreundlichkeit, aber die Wahrheit ist nur, dass ich es liebe, Knöpfe zu bewegen.

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

97
Dan

Vorzeitige Verallgemeinerung ist mein großer Bugaboo; Anstatt das vorliegende Problem zuerst zu lösen und zu warten, bis es tatsächlich notwendig ist, den allgemeinen Fall zu lösen, gehe ich immer dem allgemeinen Fall nach vorne und nach Schreiben Sie am Ende eine Menge Code, der komplexer ist, als er sein muss.

Aktualisieren:

Siehe " Sin # 1 - Vorzeitige Verallgemeinerung " für eine ausführliche Beschreibung.

67
John Bode

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

197
user18041

Die Frist ist soooooo weit weg, ich habe mehr als genug Zeit dafür. Warum also nicht ein bisschen Zeit im Internet surfen?

105
user281377

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

103
davidhaskins
  1. Refactoring Teil des Codes einige Tage vor der Veröffentlichung.
  2. Internet : Die größte Ablenkung von allen.
  3. Neue Technologie: Ich kann meine Hände nicht von neuer Technologie lassen.
  4. Optimieren : Optimieren, optimieren. .. und mehr Optimieren
  5. Perfektion: Ich war noch nie mit dem Code zufrieden.
  6. TODO : Zeitmangel, der niemals erledigt wird.
  7. Zeitschätzung : Viele PMs nehmen dies nicht als "Schätzung". Sie nehmen als Tatsache.
  8. Versprechen : Zu viele Versprechen geben.
74
Amir Rezaei

Der Versuch, alles im eigenen Haus zu bauen, wenn vorhandene Frameworks und Bibliotheken vorhanden sind.

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

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

48
Tomas Narros

Zu optimistische Schätzungen

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

Immerhin ist dein Darm wahrscheinlich schon zu niedrig!

46
Nicole

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

Um zu beweisen, wie gut Sie als Entwickler sind.

Um den Code, den Sie geschrieben haben, als Ihren zu betrachten.

33
biziclop

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

32
Richard Miskin

Die schlimmste Versuchung:

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

Ratet mal, es tut weh. :) :)

(goto

31
Goran Jovic
25
Dan

Feature Creep

Erstellen Sie einen Plan, halten Sie sich daran und stellen Sie ihn bereit. Und dann geh zurück und füge das Zeug hinzu, nach dem die Leute fragen.

Ich habe das immer und immer wieder gesehen. Sie setzen sich, erarbeiten das Design und beginnen mit dem Codieren. Die Benutzer hören einen verwirrten Unsinn darüber, dass ihre Lieblingsfunktion "fehlt", und sie beginnen, sich dafür einzusetzen. Ihr Chef verlangt, dass Sie es in der 11. Stunde hinzufügen, es verschmutzt die Bereitstellung, es führt überall Fehler ein und 3 Monate später, wenn sich alle beruhigt haben, werden Sie gebeten, es zu entfernen, weil niemand herausfinden kann, warum Sie setzen das beschissene Retro-Feature in erster Linie! Können Sie nicht sagen, dass der Rest des Designs es sinnlos machte?

23
Satanicpuppy
  1. Weitere Funktionen hinzufügen

  2. Der Wettbewerb hat diese Funktion. Dies ist also ein Muss, daher mehr Programmierung als Analyse von Strategie, Positionierung usw.

  3. Der Wettbewerb hat diese Funktion NICHT. Dies ist also ein Unterscheidungsmerkmal, daher mehr Programmierung als Analyse von Strategie, Positionierung usw.

  4. Lösen eines Geschäftsproblems mit mehr Programmierung. Bessere Kenntnisse in der Verwaltung des Linux-Servers, auf dem Ihre Website gehostet wird, können beispielsweise nicht durch Programmieren weiterer Funktionen erzielt werden. Manchmal muss man nur lernen, wie man das Problem behebt, anstatt das Ganze in C # .Net neu zu codieren

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

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

  7. Planen Sie zu codieren, aber noch nicht zu codieren, weil Sie "es richtig machen" wollen.

  8. Codieren Sie eine schmutzige Version und versprechen Sie, dass Sie "es später besser machen", aber nie wieder "es besser machen".

  9. Kein Modell oder keine Sitemap machen, weil es "so lästig" ist. Ich kann nur die Seiten der Konkurrenten für Modelle scannen und "später" freihändig eine Sitemap zeichnen, was niemals der Fall ist. Und dann programmieren Sie einfach 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, mir aber oft getäuscht, dass ich es nicht getan habe.

Ich behebe gerade 9.

[~ # ~] edit [~ # ~] Wusste nicht, dass die Frage erfordert, dass wir Lösungen einbringen.

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 nur eine Sache.

Lesen Sie über Twitter, Groupon usw., wie sie die Dinge auf nur 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, denken Sie noch einmal darüber nach. Strg + F für diese Zeile "Je mehr Funktionen ich der Software hinzufüge, desto schlechter verkauft sie sich. (Dies ist für die meisten Softwareentwickler natürlich sehr unintuitiv.)" In dieser 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) Lösen eines Geschäftsproblems mit mehr Programmierung.

Wenn Sie jemanden einstellen müssen, der Sie unterrichtet, beraten oder für Sie erledigen und dann dokumentieren kann, wie er es getan hat, damit Sie es beim nächsten Mal selbst tun können. TU ES EINFACH!! Schreiben Sie keinen Code neu, übergeben Sie GO nicht und sammeln Sie keine 200 US-Dollar.

5) Ein Marketingproblem mit mehr Programmierung lösen.

Wenn die Leute nicht verstehen, was Sie verkaufen, ist dies IS ein Marketingproblem. Gehen Sie zurück zu Lösung 1 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 vernünftigerweise noch 2 Wochen dauern.

Bewerten Sie nun die Zeit, die zum Programmieren eines Skripts zur Lösung dieses Problems aufgewendet wurde. 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: Auslagern, eine Lösung von der Stange kaufen, nichts dagegen tun 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" wollen

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ücken und 5x5 Kniebeugen gemacht habe.

8) Codiere eine schmutzige Version und verspreche, dass du es "später besser machen" wirst, aber nie zurück zu "mach es besser"

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

9) Kein Modell oder keine Sitemap erstellen, weil es "so mühsam" 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 Modelle zu wiederholen, weil ich mich wie ein Künstler, Architekt und Visionär in einem fühle, obwohl meine Zeichnung 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 und Ihnen bei RAD hilft.

EDIT beenden

20
Kim Stacks

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

17
Adam Crossland

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

16
Hila

"Dafür kann ich ohne Test auskommen. 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."

16
Wayne Conrad

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

Stretching, Liegestütze oder Klimmzüge (oder jede andere körperliche Übung) für die erste und pessimistische Stimmung, bevor die zweite geschätzt wird.

15
Nikita Barsukov

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

13
k3b

Eine massiv schädliche Versuchung, unter der mein Projekt gelitten hat, ist der „Inner Platform Effect“. Dies ist ein Ansatz, den Architekten, die längst nicht mehr existieren, in ihrer unendlichen Weisheit niedergelegt haben. Er hat ein Projekt geschaffen, das rund 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
AlexC

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, 100% objektiv zu sein.

Die Zeitersparnis kann so groß sein, dass selbst wenn 9 von 10 Fällen die Lösung von Drittanbietern vermieden werden sollte, ich objektiv genug sein muss, um die zu realisieren das wird funktionieren.

10
Nicole

Das Es muss eine Bibliothek geben, die das irgendwo macht Syndrom.

eng verwandt mit

Der Plugin Fetisch

9
Newtopian

Entwerfen, Codieren und/oder Testen von Einheiten anhand der bereitgestellten "Beispieldaten", anstatt eine Kopie der tatsächlichen Datenbank des Kunden zu analysieren. Die Frist war kurz und sie sagten immer wieder, dass es kommen würde, 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 real Daten habe.

9
dwidel

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

8
Naftuli Kay

Umschreiben statt Refactoring.

7
Dave O.

Manchmal treibt mich das Programmieren zur Flasche.

7
mipadi

Zu denken, dass es einen besseren Weg geben muss, dies zu tun. Ich werde mich nicht mit etwas zufrieden geben, das "gut genug" sein könnte. Ich nehme nichts weniger als Perfektion! Normalerweise wird dies vermieden, indem Sie mit anderen Personen sprechen, die eine andere Perspektive auf ein Problem haben oder eine Lösung aus einem anderen Blickwinkel sehen.

6
JB King

Wenn Sie alles auf den Punkt automatisieren, wird mehr Zeit für die Wartung der Tools aufgewendet als für die eigentliche Arbeit.

Lösung: Genau wie bei der Codeoptimierung zuerst Produktivitätsengpässe finden und erst nach ihrer Entdeckung mit einer guten Automatisierung beheben.

5
Dan

Was sind deine Programmierdämonen?

Abgesehen von dem, was einige andere 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.

4
Mahesh Velaga

Mein Gehirn ist von diesem Projekt erschöpft. Ich mache nur eine kurze Pause bei diesem kurzen Nebenprojekt, um es zu verjüngen.

3
emragins

"There must be a better solution to this."

Und am Ende denken und denken Sie und lassen Ihre Gedanken in ein weit entferntes Land abdriften, bis Sie merkten, dass Sie zu lange weg waren. Es sollte in Ordnung sein, aber nicht, wenn Sie eine Frist haben.

3
gladysbixly

Wir haben noch keine Genehmigung vom Kunden erhalten, aber die Frist nähert sich. Hier sind einige vorläufige Kompositionen, damit Sie loslegen können ...

Später, nachdem Sie das Projekt so erstellt haben, dass es zu den Kompositionen passt ...

Oh, hier sind die Revisionen des Kunden, sie wollen nur ein paar Kleinigkeiten ändern *

(* Hauptfunktionalität ist völlig anders)

Dann überarbeiten Sie Ihren ursprünglichen Code weiter, basierend auf dem ursprünglichen fehlerhaften Modell, anstatt nur 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. Als Webentwickler ist es schwer zu vermeiden. Mein bester Rat ist, mehr Zeit zu drücken, damit Sie die Änderungen richtig vornehmen können.

3
travis

Schreiben von neuem Code nach dem Einfrierdatum des Codes.

Das Einfrierdatum des Codes muss in Stein gemeißelt sein. Jeder neue Code, der nach dem Schreiben geschrieben wurde, muss in die zukünftige Version verschoben werden, da möglicherweise alle Arten von Regressionstests erforderlich sind.

3
Mag20

Um die Frage zu beantworten, wie man sie vermeidet: Machen Sie sich mit Anti-Patterns vertraut, damit Sie sie aufrufen können, wenn Sie sie erkennen.

3
Lee Kowalkowski

Klugheit. Natürlich nicht immer. Einige Klugheit und Prägnanz lassen Ihren Code sehr schön und wartbar aussehen. Aber nur weil du es kannst

x=foo?true:bar?biz,FooBar(true)?!foo:baz,FooBar(false):baz;

anstelle von ein paar Zeilen if-Anweisungen heißt das nicht, dass Sie es tun sollten.

Übrigens, ja, ich weiß, dass es in meinem Beispiel ein bisschen Redundanz gibt ... Wenn Sie es selbst gefangen haben :)

3
Earlz

Alle anderen plus Feature Creep: "Es wäre wirklich cool, wenn es dies tun würde, und ich weiß, dass der Kunde es lieben wird und es in die Spezifikation aufgenommen hätte, wenn er daran gedacht hätte." Ich versuche dies zu vermeiden, indem ich frage, wo in der realen Spezifikation die Anforderung für diese wirklich coole Funktion besteht.

Andererseits bekomme ich nicht oft schriftliche Spezifikationen.

2
PSU

"Es ist nur der Pilot, daher ist es nicht erforderlich, die Wartung oder Erweiterung zu vereinfachen.".

Nach meiner Erfahrung ist es üblicher, dass der Pilot in die Produktion eintritt und das Produkt, für das er verschrottet werden soll, als der Pilot verschrottet und das eigentliche Produkt in den Status "Produktionsbereit" versetzt wird.

2
jwenting

Verbringen Sie zu lange damit, den Editor zu optimieren. Der Versuch, das beste Schrift- und Farbschema für die Programmierung zu finden.

2
dheerosaur

"Mir wurde eine Funktion zugewiesen, die mit [Software/zB: Sharepoint] verbunden ist. Ich sollte wahrscheinlich alles wissen, was es über diese Software zu wissen gibt."

Dann verbringen Sie Wochen damit, dieses Produkt zu erforschen, wenn die Funktion in ein oder zwei Tagen geschrieben und getestet werden könnte. Der Hunger nach Wissen hat einen dunklen Unterbauch. rawr

2
Steven Evers

"Ich werde das später kommentieren/dokumentieren"

es passiert nie, der Autor geht weiter und dann stellen Sie fest, dass er seinen Code nicht kommentiert, wenn Ihnen der Job zugewiesen wurde.

2
sunwukung

Ein neues Projekt anzugreifen, ohne es zu verstehen, und ich vermeide dies normalerweise, indem ich ein wenig über die Projektdomäne recherchiere, bevor ich anfange, damit zu arbeiten, nur um einen guten Ausgangspunkt zu haben und um zu beweisen, dass das Projekt komplexer ist als Ich war anfangs durch.

Ich habe auch das Problem, dass ich mich gerne mit Knöpfen bewege, sie sind so cool !! Aber vielleicht liegt das daran, dass ich Multimedia-Systeme und das Design von Benutzeroberflächen mache ... Für mich bestand die Lösung für dieses Problem darin, dies tatsächlich in meinen Lehrplan aufzunehmen und etwas darüber zu studieren, damit ich eine gültige Entschuldigung habe, wenn jemand etwas sieht Ich spiele viel mit der Benutzeroberfläche. (Dazu gehört, dass Sie den Hintergrund grün, den Text orange und die Symbole mit viel Gelb setzen.)

1
Coyote21

Sehr vollständige Liste: Anti-Patterns .

1
vartec
/**
* Calculates the return value for humptyDumpty
*
* return int modifiedHumptyDumpty
*/
function awesomeWayToCalculateSomething(int humptyDumpty) {
.. 
}

TODO: Ich muss das richtig dokumentieren.

Will _never_ passiert

1

Verwenden einer Sprachfunktion, einer Redewendung oder eines Entwurfsmusters nicht, weil dies die beste Lösung für das Problem ist, sondern nur, um es zu verwenden.

1
Dima

Ich glaube, ich habe es im Kopf, dass Aufzählungen viel nützlicher sind als in Java. Ich neige dazu, zu viel mit ihnen zu tun und mich dann festzumachen, weil sie den Polymorphismus nicht wirklich unterstützen.

1
MattLBeck

90% eines Rades sind nicht besser als eines zu erfinden.

1

Verwenden eines Frameworks, ohne es vollständig zu verstehen. Aber dann wieder. Ein Framework wird nur von seinen Erstellern vollständig verstanden (in den meisten Fällen). Ich habe keine wirkliche Lösung für diesen Punkt, versuche aber, so viel wie möglich aus einem Framework heraus zu verstehen.

1
user18483

Behebung eines Fehlers, der Sie gestört hat, weil er "so einfach" ist, aber niemals die Qualitätskontrolle und/oder den Kunden informiert.

Diese Korrekturen stürzen immer die Produktion ab.

1
Scott McIntyre

Jemand sagte vorzeitige Verallgemeinerung, aber vorzeitige Spezialisierung kann genauso schlecht sein. Mit vorzeitiger Verallgemeinerung können Sie eine Software erhalten, die in 50% der Fälle funktioniert, aber vorzeitige Spezialisierung kann in 5% oder keiner funktionieren. Am Ende hätte das Management lieber 50% als 5%.

1
MPelletier

Ich habe in meiner Freizeit unzählige Stunden zusätzliche Arbeit für das Unternehmen geleistet, nur um herauszufinden, "dass dies nicht die Richtung war, nach der sie gesucht haben".

1
user13280

Was sind deine Programmierdämonen?

Alles, was bereits erwähnt wurde, insbesondere der Drang, wie verrückt umzugestalten.

und wie vermeidest du sie?

Bevor Sie mit einer nicht trivialen Bearbeitung beginnen, nehmen Sie meine Hände 5 Sekunden lang von der Tastatur und wägen Sie schnell mögliche Ergebnisse von Änderungen ab, anstatt sie zu verlassen. Wägen Sie dann vor dem Festschreiben etwa eine Minute lang die gleichen Konsequenzen ab.

1
Cheezmeister

Um ein bequemes Sofa zum Arbeiten oder Arbeiten im Bett zu finden.

1
kiewic

Perfekt sein"

Es ist zwar ein Problem, es beim ersten Mal nicht richtig zu machen, aber nicht so schlimm wie ein unsterblicher Fokus auf Perfektion. Mach es einfach, es gibt kein Perfektes, und wenn ja, ist es rein zeitlich oder bereits erledigt und es lohnt sich nicht, es noch einmal zu tun.

0
blunders