Gute Strategien zur Entwicklung von Wegwerfcode?

Ich stimme nicht mit allen Antworten überein, die "Kommentare schreiben" sagen. Das wird als Catch-All angeboten, da der Code selbst nicht verständlich ist.

Holen Sie sich eine Kopie von Code abgeschlossen (Steve McConnell, 2. Ausgabe) . Wenn Sie die Techniken lernen, wartbaren Code zu schreiben, brauchen Sie nicht mehr Zeit und Sie werden später mit weniger Schwierigkeiten zu Ihrer Arbeit zurückkehren können.

Was würden Sie bevorzugen:

• Kryptischer Code mit Kommentaren?
• Meistens OK Code ohne?

Ich bevorzuge Letzteres, da der OK-Code in Situationen, in denen der kryptische Code unkommentiert war, einfacher zu verstehen ist und Kommentare ein anderer Ort sind, an dem der ursprüngliche Entwickler Fehler machen kann. Der Code kann buggy sein, ist aber niemals falsch .

Wenn Sie mit Code Complete zufrieden sind, empfehle ich The Pragmatic Programmierer , da es einen leicht höheren Software-Entwicklungsrat gibt.

[Eigene Frage beantworten] Es gibt mehrere andere Aspekte des Problems, die nicht angesprochen wurden und die ich bei einer erneuten Überprüfung als nützlich empfunden hätte. Einige davon können "selbstverständlich" sein, aber denken Sie daran, dass dieser Code vor SVN und IDEs war.

• Auffindbarkeit Es war schwierig, den Code tatsächlich zu finden. Ich glaube, es ist in meinem SourceForge-Projekt, aber es gibt so viele Versionen und Zweige über 7 Jahre, dass ich es nicht finden kann. Also musste ich ein System haben, das Code durchforstete und bis IDEs erschienen, glaube ich nicht, dass es welche gab.
• Was macht es? . Der aktuelle Checkout enthält ungefähr 13 Klassen (alles in einem Paket, da es zu dieser Zeit nicht leicht zu refactorieren war). Einige sind klar ( DynamicAligner ), andere sind undurchsichtig ( MainBox , benannt, weil sie eine Swing-Box erweitert haben). Es gibt vier main() -Programme und tatsächlich gibt es etwa 3 Unterprojekte in der Distribution. Daher ist es wichtig, ein externes Manifest darüber zu haben, was die Komponenten tatsächlich waren.
• Anweisungen zum Ausführen . Wenn das Programm ausgeführt wird, bietet main() eine kurze Befehlszeilen-Verwendung (z. B. DynamicAligner file1 file2 ), aber es sagt nicht aus, wie der Inhalt von Dateien tatsächlich aussieht. Das wusste ich damals natürlich, aber nicht jetzt. Daher sollten Beispieldateien in gleichgeordneten Verzeichnissen verknüpft sein. Diese sind wertvoller als der Versuch, Dateiformate zu dokumentieren.
• Funktioniert es noch? . Es sollte möglich sein, jedes Beispiel ohne nachzudenken auszuführen. Die erste Frage wird sein, ob die zugehörigen Bibliotheken, Laufzeiten usw. noch relevant und verfügbar sind. Ein ehemaliger Kollege hat ein System geschrieben, das nur mit einer bestimmten Version von Python läuft. Die einzige Antwort ist das Neuschreiben. Also sollten wir auf jeden Fall ein Lock-in vermeiden, wo es möglich ist, und ich habe mich selbst (wenn auch nicht notwendigerweise Kollegen) dafür ausgebildet.

Wie können ich und meine Mitarbeiter in Zukunft Probleme vermeiden? Ich denke, der erste Schritt ist, dass es eine Disziplin geben sollte, ein "Projekt" (egal wie klein) zu erstellen, wenn Sie Code erstellen und dass diese Projekte unter Versionskontrolle stehen sollten. Dies mag für einige von Ihnen offensichtlich sein, aber in einigen Umgebungen (akademisch, inländisch) gibt es einen erheblichen Aufwand für die Einrichtung eines Projektmanagementsystems. Ich vermute, dass der Großteil des akademischen Codes keiner Versionskontrolle unterliegt.

