Wie trainiere ich mich, damit ich keinen „cleveren“ Code schreibe? [geschlossen]

75

Haben Sie das Gefühl kennen , wenn Sie gerade brauchen weg zu zeigen, dass neue Trick mit Expressions oder drei verschiedene Verfahren verallgemeinern? Dies muss nicht unbedingt im Maßstab eines Architekturastronauten sein und kann in der Tat hilfreich sein, aber ich kann nicht anders, als zu bemerken, dass jemand anderes dieselbe Klasse oder dasselbe Paket klarer, einfacher (und manchmal langweiliger) implementieren würde.

Mir ist aufgefallen, dass ich oft Programme entwerfe, indem ich das Problem übersteuere , manchmal absichtlich und manchmal aus Langeweile. In beiden Fällen glaube ich normalerweise ehrlich, dass meine Lösung kristallklar und elegant ist, bis ich Beweise für das Gegenteil sehe, aber es normalerweise zu spät ist. Es gibt auch einen Teil von mir, der undokumentierte Annahmen der Codeduplizierung und Klugheit der Einfachheit vorzieht .

Was kann ich tun, um dem Drang zu widerstehen, „cleveren“ Code zu schreiben, und wann sollte die Glocke läuten, die ich falsch mache ?

Das Problem wird immer dringlicher, da ich jetzt mit einem Team erfahrener Entwickler zusammenarbeite. Manchmal scheinen meine Versuche, intelligenten Code zu schreiben, selbst für mich nach einiger Zeit töricht, die Illusion von Eleganz zu zerstreuen.

Dan
quelle
5
etwas vom Thema ab, aber thedailywtf.com/Articles/…
@ Joe: das ist sehr thematisch, danke! Ich habe den Artikel gelesen, aber es ist mir eine Freude, ihn jetzt wieder zu entdecken.
Dan
33
Debuggen Sie viel cleveren Code ... das sollte reichen.
Dan Olson
@ Joe die Datenbank der Datenbanken Link in diesem Artikel ist ein Traum.
Newman
Kurze Antwort: Der kürzeste und einfachste Code gewinnt. Vermeiden Sie Duplikate, aber fügen Sie keine Ebenen "nur weil" hinzu. Fowler's Refactoring kann Ihnen einen Einblick geben.
Kevin Cline

Antworten:

54

Das Problem wird immer dringlicher, da ich jetzt mit einem Team erfahrener Entwickler zusammenarbeite. Manchmal scheinen meine Versuche, intelligenten Code zu schreiben, selbst für mich nach einiger Zeit töricht, die Illusion von Eleganz zu zerstreuen.

Ihre Lösung liegt hier. Ich gehe davon aus, dass "erfahren" in diesem Zusammenhang "erfahrener als Sie" bedeutet. Zumindest respektieren Sie sie eindeutig. Dies ist eine wertvolle Gelegenheit zum Lernen - vorausgesetzt, Ihr Ego kann den Treffer erzielen. (Ärgerliche Dinge, Egos. Schade, dass wir sie so brauchen.)

Haben Sie Code-Reviews mit diesen Leuten? Wenn ja, wenn sie es nicht bereits tun, bitten Sie sie ausdrücklich, Sie wegen Ihres Schwachsinns anzurufen. Erwähnen Sie, dass Sie eine Tendenz zu Überdesign bemerkt haben, einen sorgfältig entworfenen pneumatischen Presslufthammer der Spitzenklasse (vorzugsweise mit einer Art automatisiertem Straßenarbeiter-Android) zu verwenden, wenn ein einfacher Klauenhammer mehr als ausreichend wäre .

Möglicherweise winden Sie sich auf Ihrem Sitz, während Ihr Gesicht während der Codeüberprüfungen rot wird. Ertrage es. Du lernst.

Wenn Sie ein paar davon haben, achten Sie auf die Momente, in denen Sie den Verdacht haben, dass Sie möglicherweise zu viel designen. Wenn diese Momente kommen, fragen Sie sich: "Wenn mich jemand während der Codeüberprüfung dazu aufruft, kann ich meine Lösung als die beste auf dem Markt verteidigen? Oder gibt es eine einfachere Lösung, die ich aufgeben möchte?"

