Ist das Wiederverwendbarkeitsprinzip dieses Codes gut oder schlecht?

Antwortinhalt:

Zuverlässiger Code und trocken (Bild ist GacUI) – vczhs Alltag – Zhihu-Kolumne Wenn Sie einen falschen Weg einschlagen, kehren Sie schnell um.
Ein solcher Code ist komplex, schwer zu schreiben, zu lesen und zu warten, ganz zu schweigen von der Wiederverwendbarkeit. Ich denke, der Schlüssel zum Problem liegt darin, wie detailliert die Fehlerbehandlung sein muss.
Meiner Erfahrung nach ist es nicht notwendig, jede aufgerufene Funktion zu überprüfen, insbesondere in Sprachen, die die Syntax der Fehlerbehandlung nicht optimieren.
Ich denke, Sie müssen die Fehlerbehandlung nur in Funktionen durchführen, von denen Sie glauben, dass sie wahrscheinlich Fehler verursachen oder behandelt werden müssen, wenn Fehler auftreten.

Was die Wiederverwendung angeht: Wiederholen Sie sich nicht. Wenn Sie Zweifel haben, denken Sie einfach darüber nach, wie Sie den Code auf die entsprechende Ebene abstrahieren können.
Ich glaube nicht, dass es notwendig ist, die Lesbarkeit zugunsten stark abstrakter Code-Gemeinsamkeiten für die Wiederverwendung zu opfern. Bevor die zu lösenden Anforderungen oder Probleme nicht wirklich berücksichtigt oder klar studiert wurden, ist es schwierig, den Code hochgradig wiederverwendbar und leicht lesbar zu machen. Zerlegen Sie dann zunächst das große Problem in N Unterprobleme. Führen Sie dann TTD für die Unterprobleme durch und fahren Sie dann mit der Optimierung fort.



Die Wiederverwendung von Code in einem Schritt ist nicht realistisch. Es fühlt sich an, als würde man sich noch einmal C-Code ansehen. . Warum nicht den High-Tech-Try-Catch-Wurf verwenden, anstatt die Ausnahmebehandlung selbst zu schreiben? . . Unabhängig von der Logik schauen Sie sich einfach die Struktur an. Haben Sie jemals über Parallelität nachgedacht? Wenn Sie nicht eingeladen sind, besuchen Sie bitte
http://zh-google-styleguide.readthedocs.io/en/latest/Google Stilleitfaden für Open-Source-Projekte


Sehen Sie sich weitere tolle Open-Source-Projekte an Was das Subjekt tun möchte, ist eigentlich Versprechen. „Resolve“ wird erfolgreich aufgerufen, „Reject“ ist fehlgeschlagen und das Aussprudeln wird im Ausnahmefall unterstützt. Äußerlich sind dann nur noch Catch-Chain-Calls nötig, was sehr elegant aussieht. Jede Klasse muss so geschrieben sein? Was hat das mit der Wiederverwendung von Code zu tun?