Java-Optimierung – schwerer Code, wodurch der Code schöner und prägnanter wird

Zusamenfassend

Bei der Projektarbeit gibt es häufig Optimierungen, darunter SQL-Optimierung, Projektstrukturoptimierung, Business-Layer-Optimierung, Codestrukturoptimierung usw. Diese Optimierungen dienen dazu, das System einfach zu warten, zu verstehen und zu erweitern. Nachfolgend finden Sie einige meiner persönlichen Erfahrungen, die ich mit Ihnen teilen möchte. Ich habe das Gefühl, dass jedes Programm den richtigen Architekten haben muss.

Früher hatte ich das Gefühl, dass ich einfach mehr Zeit mit dem Geschäft verbringen, die funktionale Entwicklung abschließen, den Selbsttest bestehen und dann die Klassenkameraden testen müsste. Wenn die Produktakzeptanz in Ordnung ist, wird es auch in Ordnung sein. Langsam entdeckte ich, dass ich anfing, besser zu verfolgen, über Probleme von einem höheren Punkt aus nachzudenken und langsam zu einem Veteranen zu werden. Wie man die Qualität des Codes verbessert, wie man die folgenden Teams reguliert, um ein gewisses Bewusstsein zu bilden, und spontan über die Skalierbarkeit nachdenkt Code, Zhuangxing usw. erstellen.

1. Codeoptimierung ist schmerzhaft

Warum sagst du das?

Die Codeoptimierung basiert häufig auf der Optimierung des Codes anderer Personen oder Ihres eigenen Codes auf der Grundlage früherer Geschäfte und der Vorlage von Optimierungsideen. Es muss sein, dass die Lesbarkeit, Wartbarkeit und Designrichtung des aktuellen Codes nicht sehr benutzerfreundlich sind, und das muss auch so sein Umstrukturierung des bestehenden Geschäfts. Code oder Architektur. Vor der Optimierung müssen Sie die vorhandene Codelogik sowie frühere Designer oder die Geschäftsentwicklung verstehen und diese kombinieren, um den Code zu rekonstruieren.

2. Wie man umgestaltet

• Kleines Refactoring
  ist das Refactoring von Codedetails, hauptsächlich für das Refactoring von Klassen, Funktionen, Variablen usw. auf Codeebene. Zum Beispiel eine gemeinsame standardisierte Benennung (Umbenennen von Variablen, die keine Bedeutung vermitteln), die Eliminierung übermäßig großer Funktionen, die Eliminierung doppelter Codes usw. Im Allgemeinen ist diese Art der Rekonstruktion und Änderung relativ konzentriert, relativ einfach, hat relativ geringe Auswirkungen und nimmt kurze Zeit in Anspruch. Daher ist der Schwierigkeitsgrad relativ gering und wir können die tägliche Entwicklung vollständig mit der Version durchführen.

• Beim groß angelegten Refactoring
  handelt es sich um die Rekonstruktion der obersten Codeebene, einschließlich der Rekonstruktion der Systemstruktur, Modulstruktur, Codestruktur und Klassenbeziehungen. Die im Allgemeinen verwendeten Methoden sind Service Layering, Geschäftsmodularisierung, Komponentisierung, Wiederverwendung von Codeabstraktionen usw. Diese Art der Umgestaltung erfordert möglicherweise eine Neudefinition von Prinzipien, eine Neudefinition von Mustern oder sogar eine Neudefinition des Geschäfts. Es erfordert viele Codeanpassungen und -modifikationen, hat also relativ große Auswirkungen, dauert lange und birgt relativ hohe Risiken (Risiko einer Projektunterbrechung, Risiko eines Codefehlers und Risiko einer Geschäftsschwachstelle). Dafür müssen wir Erfahrung in der Sanierung von Großprojekten haben, sonst passieren leicht Fehler und am Ende überwiegen die Gewinne die Verluste.

Tatsächlich mögen die meisten Menschen keine Refactoring-Arbeit, genauso wie niemand anderen „den Hintern abwischen“ möchte. Sie haben möglicherweise die folgenden Bedenken:

• Wenn Sie nicht wissen, wie ein Refactoring durchgeführt wird, und Ihnen die Erfahrung und Methodik für das Refactoring fehlt, werden Sie beim Refactoring leicht Fehler machen.
• Es ist schwer, kurzfristige Vorteile zu erkennen. Warum also jetzt den Aufwand betreiben, wenn die Vorteile langfristig sind? Wenn das Projekt auf lange Sicht von diesen Vorteilen profitiert, sind Sie möglicherweise nicht mehr für diese Arbeit verantwortlich.
• Refactoring zerstört vorhandene Programme und bringt unerwartete Fehler mit sich, und Sie möchten diese unerwarteten Fehler nicht ertragen.
• Das Refactoring erfordert zusätzliche Arbeit Ihrerseits, ganz zu schweigen davon, dass der Code, der umgestaltet werden muss, möglicherweise nicht von Ihnen geschrieben wurde.

3. Warum ein Wiederaufbau nötig ist

Programme haben zwei Werte: „Was sie heute für Sie tun können“ und „Was sie morgen für Sie tun können.“ Meistens konzentrieren wir uns nur auf das, was unser Programm heute bewirken soll. Ganz gleich, ob es darum geht, Fehler zu beheben oder Funktionen hinzuzufügen, es geht darum, das Programm stärker zu machen und es heute wertvoller zu machen. Aber warum befürworte ich immer noch, dass jeder zum richtigen Zeitpunkt Code-Refactoring durchführen sollte? Die Hauptgründe sind folgende:

• Lassen Sie die Softwarearchitektur immer ein gutes Design beibehalten. Verbessern Sie unser Softwaredesign, lassen Sie die Softwarearchitektur sich in eine günstige Richtung entwickeln, können Sie der Außenwelt stets stabile Dienste bereitstellen und verschiedenen unerwarteten Problemen ruhig begegnen.
• Die Erhöhung der Wartbarkeit und die Reduzierung der Wartungskosten sind ein positiver positiver Kreislauf für das Team und Einzelpersonen und machen die Software verständlicher. Unabhängig davon, ob zukünftige Generationen den von Vorgängern geschriebenen Code lesen oder anschließend ihren eigenen Code überprüfen, können sie die gesamte Logik schnell verstehen, das Geschäft klären und das System einfach warten.
• Erhöhen Sie die Forschungs- und Entwicklungsgeschwindigkeit und senken Sie die Arbeitskosten. Möglicherweise haben Sie ein tiefes Verständnis dafür, dass die Fertigstellungsgeschwindigkeit beim ersten Start eines Systems beim Hinzufügen von Funktionen zum System sehr hoch ist. Wenn Sie jedoch nicht auf die Codequalität achten, kann das Hinzufügen eine Woche oder länger dauern eine kleine Funktion zum System später. Zeit. Code-Refactoring ist ein wirksames Mittel zur Sicherstellung der Codequalität, und gutes Design ist von grundlegender Bedeutung für die Aufrechterhaltung der Softwareentwicklungsgeschwindigkeit. Refactoring kann Ihnen helfen, Software schneller zu entwickeln, da es Systemverfall verhindert und sogar die Qualität Ihres Designs verbessern kann.
  
  

3. Wie man umgestaltet

kleines Refactoring

Die meisten kleinen Refactorings werden in der täglichen Entwicklung durchgeführt. Der allgemeine Referenzstandard sind unsere Entwicklungsspezifikationen und -richtlinien. Der Zweck besteht darin, die schlechten Gerüche im Code zu beseitigen. Werfen wir einen Blick auf die häufigsten schlechten Gerüche?

Zu viele Wenn-Sonst

Skalencode:

if(){
    
    
	if(){
    
    
		if(){
    
    
			} else if(){
    
    
			}
	} else if(){
    
    
	}
} else if(){
    
    
}

Andernfalls wird empfohlen, drei Schichten nicht zu überschreiten

Die for-Schleife hat viele Ebenen, genau wie oben im if else-Beispiel

Doppelter Code

Es gibt mehrere Stellen im Projekt, an denen der Restwert berechnet wird. Wir können erwägen, die Ergebnisse durch Funktionen zu kapseln und Methoden einheitlich aufzurufen, oder ähnliche Codefragmente können Methodenaufrufe einheitlich extrahieren.