Dann stellt sich die Frage, wie die Projekte organisiert werden sollten. Sie können nicht standardmäßig in Sourceforge sein, da der Code (a) trivial und (b) nicht standardmäßig geöffnet ist. Wir brauchen einen Server, auf dem sowohl kommunale als auch private Projekte stattfinden können. Ich würde berechnen, dass der Aufwand, um dies einzurichten und zu betreiben, etwa 0,1 VZÄ ist - das sind 20 Tage im Jahr von allen Parteien (Installation, Training, Wartung) - wenn es leichtere Optionen gibt, würde ich gerne wissen, da dies ein großer ist Kosten in einigen Fällen - verbringe ich meine Zeit damit, einen Server einzurichten oder schreibe ich Papiere?

Das Projekt sollte versuchen, gute Disziplin zu fördern. Das war wirklich, was ich von dieser Frage erhoffte. Es könnte enthalten:

1. Eine Vorlage der erforderlichen Komponenten (Manifest, README, Protokoll der Commits, Beispiele, erforderliche Bibliotheken usw. Nicht alle Projekte können unter maven laufen - z. B. FORTRAN).
2. Ein Mittel, um eine große Anzahl (hunderte) von kleinen Projekten nach Mnemonic Strings zu durchsuchen (Ich mochte die Idee, den Code in Googledocs zu kippen, und das mag eine fruchtbare Allee sein - aber es ist ein zusätzlicher Wartungsaufwand).
3. Löschen Sie die Namenskonventionen. Diese sind wertvoller als Kommentare. Ich habe jetzt regelmäßig Namen vom Typ iterateOverAllXAndDoY. Ich versuche, createX () anstelle von getX () zu verwenden, wenn die Routine tatsächlich Informationen erzeugt. Ich habe eine schlechte Angewohnheit Routinen process () anstelle von convertAllBToY () aufzurufen.

Ich bin mir dessen bewusst, habe aber GIT und Mercurial und GoogleCode nicht verwendet. Ich weiß nicht, wie viel Aufwand es gibt und wie viele meiner Bedenken sie beantworten. Ich würde mich freuen, wenn es ein IDE-Plugin gäbe, das dabei hilft, besseren Code zu erstellen (z. B. "schlechte Wahl des Methodennamens").

Und was auch immer die Ansätze sind, sie müssen natürlich zu Menschen kommen, die natürlich keine gute Code-Disziplin haben und die Mühe wert sind.

Wie die ausgezeichneten Antworten in Ihrem anderen Beitrag angeben Aus meiner eigenen Erfahrung ergibt sich eine schwer zu überbrückende Kluft zwischen der für die Forschung verwendeten Software und der entwickelten Software. Meiner Meinung nach könnte Code Complete ein wenig helfen, aber nicht viel. Wird es sich als eine ökonomische Frage lohnen, alles für die Wiederverwendung neu zu gestalten, verglichen mit der gelegentlichen Belohnung dafür, eine spätere Verwendung für etwas zu finden? Ihr Gleichgewichtspunkt kann variieren.

Hier ist ein praktischer Tipp zum Speichern von Snippets. Fügen Sie anstelle von vollständigen Kommentaren einige Schlüsselwörter hinzu:

• "Graphisomorphie-Wrapper"
• "polymer simulated annealing"
• "string match feynmann"
• "Gleichgewicht"

und dann den Code irgendwo Google-durchsuchbar, wie ein GMail-Konto.

Bearbeiten: Ich möchte hinzufügen, dass kostenlose Google Sites wirklich durchsuchbare Wikis sind, die einen guten Platz zum Einfügen von Code bieten, entweder in Form von Anhängen oder eingefügt.

Außerdem sollte ich sagen, dass ich ein Fan von Code Complete bin und Kopien an Studenten verteilt habe, die seit mehreren Jahren Software für wissenschaftliche Forschung schreiben. Es ist ein guter Anfang, aber keine Wunderwaffe. Ich schreibe gerade eine Arbeit über die Verwendung von Open-Source-Frameworks, um wissenschaftliche Datenverwaltungsprobleme zu lösen, und eine der Schlussfolgerungen ist, dass einige Software-Engineering-Kenntnisse für lang laufende Systeme unerlässlich sind. Viele wissenschaftliche Projekte sollten dies von Anfang an berücksichtigen.

