6. Das Rad nicht neu erfinden
Programmieren macht Spaß. Als Ingenieure neigen wir dazu, für fast alles unsere eigenen Lösungen zu schreiben, denn wir lieben es, Probleme zu lösen. Das ist jedoch nicht immer sinnvoll. Man sollte versuchen, andere Frameworks, Tools und Dienste zu nutzen und sich auf die Lösung des eigenen Problems zu konzentrieren. Es gibt bereits so viel großartige Software, die man nutzen kann – meist sogar kostenlos. Man sollte sie nutzen! Jede Zeile Code, die man nicht schreibt, muss man auch nicht pflegen.
7. Weniger Abhängigkeiten verwenden
Umgekehrt sollte man nicht für alles ein Paket hinzuziehen oder einen anderen Anbieter verwenden. Wenn es eine sehr einfache Lösung für ein Problem gibt, sollte man nicht zu viel Overhead hinzufügen, indem man eine externe Abhängigkeit verwendet. Es gibt tatsächlich npm-Pakete, die eine einzige Funktion bereitstellen. Man sollte Pakete nicht übermäßig verwenden. Es ist notwendig zu erkennen, wann es sinnvoll ist, einen Dienst oder ein Paket eines Drittanbieters zu verwenden, anstatt eigenen Code zu schreiben.
8. Selbsterklärende Namen verwenden
Wie bereits in „Konsistent sein“ erwähnt, ist es wichtig, selbsterklärende, einfache Namen für die gesamte Codebasis zu verwenden. Es sollten keine unnötigen Abkürzungen verwendet werden. Man sollte keine willkürlichen Namen verwende. Guter Code liest sich wie ein Buch. Er ist leicht zu verstehen, leicht zu pflegen und es macht Spaß, mit ihm zu arbeiten.
Dies gilt für:
- Dateien
- Funktionen
- Variablen
- Parameter
— SCHLECHT
// What does this mean?
const maxMbs = 10
// Get orders from where/whom?
const getOrders = (id: string) => {
...
}
// Matching what?
const matchingOrders = orders.filter(x => x.status === 'fulfilled')
+++ GUT
const fileSizeLimitMb = 10
const getOrdersByUserId = (userId: string) => {
...
}
const unfulfilledOrders = orders.filter(o => o.status !== 'fulfilled')
9. Nicht übertreiben (YAGNI)
In der Programmierung gibt es einen Grundsatz namens „YAGNI“ (You ain’t gonna need it), der besagt, dass Funktionen nur dann hinzugefügt werden sollten, wenn sie als notwendig erachtet werden. Dies sollte man immer im Hinterkopf behalten. Man implementiert neue Funktionen nur dann, wenn man sie tatsächlich braucht, und nicht, wenn man glaubt, dass man sie in der Zukunft brauchen wird. Denn höchstwahrscheinlich wird man sie nie brauchen. auch sollte man eine Funktion nicht auf die komplexeste Weise bauen. Abstraktion kann großartig sein, wenn sie sinnvoll ist, aber sie kann auch eine echte Qual sein, wenn man sie gedankenlos einsetzt. Es ist daran zu denken, dass jeder neue Code gewartet werden muss, daher ist es besser, nur Code hinzuzufügen, der tatsächlich benötigt wird. Andernfalls entsteht nur zusätzlicher Overhead, der keinen Nutzen bringt.
10. Duplizierung/Redundanz vermeiden
Es gibt auch einen Grundsatz namens „DRY“ (Don’t repeat yourself), der besagt, dass man Redundanz (kein doppelter Code, eine einzige Quelle der Wahrheit) um jeden Preis vermeiden sollte. Dies gilt für Code, Daten und Kommentare.
- Keinen Code kopieren oder duplizieren
- Daten nicht redundant speichern
- Keine Kommentare hinzufügen, die keinen Kontext liefern
Es ist besser, sauberen, vernünftigen Code zu schreiben und auf Kommentare zu verzichten, als weniger lesbaren Code zu schreiben und Kommentare hinzuzufügen. Außerdem ist die Duplizierung von Code eines der schlimmsten Dinge, die man tun kann. Wann immer man einen Teil des Codes wieder verwenden muss, extrahiert man ihn in eine separate Datei/Modul/Funktion, je nachdem, welche Programmiersprache man verwendet.