Dieses Prinzip besagt, dass Programmcode in der Regel so geschrieben werden soll, dass er in erster Linie für Menschen gut lesbar ist.
Es ist zwischen zwei Kategorien von falschem Eifer zu unterscheiden:
Zu frühe Resourcen-Optimierung
Erst nachdem sich in der Praxis die wirklich optimierungsbedürftigen Stellen (Hotspots) zeigen, werden diese Stück für Stück optimiert; aber auch hier eher zaghaft als voller Tatendrang.
Wenn ein Entwickler im „Flow“ ist, sich völlig eins fühlt mit dem fachlichen Problem, die technische Umgebung komplett verstanden und unter Kontrolle hat, dann ist nicht selten zu beobachten, dass hervorragender, „genialer“ Code entsteht: Code, der besonders performant und Resourcen-schonend funktioniert und das letzte Quäntchen aus der Maschine herauskitzelt. Es wird massiv gecached, externe Bibliotheken gepatcht, mit dem Interpreter/Compiler getrickst, auf eine spezielle Zielplattform optimiert und/oder SQL-Hints eingebaut…
Aber irgendwann folgt die Ernüchterung: Einerseits ist dieser Code bei weitem nicht so performancerelevant wie anfangs gedacht, andererseits versteht ihn kaum noch jemand. Eine fachliche Änderung bereitet nun viel mehr Aufwand als wenn der Code einfach nur so geschrieben worden wäre wie es sich der Otto Normalentwickler vorstellt, dass er ablaufen müsste.
Der LessCoder hakt den Task früher ab. Dafür hat er später die Zeit übrig, wenn die Praxis zeigt, dass es auch wirklich notwendig ist, sich um dessen Optimierung zu kümmern.
Nicht an dem Anwender orientiertes API-Design
Insbesondere beim Design von APIs wird gerne vergessen, dass die Zeit der Entwickler, die sich mit der API später beschäftigen müssen/dürfen, meist das wertvollere Gut ist, als einige weitere vom API-Designer entwickelte Komfort-Funktionen.
Die beste API ist die, bei der ein Zugriff mit einfachen, aber zahlreichen Grundfunktionen möglich ist, und alternativ mit zusätzlichen weitere Funktionen auf höherem Niveau, die die typischen Usecases mit sinnvoll vorbelegten Werten aufrufen lassen.
Wer in Java einen String aus einer Textdatei einlesen möchte, schafft das mit reinen JDK-Methoden kaum in weniger als 10 Zeilen Code und nur unter Zuhilfenahme von 4 oder 5 verschiedenen nicht gerade einfachen Klassen wie FileInputStream usw. Natürlich gibt es dafür externe Bibliotheken wie die Commons IO API, aber man fragt sich trotzdem, warum einiger dieser immer wieder gebrauchten Standardfunktionen nicht von vornherein im JDK seinen Platz fanden?