Kommentare - Beschreiben Sie, was Sie gedacht haben und warum Sie sich entschieden haben, etwas auf eine bestimmte Art umzusetzen, einschließlich der Alternativen, die Sie in Betracht gezogen haben. Es gibt wahrscheinlich alle Arten von ausgefallenen Lösungen, aber nur Ihren Code richtig zu dem Zeitpunkt zu kommentieren, an dem Sie ihn schreiben, scheint am besten zu funktionieren.

Ich würde wiederholen, was die anderen gesagt haben, was das "Warum" betrifft, warum der Code geschrieben wurde und wie er verwendet werden soll, aber ich würde auch Folgendes hinzufügen:

Code, als ob Sie planen, dies in Produktion zu setzen, auch wenn Sie nur herumspielen. Code für:

• Klarheit und Lesbarkeit
• Befolgen Sie die Kodierungskonventionen der Zeit. (Namenskonventionen usw.). Auch wenn sich solche Konventionen im Laufe der Zeit ändern, wenn Sie sich an die Standards halten, können Sie sie später wahrscheinlich besser verstehen.
• Sicherheit (falls zutreffend)
• Leistung (falls zutreffend)

Besonders würde ich den ersten Punkt betonen, aber die anderen sind auch wichtig. Ich finde, wenn ich später "Testcode" verwende, tendiere ich dazu, es einfach zu benutzen, wenn es funktioniert, anstatt es zu refactorieren.

Ich habe wahrscheinlich den Punkt dieser ganzen Diskussion verpasst, was ich oft tue, aber hier ist eine Einladung für Brickbats und Downvoting ...

Wenn es Wegwerfcode ist, wirf ihn weg!

Wenn Sie es nicht wegwerfen wollen, befolgen Sie den oben genannten guten Rat. Für mich, und ich schreibe eine Menge Wegwerf-Code, die Frage, ob es weggeworfen oder in einen wiederverwendbaren Zustand versetzt und gegen einen regnerischen Tag gehalten wird, läuft auf die Wirtschaft hinaus.

Kann ich Umstände vorhersehen, in denen dieser Code wieder nützlich ist? Einmal in einem blauen Mond, zweimal im Jahr, jeden Monat?

Kann ich diesen Code in kürzerer Zeit neu schreiben, als er wiederverwendbar ist? Wenn die Antwort auf diese Frage Nein ist, wie oft muss ich sie dann wiederverwenden, um sie zu verbessern, während ich sie jetzt verbessere? (Zurück zur vorherigen Frage.)

Wenn ich diesen Code wiederverwendbar mache, kann ich ihn dann wieder finden, wenn ich ihn das nächste Mal möchte? (Jeder hatte jemals die Erfahrung, mit absoluter Gewissheit zu wissen, dass irgendwo in Ihrem Code-Repository nur das Fragment vorhanden ist, das Sie wollen, aber keine Ahnung, wie es heißt, wo Sie suchen oder wonach Sie suchen sollen?)

Abschließend noch der 3-Schritt-Ansatz, um schnell geschriebenen Code wiederverwendbar zu machen. Stoppen Sie nach den folgenden Schritten:

1) Dokumentieren Sie den Code als Black-Box. Eingänge, Ausgänge, Operation (en). Legen Sie dieses Dokument sorgfältig ab.

2) Schreiben Sie Anweisungen zum Erstellen / Interpretieren / Installieren des Codes, falls Sie ihn jemals portieren müssen. Legen Sie diese Anweisungen sorgfältig ab.

3) Nur wenn es sich lohnt - verbessern Sie die Qualität des Quellcodes, damit der Code in Zukunft gepflegt werden kann. Stellen Sie sicher, dass die Quellen im Quellcodeverwaltungssystem enthalten und auffindbar sind.

Grüße

Markieren

Ich denke, das Wichtigste ist (wenn Sie kein Refactoring machen, wird es nicht passieren), Ihren Denkprozess zu diesem Zeitpunkt zu kommentieren und zu dokumentieren. Es wird dazu beitragen, den Code weniger undurchdringlich zu machen und Ihnen zu helfen, die guten Bits zu finden, wenn Sie gebraucht werden.

Nein, nein, nein, nein, nein!

Schreiben Sie keinen Wegwerfcode, auch nicht in einer Forschungsumgebung. Bitte!

