So schreiben Sie sauberen Code
Quelle: Dev.to Sauberen Code zu schreiben ist wie Gedichte zu schreiben. Das ist Poesie, die prägnant, verständlich und für Veränderungen zugänglich sein sollte. Sauberer Code setzt eine skalierbare Organisation voraus. Das bedeutet, dass Änderungen kein Chaos verursachen. Die Fähigkeit, solchen Code zu schreiben, ist eine der Schlüsselqualitäten eines erfahrenen Entwicklers. Nachdem mir mehrere Leute empfohlen hatten, das Buch „Clean Code“ zu lesen, nahm ich endlich den Mut zusammen, es zu lesen. Es stellte sich heraus, dass dies eines dieser Bücher ist, bei denen das Cover dem Hype um das Buch voll und ganz gerecht wird. Die Empfehlungen im Buch sind klar, konkret, praktisch und sogar mit Humor präsentiert. Heute möchte ich die wichtigsten Erkenntnisse aus diesem Buch mit Ihnen teilen.
1. Der Code sollte nicht nur funktionieren, sondern auch lesbar sein
Der Großteil der Softwarekosten ist an den langfristigen Support gebunden. Daher muss der von Ihnen geschriebene Code Ihre Absichten klar zum Ausdruck bringen. Es sollte so sein, dass neue Entwickler, die dem Team beitreten, leicht verstehen können, was genau im Code passiert und warum. Je verständlicher der Code ist, den der Autor schreibt, desto weniger Zeit werden andere Entwickler benötigen, um ihn zu verstehen. Dadurch werden Defekte und Wartungskosten reduziert. Wie erreicht man das? Gute Benennung + Klassen und Funktionen mit Einzelverantwortung + Schreiben von Tests.2. Später bedeutet nie
Seien wir ehrlich: Wir alle versprechen uns manchmal, dass wir später noch einmal zurückkommen und den Code bereinigen, aber am Ende vergessen wir es. Hinterlassen Sie keine nutzlosen Codeteile, die nicht mehr benötigt werden. Sie verwirren andere Entwickler und haben keinen Wert. Entfernen Sie daher bei Funktionsänderungen stets alten Code. Wenn irgendwo etwas kaputt geht, zeigen die Tests es trotzdem sofort an. Wie erreicht man das? Das Löschen von Code kann beängstigend sein, insbesondere in großen Architekturen. Daher ist das Testen hier der Schlüssel. Sie ermöglichen Ihnen, Code sicher zu entfernen.3. Die Funktionen sollten klein sein
Die erste Regel beim Schreiben von Funktionen lautet, dass sie klein sein sollten, bis zu etwa 20 Zeilen . Je kleiner die Funktion und je fokussierter sie auf eine Aufgabe ist, desto einfacher ist es, einen guten Namen dafür zu finden. Die ideale Anzahl von Funktionsargumenten ist 0. Als nächstes kommen 1 und 2, aber Sie sollten versuchen, nicht mehr als 3 Argumente zu haben. Wie erreicht man das? Funktionen sollten nach den Prinzipien der Einzelverantwortung und offen/geschlossen geschrieben werden.4. Codeduplizierung ist schlecht
Duplizierung ist der Feind eines gut organisierten Systems. Es bedeutet zusätzliche Arbeit, zusätzliches Risiko und zusätzliche unnötige Komplexität. Was tun dagegen? Stellen Sie sicher, dass Ihr Code nach dem DRY-Prinzip geschrieben, isoliert und modular ist.5. Der einzig gute Kommentar ist der, bei dem Sie einen Weg gefunden haben, ihn nicht zu schreiben.
„Es gibt nichts Nützlicheres als einen guten Kommentar an der richtigen Stelle. Aber Kommentare sind selbst im besten Fall ein notwendiges Übel.“ Kommentare sollen unsere Unfähigkeit kompensieren, unsere Gedanken im Code auszudrücken. Das heißt, es handelt sich zunächst einmal um ein Eingeständnis einer Niederlage. Ja, wir müssen sie verwenden, weil wir unsere Absichten mit Code nicht immer klar zum Ausdruck bringen können, aber das ist kein Grund zum Feiern. Die Sache ist die: Kommentare lügen oft. Nicht immer und nicht mit Absicht, aber zu oft. Je älter der Kommentar ist und je weiter er vom Code entfernt ist, den er beschreibt, desto wahrscheinlicher ist es, dass er falsch ist. Der Grund dafür ist einfach: Programmierer können sowohl den Code als auch alle Kommentare nicht wirklich gut pflegen. Daher werden Kommentare sehr oft vom Code, auf den sie verweisen, getrennt und mit minimaler Präzision zu verwaisten Anmerkungen. Was tun dagegen? Es müssen beschreibende Benennungsmethoden verwendet werden. Wenn Sie den Namen einer Variablen lesen, sollten Sie sofort verstehen, was es ist. Außerdem sind Tests erforderlich, damit andere Entwickler verstehen, welche Funktionalität am wichtigsten ist.6. Das Objekt offenbart Verhalten, aber keine Daten.
Ein Modul sollte nichts über die Interna der Objekte wissen, die es manipuliert. Objekte verbergen ihre Daten und offenbaren ihre Operationen. Das bedeutet, dass ein Objekt seine interne Struktur nicht durch Zugriffsmethoden offenlegen sollte. Es ist nicht notwendig, dass dich jeder nackt sieht. Was tun dagegen? Der Gültigkeitsbereich der Variablen sollte so lokal wie möglich sein, um nicht mehr als nötig offenzulegen.
7. Testen
Testcode ist genauso wichtig wie das, was in die Produktion geht. Daher muss es sich mit der Entwicklung des Projekts ändern und wachsen. Durch Tests bleibt Ihr Code flexibel, wartbar und wiederverwendbar. Ohne sie kann jede Änderung zu Fehlern führen. Mit Tests können Sie Ihren Code bereinigen, ohne befürchten zu müssen, dass etwas kaputt geht. Daher ist die Wahrung der Reinheit der Tests von großer Bedeutung. Die Sauberkeit der Tests gewährleistet deren Lesbarkeit. Tests bieten die Möglichkeit, anderen Entwicklern in einfacher Sprache die Absichten des Codeautors zu erklären. Daher testen wir in jeder Testfunktion nur ein Konzept. Dadurch wird der Test beschreibender und leichter lesbar, und wenn er fehlschlägt, ist es einfacher, den Grund dafür herauszufinden. Wie erreicht man das? Man muss den Grundsätzen sauberer FIRST- Tests folgen . Tests sollten sein:- Schnell. Tests müssen schnell ablaufen. Wenn Sie zu lange auf die Ausführung eines Tests warten müssen, ist die Wahrscheinlichkeit geringer, dass Sie ihn häufiger ausführen.
- Unabhängig / isoliert (unabhängig). Tests sollten möglichst isoliert und unabhängig voneinander durchgeführt werden.
- Wiederholbar. Tests sollten in jeder Umgebung wiederholbar sein – Entwicklung, Staging und Produktion.
- Selbstvalidierend. Das Ergebnis des Tests muss ein boolescher Wert sein. Der Test muss entweder bestanden oder nicht bestanden werden.
- Gründlich. Wir sollten uns bemühen, alle Grenzfälle, alle Sicherheitsprobleme, jeden Anwendungsfall (Anwendungsfall) und jeden Happy Path (das günstigste Szenario für den Code) mit Tests abzudecken.
8. Umgang mit Fehlern und Ausnahmen
Jede von Ihnen ausgelöste Ausnahme sollte genügend Kontext bieten, um die Quelle und den Ort des Fehlers zu bestimmen. Normalerweise verfügen Sie über einen Stack-Trace einer Ausnahme, aber ein Stack-Trace verrät Ihnen nicht den Zweck des fehlgeschlagenen Vorgangs. Vermeiden Sie nach Möglichkeit die Übergabe von Null in Ihrem Code. Wenn Sie versucht sind, von einer Methode null zurückzugeben, sollten Sie stattdessen eine Ausnahme auslösen. Machen Sie die Fehlerbehandlung zu einer separaten Aufgabe, die unabhängig von der Hauptlogik angezeigt werden kann. Wie erreicht man das? Erstellen Sie informative Fehlermeldungen und geben Sie diese zusammen mit Ihren Ausnahmen weiter. Geben Sie den fehlgeschlagenen Vorgang und die Art des Fehlers an.9. Klassen
Die Klassen sollten klein sein. Aber es sind nicht die Codezeilen, die gezählt werden müssen, sondern die Verantwortung. Klassennamen sind der Schlüssel zur Beschreibung dessen, wofür sie verantwortlich sind. Unsere Systeme sollten aus vielen kleinen Klassen bestehen, nicht aus wenigen großen. Jede dieser kleinen Klassen muss eine einzelne Verantwortung umfassen. Für jede Klasse darf es nur einen bestimmten Grund geben, und jede Klasse muss mit mehreren anderen Klassen „kooperieren“, um das gewünschte Verhalten des Systems zu erreichen. Es gibt selten einen guten Grund, eine öffentliche Variable zu erstellen. Eine Schwächung der Kapselung ist immer der letzte Ausweg. Darüber hinaus sollten wenige Instanzvariablen vorhanden sein. Durch ein gutes Softwaredesign können Änderungen ohne große Investitionen oder Nacharbeiten vorgenommen werden. Durch die Eingrenzung des Variablenbereichs wird diese Aufgabe erleichtert. Wie erreicht man das? Die Trennung von Belangen ist eine der ältesten und wichtigsten Designtechniken. Der Unterricht sollte für Erweiterungen geöffnet, für Änderungen jedoch geschlossen sein. In einem idealen System ermöglichen wir neue Funktionen, indem wir das System erweitern, anstatt Änderungen am vorhandenen Code vorzunehmen.10. Formatierung
Jede leere Zeile ist ein visueller Hinweis, der dabei hilft, zu erkennen, dass ein neues, separates Konzept begonnen hat. Lokale Variablen müssen oben in der Funktion erscheinen. Instanzvariablen müssen am Anfang der Klasse deklariert werden. Kurze Schlangen sind besser als lange. Normalerweise liegt die Grenze bei 100-120 Zeichen; Sie sollten es nicht länger machen. Wie erreicht man das? Die meisten Parameter können an einen Linter in Ihrem CI oder Texteditor übergeben werden. Verwenden Sie diese Tools, um Ihren Code so sauber wie möglich zu gestalten.Grundsätze der Programmentwicklung
Verwenden Sie die folgenden Techniken, damit Ihr Code immer sauber bleibt: Benennen von Variablen. Die Wahl geeigneter Namen (gute Benennung) ist entscheidend, um den Code lesbar und damit wartbar zu machen. „Sie sollten einen Namen für eine Variable genauso verantwortungsbewusst wählen, wie Sie es für Ihren Erstgeborenen tun würden.“ Die Wahl guter Namen ist für Entwickler oft eine Herausforderung. Dies erfordert gute Beschreibungsfähigkeiten und einen gemeinsamen kulturellen Hintergrund. Unter Clean Code versteht man Code, der von ganz unterschiedlichen Entwicklern gelesen und verbessert wird. Der Name einer Variablen, Funktion oder Klasse sollte alle grundlegenden Fragen beantworten: Warum diese Entität existiert, was und wie sie verwendet wird. Wenn ein Name kommentiert werden muss, bedeutet dies, dass er das Wesentliche dessen, was er beschreibt, nicht ausreichend offenbart. Längere Namen sind wichtiger als kürzere und jeder durchsuchbare Name ist besser als eine Konstante. Einbuchstabige Namen können nur als lokale Variablen innerhalb kurzer Methoden verwendet werden: Die Länge des Namens muss mit dem Gültigkeitsbereich übereinstimmen. Methodennamen müssen Verben oder Verbphrasen sein; Der Klassenname darf kein Verb sein. Abhängigkeiten sollten auf ein Minimum beschränkt werden. Es ist besser, sich auf das zu verlassen, was man kontrolliert, als auf das, was man nicht kontrollieren kann. Sonst werden dich diese Dinge kontrollieren. Genauigkeit. Jedes einzelne Codestück sollte sich an der Stelle befinden, an der der Leser es erwartet. Die Navigation durch die Codebasis sollte intuitiv sein und die Absichten des Entwicklers sollten klar sein. Reinigung. Lassen Sie keinen nutzlosen Code in der Codebasis (alt und nicht mehr verwendet oder „nur für den Fall“ erstellt). Reduzieren Sie Doppelarbeit und erstellen Sie frühzeitig einfache Abstraktionen. Standardisierung. Beim Schreiben von Code sollten Sie den für das Repository festgelegten Stil und Praktiken befolgen. Selbstdisziplin. Während sich gebrauchte Technologien weiterentwickeln und neue auftauchen, haben Entwickler häufig den Wunsch, etwas am vorhandenen Code zu ändern und zu verbessern. Geben Sie dem Hype nicht zu schnell nach: Studieren Sie neue Stacks gründlich und nur für einen bestimmten Zweck. Um Ihre Codebasis sauber zu halten, geht es um mehr als nur Höflichkeit gegenüber Ihren aktuellen und zukünftigen Kollegen. Dies ist für das langfristige Überleben des Programms von entscheidender Bedeutung. Je sauberer Ihr Code, desto zufriedener sind die Entwickler, desto besser ist das Produkt und desto länger hält es.Warum Java für Systeme mit geringer Latenz besser als C++ ist
Quelle: StackOverflow Als Entwickler wissen wir alle, dass es zwei Möglichkeiten gibt, Dinge zu erledigen: manuell, langsam und nervig, oder automatisch, schwierig und schnell. Ich könnte künstliche Intelligenz nutzen, um diesen Artikel für mich zu schreiben. Das könnte mir viel Zeit sparen – die KI kann Tausende von Artikeln pro Sekunde generieren, aber mein Redakteur wäre wahrscheinlich nicht erfreut zu erfahren, dass es zwei Jahre dauern würde, bis der erste Artikel erstellt ist.
Eine ähnliche Situation ergibt sich bei der Entwicklung von Softwaresystemen mit geringer Latenz. Die gängige Meinung ist, dass es verrückt wäre, etwas anderes als C++ zu verwenden, weil alles andere zu viel Latenz hat. Aber ich bin hier, um Sie von der gegenteiligen, kontraintuitiven, fast ketzerischen Vorstellung zu überzeugen: Wenn es darum geht, in Softwaresystemen eine niedrige Latenz zu erreichen, ist Java besser. In diesem Artikel möchte ich ein konkretes Beispiel für Software nehmen, die Wert auf niedrige Latenzzeiten legt: Handelssysteme. Die hier vorgestellten Argumente können jedoch auf fast alle Umstände angewendet werden, in denen eine niedrige Latenz erforderlich oder gewünscht ist. Es ist einfach einfacher, in Bezug auf den Entwicklungsbereich zu diskutieren, in dem ich Erfahrung habe. Und die Wahrheit ist, dass die Latenz schwer zu messen ist. Es kommt darauf an, was Sie unter geringer Latenz verstehen. Lassen Sie uns das jetzt herausfinden.
Erworbene Weisheit
Da C++ viel näher an der Hardware liegt, werden Ihnen die meisten Entwickler sagen, dass das Codieren in dieser Sprache einen Geschwindigkeitsvorteil bietet. In Situationen mit geringer Latenz, wie z. B. beim Hochgeschwindigkeitshandel, wo Millisekunden den Unterschied zwischen einer funktionsfähigen Software und einer herkömmlichen Verschwendung von Speicherplatz ausmachen können, gilt C++ als Goldstandard. Zumindest war das früher so. Die Realität sieht jedoch so aus, dass viele große Banken und Broker mittlerweile in Java geschriebene Systeme verwenden. Und ich meine nativ in Java geschrieben, nicht in Java geschrieben und dann in C++ interpretiert, um die Latenz zu reduzieren. Diese Systeme werden selbst für erstklassige Investmentbanken zum Standard, obwohl sie (vermeintlich) langsamer sind. Was ist denn los? Ja, C++ hat möglicherweise eine „geringe Latenz“, wenn es um die Ausführung von Code geht, aber es ist definitiv keine niedrige Latenz, wenn es darum geht, neue Funktionen bereitzustellen oder sogar Entwickler zu finden, die ihn schreiben können.(Echte) Unterschiede zwischen Java und C++
Das Problem der Entwicklungszeit ist erst der Anfang, wenn es um die Unterschiede zwischen Java und C++ in realen Systemen geht. Um den wahren Wert jeder Sprache in diesem Zusammenhang zu verstehen, gehen wir etwas tiefer in die Materie ein. Zunächst ist es wichtig, sich an den wahren Grund zu erinnern, warum C++ in den meisten Situationen schneller als Java ist: Ein C++-Zeiger ist die Adresse einer Variablen im Speicher. Dies bedeutet, dass die Software direkt auf einzelne Variablen zugreifen kann und nicht rechenintensive Tabellen durchsuchen muss, um sie nachzuschlagen. Oder zumindest durch die Angabe, wo sie sich befinden, behoben werden, da Sie in C++ häufig die Lebensdauer und den Besitz von Objekten explizit verwalten müssen. Wenn Sie also nicht wirklich gut darin sind, Code zu schreiben (eine Fähigkeit, deren Beherrschung Jahrzehnte dauern kann), wird C++ Stunden (oder Wochen) des Debuggens erfordern. Und jeder, der schon einmal versucht hat, eine Monte-Carlo-Engine oder ein PDE-Testtool zu debuggen, wird Ihnen sagen, dass der Versuch, den Speicherzugriff auf grundlegender Ebene zu debuggen, sehr zeitaufwändig sein kann. Ein einziger fehlerhafter Zeiger kann leicht ein ganzes System zum Absturz bringen, daher kann die Veröffentlichung einer neuen, in C++ geschriebenen Version wirklich beängstigend sein. Das ist natürlich noch nicht alles. Leute, die gerne in C++ programmieren, werden darauf hinweisen, dass der Garbage Collector von Java unter nichtlinearen Latenzspitzen leidet. Dies gilt insbesondere bei der Arbeit mit Legacy-Systemen, sodass das Senden von Aktualisierungen an Java-Code, ohne Client-Systeme zu beschädigen, diese so langsam machen kann, dass sie unbrauchbar werden. Als Antwort möchte ich darauf hinweisen, dass im letzten Jahrzehnt viel Arbeit geleistet wurde, um die durch Java GC verursachte Latenz zu reduzieren. LMAX-Disruptorist beispielsweise eine in Java geschriebene Handelsplattform mit geringer Latenz, die ebenfalls als Framework aufgebaut ist, das eine „mechanische Interaktion“ mit der Hardware hat, auf der es läuft, und keine Sperre erfordert. Probleme können weiter gemildert werden, wenn Sie ein System aufbauen, das einen kontinuierlichen Integrations- und Bereitstellungsprozess (CI/CD) verwendet, da CI/CD die automatisierte Bereitstellung getesteter Codeänderungen ermöglicht. Dies liegt daran, dass CI/CD einen iterativen Ansatz zur Reduzierung der Garbage-Collection-Latenz bietet, bei dem Java schrittweise verbessert und an bestimmte Hardwareumgebungen angepasst werden kann, ohne dass der ressourcenintensive Prozess der Vorbereitung von Code für verschiedene Hardwarespezifikationen vor der Auslieferung erforderlich ist. Da die Java-Unterstützung der IDE viel umfassender ist als die von C++, ermöglichen die meisten Frameworks (Eclipse, IntelliJ IDEA) die Umgestaltung von Java. Dies bedeutet, dass IDEs Code für eine Leistung mit geringer Latenz optimieren können, obwohl diese Fähigkeit bei der Arbeit mit C++ immer noch begrenzt ist. Auch wenn Java-Code hinsichtlich der Geschwindigkeit nicht ganz mit C++ mithalten kann, fällt es den meisten Entwicklern immer noch leichter, in Java eine akzeptable Leistung zu erzielen als in C++.Was meinen wir mit „schneller“?
Tatsächlich gibt es gute Gründe zu bezweifeln, dass C++ wirklich „schneller“ ist oder sogar eine „geringere Latenz“ als Java aufweist. Mir ist klar, dass ich mich in ziemlich trübe Gewässer begebe und dass viele Entwickler beginnen werden, meinen Verstand in Frage zu stellen. Aber hör mir zu. Stellen wir uns diese Situation vor: Sie haben zwei Entwickler – einer schreibt in C++ und der andere in Java – und Sie bitten sie, eine Hochgeschwindigkeits-Handelsplattform von Grund auf zu schreiben. Daher benötigt ein in Java geschriebenes System mehr Zeit für den Abschluss von Handelstransaktionen als ein in C++ geschriebenes System. Allerdings weist Java weitaus weniger Fälle undefinierten Verhaltens auf als C++. Um nur ein Beispiel zu nennen: Die Indizierung außerhalb eines Arrays ist sowohl in Java als auch in C++ ein Fehler. Wenn Sie dies versehentlich in C++ tun, kann es zu einem Segfault oder (häufiger) zu einer Zufallszahl kommen. In Java löst das Überschreiten der Grenzen immer einen ArrayIndexOutOfBoundsException -Fehler aus . Das bedeutet, dass das Debuggen in Java wesentlich einfacher ist, da Fehler in der Regel sofort erkannt werden und der Ort des Fehlers leichter aufzuspüren ist. Darüber hinaus kann Java zumindest meiner Erfahrung nach besser erkennen, welche Codeteile nicht ausgeführt werden müssen und welche für den Betrieb Ihrer Software von entscheidender Bedeutung sind. Sie können natürlich Tage damit verbringen, Ihren C++-Code so zu optimieren, dass er überhaupt keinen überflüssigen Code enthält, aber in der realen Welt enthält jede Software etwas Aufgeblasenes, und Java ist besser darin, dies automatisch zu erkennen. Dies bedeutet, dass Java in der realen Welt oft schneller als C++ ist, selbst bei Standardlatenzmetriken. Und selbst wenn dies nicht der Fall ist, wird der Latenzunterschied zwischen den Sprachen oft durch andere Faktoren überlagert, die nicht groß genug sind, um selbst im Hochgeschwindigkeitshandel eine Rolle zu spielen.Vorteile von Java für Systeme mit geringer Latenz
All diese Faktoren sind meiner Meinung nach ein ziemlich überzeugendes Argument für die Verwendung von Java zum Schreiben von Hochgeschwindigkeits-Handelsplattformen (und Systemen mit niedriger Latenz im Allgemeinen, mehr dazu gleich). Um C++-Enthusiasten jedoch ein wenig zu überzeugen, schauen wir uns einige zusätzliche Gründe für die Verwendung von Java an:-
Erstens wird jede übermäßige Latenz, die Java in Ihre Software einführt, wahrscheinlich viel geringer sein als andere Faktoren, die sich auf die Latenz auswirken – wie etwa Internetprobleme. Das bedeutet, dass jeder (gut geschriebene) Java-Code in den meisten Handelssituationen problemlos genauso gut funktionieren kann wie C++.
-
Die kürzere Entwicklungszeit von Java bedeutet auch, dass sich in der realen Welt in Java geschriebene Software schneller an Hardwareänderungen (oder sogar neue Handelsstrategien) anpassen kann als C++.
-
Wenn Sie sich eingehender damit befassen, werden Sie feststellen, dass sogar die Optimierung von Java-Software schneller sein kann (wenn man sie über die gesamte Software hinweg betrachtet) als eine ähnliche Aufgabe in C++.
GO TO FULL VERSION