Manchmal ist Peer Review der beste Weg, um einen guten Einblick in Ihre eigene Arbeit zu bekommen.

BlairHippo
quelle
Danke für eine wirklich gute Antwort. Nein, wir haben keine Codeüberprüfungen, hauptsächlich, weil das Projekt groß ist und die Ressourcen des Kunden sehr begrenzt sind. Aber ich denke, ich kann mich testen, indem ich am Ende eines jeden Tages frage, ob ich meine Lösung als die beste verteidigen kann, die es gibt.
Dan
7
Keine Code-Reviews? Urk. Ich würde etwas ganz Selbstgerechtes und Entsetztes schreiben, aber ich habe auch in dieser Umgebung gearbeitet. Sie sind zeitaufwändig und quälen jeden, aber sie sind sowohl für das vorliegende Projekt als auch für Ihre persönliche Entwicklung von großem Wert. Wenn das Thema "Sollten wir vielleicht Codeüberprüfungen durchführen?" Kommt immer rauf, vergewissere dich, dass du unten bist als "Hölle ja!" Und wenn sie nicht mit ihren eigenen Fristen konfrontiert werden, können Sie Kollegen, die Sie respektieren, bitten, Arbeit zu geben, bei der Sie sich nicht sicher sind, ob es sich um eine informelle Code-Review-Lite handelt.
BlairHippo
1
Nun, das Projekt ist eine Art Startup und aufgrund einiger Planungsfehler treffen wir auch auf der Kundenseite die Situation, wenn wir wirklich schnell liefern müssen oder es den Aufwand nicht wert ist. Ich habe gerade mit unserem Premierminister gesprochen und er hat bestätigt, dass die aggressive Frist der einzige Grund ist, warum wir zumindest jetzt keine Code-Überprüfungen durchführen. Wenn der Start erfolgreich verläuft und sich die Zeit entspannt, werden wir möglicherweise in Zukunft die Überprüfungen durchführen.
Dan
2
Oh mein. Klingt aufregend - mit all den guten und schlechten Konnotationen, die dieses Wort mit sich bringt. :-) Viel Glück, Junge; Wir hoffen, dass Sie am Anfang von etwas Großartigem stehen.
BlairHippo
8
@BlairHippo: Ich bin nur Ihrem Rat gefolgt, habe mich beruhigt und den Kollegen, der auf das durch meine Änderungen verursachte Problem hingewiesen hat, freundlich gebeten, informelle Überprüfungen mit mir durchzuführen, und er hat zugestimmt. Dies hat auch dazu beigetragen, gewisse Unannehmlichkeiten aus unserer Konversation zu entfernen (wie in "Sie schreiben komplexen Code und ich muss ihn reparieren .."). Vielen Dank!
Dan
20

Denken Sie am besten an die Maxime von Brian Kernighan:

„Das Debuggen ist doppelt so schwierig wie das Schreiben des Codes. Wenn Sie den Code so geschickt wie möglich schreiben, sind Sie per Definition nicht klug genug, um ihn zu debuggen. “

Daniel Roseman
quelle
1
Ich stimme dem Zitat von ganzem Herzen zu, aber die Frage ist, wie man die Versuchung überwindet , der schlaue Junge zu sein . Man kann dir sagen, dass du kein Eis essen sollst, wenn du krank bist, aber manchmal hilft es nicht.
Dan
13
+1 für eine Maxime, die jeder Code-Affe auswendig kann, -1 für die Tatsache, dass er dem OP keinen Einblick in die Anwendung auf seine eigene Arbeit gewährt. Es gleicht sich also alles so aus, dass kein Pfeil klickt.
BlairHippo
2
Tolles Zitat, aber keine wirkliche Antwort auf die Frage des OP.
Jim G.
5
Hallo Daniel, wir suchen viel mehr als nur ein Zitat: Die Website ist nur dann nützlich, wenn Fragen mit langen, nachdenklichen Antworten gepaart werden, die voller Erfahrungen, Fakten und Referenzen sind. Gibt es aus eigener Erfahrung noch etwas, das Sie hinzufügen können?
2
-1: Beantwortet die Frage des OP nicht im geringsten.
Thomas Eding
15

