Jedes Jahr weniger saugen? [geschlossen]

Jedes Jahr weniger saugen - Jeff Atwood

Ich war auf diesen aufschlussreichen Artikel gestoßen. Ich zitiere direkt aus dem Beitrag

Ich habe oft gedacht, dass bescheidene Programmierer sich verbessern, wenn sie jedes Jahr weniger saugen. Sie sollten mit dem Code, den Sie vor einem Jahr geschrieben haben, unzufrieden sein. Wenn dies nicht der Fall ist, bedeutet dies, dass entweder A) Sie seit einem Jahr nichts mehr gelernt haben, B) Ihr Code nicht verbessert werden kann oder C) Sie alten Code nie wieder aufrufen. All dies ist der Todeskuss für Softwareentwickler.

1. Wie oft passiert dir das oder passiert es dir nicht?
2. Wie lange dauert es, bis sich Ihre Codierung tatsächlich verbessert? Monat Jahr?
3. Besuchen Sie jemals Ihren alten Code noch einmal?
4. Wie oft plagt dich dein alter Code? oder wie oft müssen Sie sich mit Ihren technischen Schulden befassen.

Es ist definitiv sehr schmerzhaft, alte Fehler und schmutzigen Code zu beheben, die wir möglicherweise durchgeführt haben, um eine Frist schnell einzuhalten, und diese schnellen Korrekturen. In einigen Fällen müssen wir möglicherweise den größten Teil der Anwendung / des Codes neu schreiben. Keine Argumente dazu.

Einige der Entwickler, denen ich begegnet war, argumentierten, dass sie sich bereits in der Entwicklungsphase befanden, in der ihre Codierung nicht verbessert werden muss oder nicht mehr verbessert werden kann.

• Passiert das?
• Wenn ja, wie viele Jahre nach dem Codieren in einer bestimmten Sprache erwartet man dies?

Verbunden:

Haben Sie jemals auf einen Teil Ihres alten Codes und Ihrer schmerzverzerrten Grimasse zurückgeschaut?

Star Wars Moment im Code "Luke! Ich bin dein Code!" "Nein! Unmöglich! Es kann nicht sein!"

  > Sucking Less Every Year ?

Nein , aber Saugen anders Jedes Jahr :-)

Nach meinen ersten Bewertungen vor vielen Jahren litt ich unter fehlenden Namenskonventionen.

Dann litt ich, dass mein Code (unnötig) implementiert wurde, um so allgemein wie möglich zu sein, aber das machte es schwierig, den Code zu verstehen und zu pflegen.

Dann lernte ich die testgetriebene Entwicklung InversionOfControl, welche Dot-Net-Generika wo und viele mehr.

Fazit

Das Leiden an alten schlechten Gewohnheiten nimmt ab, wurde aber durch neue Leiden, die ich bekam, überkompensiert, weil ich mehr gelernt habe.

Interessanterweise waren alle "Rockstar" -Programmierer, mit denen ich jemals zusammengearbeitet habe, äußerst bescheiden, lernwillig und bereit zuzugeben, dass sie nicht alles wissen. Heck, viele waren tatsächlich geradezu selbstironisch, zumindest in unbeschwerten Momenten.

Ich glaube nicht, dass ich jemals einen Entwickler getroffen habe, der glaubt, dass seine Codierung "nicht verbessert werden kann", aber irgendetwas sagt mir, dass diese Jungs so weit wie möglich von Rockstar entfernt sind - um es milde auszudrücken.

Die folgenden Punkte sind keine Ratschläge, sondern ein persönliches Protokoll:

• mit weniger globalen Variablen
• Verwenden Sie keine Abkürzung für Variablen oder Funktionsnamen
• Schreibe [einige] Testcodes
• Beurteilen Sie Code nicht als langsam (oder schnell) ohne Benchmarking
• Erfahren Sie, wie Sie eine App laden
• Repariere es nicht, wenn es nicht kaputt ist
• Verwenden Sie ein Quellcode-Management-Tool (git / hg).
• Refactoring ist cool, unterschätzen Sie nicht die damit verbundenen Testkosten
• Sicherheit ist schwer, also hüte dich so früh wie möglich davor
• Patchen Sie einige Open Source-Projektfehler
• Blog etwas Neues
• Benutzerfreundlichkeit ist möglicherweise keine Funktionsanforderung, aber wichtig

Ich habe nicht alles innerhalb eines Jahres gelernt, alles braucht Zeit ...

