Una pequeña revisión del libro de veinte años fue
escrita en 2016 , publicada con micro correcciones.
La confesión original del autor se llama "Programación Zen de Windows 95". Deje que el número "95" no lo asuste, la trama clave es precisamente Zen, y no los números de versión que cambian rápidamente del sistema operativo principal de las últimas décadas. El libro es un conjunto de recomendaciones y prácticas para un desarrollador vertical (full-stack), que permite no solo sobrevivir en el mundo de la programación moderna, sino también producir el resultado de la calidad requerida.
En la página 22, Lou define al lector típico: "El fanático de la calidad". Para aquellos que en la vida están bastante satisfechos con el trabajo según la metodología "tyap-lyap-Commissioning" ("x * yak-x * yak y producción"), es poco probable que el libro sirva de ayuda.
¿El libro está desactualizado? Al principio, se describió un cambio rápido en la escena en 1995-96, cuando Windows 95 (en menor medida NT) se generalizó, las interfaces de programación (API) cambiaron ligeramente menos que por completo, mientras que resultó necesario mantener la funcionalidad de sus programas en tres versiones a la vez Sistemas operativos de Microsoft. En ese momento, el propio Lou Greenaw tenía treinta años (p. 87).
¿Alguien se queja de los rápidos cambios en la tecnología moderna? Esto sucedió hace 25 años al cambiar de DOS a Windows, y hace 20 años al cambiar los sistemas de 16 bits a los de 32 bits. En comparación con 1995, la larga migración actual a arquitecturas de 64 bits representaba el pináculo de la corrección con respecto a los programadores de aplicaciones cercados de la cocina interior de transformaciones por muchas capas de abstracciones y máquinas virtuales.
El autor no pierde la oportunidad de hablar sobre la esencia de la programación, escribiéndola en el "
arte de usar una variedad de herramientas para crear niveles de abstracción y aplicarlas para resolver problemas lógicos ". Parecería que ¿qué más se necesita para el oficio, si no es un buen libro de cocina? Sin embargo, Lou inmediatamente anuncia (p. 20) que su enfoque es "
hablar más sobre lo que no debes hacer " y "
confiar en el hecho de que juzgarás independientemente cómo aplicar este o aquel consejo ". Un poco más (pág. 48) divide a los programadores en "matemáticos" y "joyeros".
Es decir, como un oficio. Pero en realidad no. Y a veces no del todo. En mi
libro, definí la ingeniería de software como "
una aleación ecléctica de tecnologías que pueden ser utilizadas tanto por aficionados a la creatividad técnica como por profesionales de producción en masa de acuerdo con patrones y precedentes ", sin embargo, no insisto en la interpretación. La programación es tan amplia que todos, si lo desean, pueden ver y estar en él lo que quieren.
En la parte introductoria, Lu discute pragmáticamente programas públicos y privados (adicionalmente divido los programas públicos en personalizados y replicados), sobre la utilidad de los programas, sobre las actitudes hacia los usuarios, y da muchos ejemplos de la categoría de "historias de terror". Luego, con un corazón tranquilo, ella procede (p. 63) a las recomendaciones del nivel macro. Esto incluye temas como la localización, la configuración global con la perspectiva de su expansión, la documentación y el mito de la autodocumentación, la ergonomía y la facilidad de uso de la interfaz, las pruebas y la reutilización de código, las pruebas funcionales y mucho más.
El autor no ignoró temas tan importantes como el abandono inaceptable de la capacitación y la educación (p. 90) y la necesidad de alfabetización económica (p. 73) "
debe ser un economista ".
Las comparaciones de los requisitos de recursos informáticos son interesantes (p. 88). De hecho, si tomamos, por ejemplo, la muestra de Windows NT de 1996, para un trabajo cómodo con las aplicaciones (entorno de desarrollo, oficina, Internet), se requieren 16 MB de RAM, mientras que el sistema operativo en sí mismo necesita 8 MB. Para Windows 7 o 10 (con el mismo núcleo NT) en 2016, se requieren 4 GB de memoria, de los cuales solo 1 GB es utilizado por el sistema operativo. La proporción de 1: 2 incluso cayó a 1: 4. De ahí la conclusión decepcionante: los problemas no están tanto en el sistema operativo como en los programas.
En la página 105, el autor cambia sin problemas a las recomendaciones de nivel micro. ¿Qué ve Lou las diferencias entre los niveles macro y micro? Sí, el hecho es que, en ausencia de diseño, el programador pasa inmediatamente al nivel micro, sin siquiera sospechar que los problemas que se generan en él se deben en gran medida al descuido de las tareas macro.
En la naturaleza, no hay economistas que solo conozcan macro o microeconomía. Estos son solo charlatanes. Pero entre los que se llaman programadores, ¡esa charlatanería está en el orden de las cosas!
En el capítulo sobre el nivel micro, el autor también da muchos consejos útiles. Me gustó este (pág. 109): "
Nunca verifique si hay un error que no sabe cómo manejar ". Puede parecer ese consejo de una serie de "dañinos" de G. Oster, pero esta es una falsa impresión. Me he encontrado con fragmentos de código como
try... catch o
try... except muchas veces, donde el bloque
catch/except estaba vacío. Porque a veces aparecía el error, y el programador en su nivel micro no sabía cómo manejarlo. Este código no solo se ve terriblemente feo, también es muy peligroso, ya que conduce a consecuencias impredecibles en otros niveles de abstracciones.
El texto posterior está dedicado a una variedad de temas que se encuentran constantemente en el camino de los desarrolladores verticales. Voy a enumerar solo unos pocos.
- Cómo evitar "falsos negativos" cuando el programa es paranoico para evitar que el usuario realice acciones (verificaciones como LooksLike () en lugar de Is ()).
- Separar el código de la interfaz de usuario de la lógica. Sin lanzar hechizos MVC / MVP, el autor enumera todas las ventajas de este enfoque, sin olvidar las desventajas, que consisten principalmente en un trabajo adicional serio.
- Cualquier cambio en las bibliotecas de framework le carga al programador la carga de su soporte al cambiar las versiones. El problema adhoc resuelto rápidamente se convierte en un dolor de cabeza al actualizar el marco.
- Acerca de los beneficios de los archivos de configuración binarios y la protección de la integridad del programa y sus recursos.
- Reglas simples para usar DLL. También se aplica a los ensamblados .NET modernos que no se encuentran en la memoria caché global.
- ... y mucho más
En la página 147, Lou cita dos características extremas de los programadores, los gizmonautas y los neoluditas. La verdad, como siempre, está en algún punto intermedio. No puede elegir tecnologías y herramientas solo porque son nuevas. Pero es imposible descansar contra los cuernos en entornos y métodos antiguos si hay un beneficio de la modernización.
Hay algunos puntos en el libro que parecen divertidos desde 2019, por ejemplo (p. 154), recomendaciones para almacenar copias impresas de las fuentes de sus programas. Los manuscritos, por supuesto, no se queman, pero ...
A pesar de que el autor es un desarrollador profesional de C ++, en las páginas 167-180, Lou da muchas razones para usar Delphi "
en todos los proyectos nuevos ". De hecho, la aparición de Delphi en 1995 no fue menos revolucionaria que el lanzamiento del nuevo Windows de 32 bits.
Retirándose del libro, es divertido en 2019 escuchar declaraciones de que Delphi es un producto obsoleto. Y ese Java o C # es, como, entornos modernos. Permíteme recordarte que Java apareció solo un año y C #, cuatro años después. Para un programador que comenzó a operar en algún lugar alrededor de 2010, estos tres nombres deberían parecerse a Kobol o Fortran.
Según Lou de 1996 (p. 146), una situación típica: un programador apurado comete un error, al no tener tiempo para estudiar alternativas, al elegir un camino antinatural por ignorancia. Para desarrolladores experimentados en este caso, la decisión correcta es escuchar sus sentimientos.
Esta es la programación Zen en cualquier entorno. Lo cual también te deseo.