Normalerweise gibt es mindestens drei Lösungen für Softwareprobleme von Bedeutung: den offensichtlichen Weg, einen nicht offensichtlichen komplexen Weg (clever) und einen nicht offensichtlichen einfachen Weg (elegant). Hier gilt ein Zitat über Autoren:

Schreib alles auf, was dir in den Sinn kommt, und dann bist du ein Schriftsteller. Aber ein Autor ist einer, der den Wert seines eigenen Materials ohne Mitleid beurteilen und das meiste davon zerstören kann. - Colette

Sie werden keinen eleganten Code schreiben können, bis Sie den Wert Ihres eigenen Codes ohne Mitleid beurteilen und das meiste davon zerstören können. Wenn Sie den eleganten Code nach dem Endergebnis beurteilen, sieht es täuschend einfach aus, aber es muss langsamer werden, viele Entwürfe durchlaufen, den Rat anderer einholen und herausfinden, was nicht richtig auf der Seite steht. Das heißt, selbst wenn Ihr Code einwandfrei funktioniert, fragen Sie sich oder einen Kollegen, warum sich etwas nicht richtig anfühlt, bis Sie mit der Antwort zufrieden sind. Vielleicht fühlt es sich zu lang an oder wiederholt sich, oder Sie haben das Gefühl, der Compiler hätte eine bestimmte Art von Fehler abfangen sollen. Die meisten Programmierer mit einem Minimum an Erfahrung kann erkennen unelegant Code leicht. Der Trick besteht darin, herauszufinden, warum .

Das ist die methodische Methode, um eleganteren Code zu schreiben. Außerdem ist häufig ein kurzer Einblick erforderlich, der Ihnen hilft, ein Problem auf eine neue Art und Weise zu betrachten. Dies ist schwieriger zu erreichen, aber es hilft, langsamer zu werden und sich nur Gedanken über ein Problem zu machen, bevor Sie sich mit dem Codieren befassen. Wenn Sie eine gute Lösung finden, suchen Sie nach einer besseren. Das Lesen anderer Codes hilft. Es hilft, Unterricht zu nehmen oder Bücher über bewährte Methoden zu lesen. Das Erlernen anderer Programmierparadigmen hilft. Fragen Sie Kollegen, deren Code Sie bewundern, um Rat.

Karl Bielefeldt
quelle
3
Das erinnert mich an das Zitat eines alten Mathematikers: "Für jedes Problem gibt es eine einfache, elegante und falsche Lösung."
Joris Timmermans
9

Ich würde vorhandene Antworten ergänzen, auf TDD-Weise entwickeln, sodass Sie zuerst Tests darüber schreiben, was Ihr Code tun sollte, und dann implementieren, damit Ihre Tests grün werden. Auf diese Weise erfüllen Sie nur die Anforderungen, die die Tests stellen. Da Sie den Test schreiben, ist dies ein guter Weg, um sich selbst diszipliniert weiterzuentwickeln.

Matteo Mosca
quelle
Ich versuche definitiv, mir das aufzuzwingen, wann immer Zeit ist.
Newman
Das anschließende Schreiben von Tests ist auch ein guter Weg, um große Fehler in Ihrem Code zu erkennen. Es ist irgendwie selbstkritisch. Aber TDD ist eindeutig der beste Ansatz, wenn Sie neu anfangen.
Vanna
6

Wenn Sie für ein großes und dynamisches Team arbeiten, das sich über viele verschiedene Fähigkeiten und Jahre erstreckt, muss die Entwicklung naturgemäß auf die unterste Ebene des konservativsten oder intellektuell mangelhaftesten Mitglieds des Teams, aktuell oder historisch, heruntergestuft werden.

Dies muss nicht unbedingt eine schlechte Sache sein, da clevere Codes möglicherweise schwieriger zu debuggen sind, schwieriger in einer technischen Spezifikation zu vermitteln sind und das Schreiben länger dauert, was die Entwicklungszeit verlangsamt.

Es gibt Zeiten, in denen cleverer Code wichtig ist, z. B. wenn cleverer Code später im Reifezyklus der Software zu Effizienz- und Leistungssteigerungen führt, wenn Leistung zur Anforderung wird.

