Ist das Schreiben von Software einfacher als das Lesen und Verstehen von Grund auf? [geschlossen]

Ich und ein Freund von mir diskutierten gestern über die Unterschiede zwischen dem Schreiben einer großen C ++ - Software und dem Verstehen als Neuzugang.

Ist es möglich, dass das Schreiben einer großen Software einfacher ist, als sie zu lesen und zu verstehen, was sie tut, da eine Software Zeile für Zeile ausgeführt wird und dieser Prozess der Art ähnelt, wie wir (Menschen) Dinge lernen und eine Sache auf eine andere aufbauen (Durchlaufen des Codes hilft, aber Sie müssen sich mehrere Klassen / Quelldateien zusammen merken. Sie wissen nicht einmal, wofür sie geschrieben wurden. Multithread-Code fügt Maluspunkte hinzu.)

Das klingt zunächst seltsam, aber nachdem wir uns ein bisschen überlegt hatten, schien es vernünftig

Aufgrund meiner Erfahrung würde ich die folgenden Aktivitäten in der Reihenfolge von der einfachsten bis zur schwierigsten einordnen.

1. Guten Code lesen
2. Schlechten Code schreiben
3. Guten Code schreiben
4. Schlechten Code lesen

Die obige Rangfolge führt zu 2 Schlussfolgerungen

1. Während es einfacher ist, Code zu schreiben als schlechten Code zu lesen, ist es einfacher, guten Code zu lesen als Ihren eigenen Code zu schreiben
2. Das Schreiben von schlechtem Code ist einfacher als das Schreiben von gutem Code, aber das Schreiben von schlechtem Code bereitet Sie darauf vor, schlechten Code zu lesen, was das Schwierigste von allem ist. Zumal schlechter Code mehr gelesen als geschrieben wird.

Natürlich sind guter Code und schlechter Code allgemeine Verallgemeinerungen. Ich empfehle Code Complete und Clean Code für weitere Details zu gutem Code.

Diese Frage spricht einen falschen Konsens an. http://en.wikipedia.org/wiki/False-consensus_effect

Unterschiedliche Menschen lernen und nehmen Informationen unterschiedlich auf. Es ist vergleichbar mit auditorischen Lernern, visuellen Lernern und kinästhetischen Lernern. Für einige ist das Lesen von Code einfacher, für andere ist das Erstellen von Code einfacher. Für mich ist es das letztere. Für andere in meinem Team ist es das erstere. Ich glaube nicht, dass es sinnvoll ist, einen Konsens oder eine Mehrheit zu finden. Es ist besser zu verstehen, wie Ihr Gehirn Informationen aufnimmt und lernt, und dieses Wissen zu nutzen, um sich selbst zu verbessern und andere zu akzeptieren, die anders sind.

Unterschiede zwischen dem Schreiben einer großen C ++ - Software und dem Verstehen als Neuzugang

Dies ist nicht der Unterschied zwischen Lese- und Schreibsoftware. Wenn Sie neu in einem Projekt sind (und besonders wenn Sie neu in einem Unternehmen sind), müssen Sie viel mehr lernen als nur, was der Code tut. Um zu verstehen, warum der Code das tut, was er tut, ist häufig ein Verständnis der Funktionsweise des Unternehmens und der Beziehung des Projekts zum Rest der Organisation erforderlich. Kurz gesagt, das Lesen von Code ohne Hintergrundwissen ist eine langsamere und schwierigere Aufgabe als das Lesen von Code, wenn Sie den Kontext, in dem der Code funktioniert, vollständig verstehen.

Es gibt einen Unterschied zwischen dem Schreiben von brandneuem Code in einem Greenfield-Projekt und dem Lesen und Ändern von vorhandenem Code, aber ich würde nicht sagen, dass einer notwendigerweise einfacher als der andere ist, nur anders. Wenn Sie etwas Neues erstellen, müssen Sie sich nicht darum kümmern, wie Ihr Code mit den bereits vorhandenen Elementen funktioniert, sondern Sie müssen sich darum kümmern, dass Ihr Projekt ausreichend erweiterbar und anpassbar ist, damit es auch in Zukunft nützlich bleibt . Wenn Sie an einem vorhandenen Projekt arbeiten, können Sie häufig die bereits vorhandenen Informationen als Leitfaden verwenden. Sie müssen jedoch zunächst verstehen, was vorhanden ist.

Als "Neueinsteiger" ist es normalerweise besser, an einem vorhandenen Projekt zu arbeiten, da Sie so alles lernen, was Sie nicht wissen: wie das Geschäft funktioniert, wie die verschiedenen Projekte zusammenarbeiten, Standards und Praktiken programmieren und sogar (vor allem) was könnte verbessert werden.

Es ist eine interessante Frage, aber ich tendiere dazu, mich auf die Seite zu neigen, die leichter zu lesen und zu verstehen ist, als sie zu erstellen.

Wenn Sie ein erfahrener Programmierer sind, lesen Sie wahrscheinlich den Code durch und sagen: "Ja, gute Wahl, überprüfen Sie, oh, ich hätte vielleicht X statt Y gemacht." Sparen Sie immense Zeit beim Schreiben von Grund auf (es sei denn, es gibt Gründe dafür).

