Jedes Jahr weniger saugen? [geschlossen]

10

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

Aditya P.
quelle
3
IMHO Leute, die denken, dass sie perfekt sind und denken, dass sie sich nicht verbessern müssen, haben Recht. Sie können sich nicht verbessern. Jeder vernünftige Mensch weiß, dass er niemals perfekt sein kann. Es gibt immer Raum für Verbesserungen / das Erlernen neuer Dinge. Ich wäre entsetzt, wenn ich herausfinden würde, dass ich mich nicht verbessern kann - ich möchte nicht glauben, dass ich eine Decke habe.
MAK
Ich liebe es, zu Projekten zurückzukehren, die ich gemacht habe, als ich noch sehr neu war, und mir Code anzusehen, der für mich so schwer zu schreiben war. Oft ist der Code sooo einfach. Es bringt mich zum Lachen.
Der Muffin-Mann

Antworten:

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

k3b
quelle
19

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.

Bobby Tische
quelle
2
Ich stimme zu 100% zu%. Sie sind stille Attentäter! Oh und super Benutzername, xkcd? :)
Jamiebarrow
@ Jamiebarrow: Natürlich. :)
Bobby Tables
Ein weiterer Fehlerfall ist die Person, die sagt: "Alle Software ist schlecht, es sind alles Hacks, Ihre Verbesserungsvorschläge spielen keine Rolle." Art deprimierend, mit diesen Typen zu arbeiten.
Doug T.
13

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

Oh ho
quelle
Mir gefällt, wie Sie "Schreiben Sie [einige] Testcodes" erwähnen. Ich glaube, niemand erreicht jemals Perfektion, wo er als Programmierer niemals einen Fehler machen wird - wir sind alle Menschen und machen von Zeit zu Zeit Fehler. Unit-Tests und Integrationstests können unsere Fehler reduzieren. Und ich stelle fest, dass Sie "einige" Tests sagen, was wichtig ist, weil ich manchmal mitgerissen wurde, Tests zu schreiben, die nicht wirklich nützlich waren.
Jamie Barrow
Tatsächlich denke ich unter "Nicht reparieren, wenn es nicht kaputt ist" würde ich hinzufügen "Wenn es kaputt ist und es kompliziert ist, reproduzieren und beheben Sie den Fehler mit
Testcode
2
Kann ich ein paar hinzufügen? Wenn es sich um eine API handelt, legen Sie nicht mehr interne Details offen als nötig. Wenn Sie sie ausblenden, können Sie sie später ändern. Verwenden Sie immer Konstanten anstelle von magischen Zahlen, da diese einfacher zu dokumentieren und zu ändern sind. Unveränderlichkeit ist äußerst nützlich, insbesondere wenn es sich um Parallelität handelt. Arbeiten Sie an der Codebasis einer anderen Person. Es ist ein unendlich wertvoller Prozess, Ihren eigenen Codierungsstil zu beurteilen, wenn Sie ihn gegenüber einer anderen Person rechtfertigen müssen. Holen Sie sich die Spezifikation eingefroren (wenn möglich), weil es schwieriger ist, ein sich bewegendes Ziel zu treffen.
Evan Plaice
Wenn Sie vor Ort oder in der Nähe von Kunden arbeiten, packen Sie Ihre Karten ohne Berechtigung und mit höherer Leistung ein. Wenn Sie aufgefordert werden, etwas außerhalb der Spezifikation zu ändern, ziehen Sie die (ich habe) Karte ohne Berechtigung, gefolgt von der (Überweisung an) eine Karte mit höherer Leistung (vorzugsweise eine PM außerhalb des Standorts, die die Anforderungen annehmen kann). Im besten Fall können Sie sich auf die Entwicklung konzentrieren. Im schlimmsten Fall wird die Anzahl der Drive-by-Funktionsanforderungen reduziert. (umstritten) Frühzeitig zurückkehren und häufig zurückkehren. Wenn die Rückgabe am Ende eines Codeblocks erfolgen soll, gibt es kein Schlüsselwort dafür. Hoffentlich lutsche ich jedes Jahr weniger.
Evan Plaice
4

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.

Rafa de Castro
quelle
1
In einem Punkt stimme ich Ihnen nicht zu. Ich glaube, auf einen Code können Sie stolz sein. Das Ironische ist, dass Sie ein Projekt sehr gut laufen lassen und stolz darauf sein können, mit vielleicht ein paar kleinen Ärgernissen. Dann, beim nächsten Projekt, sind Ihre WTFs pro Stunde hoch ... für Ihren eigenen Code! : D
Jamiebarrow
1
Vielleicht hängt es von dem Schritt ab, den Sie jetzt sind. Jetzt finde ich Code, den ich vor einem Jahr geschrieben habe, und selbst ich finde es schwierig, einige Namen oder den Zweck einiger Methoden zu verstehen. Außerdem finde ich Code, der durch Tests und ähnliches aufgedeckt wurde. Während ich mich weiter verbessere, sind solche Dinge eher Ausnahmen als Norm und ich
Rafa de Castro
+1 für sauberen Code, obwohl der Vergleich immer mit dir selbst ist.
Aditya P
4

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.

Chris Browne
quelle
3

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.

Jerry Sarg
quelle
3
  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.

Dunkle Nacht
quelle
3

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.

Arseni Mourzenko
quelle
Wenn Sie dies fragen, besteht die Gefahr, dass Sie wie jemand aussehen, der nicht weiß, wie man guten Code schreibt.
Aditya P
@AdityaGameProgrammer: Es gibt einen Unterschied zwischen fehlerhaftem, hässlichem Code und gutem Code, der nach einem Jahr oder weniger eleganter geschrieben werden kann. (1.) Niemand kann perfekten Code schreiben, der für immer perfekt bleibt, daher müssen wir zugeben, dass unser Code im Laufe der Zeit verbessert werden kann. (2.) Wir sammeln im Laufe der Zeit Erfahrung und Wissen, was auch eine Quelle für die Verbesserung des alten Codes ist.
Arseni Mourzenko
1

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.

JB King
quelle
1

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.

Steven Evers
quelle
weiße Wäsche = Re-Faktor? Beziehen Sie sich auf einen Projektcode oder Ihre persönliche Codebasis?
Aditya P
1
@AdityaGameProgrammer: White Wash = Wirf alles raus und schreibe es von Anfang an neu. Ich spreche über meinen persönlichen Code.
Steven Evers