Cleverer Code bietet auch die Möglichkeit, einem Team, das möglicherweise keinen neuen Sprachfunktionen oder Bibliotheksaufrufen ausgesetzt ist, einen schneller zu entwickelnden, besser lesbaren und verständlicheren Code bereitzustellen. Als ich zum Beispiel von einem Junior-Entwickler zum ersten Mal in Linq eingeführt wurde, war ich sofort angewidert, es sei unnötig, schwer zu debuggen, dumm und "clever". Nachdem ich selbst damit gespielt und herausgefunden hatte, wie nützlich und leistungsfähig Linq-Abfragen sein können, investierte ich die Zeit, um es zu lernen, und mein DAL-Code war nie sauberer und lesbarer sowie einfacher zu debuggen und zu erweitern.

Ich bedaure, dass ich vorher nicht aufgeschlossen war, und wünschte, ich wäre nicht so hart gegen einen so "klugen" Nachwuchsentwickler gewesen.

Mein Punkt ist, dass "kluger" Code verdächtig sein SOLLTE, aber wir sollten nicht gegen ihn vorgehen, da dies Kreativität und Innovation behindern könnte.

EDIT: Mir ist gerade aufgefallen, dass ich Ihre Frage nicht vollständig beantwortet habe. Wenn Sie in Ihrem Projekt die Fähigkeit haben, sehr einfach cleveren Code zu schreiben, sollte das Team möglicherweise strengere Codierungsstandards anwenden, um eine einheitliche und eindeutige Vorlage und einen eindeutigen Stil zu verfolgen. Auf diese Weise können Sie die Linien Ihres Sandkastens herausziehen, damit Sie nicht auf die Straße gehen, um nach einem Ball zu jagen.

maple_shaft
quelle
6

Wenn 20% (Ihre% können variieren) oder mehr Ihrer hinzugefügten Zeilen dokumentiert werden müssen, ist es Zeit, einen Schritt zurückzutreten und umzudenken .

Ich denke wirklich, Sie sollten danach streben, klug zu sein. Es ist eine natürliche Nebenwirkung, wenn Sie kompetenter werden. Wenn Sie sich einen allgemeinen Leitfaden geben, wie z. B.% der Kommentare, die Sie benötigen, um sich selbst klar zu machen, können Sie sich dazu zwingen, zurückzubleiben und zu bewerten, ob die Verwendung des Gelernten eine kluge Wahl oder nur ein Weg ist, um Ihr neues Spielzeug vorzuführen.

DKnight
quelle
3
Ich neige dazu, Dokumentation / Kommentare als einen Fehler zu betrachten. Wenn Sie etwas dokumentieren / kommentieren müssen, bedeutet dies zunächst, dass Ihr Code nicht klar ist. Leider ist dies ein unrealistisches Ziel und wir brauchen irgendwann eine Dokumentation. Denken Sie daran, dass dieser Teil des Codes auf ein Minimum reduziert werden sollte.
Deadalnix
@deadalnix: Kein schlechter Punkt. Ich vermute, mein% wäre höher als die meisten, da ich normalerweise in einer ansonsten toten und stark von Makros betroffenen Assemblersprache codiere. Schwieriger zu lesen und jeder neue Mitarbeiter muss die Sprache lernen, daher sind weitere Kommentare erforderlich.
DKnight
2
@deadalnix - Dokumentation, um zu erklären, wie ein Zeichen Ihr Code unklar ist. Dokumentation, um das Warum zu erklären, wird dringend benötigt. Ich habe allzu viele Code-Teile gesehen, die ich verstehen konnte, was sie taten, aber nicht, warum sie beschlossen, es auf eine nicht intuitive Weise zu tun. Das macht es sehr schwer zu pflegen.
HLGEM
@HLGEM Das ist fraglich. Die Unklarheit des Codes kann von schlecht gestalteten Bibliotheken / APIs herrühren, von der Unklarheit innerhalb der Konzeption selbst wie einer schlechten Trennung von Bedenken. Wir leben in der realen Welt und unsere Kapazitäten sind begrenzt. Daher benötigen wir definitiv Unterlagen, aber jedes Mal, wenn wir sie benötigen, bedeutet dies, dass jemand unperfekten Code geschrieben hat. Keine Dokumentation ist etwas, das Sie nicht tun sollten - denken Sie nicht einmal darüber nach, sondern etwas, über das Sie die ganze Zeit nachdenken müssen, um sich in die richtige Richtung zu verbessern.
Deadalnix
@deadalnix - Perfekter Code ist in der realen Welt niemals eine praktische Lösung.
JeffO
4

