Schlechte Gewohnheiten sind schwer zu brechen und noch schwerer, wenn Sie nicht erkennen, dass das, was Sie tun, Ihre Arbeit untergräbt. Wenn Sie es wissen, es Ihnen aber egal ist – das wäre das Schlimmste. Aber Sie sind ja hier, nicht wahr?
Als Programmierer habe ich viele schlechte Praktiken gesehen, nicht nur in Bezug auf den Code, sondern auch auf die Teamarbeit. Viele dieser schlechten Angewohnheiten habe ich mir selbst angewöhnt. Hier sind meine 35 besten schlechten Programmiergewohnheiten, die in vier Kategorien eingeteilt sind: Code-Organisation, Teamarbeit, Schreiben von Code sowie Testen und Wartung.
Code-Organisation
1. Sagen: „Das repariere ich später“
Die Gewohnheit, Code-Korrekturen aufzuschieben, ist nicht nur ein Problem der Prioritäten. Die Organisation Ihres Issue-Trackers könnte einige Fortschritte bringen, aber Sie müssen auch eine Möglichkeit haben, kleinere Probleme, die auftauchen, zu verfolgen. Das Hinzufügen von „TODO“-Kommentaren ist ein schneller Weg, um sicherzustellen, dass Sie nichts übersehen.
2. auf einer Einzeiler-Lösung zu bestehen
Es ist eine häufige Eigenschaft von Programmierern, besessen davon zu sein, effiziente, elegante Codestücke zu schreiben. Es ist wie beim Lösen eines Puzzles – man findet eine Kombination von Funktionen und regulären Ausdrücken, die aus 20 Codezeilen 2 oder 3 macht. Leider führt dies nicht immer zu lesbarem Code, und das ist im Allgemeinen das weitaus wichtigere Ergebnis. Machen Sie Ihren Code erst zugänglich, dann schlau.
3. Sinnlose Optimierungen
Ein weiterer Punkt, an dem wir unsere Bemühungen oft falsch einsetzen, sind Optimierungen. Es hört sich toll an, die Größe der Website um ein paar Bytes zu verringern, aber wird das nicht durch gzip wieder wettgemacht? Und sind Anfragen nicht viel wichtiger? Kümmern Sie sich erst am Ende eines Projekts um Optimierungen, denn meistens ändern sich die Anforderungen, und Ihre Zeit war umsonst.
„Verfrühte Optimierung ist die Wurzel allen Übels.“
-Donald Knuth
4. Sich selbst davon überzeugen, dass Stilfragen nicht so wichtig sind
Wenn ich in den Jahren, in denen ich mir den Code anderer Leute angeschaut habe, etwas gelernt habe, dann ist es, dass die Beschäftigung mit Fragen des Codierungsstils das ist, was Entwickler am ehesten aufschieben. Vielleicht ist es für unerfahrene Programmierer schwer zu erkennen, was es bringt, sich mit Stilfragen zu befassen, aber mit der Zeit wird klar, dass ein Schneeballeffekt jedes Projekt in ein völliges Chaos verwandelt, sobald die Codequalität entgleist. Halten Sie sich strikt an die besten Praktiken, auch wenn sie vernachlässigbar erscheinen. Richten Sie Tools zur Codeüberprüfung und zum Linting ein, damit Sie sich um die wichtigeren Dinge kümmern können.
5. Dinge unter den Teppich kehren
Etweder durch das Abfangen und Ignorieren von Ausnahmen oder durch die Verwendung von Bibliotheken, die keine Fehler melden (wie jQuery), gibt es viele Möglichkeiten, Dinge unter den Teppich zu kehren. Aber wenn einer dieser Fehler zu einer Priorität wird, ist die Herausforderung, ihn zu beheben, um ein Vielfaches größer, wenn man bedenkt, dass man keine Ahnung hat, wo man anfangen soll. Eine einfache Möglichkeit, dies zu verhindern, besteht darin, die ignorierten Fehler zu protokollieren, damit Sie sie später untersuchen können.
6. Namen verwenden, die keine Informationen hinzufügen
Benennen ist schwer, aber es gibt einen einfachen Weg, um sicherzustellen, dass Ihre Variablen- und Funktionsnamen zumindest von anständiger Qualität sind. Solange die Namen irgendeine Art von Information hinzufügen, die der Rest des Codes nicht vermittelt, werden andere Entwickler es leichter haben, Ihren Code zu lesen. Der Grund, warum die Namensgebung so wichtig ist, liegt darin, dass Namen eine allgemeine Vorstellung davon vermitteln können, was der Code tut. Es kostet mehr Zeit, wenn Sie sich in die Berechnungen vertiefen müssen, um herauszufinden, was ein Teil des Codes tut, aber ein guter Name kann Ihnen helfen, in Sekundenschnelle zu verstehen, was der Code tut.
7. Ignorieren bewährter Best Practices
Code-Reviews, testgetriebene Entwicklung, Qualitätssicherung, Automatisierung der Bereitstellung – diese und andere Praktiken haben sich in zahllosen Projekten bewährt, weshalb Entwickler ständig darüber bloggen. Ein hervorragendes Nachschlagewerk für diese Best Practices ist das Buch Making Software: What Really Works, and Why We Believe It. Nehmen Sie sich die Zeit, um zu lernen, wie man sie richtig einsetzt, und Ihr Entwicklungsprozess wird sich bei all Ihren Projekten auf eine Weise verbessern, die Sie überraschen wird.
Teamarbeit
8. Zu frühes Aufgeben von Plänen
Ein todsicherer Weg, Ihr System undurchschaubar zu machen, ist es, sich nicht auf einen Plan festzulegen. Sie können immer, wenn Ihr Code kritisiert wird, sagen, dass der Plan nicht vollständig ist. Halbfertige Module führen jedoch zu eng gekoppeltem Code, sobald Sie versuchen, diese unfertigen Module miteinander arbeiten zu lassen. Diese Art von Komplikation tritt auch auf, wenn die Führungsrolle in einem Projekt wechselt und die neuen Leiter entscheiden, dass ihre Vorstellungen wichtiger sind als architektonische Konsistenz.
9. Beharren auf einem Plan, der wenig Aussicht auf Erfolg hat
So wie das Aufgeben von Plänen zu Problemen führen kann, kann man auch an einem Plan festhalten, der nicht funktioniert. Deshalb sollten Sie Ihre Ideen mit Ihrem Team teilen, um Rückmeldungen und Ratschläge einzuholen, wenn die Dinge schwierig werden. Manchmal kann eine andere Sichtweise den Unterschied ausmachen.
10. Die ganze Zeit allein arbeiten
Sie sollten sich bemühen, Ihre Fortschritte und Ideen mit dem Team zu teilen. Manchmal denkt man, dass man etwas richtig macht, aber man macht es nicht richtig. Auch für andere ist es von Vorteil, wenn Sie mit ihnen zusammenarbeiten. Ihre Arbeit wird oft besser, wenn Sie Ideen mit ihnen diskutieren und die weniger erfahrenen Mitglieder Ihres Teams anleiten, bei denen die Wahrscheinlichkeit größer ist, dass sie nicht weiterkommen.
11. Sich weigern, schlechten Code zu schreiben
Im Leben eines jeden Entwicklers kommt eine Zeit, in der man aufgrund von Terminen gezwungen ist, schlechten Code zu schreiben, und das ist in Ordnung. Sie haben versucht, Ihren Kunden oder Manager vor den Folgen zu warnen, aber sie bestehen darauf, die Frist einzuhalten, also ist es jetzt an der Zeit, zu programmieren. Oder vielleicht gibt es einen dringenden Fehler, der nicht warten kann, bis Sie eine saubere Lösung gefunden haben. Deshalb ist es wichtig, als Programmierer vielseitig zu sein und in der Lage zu sein, sehr schnell sowohl schlechten als auch guten Code zu schreiben. Hoffentlich kannst du den Code überarbeiten und die technische Schuld zurückzahlen.
12. Anderen die Schuld geben
Es ist kein Geheimnis, dass Arroganz eine allzu häufige Eigenschaft unter Entwicklern und anderen technischen Fachleuten ist. Die Verantwortung für Ihre Fehler zu übernehmen ist eine Tugend, die Sie unter Ihren Kollegen hervorheben wird. Scheuen Sie sich nicht, zuzugeben, dass Sie einen Fehler gemacht haben. Wenn Sie sich damit abgefunden haben, können Sie sich darauf konzentrieren, zu lernen, warum Sie diesen Fehler gemacht haben und wie Sie ihn vermeiden können. Wenn Sie den Fehler nicht zugeben, wird Lernen unmöglich.
13. Nicht mit Ihrem Team teilen, was Sie gelernt haben
Ihr Wert als Entwickler liegt nicht nur in dem Code, den Sie schreiben, sondern auch in dem, was Sie beim Schreiben lernen. Teilen Sie Ihre Erfahrungen, schreiben Sie Kommentare dazu, lassen Sie andere wissen, warum die Dinge so sind, wie sie sind, und helfen Sie ihnen, neue Dinge über das Projekt und seine Feinheiten zu lernen.
14. Zu langsames Feedback an Vorgesetzte/Kunden
Eine der wertvollsten Charaktereigenschaften eines Handwerkers besteht darin, dafür zu sorgen, dass alle so weit wie möglich auf der gleichen Seite stehen, was die Arbeit angeht. Der Grund dafür ist nicht, dass Ihr Vorgesetzter Tabellenkalkulationen füllen kann. Es ist auch zu Ihrem eigenen Vorteil: Sie werden weniger Unsicherheiten haben und die Ungewissheit über die Lebensdauer und Zukunft des Projekts verringern.
15. Google nicht genug nutzen
Die beste Möglichkeit, ein komplexes Problem schnell zu lösen, ist, es gar nicht erst lösen zu müssen. Im Zweifelsfall googeln Sie es. Natürlich können Sie stattdessen den Ingenieur neben Ihnen befragen, aber er wird selten eine so detaillierte Antwort geben können wie Stack Overflow, ganz zu schweigen davon, dass Sie auch seine Arbeit unterbrechen.
16. Überbewertung Ihres persönlichen Stils
Streben Sie immer danach, Ihren Arbeitsstil und die Einrichtung Ihrer Umgebung mit Ihrem Team abzustimmen. Idealerweise sollte jeder in Ihrem Team unter ähnlichen Bedingungen arbeiten und denselben Codierungsstil verfolgen. Es kann mehr Spaß machen, Dinge auf Ihre Art zu tun, aber die Kollegen sind vielleicht nicht an Ihren Programmierstil gewöhnt, und wenn er ungewöhnlich ist, wird es für den nächsten Entwickler schwieriger sein, mit dem zu arbeiten, was Sie aufgebaut haben.
17. Eine persönliche Beziehung zu Ihrem Code
Wenn jemand Ihren Code kommentiert, nehmen Sie es nicht persönlich. Ihr Code sollte auf einer soliden Grundlage stehen, d.h. Sie sollten in der Lage sein zu erklären, warum Sie ihn auf diese Weise geschrieben haben. Wenn er verbesserungswürdig ist, ist das nur ein Hinweis auf die Korrektheit des Codes, nicht auf dich selbst.
Code schreiben
18. Nicht wissen, wie man optimiert
Eine gute Optimierungsstrategie braucht einige Erfahrung, um richtig zu sein. Sie erfordert Erkundung, Analyse und die Kenntnis aller an einem Prozess beteiligten Systeme. Informieren Sie sich über diese Dinge. Informieren Sie sich über die Komplexität von Algorithmen, die Auswertung von Datenbankabfragen, Protokolle und die Messung der Leistung im Allgemeinen.
19. Das falsche Werkzeug für die Aufgabe verwenden
Man kann nur so viel wissen, aber der Grund, warum man ständig dazulernen muss, ist, dass jedes neue Problem einen anderen Kontext mit sich bringt und ein anderes Werkzeug erfordert – eines, das für die jeweilige Aufgabe besser geeignet ist. Seien Sie offen für neue Bibliotheken und Sprachen. Treffen Sie Ihre Entscheidungen nicht ausschließlich auf der Grundlage dessen, was Sie wissen.
20. Sich nicht um die Beherrschung der Tools und der IDE kümmern
Jeder neue Hotkey, Shortcut oder Parameter, den Sie bei der Verwendung der Tools, mit denen Sie täglich arbeiten, lernen, wird sich positiver auf Ihre Programmiergeschwindigkeit auswirken, als Sie denken. Es geht nicht darum, mit einer Tastenkombination ein paar Sekunden einzusparen, sondern darum, den Kontextwechsel zu reduzieren. Je mehr Zeit Sie für jede kleine Aktion aufwenden, desto weniger Zeit haben Sie, um darüber nachzudenken, warum Sie das tun und was als Nächstes kommt. Wenn Sie Abkürzungen beherrschen, haben Sie den Kopf frei.
21. Ignorieren von Fehlermeldungen
Nehmen Sie nicht an, dass Sie wissen, was mit Ihrem Code nicht stimmt, ohne eine Fehlermeldung zu lesen, oder dass Sie es schnell genug herausfinden werden. Es ist immer besser, mehr Informationen über ein Problem zu haben, und sich die Zeit zu nehmen, diese Informationen zu sammeln, spart auf lange Sicht mehr Zeit.
22. Romantisierung Ihres Entwickler-Toolkits
Manchmal ist Ihr bevorzugter Editor oder Ihr Befehlszeilen-Tool nicht das beste Werkzeug für die anstehende Aufgabe. Visual Studio ist großartig zum Schreiben von IDEs, Sublime ist großartig für dynamische Sprachen, Eclipse ist großartig für Java, und so weiter. Sie mögen vim oder emacs lieben, aber das bedeutet nicht, dass es das richtige Werkzeug für jede Aufgabe ist.
23. Hardcoding von Werten, anstatt sie konfigurierbar zu machen
Denken Sie immer daran, welche Änderungen kommen könnten und wie man damit umgeht. Die technischen Schulden wachsen ins Unermessliche, wenn man die beweglichen Teile nicht vom Rest der Arbeit trennt. Verwenden Sie Konstanten und Konfigurationsdateien, wo es angebracht ist.
24. Das Rad immer wieder neu erfinden
Schreiben Sie keinen Code, den Sie nicht brauchen. Vielleicht hat jemand anderes bereits viel Zeit mit Ihrem Problem verbracht, und er oder sie hat vielleicht eine gut getestete Lösung, die Sie wiederverwenden können. Ersparen Sie sich die Mühe.
25. Blindes Kopieren/Einfügen von Code
Verstehen Sie den Code, bevor Sie ihn wiederverwenden. Manchmal sieht man nicht alles, was der Code macht, auf den ersten Blick. Du wirst auch mehr über ein Problem lernen, wenn du dir die Zeit nimmst, den Code im Detail zu lesen.
26. Sich nicht die Zeit nehmen, um zu lernen, wie die Dinge wirklich funktionieren
Nutzen Sie immer die Gelegenheit, Ihr Wissen zu erweitern, indem Sie darüber nachdenken, wie die Dinge funktionieren und über die zugrunde liegenden Probleme lesen. Du kannst Zeit sparen, wenn du dich jetzt nicht darum kümmerst, aber das, was du bei einem Projekt lernst, wird auf lange Sicht wichtiger sein als die tatsächliche Ausführung des Projekts.
27. Übermäßiges Vertrauen in den eigenen Code
Es ist gefährlich, anzunehmen, dass etwas, nur weil man es geschrieben hat, auch gut sein muss. Man lernt mehr über das Programmieren, wenn man an neuen Dingen arbeitet und Erfahrungen sammelt, also schau dir von Zeit zu Zeit deinen alten Code an und denke darüber nach, wie du dich weiterentwickelt hast.
28. Nicht über die Kompromisse der einzelnen Entwürfe, Lösungen oder Bibliotheken nachdenken
Jedes Produkt hat seine Feinheiten, die Sie nur kennenlernen, wenn Sie es benutzen und analysieren. Wenn Sie ein paar Anwendungsbeispiele für eine Bibliothek sehen, werden Sie sie nicht beherrschen, und es bedeutet auch nicht, dass sie für jede Situation, die in Ihrem Projekt auftaucht, die perfekte Lösung ist. Seien Sie ständig kritisch gegenüber allem, was Sie verwenden.
29. Keine Hilfe holen, wenn man nicht weiterkommt
Eine kurze Feedback-Schleife wird immer weniger schmerzhaft für Sie sein. Um Hilfe zu bitten, bedeutet nicht, dass Sie inkompetent sind. Die richtigen Leute werden Ihre Bemühungen und Ihr Eingeständnis von Unwissenheit als Antrieb zum Lernen sehen, und das ist eine große Tugend.
Testen und Wartung
30. Tests schreiben, um sie zu bestehen
Tests zu schreiben, von denen man weiß, dass sie bestehen werden, ist notwendig. Sie machen das Refactoring und die Umstrukturierung eines Projekts viel sicherer. Andererseits muss man auch Tests schreiben, von denen man weiß, dass sie nicht bestanden werden. Sie sind notwendig, um das Projekt voranzubringen und Probleme im Auge zu behalten.
31. Vernachlässigung von Leistungstests für kritische Fälle
Bereiten Sie etwa in der Mitte des Entwicklungsprozesses eines Projekts ein automatisches Leistungstest-Setup vor, damit Sie sicherstellen können, dass Sie keine eskalierenden Leistungsprobleme haben.
32. Nicht überprüfen, ob der Build funktioniert
Es kommt selten vor, dass ein Build erfolgreich ist, aber nicht wirklich funktioniert, aber es kann passieren, und je länger man damit wartet, das Problem zu beheben, desto mühsamer wird es. Schnelles Testen jedes Builds ist eine wichtige Angewohnheit.
33. Große Änderungen zu spät einführen oder nach einer großen Änderung abhauen
Das ist der Punkt, an dem Selbstüberschätzung einen zu Fall bringt, und es kann sein, dass man mehrmals verbrannt wird, um zu lernen, warum man das nicht tun sollte, also nehmen Sie jetzt meinen Rat an und stellen Sie sicher, dass Sie immer da sind, wenn Ihr Build schließlich kaputt geht.
34. Code verleugnen, den du geschrieben hast
Sei bereit, Code zu unterstützen, den du geschrieben hast. Sie sind die am besten geeignete Person, um anderen zu helfen, ihn zu verstehen. Du solltest dich bemühen, dass dein Code auch in vielen Jahren noch für dich und andere lesbar ist.
35. Ignorieren der nicht-funktionalen Anforderungen
Wenn Sie versuchen, etwas zu liefern, kann es leicht passieren, dass Sie einige wichtige Bereiche wie Leistung und Sicherheit vergessen. Führen Sie eine Checkliste für diese Bereiche. Sie wollen nicht, dass sie Ihnen die Party verderben, weil Sie Ihre Fristen ohne Rücksicht auf diese nichtfunktionalen Belange festgelegt haben.
Was sind Ihre schlimmsten Programmiergewohnheiten?
Wie man oft sagt, sind wir Geschöpfe der Gewohnheit. Die Verbesserung der Arbeitsweise durch Gewohnheiten ist ein guter Weg, um zu vermeiden, dass man zu viel über jede einzelne Situation nachdenken muss. Wenn man sich einmal eine gute Vorgehensweise angewöhnt hat, wird sie mühelos.