Ein guter Programmierer muss in der Lage sein, seine Fähigkeiten mit gesundem Menschenverstand zu kombinieren. Es geht um Pragmatismus und die Fähigkeit, die beste Lösung für Ihr Problem zu finden. Wenn Sie mit einem Problem in der Softwareentwicklung konfrontiert sind, können Sie anhand von Grundprinzipien den richtigen Ansatz auswählen.
Dieser Text enthält eine Reihe von Grundsätzen, die jeder Entwickler kennen und die regelmäßig aktualisiert werden sollten. Betrachten Sie sie als Ihre geheime Programmierwaffe.
Die konsequente Anwendung dieser Grundsätze erleichtert Ihnen den Übergang von der mittleren zur höheren Klasse. Sie können feststellen, dass einige (wahrscheinlich) Sie intuitiv verwenden.
Es gibt viele Prinzipien. Wir werden uns auf die sieben wichtigsten konzentrieren. Wenn Sie sie verwenden, können Sie wachsen und ein besserer Programmierer werden.
1. YAGNI
Sie werden es nicht brauchenDieses Prinzip ist einfach und offensichtlich, aber nicht jeder folgt ihm. Wenn Sie Code schreiben, stellen Sie sicher, dass Sie ihn benötigen. Schreiben Sie keinen Code, wenn Sie glauben, dass er später nützlich sein wird.
Dieses Prinzip gilt für das Refactoring. Wenn Sie eine Methode, Klasse oder Datei umgestalten, haben Sie keine Angst, unnötige Methoden zu entfernen. Auch wenn sie vorher nützlich waren, werden sie jetzt nicht mehr benötigt.
Der Tag kann kommen, an dem sie wieder benötigt werden - dann können Sie das Git-Repository verwenden, um sie von den Toten wiederzubeleben.
2. TROCKEN
Wiederholen Sie sich nichtDieses Konzept wurde erstmals in Andy Hunt und Dave Thomas 'Buch The Pragmatic Programmer: Die Reise vom Lehrling zum Meister formuliert.
Die Idee dreht sich um eine einzige Quelle der Wahrheit (SSOT). Was ist das überhaupt?
Im Entwurf und in der Theorie von Informationssystemen ist die Single Source of Truth (SSOT) die Praxis der Strukturierung von Informationsmodellen und Datenschemata, was impliziert, dass alle Daten an nur einem Ort verarbeitet (oder bearbeitet) werden ... SSOTs bieten zuverlässige, relevante und verwendbare Daten.
- Wikipedia
Durch die Verwendung von SSOT wird eine robustere und verständlichere Codebasis erstellt.
Das Duplizieren von Code ist eine Verschwendung von Zeit und Ressourcen. Sie müssen dieselbe Logik beibehalten und den Code an zwei Stellen gleichzeitig testen. Wenn Sie den Code an einer Stelle ändern, müssen Sie ihn an einer anderen Stelle ändern.
In den meisten Fällen tritt eine Codeduplizierung aufgrund von Unkenntnis des Systems auf. Seien Sie pragmatisch, bevor Sie etwas schreiben: Schauen Sie sich um. Vielleicht ist diese Funktion irgendwo implementiert. Vielleicht existiert diese Geschäftslogik woanders. Die Wiederverwendung von Code ist immer eine kluge Entscheidung.
3. KUSS
Halte es einfach, dummDieses Prinzip wurde 1960 von der US Navy entwickelt. Dieses Prinzip besagt, dass einfache Systeme eine bessere und zuverlässigere Leistung erbringen.
Dieses Prinzip hat viel mit der Neuerfindung des Rades zu tun, die in den 1970er Jahren durchgeführt wurde. Dann klang es wie eine Geschäfts- und Werbemetapher.
In Bezug auf die Softwareentwicklung bedeutet dies Folgendes: Lassen Sie sich keine komplexere Lösung für das Problem einfallen, als es benötigt.
Manchmal stellt sich heraus, dass die klügste Entscheidung die einfachste ist. Das Schreiben von effizientem, effizientem und einfachem Code ist großartig.
Einer der häufigsten Fehler unserer Zeit ist die Verwendung neuer Werkzeuge nur, weil sie glänzen. Entwickler sollten motiviert sein, die neueste Technologie zu verwenden, nicht weil sie neu ist, sondern weil sie für den Job geeignet ist.
4. Großes Design vorne
Globales Design zuerstDieser Ansatz zur Softwareentwicklung ist sehr wichtig und wird oft übersehen. Stellen Sie sicher, dass alles gut durchdacht ist, bevor Sie mit der Implementierung fortfahren.
… . , . , . , BDUF, , . , .
—
Viele Entwickler glauben, dass sie keine Fortschritte machen, wenn sie keinen Code schreiben. Dies ist der falsche Ansatz. Wenn Sie einen Plan erstellen, ersparen Sie sich die Mühe, immer wieder von vorne zu beginnen.
Manchmal müssen andere Menschen in die Mängel und Prozesse der Architekturentwicklung involviert sein. Je früher Sie all dies besprechen, desto besser wird es für alle sein.
Ein sehr häufiges Gegenargument ist, dass die Kosten für die Lösung von Problemen oft geringer sind als die Kosten für die Planungszeit. Je weniger Fehler der Benutzer hat, desto besser ist die Erfahrung. Möglicherweise haben Sie keine weitere Chance, diese Fehler zu beheben.
5. FEST
Dies ist das bekannteste Prinzip der Softwareentwicklung. Solid ist eine Abkürzung für:
S) Prinzip der Einzelverantwortung
Seine Bedeutung kann nicht überbetont werden. Jedes Objekt, jede Klasse und jede Methode sollte nur für eine Sache verantwortlich sein. Wenn Ihr Objekt / Ihre Klasse / Ihre Methode zu viel bewirkt, erhalten Sie Spaghetti-Code. Hier ist ein Beispiel:
const saveTodo = async () => {
try {
response = await saveTodoApi();
showSuccessPop('Success');
window.location.href = '/successPage';
} catch (error) {
showErrorPopup(`Error: ${error} `);
}
}
Diese Methode scheint harmlos, aber sie macht tatsächlich zu viel:
- Speichert das Objekt
- Behandelt Benachrichtigungen in der Benutzeroberfläche
- Führt die Navigation durch
Ein weiterer Nebeneffekt dieses Codes ist das Testen von Problemen. Komplizierte Funktionen sind schwer zu testen.
O) Open-Closed-Prinzip
Programmobjekte sollten zur Erweiterung geöffnet, aber zur Änderung geschlossen sein. Der Punkt ist, dass Sie Methoden oder Klassen nicht überschreiben können, indem Sie einfach nach Bedarf zusätzliche Funktionen hinzufügen.
Ein guter Weg, um dieses Problem zu lösen, ist die Verwendung der Vererbung. JavaScript löst dieses Problem mit der Komposition.
Eine einfache Faustregel: Wenn Sie eine Entität ändern, um sie erweiterbar zu machen, brechen Sie dieses Prinzip zum ersten Mal.
L) Liskov-Substitutionsprinzip
Dieses Prinzip besagt, dass Objekte höherer Klassen durch Objekte von Unterklassen ersetzt werden können und dass die Anwendung wie erwartet ausgeführt werden sollte, wenn solche Ersetzungen vorgenommen werden.
I) Prinzip der Schnittstellentrennung
Dieses Prinzip wurde von Robert Martin formuliert, als er Xerox konsultierte, und es ist offensichtlich.
Objekte sollten nicht von Schnittstellen abhängen, die sie nicht verwenden
Die Software sollte in unabhängige Teile unterteilt werden. Nebenwirkungen müssen minimiert werden, um die Unabhängigkeit zu gewährleisten.
Stellen Sie sicher, dass Sie Objekte nicht zwingen, Methoden zu implementieren, die sie nie benötigen. Hier ist ein Beispiel:
interface Animal {
eat: () => void;
walk: () => void;
fly: () => void;
swim: () => void;
}
Nicht alle Tiere können fliegen, gehen oder schwimmen, daher sollten diese Methoden nicht Teil der Benutzeroberfläche sein oder optional sein.
D) Prinzip der Abhängigkeitsinversion
Dieses Prinzip kann nicht überbetont werden. Wir müssen uns auf Abstraktionen verlassen, nicht auf konkrete Implementierungen. Softwarekomponenten sollten eine geringe Kohäsion und eine hohe Konsistenz aufweisen.
Sie müssen sich nicht darum kümmern, wie etwas funktioniert, sondern darum, wie es funktioniert. Ein einfaches Beispiel ist die Verwendung von Datumsangaben in JavaScript. Sie können für sie Ihre eigene Abstraktionsschicht schreiben. Wenn Sie dann die Quelle für das Abrufen von Daten ändern, müssen Sie Änderungen an einem Ort und nicht an tausend vornehmen.
Manchmal ist es mühsam, diese Abstraktionsebene hinzuzufügen, aber es zahlt sich am Ende aus.
Schauen Sie sich als Beispiel date-io an . Diese Bibliothek verfügt über eine Abstraktionsebene, mit der Sie sie mit verschiedenen Datumsquellen verwenden können.
6. Vermeiden Sie vorzeitige Optimierung
Vermeiden Sie vorzeitige OptimierungDiese Vorgehensweise ermutigt Entwickler, ihren Code zu optimieren, bevor sich die Optimierung als notwendig erwiesen hat. Ich denke, wenn Sie KISS oder YAGNI folgen, werden Sie nicht in diesen Haken fallen.
Machen Sie es richtig, es ist gut zu erwarten, dass etwas Schlimmes passieren wird. Bevor Sie sich jedoch mit den Implementierungsdetails befassen, stellen Sie sicher, dass diese Optimierungen wirklich nützlich sind.
Ein sehr einfaches Beispiel ist die Skalierung. Sie werden keine 40 Server kaufen, vorausgesetzt, Ihre neue Anwendung wird sehr beliebt. Sie werden nach Bedarf Server hinzufügen.
Eine vorzeitige Optimierung kann zu Verzögerungen im Code führen und daher die Zeit verlängern, die erforderlich ist, um Funktionen auf den Markt zu bringen.
Viele betrachten vorzeitige Optimierung als die Wurzel allen Übels.
7. Occams Rasiermesser
Brithva Okkama (manchmal Lezvie Okkama) ist ein methodisches Prinzip, das kurz sagt: „Sie sollten Dinge nicht unnötig multiplizieren“ [1] (oder „Sie sollten keine neuen Entitäten anziehen, es sei denn, dies ist absolut notwendig“).
- Wikipedia
Was bedeutet das in der Programmierwelt? Erstellen Sie keine unnötigen Entitäten. Seien Sie pragmatisch - überlegen Sie, ob sie benötigt werden, da sie Ihre Codebasis möglicherweise komplizieren.
Fazit
Diese Prinzipien sind nicht sehr schwierig. In der Tat ist es die Einfachheit, die sie schön macht. Wenn Sie verwirrt sind, versuchen Sie nicht, alle auf einmal anzuwenden. Versuchen Sie einfach, bewusst zu arbeiten und diese Prinzipien schrittweise in Ihren Workflow zu integrieren.
Die Verwendung grundlegender und dennoch leistungsfähiger Prinzipien ermöglicht es Ihnen, ein besserer Programmierer zu werden und ein klareres Verständnis dafür zu haben, warum Sie etwas tun.
Wenn Sie die meisten Prinzipien intuitiv anwenden, lohnt es sich zu überlegen und zu verstehen, warum Sie etwas auf eine bestimmte Weise tun.
Alles Gute.
- Russlands erstes serielles Steuerungssystem für einen Zweistoffmotor mit funktionaler Trennung der Steuerungen
- In einem modernen Auto gibt es mehr Codezeilen als ...
- - Automotive, Aerospace, (50+)
- McKinsey: automotive