Ich kann nicht widerstehen, etwas Kluges auszuprobieren.

Also mache ich es auf einem Spielzeugprojekt, in meiner Freizeit, zu Hause.

Wenn die Neuheit nachlässt - Problem gelöst.

Mike Dunlavey
quelle
3

Ich glaube, eine Möglichkeit, herauszufinden, ob Ihr Code zu "clever" ist, besteht darin, einen Schritt zurückzutreten und sich folgende Fragen zu stellen:

Wenn ich jemandem, der noch nie an diesem Projekt / Code gearbeitet hat, einen Ausdruck dieses Codes geben würde, wäre er dann in der Lage, ihn zu lesen und mir zu beschreiben, was die Funktion bewirkt (nachdem er ihnen einen kurzen Kontext gegeben hat)? Wenn nicht, wie viel würde ich erklären müssen? Wie würde ich das jemandem erklären, der CS101 einnimmt?

Wenn sich herausstellt, dass Sie jemanden durch jede Zeile oder die meisten Zeilen in einer Methode oder Klasse führen müssten, ist dies wahrscheinlich zu clever. Wenn Sie jemandem, der sich damit nicht auskennt, Sprachkonstrukte erklären müssen (z. B. LINQ), ist das wahrscheinlich in Ordnung. Wenn Sie sich eine Zeile ansehen und ein wenig darüber nachdenken müssen, bevor Sie sie erklären können, muss Ihr Code überarbeitet werden.

Becuzz
quelle
Ich habe gehört, dass dies "Gummiente" genannt wird, wenn es zur Problemlösung angewendet wird. Wenn Sie ratlos sind, versuchen Sie, das Problem jemandem zu erklären, der nichts davon weiß (wie z. B. Ihr Gummiente), und prüfen Sie, ob die Lösung nicht in Ihren Schoß fällt. Ich muss denken, dass es auch dafür funktionieren würde.
BlairHippo
2

1) Lass dich vorher davon verbrennen, damit du weißt, dass es eine schlechte Sache ist. Es macht großen Spaß, etwas zu debuggen, das vor langer Zeit geschickt geschrieben wurde. Ich denke, Sie haben das abgedeckt.
2) Kommentieren Sie Ihren Code und erklären Sie, was Sie vor jedem Codeabschnitt tun.
3) Wenn Sie Schwierigkeiten haben, es zu erklären, oder wenn Sie das Gefühl haben, ein Diagramm einfügen zu müssen, dann ist das, was Sie gerade getan haben, zu clever und könnte wahrscheinlich sauberer gemacht werden.

Clevere Problemlösungen können fantastisch sein, bis Sie sie debuggen oder erweitern müssen. Manchmal ist es die einzige Lösung. Wenn Sie genau beschreiben können, was zur Hölle es tut und wie es tut, können clevere Lösungen akzeptabel sein.

Normalerweise beschreibe ich mit Kommentaren, was ich mit einem Codeabschnitt mache. Wenn es am wenigsten verwirrend erscheint, beschreibe ich auch, wie ich es mache. Im Idealfall sollte der Code einfach und selbsterklärend sein. Wenn ich jedoch nicht erklären kann, wie ich das getan habe, was ich gerade getan habe, ist dies ein klares Zeichen dafür, dass ich zurücktreten und es erneut versuchen muss.