Momentan bin ich mit einem solchen "Wegwerf-Code", nämlich dem BLAST-Projekt, beschäftigt. Die Sache ist, dass es als Spielplatz begann, aber dann zufällig etwas erfolgreich wurde. Jetzt ist es ein nettes Werkzeug mit vielen implementierten Konzepten, aber der Code ist praktisch nicht zu halten. Aber das ist nicht der Hauptpunkt.

Der wichtigste Punkt ist, dass Sie nach Ingenieuren suchen, um später von Ihren Ergebnissen zu profitieren. Nachdem Sie eine gute wissenschaftliche Arbeit über das allgemeine Konzept geleistet und ein Werkzeug geschrieben haben, das diesen Erfolg beweist, können Sie leicht vergessen, dass Sie es nicht für die Veröffentlichung und nur für die Promotion tun. Du tust es zum Wohle der Menschheit. Ihr Code enthält möglicherweise eine Reihe von "Sonderfällen", die schwer zu debuggen sind, eine Reihe von Macken und Hacks, die nicht in einen Konferenzartikel passen. Es ist besonders wichtig, solche Dinge im gesamten Code zu dokumentieren und zu kommentieren.

Wenn ein Entwickler sich dazu entschloss, Ihre Konzepte in ein kommerzielles Produkt zu implementieren, hätte er die Macken und Hacks aus Ihrem Code herauslesen können und die Implementierung hätte weniger Bugs als sie vielleicht gehabt hätte. Jeder sagt: "Wow, seine Forschung über A ist wirklich nützlich!" Aber wenn du "wegwerfen" schreibst, sagen sie "sein Konzept sieht auf dem Papier gut aus, aber X hat versucht es zu implementieren und ertrank in einer Menge Bugs."

( BEARBEITEN : aus den Kommentaren unten) Um zukünftigen Entwicklern Ihrer Codebasis zu helfen, brauchen Sie nicht viel. Zuerst kommentieren Sie, was jede Funktion macht . Zweitens, stelle sicher, dass jede nicht offensichtliche Korrektur eines kniffligen Fehlers in einem separaten Commit im Revisionskontrollsystem abgelegt wird (natürlich mit einem entsprechenden Kommentar). Das ist genug. Und wenn Sie die Dinge sogar modular machen (auch wenn sie nicht bereit sind für eine sofortige Wiederverwendung - das ist laut Brooks dreimal teurer), werden Sie von Ingenieuren, die Ihre Forschung umsetzen, begeistert sein.

Ich denke, dass die Welt ein besserer Ort wäre, wenn die Forscher ihre Hybris wegwerfen und nicht mehr hochmütig denken würden, dass sie nicht diese schmutzigen Programmierer sind, die einen schlechten Code schreiben. Einen guten Code zu schreiben ist nicht nur ein Job für diese blöden Programmierer. Es ist eine wirklich wertvolle Sache, die jeder anstreben sollte. Ohne dies wird dein experimenteller Boden, dein Code, dein Geisteskind einfach sterben.

Einige Strategien:

1. Gute Kommentare. Schwer zu verwenden, was du später nicht finden oder verstehen kannst.
2. Speichern Sie jede Abfrage in einem Ordner, der gesichert wird oder der Quellcodeverwaltung unterliegt.
3. Haben Sie eine gemeinsame Bibliothek nützlicher Funktionen, die Sie nach der Wiederverwendung "fördern" können.

Sie könnten auch die Idee von Unit-Tests von den TDD-Leuten (test-driven development) ausleihen. Sie müssen sicherstellen, dass der Wegwerfcode tatsächlich trotzdem OK funktioniert. Warum also nicht den Check ausdrücken, wenn Sie einen kleinen Unit-Test ausführen? Dies hätte zwei Vorteile:

1. Das Lesen des Testcodes vermittelt die Absicht des Wegwerfers ganz klar: Schließlich drückt er seine Erwartungen in derselben Sprache aus: Code.

2. Es würde auch beim 4. Problem Ihrer Selbstantwort helfen: "Funktioniert es noch?". Nun, es ist einfach: einfach die Komponententests ausführen und sie sagen Ihnen, was und wo (und mit etwas Glück), warum (es) nicht funktioniert.