Uma pequena resenha do livro de vinte anos foi
escrita em 2016 , publicada com micro-correções.
A confissão original do autor é chamada “Zen of Windows 95 Programming”. Que o número "95" não o assuste, o gráfico principal é o Zen, e não os números de versão que mudam rapidamente do sistema operacional principal das últimas décadas. O livro é um conjunto de recomendações e práticas para um desenvolvedor vertical (pilha completa), permitindo não apenas sobreviver no mundo da programação moderna, mas também produzir o resultado da qualidade exigida.
Na página 22, Lou define o leitor típico: "O fanático da qualidade". Para aqueles que na vida estão bastante satisfeitos com o trabalho de acordo com a metodologia "tyap-lyap-commissioning" ("x * yak-x * yak e produção"), é improvável que o livro ajude.
O livro está desatualizado? No início, uma rápida mudança de cenário foi descrita em 1995-96, quando o Windows 95 (em menor grau NT) se espalhou, as interfaces de programação (APIs) mudaram um pouco menos do que completamente, embora fosse necessário manter a funcionalidade de seus programas em três versões ao mesmo tempo Sistemas operacionais da Microsoft. Naquela época, o próprio Lou Greenaw tinha trinta anos (p. 87).
Alguém reclamando das rápidas mudanças na tecnologia moderna? Isso aconteceu há 25 anos ao mudar do DOS para o Windows e há 20 anos ao mudar os sistemas de 16 bits para os de 32 bits. Comparada a 1995, a longa migração atual para arquiteturas de 64 bits representou o auge da correção em relação aos programadores de aplicativos isolados da cozinha interna das transformações por muitas camadas de abstrações e máquinas virtuais.
O autor não perde a chance de falar sobre a essência da programação, escrevendo-a no "
ofício de usar uma variedade de ferramentas para criar níveis de abstração e aplicá-los para resolver problemas lógicos ". Parece que o que mais é necessário para o artesanato, se não um bom livro de receitas? No entanto, Lou anuncia imediatamente (p. 20) que sua abordagem é “
falar mais sobre o que você não deve fazer ” e “
confiar no fato de que você julgará independentemente como aplicar esse ou aquele conselho ”. Um pouco mais (p. 48) divide os programadores em "matemáticos" e "joalheiros".
Ou seja, como um ofício. Mas na verdade não. E às vezes nem um pouco. Em meu
livro, defini engenharia de software como "
uma liga eclética de tecnologias que podem ser usadas tanto por amadores da criatividade técnica quanto por profissionais de produção em massa de acordo com padrões e precedentes ", no entanto, não insisto na interpretação. A programação é tão ampla que todos, se desejado, podem ver e estar nele o que ele deseja.
Na parte introdutória, Lou discute pragmaticamente os programas públicos e privados (eu também divido os programas públicos em programas personalizados e replicados), sobre a utilidade dos programas, sobre a atitude em relação aos usuários e fornece muitos exemplos da categoria "histórias de horror". Então, com o coração calmo, ela prossegue (p. 63) com as recomendações do nível macro. Isso inclui tópicos como localização, configurações globais com perspectiva de expansão, documentação e o mito da auto-documentação, ergonomia e facilidade de uso da interface, teste e reutilização de código, testes funcionais e muito mais.
O autor não ignorou tópicos importantes como a negligência inaceitável de treinamento e educação (p. 90) e a necessidade de alfabetização econômica (p. 73) "
você deve ser um economista ".
As comparações dos requisitos de recursos do computador são interessantes (p. 88). De fato, se pegarmos, por exemplo, a amostra do Windows NT de 1996, para um trabalho confortável com aplicativos (ambiente de desenvolvimento, escritório, Internet), seriam necessários 16 MB de RAM, enquanto o próprio sistema operacional precisava de 8 MB. Para o Windows 7 ou 10 (com o mesmo kernel NT) em 2016, são necessários 4 GB de memória, dos quais apenas 1 GB é usado pelo sistema operacional. A proporção de 1: 2 caiu para 1: 4. Daí a conclusão decepcionante: os problemas não estão tanto no sistema operacional, mas nos programas.
Na página 105, o autor alterna suavemente para recomendações de nível micro. O que Lou vê as diferenças entre os níveis macro e micro? Sim, o fato é que, na ausência de design, o programador vai imediatamente para o nível multinível, nem mesmo suspeitando que os problemas que ocorrem nele se devem em grande parte à negligência de tarefas macro.
Na natureza, não há economistas que conhecem apenas macro ou microeconomia. Estes são apenas charlatães. Mas entre aqueles que se dizem programadores, esse charlatanismo está na ordem das coisas!
No capítulo sobre o nível micro, o autor também oferece muitas dicas úteis. Gostei desta (p. 109): "
Nunca verifique se há um erro que você não sabe como lidar ." Pode parecer que o conselho de uma série de "prejudicial" de G. Oster, mas esta é uma impressão falsa. Encontrei fragmentos de código como
try... catch ou
try... except muitas vezes, em que o bloco
catch/except estava vazio. Porque o erro às vezes aparecia, e o programador em seu nível micro não sabia como lidar com isso. Esse código não só parece terrivelmente feio, como também é muito perigoso, pois leva a consequências imprevisíveis em outros níveis de abstração.
O texto subsequente é dedicado a uma variedade de assuntos que são constantemente encontrados ao longo do caminho dos desenvolvedores verticais. Vou listar apenas alguns.
- Como evitar "falsos negativos" quando o programa é paranóico, impedindo o usuário de executar qualquer ação (verificações como LooksLike () em vez de Is ()).
- Separando o código da interface do usuário da lógica. Sem lançar feitiços MVC / MVP, o autor lista todas as vantagens dessa abordagem, sem esquecer os pontos negativos, consistindo principalmente em trabalho adicional sério.
- Quaisquer alterações nas bibliotecas da estrutura dependem do programador da carga de seu suporte ao alterar as versões. O problema adhoc resolvido rapidamente se transforma em dor de cabeça ao atualizar a estrutura.
- Sobre os benefícios dos arquivos de configuração binária e protegendo a integridade do programa e seus recursos.
- Regras simples para usar DLLs. Também se aplica a assemblies .NET modernos que não estão localizados no cache global.
- ... e muito mais
Na página 147, Lou cita duas características extremas dos programadores, os Gizmonauts e os Neoluddites. A verdade, como sempre, está em algum lugar no meio. Você não pode escolher tecnologias e ferramentas apenas porque são novas. Mas é impossível descansar contra chifres em ambientes e métodos antigos se houver um benefício com a modernização.
Há alguns pontos no livro que parecem engraçados a partir de 2019, por exemplo (p. 154), recomendações para armazenar cópias impressas das fontes de seus programas. Os manuscritos, é claro, não queimam, mas ...
Apesar do autor ser um desenvolvedor profissional de C ++, nas páginas 167-180, Lou fornece vários motivos para usar o Delphi "
em todos os novos projetos ". De fato, a aparência do Delphi em 1995 não foi menos revolucionária do que o lançamento do novo Windows de 32 bits.
Recuando do livro, é engraçado em 2019 ouvir declarações de que o Delphi é um produto obsoleto. E que Java ou C # são, como - ambientes modernos. Deixe-me lembrá-lo que o Java apareceu apenas um ano e C # - quatro anos depois. Para um programador que iniciou suas operações por volta de 2010, todos esses três nomes devem se parecer com Kobol ou Fortran.
Segundo Lou de 1996 (p. 146), uma situação típica: um programador às pressas comete um erro, não tendo tempo para estudar alternativas, escolhendo um caminho não natural por ignorância. Para desenvolvedores experientes, neste caso, a decisão certa é ouvir seus sentimentos.
Esta é a programação Zen em qualquer ambiente. O que também desejo a você.