Philip
quelle
2
Der Kommentar-Trick funktioniert auch bei mir. Unter anderem füge ich immer einen Kommentarblock über alle nicht trivialen Unterprogramme als eine Art abschließende Überprüfung der geistigen Gesundheit ein. Wenn ich viel erklären muss (oder mich gelegentlich dafür entschuldigen muss), verschlungene oder stumpfe Codeabschnitte oder seltsame Eingabeparams oder was auch immer, dann ist das ein Warnsignal, das ich möglicherweise ein wenig überdenken muss.
BlairHippo
@BlairHippo HA! "final sanity check" gefällt mir.
Philip
2

Ein guter Weg, um mit dem Schreiben von einfachem Code zu beginnen, ist wahrscheinlich, Cleverness Passion für ein Projekt zu veröffentlichen, das nach Cleverness fragt . Der Rest der Antwort ist spezifisch für .NET, aber ich bin sicher, man kann ähnliche Projekte in jeder anderen Sprache finden.

Es gibt Open-Source-Frameworks für die Abhängigkeitsinjektion , die nur nach ExpressionTricks fragen . Es gibt F # und eine wunderbare Reihe von Aufgaben, für die man es vielleicht ausprobieren möchte.

Wenn Sie sich für Mathematik interessieren (und das ist sprachunabhängig ), gibt es Project Euler für Sie.

Last but not least gibt es in der .NET-Welt Mono Project mit vielen Bereichen, die der Aufmerksamkeit von Entwicklern bedürfen , von denen einige ziemlich kompliziert sind. Wie wäre es, einen Beitrag zu einem Open-Source-Tool für die statische .NET-Codeanalyse zu leisten ? Es gibt einige IL-Analysen sowie hochrangige Dinge. Jb Evain arbeitet immer an etwas Interessantem, egal ob es sich um eine Cecil-Reflection-Bibliothek, eine ExpressionUnterstützung oder einen .NET-Dekompiler handelt.

Wenn nichts passt, starte einfach dein eigenes Spott-Framework :-)

Dan
quelle
2

Kennen Sie dieses Gefühl, wenn Sie nur diesen neuen Trick mit Ausdrücken vorführen oder drei verschiedene Verfahren verallgemeinern müssen?

Nein

Dies ist einer der Gründe, warum ich immer sage, dass es eine gute Sache ist, wenn neue Entwickler in ein großes Durcheinander von undokumentiertem Speghetti-Code gestürzt werden, um ihn zu warten und zu überarbeiten. Es wird ihnen die Realität lehren, übermäßig 'cleveren' Code beizubehalten, den sie nicht geschrieben haben, und hoffentlich ein bisschen Empathie für den armen Trottel wecken, der in 5 Jahren seinen Code debuggen muss.

GroßmeisterB
quelle
Ich denke, dies wird sie eher frustrieren und denke, dass IHR Code viel besser und eleganter sein wird als die Noobs, die DIESES Chaos geschrieben haben. Niemand schreibt Code mit der Absicht, die Wartung zu erschweren.
Sara
2

Ich denke, das Thema ist gut gewählt. Es ist "cool", eine Perl-Zeile zu schreiben, die auf einmal zehntausende Dinge erledigt, aber dann ist es scheiße, wenn Sie sie noch einmal durchgehen müssen.

Auf einer anderen Anmerkung, klug oder nicht, muss Code dokumentiert werden. Zwischen den in der Industrie akzeptierten Programmiersprachen und den hochrangigen Konzepten, an die wir Menschen in unserem Denken gewöhnt sind, besteht eine inhärente Impedanzinkongruenz. Selbstdokumentierender Code ist einfach nicht realisierbar - bis er zur natürlichen Sprache wird. Sogar Prolog-Code muss dokumentiert werden, so formell er auch sein mag.

Feinkörniger Imperativcode dient dazu, grobkörnige Pläne zu implementieren - das muss dokumentiert werden. Ich möchte nicht alle 50 Zeilen der Methode durchlesen müssen, wenn ein kurzer dreizeiliger Roadmap-Kommentar ausreicht.

Später bearbeiten: Ein beredteres Beispiel ist eines, das Computer übersteigt. Ein Buch mag sehr gut geschrieben sein, aber wir möchten es oft auf verschiedenen Abstraktionsebenen verarbeiten. Oft reicht eine Zusammenfassung des Buches, und genau das können Kommentare für den Code bieten. Natürlich kann gut abstrahierter Code viel zur Selbstdokumentation beitragen, aber nicht alle Abstraktionsebenen bieten.

