Was macht Ihrer Meinung nach Menschen am ungeduldigsten, wenn sie alten Code übernehmen? Extrem komplexes UML? Das glaube ich nicht. Meine Antwort lautet: Wenn mit mehr als zwei anderen Fällen oder mit mehr als zwei Fällen wechseln. Aber ist es normal, in Ihrem Code viele if else- Befehle zu verwenden und die Groß-/Kleinschreibung zu wechseln ? falsch! Die meisten if else- und switch-Fälle mit mehr als zwei Zweigen sollten nicht in fest codierter Form erscheinen.
Woher kommen komplexe Zweige?
Die erste Frage, die wir diskutieren wollen, ist zunächst, warum es in Legacy-Code oft so viele komplexe Verzweigungen gibt. Diese komplexen Zweige sind in der ersten Version des Codes oft nicht vorhanden. Vorausgesetzt, dass der Designer noch über einige Erfahrung verfügt, sollte er Bereiche vorhersehen, die in Zukunft möglicherweise erweitert werden müssen, und abstrakte Schnittstellen reservieren.
Nachdem der Code jedoch mehrere Iterationen durchlaufen hat, insbesondere nach mehreren Anpassungen der Anforderungsdetails, werden komplexe Verzweigungen auftreten. Detaillierte Anpassungen der Anforderungen werden oft nicht in UML, sondern direkt im Code widergespiegelt. Beispielsweise wurden Nachrichten ursprünglich in zwei Kategorien unterteilt: Chat-Nachrichten und Systemnachrichten. Beim Entwurf wurden diese natürlich als zwei Unterkategorien der Nachrichtenkategorie entworfen. Aber eines Tages werden die Anforderungen im Detail angepasst und ihre Titel sollten in rot angezeigt werden. Zu diesem Zeitpunkt nehmen Programmierer häufig die folgenden Änderungen vor:
Fügen Sie der Systemnachrichtenklasse ein wichtiges Attribut hinzu
Fügen Sie in der entsprechenden Rendermethode einen Zweig über das wichtige Attribut hinzu, um die Titelfarbe zu steuern. Warum sollte der Programmierer eine solche Änderung vornehmen? Vielleicht liegt es daran, dass ihm nicht klar war, dass es abstrakt sein sollte. Da die Anforderung besagt, dass „einige der Systemmeldungen wichtig sind“, denken Programmierer, die eine umfassendere Ausbildung in imperativen Programmiersprachen erhalten haben, möglicherweise als Erstes an das Flag-Bit – ein Flag-Bit kann zwischen wichtigen und unwichtigen Nachrichten unterscheiden . wichtig. Er rechnete nicht damit, dass diese Vorgabe anders ausgelegt werden könne: „Systemmeldungen werden in zwei Kategorien eingeteilt: wichtig und unwichtig.“ Als er es so interpretierte, wusste er, dass die Systemnachrichten abstrahiert werden sollten.
Es ist natürlich möglich, dass der Programmierer weiß, dass Abstraktion möglich ist, sich aber aus irgendeinem Grund dagegen entscheidet. Eine sehr häufige Situation besteht darin, dass jemand Programmierer dazu zwingt, im Austausch für die Geschwindigkeit des Projektfortschritts Abstriche bei der Codequalität zu machen. Das Hinzufügen einer Eigenschaft und eines Zweigs ist viel einfacher als abstraktes Refactoring. Wenn Sie 10 dieser Form ändern möchten, ist es schneller, 10 zu erstellen? Zweige oder 10 Abstraktionen? Der Unterschied ist offensichtlich.
Wenn es zu viele davon gibt, werden natürlich einige kluge Leute aufstehen und sagen: „Warum tauschen wir es nicht gegen ein Schaltergehäuse aus?“ In einigen Fällen kann dies tatsächlich die Lesbarkeit des Codes verbessern, vorausgesetzt, dass sich die einzelnen Zweige gegenseitig ausschließen. Wenn jedoch die Anzahl der Schalterfälle zunimmt, wird der Code auch unleserlich.
Welche Nachteile haben komplexe Filialen?
Welche Nachteile haben komplexe Filialen? Lassen Sie mich als Beispiel einen Abschnitt aus dem alten Code der Baidu Hi-Webversion nehmen.
switch (json.result) {
Fall „ok“:
switch (json.command) {
Fall „Nachricht“:
Fall „Systemmeldung“:
if (json.content.from == ""
&& json.content.content == "gekickt") {
/* trennen */
} else if (json.command == "systemmessage"
||. json.content.type == "sysmsg") {
/* Systemmeldung rendern */
} anders {
/* Chat-Nachricht rendern */
}
brechen;
}
brechen;
Quelle: Baidu-All-User-Erfahrung