Funktion zu lang

Eine gute Funktion muss dem Prinzip der Einzelverantwortung genügen, kurz und prägnant sein und nur eine Aufgabe erfüllen. Zu lange Funktionskörper und Multitasking-Methoden sind nicht förderlich für das Lesen und die Wiederverwendung von Code.

Regeln der Namensgebung

Eine gute Namensgebung muss „des Namens würdig und durch den Namen verständlich“, geradlinig und eindeutig sein.

Unangemessene Kommentare

Kommentare sind ein zweischneidiges Schwert. Gute Kommentare können uns eine gute Orientierung geben, aber schlechte Kommentare können Menschen nur in die Irre führen. In Bezug auf Kommentare müssen wir die Kommentare bei der Integration des Codes gemeinsam ändern, da es sonst zu Inkonsistenzen zwischen Kommentaren und Logik kommt. Darüber hinaus sind die Kommentare überflüssig, wenn der Kodex seine Absicht klar zum Ausdruck bringt.

nutzloser Code

Es gibt zwei Möglichkeiten, nutzlosen Code zu verwenden: Die eine besteht darin, dass es kein Verwendungsszenario gibt. Wenn es sich bei diesem Codetyp nicht um eine Toolmethode oder Toolklasse, sondern um nutzlosen Geschäftscode handelt, muss er rechtzeitig gelöscht und bereinigt werden. Der andere ist ein in Kommentare verpackter Codeblock. Diese Codes sollten gelöscht werden, wenn sie mit Kommentaren markiert sind.

Klasse, die zu groß ist

Wenn eine Klasse zu viele Dinge tut und zu viele Funktionen verwaltet, wird ihre Lesbarkeit schlechter und auch ihre Leistung nimmt ab. Sie ordnen beispielsweise auftragsbezogene Funktionen einer Klasse A zu, Produktbestandsbezogene Funktionen werden ebenfalls in Klasse A eingeordnet, punktbezogene Funktionen werden ebenfalls in Klasse A eingeordnet ... Stellen Sie sich vor, alle unordentlichen Codeblöcke werden in eingeordnet eine Klasse. Verdammt, reden wir über Lesbarkeit. Der Code sollte entsprechend den einzelnen Verantwortlichkeiten in verschiedene Klassen unterteilt werden.

Dies sind relativ häufige „schlechte Gerüche“ für Code. Natürlich gibt es in der tatsächlichen Entwicklung auch andere „schlechte Gerüche“, wie z. B. verwirrenden Code, unklare Logik und komplizierte Klassenbeziehungen. Wenn Sie diese verschiedenen „schlechten Gerüche“ riechen, sollten wir es versuchen es zu lösen, anstatt es einfach loszulassen.

Großes Refactoring

Im Vergleich zum Refactoring im kleinen Maßstab müssen beim Refactoring im großen Maßstab mehr Dinge berücksichtigt werden, und es ist notwendig, einen guten Rhythmus festzulegen und ihn Schritt für Schritt auszuführen, da sich die Situation beim Refactoring im großen Maßstab ändert.

Die Schritte zum Einsetzen des Elefanten in den Kühlschrank lassen sich im Allgemeinen in drei Schritte unterteilen: 1) Kühlschranktür öffnen (vor der Veranstaltung); 2) Elefanten hineinschieben (während der Veranstaltung); 3) Kühlschranktür schließen (nach der Veranstaltung). Ereignis). Alle alltäglichen Dinge können mit einem dreistufigen Ansatz gelöst werden, und Refactoring bildet da keine Ausnahme.

Vorauszahlung

Die Vorbereitung ist der erste Schritt beim Refactoring. Die Dinge in diesem Teil sind relativ komplex und auch die wichtigsten. Wenn die Vorbereitung im Vorfeld nicht ausreicht, ist es sehr wahrscheinlich, dass die Ergebnisse während der Ausführung oder nach dem Start des Refactorings erzielt werden im Widerspruch zu den Erwartungen. Phänomen.

Diese Phase kann grob in drei Schritte unterteilt werden:

• Klären Sie den Inhalt, den Zweck, die Richtung und die Ziele des Wiederaufbaus
  . In diesem Schritt ist es am wichtigsten, die Richtung klar festzulegen, und diese Richtung kann allen Zweifeln standhalten und die Richtung der nächsten drei bis fünf Jahre mindestens erfüllen. Das andere ist das Ziel dieser Rekonstruktion. Aufgrund technischer Einschränkungen, historischer Belastungen und anderer Gründe ist dieses Ziel möglicherweise nicht das endgültige Ziel. Dann muss geklärt werden, was das endgültige Ziel ist. Bis dahin ist es noch ein weiter Weg vom Ziel dieser Rekonstruktion zum endgültigen Ziel. Es ist am besten, sich darüber im Klaren zu sein, was getan werden muss.

• Der Schritt des Organisierens der Daten
  erfordert die Sortierung der vorhandenen Unternehmen und Architekturen, die am Rekonstruktionsteil beteiligt sind, und die Klärung, zu welchem ​​Servicelevel des Systems der rekonstruierte Inhalt gehört, zu welchem ​​Geschäftsmodul er gehört, wer die vertrauenden und abhängigen Parteien sind, Welche Geschäftsszenarien gibt es? Wie hoch ist die Dateneingabe und -ausgabe jeder Szene? In dieser Phase wird es Ergebnisse geben, zu denen im Allgemeinen Projektbereitstellung, Geschäftsarchitektur, technische Architektur, vor- und nachgelagerte Serviceabhängigkeiten, starke und schwache Abhängigkeiten, internes Service-Layering-Modell des Projekts, Inhalts- und Funktionsabhängigkeitsmodell sowie Eingabe- und Ausgabedatenflüsse gehören usw. Konstruktionszeichnungen und Dokumente.

• Die Projektgründung
  erfolgt in der Regel durch Besprechungen. Alle am Wiederaufbau beteiligten Abteilungen bzw. Gruppen werden über die Wiederaufbauarbeiten informiert, der ungefähre Zeitplan ist bekannt (ungefährer Zeitrahmen) und die Hauptverantwortlichen jeder Gruppe sind klar definiert. Darüber hinaus ist es auch notwendig zu wissen, welche Unternehmen und Szenarien am Refactoring beteiligt sind, welche ungefähre Refactoring-Methode es gibt, welche Auswirkungen das auf das Unternehmen haben kann, welche Schwierigkeiten es gibt und welche Schritte es zu Engpässen geben kann.

im Gange

Die Aufgaben und Aufgaben, die mit der Ausführung dieses Schritts verbunden sind, sind relativ mühsam und erfordern relativ viel Zeit.

• Architekturdesign und -überprüfung
  Die Überprüfung des Architekturdesigns umfasst hauptsächlich den Entwurf und die Überprüfung von Standard-Geschäftsarchitektur, technischer Architektur und Datenarchitektur. Entdecken Sie Architektur- und Geschäftsprobleme durch Überprüfung. Bei dieser Überprüfung handelt es sich im Allgemeinen um eine Überprüfung im Team. Wenn sich nach einer Überprüfung herausstellt, dass der Architekturentwurf nicht bestimmt werden kann, müssen Anpassungen vorgenommen werden, bis das Team eine Einigung über die Lösungsarchitektur erzielt Erst dann können Sie mit dem nächsten Schritt fortfahren und die Prüfergebnisse müssen den Teilnehmern nach bestandener Prüfung auch per E-Mail mitgeteilt werden.

Das Ergebnis dieser Phase: rekonstruierte Servicebereitstellung, Systemarchitektur, Geschäftsarchitektur, Standarddatenfluss, Service-Layering-Modell, Funktionsmodul-UML-Diagramm usw.

• Detaillierter Implementierungsentwurfsplan und Überprüfung
  . Dieser Implementierungsentwurfsplan ist der wichtigste Plan in der Implementierung. Er steht im Zusammenhang mit der anschließenden F&E-Codierung, dem Selbsttest und dem gemeinsamen Debuggen, dem Andocken der vertrauenden Partei, dem QS-Test, dem Offline-Release- und Implementierungsplan usw Online-Release- und Implementierungsplan, spezifische Arbeitsbelastung, Schwierigkeiten, Arbeitsengpässe usw. Dieser detaillierte Implementierungsplan muss tief in die gesamte Forschung und Entwicklung, Offline-Tests, Online-Prozesse und Details der Graustufenszene eintauchen, einschließlich des AB-Graustufenprogramms und des AB-Verifizierungsprogramms.

