Une petite revue du livre de vingt ans a été
écrite en 2016 , publiée avec des micro-corrections.
La confession originale de l'auteur s'appelle «Zen de la programmation Windows 95». Que le chiffre «95» ne vous fasse pas peur, l'intrigue clé est précisément zen, et non les numéros de version en évolution rapide du système d'exploitation principal des dernières décennies. Le livre est un ensemble de recommandations et de pratiques pour un développeur vertical (full-stack), permettant non seulement de survivre dans le monde de la programmation moderne, mais aussi de produire le résultat de la qualité requise.
À la page 22, Lou définit le lecteur type: «Le fanatique de la qualité». Pour ceux qui dans la vie sont très satisfaits du travail selon la méthodologie "tyap-lyap-commissioning" ("x * yak-x * yak and production"), le livre est peu susceptible d'aider.
Le livre est-il obsolète? Au tout début, un changement rapide de la scène a été décrit en 1995-96, lorsque Windows 95 (dans une moindre mesure NT) s'est généralisé, les interfaces de programmation (API) ont changé légèrement moins que complètement, alors qu'il était nécessaire de maintenir la fonctionnalité de leurs programmes en trois versions à la fois Systèmes d'exploitation Microsoft. À cette époque, Lou Greenaw lui-même avait trente ans (p. 87).
Quelqu'un se plaint des changements rapides de la technologie moderne? Cela s'est produit il y a 25 ans lors du passage de DOS à Windows et il y a 20 ans lors du passage de systèmes 16 bits à des systèmes 32 bits. Par rapport à 1995, la longue migration actuelle vers les architectures 64 bits représentait le summum de l'exactitude en ce qui concerne les programmeurs d'applications séparés de la cuisine interne des transformations par de nombreuses couches d'abstractions et de machines virtuelles.
L'auteur ne manque pas une occasion de parler de l'essence de la programmation, en l'écrivant dans «l'
art d'utiliser une variété d'outils pour créer des niveaux d'abstraction et les appliquer pour résoudre des problèmes logiques ». Il semblerait que quoi d'autre soit nécessaire pour le métier, sinon un bon livre de cuisine? Cependant, Lou annonce immédiatement (p. 20) que son approche est de «
parler davantage de ce que vous ne devriez pas faire » et de «
compter sur le fait que vous jugerez indépendamment comment appliquer tel ou tel conseil ». Un peu plus loin (p. 48) divise les programmeurs en «mathématiciens» et «bijoutiers».
Autrement dit, comme un métier. Mais pas vraiment. Et parfois pas du tout. Dans mon
livre, j'ai défini le génie logiciel comme "
un alliage éclectique de technologies pouvant être utilisées à la fois par des amateurs de créativité technique et des professionnels de la production de masse selon des modèles et des précédents ", mais je n'insiste pas sur l'interprétation. La programmation est si large que chacun, s'il le souhaite, peut voir et être en lui ce qu'il veut.
Dans la partie introductive, Lu discute de manière pragmatique des programmes publics et privés (je divise en outre les programmes publics en programmes personnalisés et reproduits), de l'utilité des programmes, de l'attitude envers les utilisateurs et donne de nombreux exemples de la catégorie des "histoires d'horreur". Puis, le cœur calme, elle procède (p. 63) aux recommandations du niveau macro. Cela comprend des sujets tels que la localisation, les paramètres globaux avec la perspective de leur expansion, la documentation et le mythe de l'auto-documentation, l'ergonomie et l'interface conviviale, les tests et la réutilisation du code, les tests fonctionnels et bien plus encore.
L'auteur n'a pas ignoré des sujets aussi importants que la négligence inacceptable de la formation et de l'éducation (p. 90) et le besoin d'alphabétisation économique (p. 73) «
vous devez être un économiste ».
Les comparaisons des besoins en ressources informatiques sont intéressantes (p. 88). En effet, si l'on prend, par exemple, l'échantillon Windows NT de 1996, alors pour un travail confortable avec des applications (environnement de développement, bureau, Internet), 16 Mo de RAM étaient nécessaires, alors que le système d'exploitation lui-même avait besoin de 8 Mo. Pour Windows 7 ou 10 (avec le même noyau NT) en 2016, 4 Go de mémoire sont requis, dont seulement 1 Go est utilisé par le système d'exploitation. La proportion de 1: 2 est même tombée à 1: 4. D'où la conclusion décevante: les problèmes ne sont pas tant dans le système d'exploitation que dans les programmes.
À la page 105, l'auteur passe en douceur aux recommandations de niveau micro. Que voit Lou les différences entre les niveaux macro et micro? Oui, le fait est qu'en l'absence de conception, le programmeur passe immédiatement au niveau micro, ne soupçonnant même pas que les problèmes qui s'y déversent sont largement causés par la négligence des tâches macro.
Dans la nature, il n'y a pas d'économistes qui ne connaissent que la macro ou la microéconomie. Ce ne sont que des charlatans. Mais parmi ceux qui se disent programmeurs, un tel charlatanisme est dans l'ordre des choses!
Dans le chapitre sur le niveau micro, l'auteur donne également de nombreux conseils utiles. J'ai aimé celui-ci (p. 109): "
Ne recherchez jamais une erreur que vous ne savez pas comment gérer ." Il peut sembler que les conseils d'une série de «nuisibles» de G. Oster, mais c'est une fausse impression. J'ai rencontré des fragments de code comme
try... catch ou
try... except plusieurs fois, où le bloc
catch/except était vide. Parce que l'erreur apparaissait parfois, et le programmeur à son niveau micro ne savait pas comment le gérer. Non seulement ce code a l'air terriblement moche, mais il est également très dangereux, car il entraîne des conséquences imprévisibles à d'autres niveaux d'abstractions.
Le texte suivant est consacré à une variété de sujets qui sont constamment rencontrés sur le chemin des développeurs verticaux. Je n'en énumérerai que quelques-uns.
- Comment éviter les "faux négatifs" lorsque le programme est paranoïaque en empêchant l'utilisateur d'effectuer des actions (vérifie comme LooksLike () au lieu de Is ()).
- Séparer le code de l'interface utilisateur de la logique. Sans lancer de sorts MVC / MVP, l'auteur énumère tous les avantages de cette approche, sans oublier les inconvénients, qui consistent principalement en un travail supplémentaire sérieux.
- Tout changement dans les bibliothèques du framework dépend du programmeur de la charge de son support lors du changement de version. Le problème adhoc rapidement résolu se transforme en mal de tête lors de la mise à jour du framework.
- À propos des avantages des fichiers de configuration binaires et de la protection de l'intégrité du programme et de ses ressources.
- Règles simples pour l'utilisation des DLL. Il s'applique également aux assemblys .NET modernes qui ne se trouvent pas dans le cache global.
- ... et bien plus
À la page 147, Lou cite deux caractéristiques extrêmes des programmeurs, les Gizmonautes et les Neoluddites. La vérité, comme d'habitude, se situe quelque part entre les deux. Vous ne pouvez pas choisir des technologies et des outils simplement parce qu’ils sont nouveaux. Mais il est impossible de se reposer contre les cornes dans les anciens environnements et méthodes s'il y a un avantage à la modernisation.
Il y a des points dans le livre qui semblent drôles à partir de 2019, par exemple (p. 154), des recommandations pour stocker des copies papier des sources de leurs programmes. Les manuscrits, bien sûr, ne brûlent pas, mais ...
Malgré le fait que l'auteur soit un développeur C ++ professionnel, aux pages 167-180, Lou donne de nombreuses raisons d'utiliser Delphi "
dans tous les nouveaux projets ". En effet, l'apparition de Delphi en 1995 n'était pas moins révolutionnaire que la sortie du nouveau Windows 32 bits.
En retrait du livre, il est drôle en 2019 d'entendre des déclarations selon lesquelles Delphi est un produit obsolète. Et que Java ou C # est, comme - des environnements modernes. Permettez-moi de vous rappeler que Java est apparu seulement un an, et C # - quatre ans plus tard. Pour un programmeur qui a commencé ses opérations vers 2010, ces trois noms devraient ressembler à Kobol ou Fortran.
Selon Lou de 1996 (p. 146), une situation typique: un programmeur pressé fait une erreur, n'ayant pas le temps d'étudier des alternatives, choisissant une voie contre nature par ignorance. Pour les développeurs expérimentés dans ce cas, la bonne décision est d'écouter vos sentiments.
Il s'agit d'une programmation zen dans n'importe quel environnement. Ce que je vous souhaite aussi.