Oft denken die Leute, dass guter Code plötzlich passiert, aber für die meisten von uns Sterblichen wächst guter Code in unserer Codebasis. Ich meine, es ist sehr schwierig, von Anfang an die perfekte Software zu schreiben, da sich die Anforderungen ständig ändern und wir keine perfekten Programmierer sind und auch nicht ständig dumme Entscheidungen von Managern und Programmierern getroffen werden. Dann sehe ich, dass jede Anforderung eine gute Gelegenheit bietet, einen Teil des alten Codes in besseren Code umzuwandeln (und dafür bezahlt zu werden!) Und ein bisschen technische Schulden zurückzuzahlen. Wie sie sagen: "Verlassen Sie das Code-Repository jedes Mal ein bisschen besser, wenn Sie Code festschreiben". Dann entwickelt sich Ihr System zu einem idealeren System.

Ich kenne absolut keinen Programmierer, der stolz auf seine Software ist, aber das ist gut. Dann hat der Programmierer dabei gelernt.

Auch wenn Sie das Buch "Code reinigen" lesen, erhöhen Sie Ihren eigenen Code "Saugfaktor" mehrmals. : D.

Ich habe tatsächlich beide Seiten der Medaille dafür.

Auf der einen Seite sehen Sie sich alten Code an und sehen, dass er voller Fehler und komplizierter Methoden ist, die einfach durch die Nutzung von Techniken und Sprachfunktionen erreicht werden, die Sie damals noch nicht kannten.

Auf der anderen Seite finden Sie eine besonders elegante Lösung für ein Problem, und Sie können nicht anders, als ein selbstgefälliges Grinsen darüber auszulösen, wie klug Sie damals waren.

Und dann scrollen Sie ein paar Zeilen nach unten und verziehen das Gesicht vor Entsetzen, weil Sie GOTO in C verwendet haben.

Hmm ... Ich bin oft ziemlich angenehm überrascht, wie gut ein Großteil meines älteren Codes ist.

Wenn ich es heute machen würde, würde ich es oft anders schreiben, aber wenn ich mit den Einschränkungen der Zeit leben müsste, wäre ich mir nicht sicher , ob ich es tun würde. Wenn Sie sich auf einen typischen Computer mit mindestens ein paar GB RAM verlassen können, können (und sollten) Sie Ihren Code etwas anders schreiben als bei einer großen Festplatte mit 100 Megabyte.

1. Wie oft passiert dir das oder passiert es dir nicht?

2. Wie lange dauert es, bis sich Ihre Codierung tatsächlich verbessert? Monat Jahr?

3. Besuchen Sie jemals Ihren alten Code noch einmal?

4. Wie oft plagt dich dein alter Code? oder wie oft müssen Sie sich mit Ihren technischen Schulden befassen.

1. Jedes Mal, wenn ich etwas Neues lerne, ist das hoffentlich jeden Tag.

2. Wenn ich das Gelernte umsetzen kann, ist es unmittelbar nach dem Umsetzen.

3. Ja, nur für (1) neue Funktionen, (2) Fehlerkorrekturen, (3) Nostalgie, (4) Sehen Sie, wie ich etwas gelöst habe, kann nützlich sein.

4. Im Zusammenhang mit 1., wenn ich lerne, wie man etwas besser macht, bin ich mir bewusst, dass einige ältere Projekte "besser hätten gemacht werden können". Ich lasse sie sein. Stellen Sie einfach sicher, dass das nächste Projekt besser durchgeführt wird. Ich mache mir keine Sorgen, es sei denn, es ist ein tatsächlicher Fehler.

In einer anderen Frage ging es um die Möglichkeiten, die Qualität Ihres eigenen Codes zu bewerten. Einer meiner Vorschläge war, es in einigen Jahren zu überprüfen, wenn Ihre Erfahrung viel höher ist als zu dem Zeitpunkt, als der Code geschrieben wurde. Ein Zitat meiner Antwort auf diese andere Frage steht in direktem Zusammenhang mit Ihrer Frage:

"In meinem Fall beträgt die Lebensdauer ein Jahr: Dies bedeutet, dass ich den Code, den ich vor sechs Monaten geschrieben habe, möglicherweise ändern kann. Wenn der Code jedoch vor zwei Jahren geschrieben wurde, besteht eine hohe Wahrscheinlichkeit, dass er geworfen und seitdem vollständig neu geschrieben wird es saugt einfach zu viel. "

Ja, in der Praxis wird jeder Code, den ich geschrieben habe, aus meiner Sicht in einem Jahr unerträglich. Und ich spreche nicht über Wegwerfcode, sondern auch über den Code, den ich unter Berücksichtigung von Qualität, Wartbarkeit und Lesbarkeit geschrieben habe. Im Moment gab es keine Ausnahmen.

Um Ihre zweite Frage zur Lebensdauer zu beantworten, variiert sie stark. Ein wegwerfbarer Code hat eine Lebensdauer von null Sekunden : Er saugt kurz nachdem Sie ihn geschrieben haben, aber es spielt keine Rolle. Einige Codeteile, die ich geschrieben habe, waren nach zwei Jahren erträglich , erforderten jedoch einige kosmetische Änderungen: ein wenig Refactoring, Durchsetzung der StyleCop-Regeln usw. Im Durchschnitt variiert die Lebensdauer in meinem genauen Fall zwischen acht Monaten und einem Jahr für C # und zwischen zwei und sechs Monaten für PHP.

