Eine kleine Rezension des Buches über zwanzig Jahre Exposition wurde
bereits 2016 geschrieben und mit Mikrokorrekturen veröffentlicht.
Das ursprüngliche Geständnis des Autors heißt „Zen of Windows 95 Programming“. Haben Sie keine Angst vor der Zahl "95", die Haupthandlung ist Zen und nicht die sich schnell ändernden Versionsnummern des Hauptbetriebssystems der letzten Jahrzehnte. Das Buch enthält eine Reihe von Empfehlungen und Vorgehensweisen für einen vertikalen (Full-Stack-) Entwickler, die es ermöglichen, nicht nur in der Welt der modernen Programmierung zu überleben, sondern auch das Ergebnis der erforderlichen Qualität zu erzielen.
Auf S. 22 definiert Lou den typischen Leser: „Der Eiferer der Qualität“. Für diejenigen, die im Leben mit der Arbeit nach der Methode "Tyap-Lyap-Inbetriebnahme" ("x * yak-x * yak und Produktion") recht zufrieden sind, ist es unwahrscheinlich, dass das Buch hilft.
Ist das Buch veraltet? Zu Beginn wurde 1995-96 eine rasche Änderung der Szene beschrieben, als Windows 95 (in geringerem Maße NT) weit verbreitet wurde. Die Programmierschnittstellen (APIs) änderten sich geringfügig weniger als vollständig, während es sich als notwendig herausstellte, die Funktionalität ihrer Programme in drei Versionen gleichzeitig aufrechtzuerhalten Microsoft-Betriebssysteme. Zu dieser Zeit war Lou Greenaw selbst dreißig Jahre alt (S. 87).
Jemand, der sich über die raschen Veränderungen in der modernen Technologie beschwert? Dies geschah vor 25 Jahren beim Wechsel von DOS zu Windows und vor 20 Jahren beim Wechsel von 16-Bit-Systemen zu 32-Bit-Systemen. Im Vergleich zu 1995 war die derzeitige lange Migration zu 64-Bit-Architekturen der Höhepunkt der Korrektheit in Bezug auf Anwendungsprogrammierer, die durch viele Schichten von Abstraktionen und virtuellen Maschinen von der inneren Küche der Transformationen abgegrenzt wurden.
Der Autor verpasst keine Gelegenheit, über das Wesentliche des Programmierens zu sprechen und es in das "
Handwerk der Verwendung einer Vielzahl von Werkzeugen zur Schaffung von Abstraktionsebenen und deren Anwendung zur Lösung logischer Probleme " zu schreiben. Es scheint, dass was sonst noch für das Handwerk benötigt wird, wenn nicht ein gutes Kochbuch? Lou kündigt jedoch sofort an (S. 20), dass sein Ansatz darin besteht, „
mehr darüber zu sprechen, was Sie nicht tun sollten “ und „
sich darauf zu verlassen, dass Sie unabhängig beurteilen, wie dieser oder jener Rat anzuwenden ist “. Ein wenig weiter (S. 48) unterteilt Programmierer in „Mathematiker“ und „Juweliere“.
Das heißt, wie ein Handwerk. Aber nicht wirklich. Und manchmal überhaupt nicht. In meinem
Buch habe ich Software-Engineering als "
eine vielseitige Legierung von Technologien definiert, die sowohl von Amateuren technischer Kreativität als auch von Massenproduktionsprofis nach Mustern und Präzedenzfällen verwendet werden kann ". Ich bestehe jedoch nicht auf der Interpretation. Die Programmierung ist so umfangreich, dass jeder auf Wunsch sehen und in ihm sein kann, was er will.
Im einleitenden Teil diskutiert Lou pragmatisch öffentliche und private Programme (ich teile öffentliche Programme zusätzlich in benutzerdefinierte und replizierte), über die Nützlichkeit von Programmen, über die Einstellung gegenüber Benutzern und gibt viele Beispiele aus der Kategorie „Horrorgeschichten“. Dann geht sie mit ruhigem Herzen (S. 63) zu den Empfehlungen der Makroebene über. Dazu gehören Themen wie Lokalisierung, globale Einstellungen mit Aussicht auf Erweiterung, Dokumentation und der Mythos der Selbstdokumentation, Ergonomie und Benutzerfreundlichkeit der Benutzeroberfläche, Codetests und -wiederverwendung, Funktionstests und vieles mehr.
Der Autor ignorierte nicht so wichtige Themen wie die inakzeptable Vernachlässigung von Aus- und Weiterbildung (S. 90) und die Notwendigkeit wirtschaftlicher Kompetenz (S. 73). "
Sie müssen ein Ökonom sein ."
Vergleiche der Anforderungen an Computerressourcen sind interessant (S. 88). Wenn wir zum Beispiel das Windows NT-Beispiel von 1996 nehmen, waren für eine komfortable Arbeit mit Anwendungen (Entwicklungsumgebung, Büro, Internet) 16 MB RAM erforderlich, während das Betriebssystem selbst 8 MB benötigte. Für Windows 7 oder 10 (mit demselben NT-Kernel) im Jahr 2016 sind 4 GB Speicher erforderlich, von denen nur 1 GB vom Betriebssystem verwendet wird. Das Verhältnis von 1: 2 sank sogar auf 1: 4. Daher die enttäuschende Schlussfolgerung: Die Probleme liegen weniger im Betriebssystem als in Programmen.
Auf Seite 105 wechselt der Autor reibungslos zu Empfehlungen auf Mikroebene. Was sieht Lou in den Unterschieden zwischen Makro- und Mikroebene? Ja, Tatsache ist, dass der Programmierer ohne Design sofort auf die Mikroebene wechselt und nicht einmal den Verdacht hegt, dass die Probleme, die in das Programm fließen, größtenteils durch die Vernachlässigung von Makroaufgaben verursacht werden.
In der Natur gibt es keine Ökonomen, die nur Makro- oder Mikroökonomie kennen. Dies sind nur Scharlatane. Aber unter denen, die sich Programmierer nennen, liegt eine solche Quacksalberei in der Reihenfolge der Dinge!
In dem Kapitel über die Mikroebene gibt der Autor auch viele nützliche Tipps. Ich mochte diesen (S. 109): "
Suchen Sie niemals nach einem Fehler, mit dem Sie nicht umgehen können ." Es mag scheinen, dass Ratschläge aus einer Reihe von "schädlichen" von G. Oster, aber dies ist ein falscher Eindruck. Ich bin auf Codefragmente wie
try... catch oder
try... except ,
try... except oft, wo der
catch/except Block leer war. Weil der Fehler manchmal auftauchte und der Programmierer auf seiner Mikroebene nicht wusste, wie er damit umgehen sollte. Dieser Code sieht nicht nur furchtbar hässlich aus, er ist auch sehr gefährlich, da er auf anderen Abstraktionsebenen zu unvorhersehbaren Konsequenzen führt.
Der nachfolgende Text widmet sich einer Vielzahl von Themen, die auf dem Weg vertikaler Entwickler ständig angetroffen werden. Ich werde nur einige auflisten.
- So vermeiden Sie "falsche Negative", wenn das Programm paranoid ist, indem Sie verhindern, dass der Benutzer Aktionen ausführt (Überprüfungen wie LooksLike () anstelle von Is ()).
- Trennen des Benutzeroberflächencodes von der Logik. Ohne MVC / MVP-Zauber zu wirken, listet der Autor alle Vorteile dieses Ansatzes auf, nicht zu vergessen die Minuspunkte, die hauptsächlich aus ernsthafter zusätzlicher Arbeit bestehen.
- Alle Änderungen in den Framework-Bibliotheken hängen davon ab, wie viel Unterstützung der Programmierer beim Ändern von Versionen benötigt. Das schnell gelöste Ad-hoc-Problem bereitet beim Aktualisieren des Frameworks Kopfschmerzen.
- Informationen zu den Vorteilen von Binärkonfigurationsdateien und zum Schutz der Integrität des Programms und seiner Ressourcen.
- Einfache Regeln für die Verwendung von DLLs. Dies gilt auch für moderne .NET-Assemblys, die sich nicht im globalen Cache befinden.
- … und vieles mehr
Auf Seite 147 nennt Lou zwei extreme Merkmale von Programmierern, die Gizmonauts und die Neoluddites. Die Wahrheit liegt wie immer irgendwo dazwischen. Sie können Technologien und Tools nicht auswählen, nur weil sie neu sind. In alten Umgebungen und Methoden kann man sich jedoch nicht gegen Hörner ausruhen, wenn die Modernisierung von Vorteil ist.
Es gibt einige Punkte in dem Buch, die ab 2019 lustig erscheinen, zum Beispiel (S. 154), Empfehlungen zum Speichern von Ausdrucken der Quellen ihrer Programme. Manuskripte brennen natürlich nicht, aber ...
Trotz der Tatsache, dass der Autor ein professioneller C ++ - Entwickler ist, gibt Lou auf den Seiten 167 bis 180 viele Gründe an, Delphi "
in allen neuen Projekten " zu verwenden. In der Tat war das Erscheinen von Delphi im Jahr 1995 nicht weniger revolutionär als die Veröffentlichung des neuen 32-Bit-Windows.
Wenn man sich aus dem Buch zurückzieht, ist es lustig, 2019 Aussagen zu hören, dass Delphi ein veraltetes Produkt ist. Und dass Java oder C # wie moderne Umgebungen sind. Ich möchte Sie daran erinnern, dass Java nur ein Jahr und C # - vier Jahre später - erschien. Für einen Programmierer, der irgendwo um 2010 seinen Betrieb aufgenommen hat, sollten alle drei Namen ungefähr so aussehen wie Kobol oder Fortran.
Laut Lou aus dem Jahr 1996 (S. 146) ist dies eine typische Situation: Ein eiliger Programmierer macht einen Fehler, hat keine Zeit, Alternativen zu studieren, und wählt aus Unwissenheit einen unnatürlichen Weg. Für erfahrene Entwickler ist es in diesem Fall die richtige Entscheidung, auf Ihre Gefühle zu hören.
Dies ist Zen-Programmierung in jeder Umgebung. Was ich dir auch wünsche.