Der wichtigste Teil des Lösungsentwurfs ist das AB-Verifizierungsprogramm und der AB-Verifizierungsschalter, die die Standardgrundlage für die Bewertung und Prüfung der Vollständigkeit unserer Rekonstruktion bilden. Das allgemeine AB-Überprüfungsverfahren ist ungefähr wie folgt:

Verwenden Sie am Dateneingang dieselben Daten, um Verarbeitungsanforderungen sowohl an den neuen als auch an den alten Prozess zu initiieren. Nach Abschluss der Verarbeitung werden die Verarbeitungsergebnisse jeweils im Protokoll ausgedruckt. Abschließend wird mit einem Offline-Programm verglichen, ob die Ergebnisse des neuen und des alten Prozesses konsistent sind. Dabei gilt der Grundsatz, dass bei gleichen Eingabeparametern auch die Antwortergebnisse konsistent sein sollten.

Im AB-Programm sind zwei Schalter beteiligt. Graustufenschalter (nur wenn er aktiviert ist, wird die Anfrage zur Codeausführung an einen neuen Prozess gesendet). Ausführungsschalter (Wenn der neue Prozess Schreibvorgänge umfasst, müssen Sie einen Schalter verwenden, um zu steuern, ob in den neuen Prozess oder in den alten Prozess geschrieben werden soll). Vor der Weiterleitung müssen der Graustufenschalter und der Ausführungsschalter (im Allgemeinen im Konfigurationscenter konfiguriert und jederzeit angepasst werden) in den Thread-Kontext geschrieben werden, um inkonsistente Ergebnisse beim Ändern des Konfigurationscenter-Schalters zu vermeiden.

• Code schreiben, testen und offline implementieren
  In diesem Schritt werden Codierung, Unit-Tests, gemeinsames Debuggen, Funktionstests, Geschäftstests und QS-Tests gemäß dem detaillierten Entwurfsplan durchgeführt. Simulieren Sie nach dem Bestehen den Online-Prozess und den Online-Switch-Implementierungsprozess offline, überprüfen Sie das AB-Programm, prüfen Sie, ob es den Erwartungen entspricht und ob die Codeabdeckung des neuen Prozesses den Online-Anforderungen entspricht. Wenn es relativ wenige Offline-Datenproben gibt und nicht alle Szenarien abdecken können, müssen Sie den Datenverkehr so ​​konstruieren, dass er alle Szenarien abdeckt, um sicherzustellen, dass alle Szenarien die Erwartungen erfüllen können. Wenn die Offline-Abdeckung den Erwartungen entspricht und das AB-Verifizierungsprogramm keine Anomalien erkennt, kann der Online-Vorgang durchgeführt werden.

nachher

Diese Phase muss online gemäß dem Implementierungsprozess der Offline-Simulation implementiert werden, der in mehrere Phasen unterteilt ist: Online, groß angelegt, Reparatur, Offline-Altlogik und Überprüfung. Das wichtigste und energieintensivste Verfahren ist das volumetrische Verfahren.

• Der Graustufenumschaltvorgang
  wird schrittweise auf den neuen Beobachtungsprozess erweitert. Die Lautstärke kann entsprechend dem Fortschritt um 1 %, 5 %, 10 %, 20 %, 40 %, 80 % und 100 % erhöht werden, sodass das Neue entsteht Der Prozess kann die Codelogik schrittweise abdecken. Beachten Sie, dass in dieser Phase nicht der Schalter aktiviert wird, um den Schreibvorgang tatsächlich auszuführen. Wenn die Logikabdeckung des neuen Prozesses den Anforderungen entspricht und die AB-Überprüfungsergebnisse den Erwartungen entsprechen, kann der Schreibvorgangsschalter schrittweise aktiviert werden, um das eigentliche Geschäft auszuführen.

