Wie der legendäre Schriftsteller Jules Verne zu Recht bemerkte: "Ein gut genutztes Minimum ist völlig ausreichend." In unserer Zeit gilt das Konzept eines gut genutzten Minimums für Code. Traurig aber wahr: In der modernen Welt des Codes gibt es zu viel. Genauer gesagt gibt es zu viel unnötigen Code, unter dem der nützliche Code einfach erstickt.
In Anbetracht dessen ist unnötiger Code standardmäßig böse. Es verschlechtert sich mit der Zeit. Es erfordert fortlaufende Unterstützung. Es enthält Fehler, nach denen Sie suchen müssen. Wenn neue Funktionen angezeigt werden, muss der alte Code an diese angepasst werden. Je mehr Code Sie haben, desto mehr Fehler können darin enthalten sein. Je länger die Überprüfung oder Kompilierung dauert, desto länger versteht der neue Mitarbeiter Ihr System.
Und obendrein wird Code von Programmierern geschrieben. Je mehr es ist, desto mehr Programmierer werden benötigt. Mit zunehmender Anzahl von Programmierern steigen auch die Kommunikationskosten zwischen ihnen, was weiter zu den Kosten für die Entwicklung und Wartung des Codes beiträgt.
Für all diese Probleme gibt es eine Lösung: Schreiben Sie weniger Code. Dieser Ansatz hat viele Vorteile:
- Weniger Code zum Entwickeln = weniger Entwicklungskosten
- Weniger Code in der Entwicklung = weniger Wartungskosten
- Weniger Code in der Entwicklung = weniger Fehler
- Weniger zu entwickelnder Code = effizienteres Testen
Und vor allem: Je weniger Code Sie zum Lesen zwingen, desto größer ist die Wahrscheinlichkeit, dass jemand ihn überhaupt liest.
Hier sind einige Möglichkeiten, wie Sie den Code reduzieren können.
Das YAGNI-Prinzip („Du brauchst es nicht“)
Das Prinzip "Du brauchst es nicht" (es wird oft als YAGNI bezeichnet - du wirst es nicht brauchen) bedeutet die folgende extreme Programmierregel: "Verwirkliche diese oder jene Gelegenheit nur, wenn sie wirklich gebraucht wird und nicht, wenn du annimmst dass sie bald gebraucht wird. “ Auch wenn Sie hundertprozentig sicher sind, dass diese Funktion in Zukunft nicht mehr ausgeführt werden kann, beginnen Sie jetzt nicht mit der Implementierung.
Es gibt zwei Gründe für diese Praxis:
- Sie sparen Zeit, indem Sie sich weigern, Code zu schreiben, der derzeit nicht benötigt wird.
- Die Qualität des Codes verbessert sich - Sie verschmutzen ihn nicht mit Fragmenten, die auf mehr oder weniger korrekten Vermutungen beruhen, und verbleiben in der Codebasis, auch wenn diese Vermutungen nicht bestätigt werden.
Das Konzept von YAGNI ist durchaus vernünftig, unabhängig davon, an welche Projektmanagementmethode Sie sich halten. Gute Architektur erfordert ein ausgewogenes Verhältnis der Möglichkeiten. Eine schlechte Architektur besteht aus einer Reihe von skizzierten Funktionen, die eine Codebasis generieren, deren Unterstützung Sie gequält werden.
Die Grundregel lautet hier: Konzentrieren Sie sich auf das, was eindeutig benötigt wird, und denken Sie nicht darüber nach, was wahrscheinlich passieren wird.
Schreiben Sie keinen unverwundbaren Code
Ein unverwundbarer Code ist ein idealer Code, ein Code, der unter allen Eingabedaten und unter allen Bedingungen funktioniert. Die Idee, etwas Ähnliches zu schaffen, hat ihren eigenen Reiz, insbesondere für ehrgeizige Entwickler, die das Scheitern in einem bestimmten Szenario als persönliche Beleidigung empfinden. Das Schreiben (oder der Versuch, unverwundbaren Code zu schreiben) ist jedoch eine leere Idee, da alles auf der Welt seine eigenen Grenzen hat und Code keine Ausnahme darstellt.
Wenn Sie versuchen, das ideale Modul zu implementieren, werden Sie zusätzliche Bedingungen vorschreiben, wodurch die Codebasis komplexer wird, was dem eigentlichen Zweck des Codes zuwiderläuft. Das Modul wird im Laufe der Zeit immer umfangreicher, verbraucht mehr Ressourcen und wird ein Kandidat für unachtsame Wartung.
Wenn Sie weniger Code schreiben möchten, sollten Sie daher eine möglichst einfache Implementierung aus der Kategorie "Wenn es nur funktioniert" anstreben.
Der Extreme Programming Guide erwähnt zwei goldene Regeln für das Schreiben von einfachem Code:
- Implementieren Sie zunächst die neue Funktionalität auf die primitivste Art und Weise, die nur funktionieren kann. Stellen Sie keine atemberaubenden Aufbauten auf, verfeinern Sie sich nicht - stellen Sie nur sicher, dass alles beginnt. Stellen Sie sicher, dass der Code Unit-Tests für neue Funktionen (und wie immer auch für alte) besteht.
- Dann - und dies ist ein kritischer Teil der Regel - überarbeiten Sie das System und vereinfachen Sie den Code so weit wie möglich für alle Funktionen, die derzeit im Produkt enthalten sind. Befolgen Sie das DRY-Prinzip und andere Prinzipien, die dazu beitragen, das System aufgeräumter zu machen.
Vergessen Sie nicht: Wir streben nicht nach dem kürzesten Weg, sondern nach dem einfachsten Ergebnis.
Dementsprechend teilen wir zunächst die bestehende Methode in mehrere Teile. In diesem Fall funktionieren die Testoptionen ohne Fehler. Dann ändern wir (in Richtung der Vereinfachung) eine der resultierenden kleinen Methoden mit Blick auf die nächste Testoption und so weiter.
Denken Sie daran, dass Einfachheit das Herzstück von Eleganz ist. Die Fähigkeit, unnötige Komplexität zu kontrollieren und zu beseitigen, ist meisterhafte Programmierung.
Machen Sie den Code nicht schlechter
Diese Regel kann als hippokratischer Eid für Entwickler angesehen werden. Diejenigen, die an der Programmierung beteiligt sind, hören ständig Tipps, keine Ecken zu schneiden und nicht nach Problemumgehungen zu suchen, die den Code beschädigen und zu dessen Verschlechterung führen können.
Softwareentwicklungsverfahren beinhalten wie medizinische Verfahren häufig grobe Störungen und zerstörerische Maßnahmen. Darüber hinaus sind die von uns verwendeten Tools und Techniken häufig neu und nicht verifiziert (oder unzureichend verifiziert). Darüber hinaus haben wir kein Analogon des Medical Licensing Council oder des Office of Product Control, das die von uns gewählten Praktiken und Entwicklungsinstrumente regeln würde. Daher setzen wir unseren Patienten, dh Software, manchmal Verfahren aus, die mit unnötigen Risiken verbunden sind, und verstehen diese Risiken nicht einmal vollständig.
Manchmal tun wir bei der Behebung eines Problems mehr Schaden als Nutzen. In seinem Buch „Perfect Code“, das Teil der goldenen Literatur für Programmierer ist, schreibt Steve McConnell, dass Sie, wenn Sie nicht an der Wurzel des Problems, sondern an seinem Symptom arbeiten, die Situation nur verschlechtern - Sie täuschen sich selbst und erzeugen die Illusion, dass das Problem gelöst ist .
Manchmal kann es jedoch sehr schwierig sein, diese Regel einzuhalten. Manchmal befindet sich veralteter Code in einem solchen Zustand, dass es praktisch unmöglich ist, neue Funktionen ordnungsgemäß zu implementieren, ohne sie zu beschädigen. Um realistischer zu sein, müssen Sie die Regel daher ein wenig umformulieren: von "Machen Sie den Code nicht schlechter" bis "Wenn Sie die Qualität des Codes verschlechtern, müssen Sie sich dessen bewusst sein, was Sie tun."
Genau so. Wenn Sie keine Möglichkeit sehen, die erforderlichen Funktionen zu implementieren und den Code nicht zu verderben, warnen Sie andere Teammitglieder, bevor Sie Änderungen vornehmen. Die Quintessenz ist, dass Sie in diesem Fall die Qualität des Codes absichtlich verschlechtern.
Natürlich wird dies schlechten Code nicht verbessern, aber auf diese Weise haben Sie Zeit, über die Situation nachzudenken. Die Erfahrung zeigt, dass Menschen oft nicht die optimale Lösung erreichen, nur weil sie bereit sind, die allererste Idee zu akzeptieren, die ihnen in den Sinn kommt. Beachten Sie, dass Sie nicht um Erlaubnis bitten oder bei der Suche nach der besten Lösung helfen müssen.
Ein weiterer Vorteil dieser Methode ist, dass sie die Wahrscheinlichkeit unangenehmer Überraschungen in schlechten Zeiten verringert - das gesamte Team weiß, mit welchen Problemen zu rechnen ist. Dank dieser Funktion können Sie im wahrsten Sinne des Wortes in einem Team arbeiten und diese Situation rechtzeitig bewältigen.
Vermeiden Sie übermäßige Parallelität
Parallelität ist ein zweischneidiges Schwert. Es sollte nur dann darauf zurückgegriffen werden, wenn Sie nicht darauf verzichten können.
Wenn der Code nacheinander ausgeführt wird, ist es einfacher, Fehler zu verstehen und zu suchen. Bei Verwendung der Parallelität werden Vorgänge entweder gleichzeitig oder in verzerrter Reihenfolge ausgeführt. Diese spezielle Implementierung verursacht viele Probleme beim Erkennen und Beheben von Fehlern. Offensichtlich erschwert es die Architektur und Implementierung von Funktionen gleichzeitig auf mehreren Ebenen. Hier sind einige Probleme, die eine schlecht implementierte Parallelität verursachen kann:
- Rennbedingung: Der Betrieb beginnt unvorhersehbar
- Gegenseitiges Blockieren: Beteiligte Objekte blockieren sich gegenseitig, während sie auf den Abschluss gleichzeitiger Vorgänge warten
- Mangel an Ressourcen: Der Vorgang erhält stabil keinen Zugriff auf die erforderliche Ressource, die er erwartet
Eine der bekanntesten Katastrophen im Zusammenhang mit der Softwareentwicklung wurde genau durch falsch vorgeschriebene voneinander abhängige Bedingungen verursacht. Ein Programmierfehler mit Therac-25, einem Strahlentherapiegerät, führte zum Tod von vier Personen.
Es ist zu beachten, dass die meisten modernen Programmiersprachen und Frameworks spezielle Tools zum Debuggen von Parallelität bieten. Letztendlich hängt alles vom Entwickler ab - er entscheidet, wann, wo und wie er sie anwendet, um das beste Ergebnis zu erzielen.
Nicht auf Horten stoßen
Pathologisches Horten ist eine Art von Verhalten, das durch das Sammeln einer großen Anzahl unnötiger Dinge und die mangelnde Bereitschaft, sie loszuwerden, gekennzeichnet ist. Dinge können jedoch den größten Teil des Wohnraums einnehmen, was zu Verletzungen und Stress führen kann.
Wenn bei Entwicklern die Akkumulationssymptome auftreten, klammern sie sich an jeden Code, selbst wenn dieser bereits veraltet ist oder voller Fehler steckt. Solche Entwickler löschen den Code niemals selbst und lehnen diese Praxis im Allgemeinen ab. Wenn Sie ihnen direkt davon erzählen, erhalten Sie Antworten im Geiste: "Er könnte eines Tages gebraucht werden" oder "Ohne dies kann ich Operation X nicht ausführen" und so weiter.
Hat Sie das Plyushkin-Syndrom jemals angegriffen? Vielleicht haben Sie die Idee, die Dinge in Ordnung zu bringen, aufgegeben, weil Sie verstehen, dass Sie einfach nicht genug Zeit haben, um all dieses Durcheinander herauszufinden? Wenn ja, dann leiden Sie immer noch unter Horten und es herrscht völliges Chaos in Ihrem Arbeitsleben.
Sparen ist irrational. Wenn Ihnen das Vorhandensein eines Codes gerechtfertigt erscheint, Sie sich jedoch nicht ganz sicher sind, markieren Sie ihn entsprechend, damit Sie später darauf zurückgreifen können. So wird es nicht aus Ihrem Gedächtnis fallen. Was den Code betrifft, der keinen bestimmten Zweck erfüllt und nicht lebenswichtig ist, muss er gelöscht werden und der Punkt.
Ein guter Programmierer arbeitet daran, den Code Tag für Tag zu verbessern, und im Laufe der Zeit wächst die Qualität des Codes stetig. Veralteter Code, der von einem guten Programmierer geschrieben wurde, zeichnet sich immer durch seine Genauigkeit aus - Profis hinterlassen kein Chaos nach sich selbst; Schließlich ist der Code unser Ruf und sie werden es sein, die uns danach beurteilen. Wie Robert Martin zu Recht sagte: "Wahrheit kann nur im Code gefunden werden."