Schädliche Versuchungen beim Programmieren

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?

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

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

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

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

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.

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

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

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

Ü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!

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.

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

Die schlimmste Versuchung:

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

Ratet mal, es tut weh. :)

Das Vergessen, dass das Schreiben von Code der letzte Ausweg ist, um ein Problem zu lösen .

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?

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

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

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

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

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.

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

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

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.

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.

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

eng verwandt mit

Der Plugin Fetisch

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

Na ja, manchmal treibt mich das Programmieren zur Flasche.

Umschreiben statt umgestalten.

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.

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 .

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.

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.