Besuche ich meinen alten Code noch einmal? Ja, natürlich wie jeder Entwickler, es sei denn, Sie interessieren sich nicht für DRY und erfinden Ihr eigenes Rad immer wieder neu. Es besteht auch die Möglichkeit, Code sehr häufig zu überprüfen und zu verbessern, wenn Sie eine gemeinsame Codebasis haben, die Sie in vielen Projekten verwenden . Ein weiterer Punkt ist, dass einige Jahre dauern können , wenn Sie an großen Projekten arbeiten. Daher müssen Sie den alten Code erneut aufrufen.

Einige der Entwickler, denen ich begegnet war, argumentierten, dass sie sich bereits in der Entwicklungsphase befanden, in der ihre Codierung nicht verbessert werden muss oder nicht mehr verbessert werden kann.

Wenn eine Person sagt, dass sie so perfekt ist, dass sie nichts lernen muss, bedeutet dies, dass sie nicht einmal verstehen kann, wie dumm sie ist.

Selbst wenn Sie zwanzig Jahre Erfahrung im Bereich Computer / Programmierung haben, ändern sich die Dinge zu schnell, sodass es immer neue Dinge zu lernen und neue Techniken zur Verbesserung des Codes gibt. Zum Beispiel kann ein C # -Code, der geschrieben wurde, als es kein .NET Framework 3.0 gab, sehr wahrscheinlich mit den neuen Dingen, die wir heute haben (einschließlich Linq, Code-Verträgen usw.), lesbarer und besser gemacht werden, und dies auch dann, wenn der alte Code wurde vom klügsten Entwickler geschrieben.

Es passiert ziemlich regelmäßig, wenn ich mir Code anschaue und mich frage: "Was habe ich gedacht, als ich das geschrieben habe?"

Normalerweise gibt es ständig Verbesserungen, da mir manchmal eine neue Idee zum Organisieren des Codes, zum Stylen des Codes oder zu etwas anderem einfällt. Auch wenn dies keine große Verbesserung darstellt, kann jede Kleinigkeit helfen, die es wert ist, getan zu werden.

Abhängig von der Arbeitsumgebung wird möglicherweise Code von vor einigen Jahren angezeigt, da ich weiterhin in derselben Codebasis arbeite und mit den darin enthaltenen Informationen vertraut bin.

Alter Code plagt mich fast immer, da ich normalerweise entweder ein vorhandenes System ändere oder das System ersetze. In beiden Fällen muss ich die Macken des vorhandenen Systems kennen, um sicherzustellen, dass sie im neuen vorhanden sind.

Ich bin mir zwar sicher, dass es solche wie Jon Skeet gibt, die sich nur perfekten Code ausdenken können, aber die meisten anderen Leute, die sagen, dass ihr Code nicht verbessert werden kann, sagen dies aus einem Ego-Punkt, der durchaus unattraktiv sein könnte. Gleichzeitig ist es nicht immer der Fall, jedes Mal eine große Verbesserung zu finden.

1.Wie oft passiert Ihnen das oder passiert es Ihnen nicht?

Wie oft bin ich mit meinem alten Code unzufrieden? Fast immer. Es gibt seltene Ausnahmen, in denen ich Code habe, auf den ich wirklich stolz bin ... aber auch hier sind sie selten. Mir wurde gesagt, dass der Code, den ich vor ein paar Jahren geschrieben habe, gut war ... Ich zuckte zusammen und dachte: "Du arme arme Person, weil du Schlimmeres gesehen hast als den Müll, den ich geschrieben habe."

2.Wie lange bevor Sie eine tatsächliche Verbesserung Ihrer Codierung sehen? Monat Jahr?

Es ist normalerweise in Etappen ... Ich beschäftige mich wirklich mit einem Stil oder einer Methodik (zum Beispiel mit fließenden Schnittstellen ... da dies der letzte Stil war, für den ich einen riesigen nassen hatte) und schlachte alles, was ich schreibe, für ein oder vier Monate . Dann sieht es besser aus.

3. Haben Sie jemals Ihren alten Code erneut besucht?

Nicht so oft wie ich möchte. Der größte Teil meines alten Codes gehört früheren Arbeitgebern. Der persönliche Code wird viel zu oft weiß getüncht.

4.Wie oft plagt Sie Ihr alter Code? oder wie oft müssen Sie sich mit Ihren technischen Schulden befassen.

Da frühere Arbeitgeber den größten Teil meines alten Codes haben und ich den größten Teil meines persönlichen Codes weiß wasche ... nicht sehr oft.