• Nachdem der Prozess zum Umschalten der Geschäftsausführung
  die Erwartungen im neuen Graustufenprozess erfüllt, kann der Prozess zum Umschalten des Geschäftsausführungs-Schreibvorgangs schrittweise aktiviert werden, und die Lautstärke kann immer noch schrittweise entsprechend einem bestimmten Verhältnis erhöht werden. Erst nach dem Einschalten des Schreibvorgangs Die neue Logik führt den Schreibvorgang aus, und der Schreibvorgang der alten Logik wird geschlossen. In dieser Phase ist es notwendig, Online-Fehler, Indikatoranomalien, Benutzerfeedback und andere Probleme zu beobachten, um sicherzustellen, dass es keine Probleme mit dem neuen Prozess gibt.

Nachdem die groß angelegten Arbeiten abgeschlossen sind und eine bestimmte Version stabilisiert ist, können die alte Logik und das AB-Verifizierungsprogramm offline geschaltet werden und die Rekonstruktionsarbeiten sind abgeschlossen. Wenn möglich, können Sie eine Besprechung zur Überprüfung des Wiederaufbaus abhalten, um zu überprüfen, ob jeder Teilnehmer die für den Wiederaufbau erforderlichen Standards erfüllt hat, um die während des Wiederaufbaus aufgetretenen Probleme und Lösungen zu überprüfen und um spätere Probleme mithilfe der Niederschlagsmethode zu vermeiden. Ähnliche Probleme treten auf arbeiten.

Zusammenfassen

Programmierkenntnisse

• Befolgen Sie beim Schreiben von Code einige Grundprinzipien, z. B. das Single-Prinzip, und verlassen Sie sich auf Schnittstellen/Abstraktionen, anstatt sich auf bestimmte Implementierungen zu verlassen.
• Halten Sie sich strikt an die Codierungsstandards und verwenden Sie TODO, FIXME und XXX für spezielle Kommentare.
• Unit-Tests, Funktionstests, Schnittstellentests und Integrationstests sind wesentliche Werkzeuge zum Schreiben von Code.
• Wir sind die Autoren des Codes und zukünftige Generationen sind die Leser des Codes. Wenn Sie Code schreiben, müssen Sie ihn immer überprüfen, das tun, was die Vorgänger Bäume gepflanzt haben, damit zukünftige Generationen sie genießen können, und nicht das tun, was die Vorgänger getan haben, indem Sie Löcher graben, die zukünftige Generationen mit ihnen begraben können.
• Wenn Sie die erste Person sind, die den Effekt des zerbrochenen Fensters vermeidet, denken Sie nicht, dass der Code jetzt bereits schlecht ist und keine Notwendigkeit mehr besteht, ihn zu ändern, sondern häufen Sie den Code einfach weiter an. Wenn dies der Fall ist, werden Sie eines Tages vom Kodex anderer Leute angewidert sein und „früher oder später müssen Sie es zurückzahlen“.

Refactoring-Fähigkeiten

• Das Modellieren und Analysieren von oben nach unten, von außen nach innen und die Klärung verschiedener Zusammenhänge stehen bei der Rekonstruktion an erster Stelle.
• Verfeinern Sie Klassen, verwenden Sie Funktionen wieder und konzentrieren Sie sich auf Kernfunktionen, um die Verantwortlichkeiten der Module klar zu machen.
• Die Abhängigkeit von der Schnittstelle ist besser als die Abhängigkeit von der Abstraktion, und die Abhängigkeit von der Abstraktion ist besser als die Abhängigkeit von der Implementierung. Wenn Klassenbeziehungen kombiniert werden können, ist keine Vererbung erforderlich.
• Berücksichtigen Sie beim Entwerfen von Klassen, Schnittstellen und abstrakten Schnittstellen die Bereichsqualifizierer, welche umgeschrieben werden können, welche nicht umgeschrieben werden können und ob die generische Qualifikation korrekt ist.
• Erstellen Sie verschiedene Entwürfe und Pläne für ein umfangreiches Refactoring und simulieren Sie verschiedene Szenarien offline. Für die Online-Schaltung müssen AB-Verifizierungsverfahren erforderlich sein, und der Wechsel zwischen Neu und Alt ist jederzeit möglich.