Kommentare können sich auch wie Randnotizen in einem Buch verhalten, wenn wir den Argumentationsprozess hinter einer Behauptung im Haupttext erläutern müssen, ohne sie zu entgleisen.

In diesem Zusammenhang stelle ich fest, dass meine vorherige Aussage zur natürlichen Sprache, die über die Notwendigkeit von Kommentaren hinausgeht, falsch ist. Sogar die natürliche Sprache, wie in einem Buch, eignet sich möglicherweise zur Dokumentation, um die im Text enthaltene Abstraktion auf spärliche Weise zu erklären oder Umwege zu bieten, ohne den Haupttext zu entgleisen. Mit der Bemerkung, dass gut abstrahierter Code möglicherweise bereits einen langen Weg zur Selbstdokumentation zurückgelegt hat.

Last but not least können Kommentare dazu beitragen, dass der Codierer einen hohen Abstraktionsgrad beibehält. Oft stelle ich fest, dass zwei aufeinanderfolgende Kommentare, die ich in eine Liste von Schritten aufgenommen habe, nicht auf derselben Abstraktionsebene sprechen, was eine sofortige kritische Betrachtung meiner Arbeit mit diesem Code rechtfertigt.

Bestimmte Probleme gehen über die Codierung hinaus und wirken sich wie andere Aktivitäten auch auf die Codierung aus. Kommentare können dabei helfen, die Hintergründe und Facetten unseres Codes zu klären, und ich finde, dass sie ein angenehmer Begleiter sind, der eine weichere Sprache spricht, von der die Person bei einer Änderung profitiert.

Mihai Danila
quelle
1

Wie? Zeigen Sie Ihren Code weiterhin den erfahrenen Entwicklern. und wenn Sie verrückt werden, weil Sie sophomorisch und auffällig sind, saugen Sie es auf und fragen Sie sie, wie sie es tun würden und warum (natürlich ohne Konfrontation).

Bearbeiten Sie im Lichte von -1:

Vor vielen Monden befand ich mich in der gleichen Situation - ich hatte einen Chef, der jedes Mal zusammenzuckte, wenn ich einen Zeiger in Delphi oder dem 'with construct' benutzte, und einen anderen, der mir drohte, mich zu feuern, wenn ich nicht aufhörte, alle meine Booleaner kurzzuschließen mit 0-1 und überall mit Einzelbuchstabenvariablen.

Ich habe es gelernt, weil ich gefragt habe, warum und sie sich die Mühe gemacht haben, es zu erklären, weil sie dachten, ich könnte auf etwas hinauslaufen - LOL ...

Mikey
quelle
1
Hallo Mikey, wir suchen viel mehr als einen Einzeiler: Die Website ist nur dann nützlich, wenn Fragen mit langen, nachdenklichen Antworten gepaart werden, die mit Erfahrungen, Fakten und Referenzen gefüllt sind. Gibt es aus eigener Erfahrung noch etwas, das Sie hinzufügen können?
1

Habe ich das Bedürfnis anzugeben? Nein nicht mehr. Wie bin ich daran vorbei gekommen? Wie die meisten Leute kommen sie an keiner anderen schlechten Angewohnheit vorbei ... bewusste und bewusste Ausübung der richtigen Techniken. Wenn Sie es genug tun, werden Sie den Wert von Best Practices verstehen und durch deren ständigen Einsatz gute Gewohnheiten entwickeln.

Wenn Sie sich auf funktionierende Software konzentrieren, die pünktlich und einfach zu warten ist, werden Sie auch die Anerkennung erhalten, die Sie suchen. Erfahrene Entwickler werden zu Ihnen kommen und sagen: "Mann, das Modul, das Sie geschrieben haben, war gut gestaltet. Ich musste nur eine Komponente implementieren, um es in mein Projekt zu integrieren." im Gegensatz zu "Ich musste das gesamte Modul überarbeiten, das Sie geschrieben haben, um es in einer anderen Komponente zu verwenden. Haben Sie sogar von Bob Martin oder Ward Cunningham gehört?"