Wenn Sie ein neuerer Programmierer sind, dann "wissen Sie nicht, was Sie nicht wissen", und so müssen Sie all die kleinen Dinge erfinden / lernen, und sehr wahrscheinlich werden Sie einige Ineffizienzen in der Code. Sie werden jedoch wahrscheinlich ein besseres Verständnis der Sprache entwickeln.

In beiden Fällen ist es jedoch einfacher, den Code zu lesen und von dort aus fortzufahren, als ihn vollständig von Grund auf neu zu schreiben.

Den meisten Programmierern fällt es leichter, selbst geschriebenen Code zu verstehen, im Vergleich zu Code, den andere Leute geschrieben haben. Dies ist sowohl auf das von Ihnen erwähnte zeilenweise Lernen als auch auf individuellen Stil und Talent zurückzuführen. Das ist der Grund, warum so viel Rad neu erfunden wird.

Das ist jedoch der Blick auf die Bäume. Die Gesamtstrukturansicht sieht so aus, dass es viel einfacher ist, Code zu lesen, als ihn von Grund auf neu zu schreiben. Ist es beispielsweise einfacher, ein neues Textverarbeitungsprogramm von Grund auf neu zu schreiben oder eine vorhandene Codebasis gut genug zu lernen, um Verbesserungen vorzunehmen?

Wenn Sie mit dem Lesen des Codes beginnen, können Sie sich unzählige Möglichkeiten vorstellen, um den Code für sich selbst leichter lesbar zu machen. Sie verbringen die erste Zeit damit, nur den Code zu verfolgen und zu versuchen, die Lage des Landes herauszufinden, manchmal in einer Architektur, die völlig unvorstellbar ist, wie Sie es tun möchten. Aber selbst in wirklich großen Codebasen werden Sie vielleicht 40-80 Stunden damit verbringen, Ihre Räder zu drehen, verglichen mit den hunderttausenden Arbeitsstunden, die bereits in die Erstellung dieser Anwendung investiert wurden.

Die Person, die die Software schreibt, hat fast immer das beste Verständnis für das Programm, da sie die Logik und den Denkprozess während des Schreibens kennt.

Ich glaube nicht, dass das Schreiben von Code mit dem Lesen von Code in Bezug auf die Verständlichkeit verglichen werden kann. Auf der einen Seite bietet das einfache Schreiben von Software ein besseres Verständnis dieser spezifischen Software, da der Kontext für jeden Abschnitt des verwendeten Codes, der verwendeten Bibliothek usw. bekannt ist. Das Lesen von Code, den andere geschrieben haben, kann jedoch schwierig zu verstehen sein die eigentliche Software, aber in Bezug auf das Verständnis der Sprache kann sie Einblicke in neue Möglichkeiten geben, Dinge oder Verwendungen einer Bibliothek zu tun, die Sie möglicherweise nicht in Betracht gezogen haben, was dazu führen kann, dass Sie Ihr Leben leichter mit dem Schreiben von Code verbringen.

In Bezug auf das Build-Wissen denke ich, dass das Lesen und Schreiben von Code sehr eng miteinander verbunden sind und in vielerlei Hinsicht aufeinander aufbauen. Die Erfahrung mit dem Schreiben von Code erleichtert das Verstehen von Code anderer Benutzer, und das Lesen von Code erleichtert das Schreiben von Code (durch neue Logikkonzepte, Bibliotheksnutzung usw.).

Dies ist etwas, das ich persönlich als selbstverständlich empfunden habe, aber ich war mir nie ganz sicher, ob es für die gesamte Programmpopulation gilt. Ich kenne zum Beispiel einige sehr talentierte Programmierer, die die Dokumentation nicht lesen, sondern gerne den Code anderer lesen und verstehen können, als ob es ihr eigener wäre.

Dies führt zu der Frage: Ist das wichtig?

Wenn Sie den Code lesen, nehmen Sie wahrscheinlich eine Änderung vor, anstatt ihn neu zu schreiben. Selbst wenn Sie es umschreiben, schreiben Sie es wahrscheinlich in einer neuen Sprache / Version, sodass Sie den Code möglicherweise nicht unbedingt auf die gleiche Weise erstellen. Der Punkt, den ich anspreche, ist, dass es nicht immer notwendig ist, den gesamten Code zu verstehen.

In Anbetracht dessen erkennen neuere Entwicklungsmethoden, z. B. BDD , dass es wichtig ist, dass die Geschäftslogik aus dem Code klar hervorgeht, anstatt dass der Code lediglich ein Mittel ist, um die Maschine anzutreiben. Das ist natürlich nichts Neues - das Konzept gibt es seit Donald Knuths wegweisender Arbeit: Literate Programming .

Ich gehe auf die Antwort von StMotorSpark ein und füge nur hinzu:
Es hängt von so vielen Faktoren ab, dass es keine Ja- oder Nein-Frage sein kann, zum Beispiel:

• Ist der vorhandene Code gut dokumentiert und gut geschrieben oder sieht er wie ein Spaghetti ohne Sinn und Kommentar aus?
• Ist es eine winzige App mit sehr seltenen Situationen, die Sie unendlich viel Zeit gekostet haben, um herauszufinden, wie die Lösung aussehen soll, oder eine größere, aber einfache App?
• etc.