TLDR: Du bist nicht allein. Das Erkennen von Fähigkeiten wird am besten als Nebenprodukt der intelligenten Lösung von Problemen erreicht.

Heath Lilley
quelle
0

Für mich ist zu cleverer Code oft bestrebt, imaginäre zukünftige Anforderungen zu lösen, anstatt sich auf die heutigen Anforderungen zu konzentrieren. Große Falle!

0% überkomplizierter Code ist kein erreichbares Ziel. Vielleicht nicht einmal das beste Ziel, nach dem man streben kann. Überkomplizierter Code ist schlecht, aber Sie müssen neue Dinge ausprobieren, um als Programmierer zu wachsen. Sie sollten sie nicht mit Seriencode ausprobieren, wenn Sie dies vermeiden können. Im Gegensatz zu Maschinen machen Menschen Fehler.

Hilfe zur Codeüberprüfung. Es hilft, Jahre damit zu verbringen, den "cleveren" Code anderer Leute zu reparieren. Sich auf das zu konzentrieren, was der Kunde heute wirklich braucht, hilft.

Schulen und Unternehmen beschäftigen Besatzungen von Reinigungs- und Instandhaltungspersonal. Code muss auch bereinigt und gewartet werden! Räumen Sie, wenn möglich, die Unordnung auf (besonders Ihre eigene)! Ich denke, das ist das Beste, was man tun kann.

GlenPeterson
quelle
-2

Zusätzlich zu den guten Ratschlägen, die bisher gegeben wurden (Codeüberprüfung, Debugging, TDD-Ansatz), sollten Sie von Zeit zu Zeit die (besten Bücher imho) zu guten Codierungspraktiken (neu) lesen:

  • Pragmatischer Programmierer
  • Code abgeschlossen
  • Code bereinigen

und andere, je nach verwendeter Technologie.

m3th0dman
quelle
-2

Denken Sie daran, YAGNI - Sie werden es nicht brauchen .

Programmierer sollten erst dann Funktionalität hinzufügen, wenn dies als notwendig erachtet wird ...

YAGNI ist ein Prinzip hinter der XP-Praxis, "das Einfachste zu tun, was möglicherweise funktionieren könnte" (DTSTTCPW). Es soll in Kombination mit mehreren anderen Methoden verwendet werden, wie z. B. kontinuierliches Refactoring, kontinuierliches automatisiertes Testen von Einheiten und kontinuierliche Integration. Ohne kontinuierliches Refactoring könnte es zu unordentlichem Code und massiven Nacharbeiten führen ...

Nach Ansicht der Befürworter des YAGNI-Ansatzes hat die Versuchung, Code zu schreiben, der derzeit nicht notwendig ist, aber möglicherweise in der Zukunft liegt, die folgenden Nachteile:

  • Die aufgewendete Zeit wird für das Hinzufügen, Testen oder Verbessern der erforderlichen Funktionalität benötigt.
  • Die neuen Funktionen müssen getestet, dokumentiert und unterstützt werden.
  • Jede neue Funktion unterliegt Einschränkungen für zukünftige Aktionen. Daher kann eine unnötige Funktion das Hinzufügen erforderlicher Funktionen in der Zukunft verhindern.
  • Bis die Funktion tatsächlich benötigt wird, ist es schwierig, ihre Funktion vollständig zu definieren und zu testen. Wenn die neue Funktion nicht ordnungsgemäß definiert und getestet wurde, funktioniert sie möglicherweise nicht ordnungsgemäß, auch wenn sie eventuell benötigt wird.
  • Es führt zu Code Bloat; Die Software wird größer und komplizierter.
  • Wenn es keine Spezifikationen und Revisionskontrollen gibt, ist die Funktion Programmierern möglicherweise nicht bekannt, die davon Gebrauch machen könnten.
  • Das Hinzufügen der neuen Funktion kann andere neue Funktionen vorschlagen. Wenn diese neuen Funktionen ebenfalls implementiert werden, kann dies zu einem Schneeballeffekt in Richtung Feature Creep führen.
Mücke
quelle
3
Dies mag zwar zutreffen, aber mehr Details würden dies zu einer viel besseren Antwort machen.
ChrisF