[LIVRO] The Pragmatic Programmer - Capítulos 3 e 4
Dando sequência aos posts sobre o livro "The Pragmatic Programmer: from journeyman to master” (Andrew Hunt e David Thomas) ou em português “O Programador Pragmático: de Aprendiz a Mestre”, onde estou publicando minhas anotações do livro aqui no TabNews para compartilhar o conhecimento de forma mútua.
Link dos posts anteriores:
P.S: Ressalto que eu li a 1a Edição de 1999 em inglês. São minhas anotações pessoais, com tradução de termos e ideias próprias, logo poderão ter informações que na tradução em português oficial estejam diferentes. A ideia não é ser, necessariamente, um resumo/resenha do livro, mas de pontuar algumas ideias que eu entendi serem interessantes a compartilhar.
Capítulo 3 - The Basic Tools (As Ferramentas Básicas)
Investa na sua própria caixa de ferramentas
The Power of Plain Text (O poder do texto)
- Nosso material basal é o conhecimento
- Plain text tendem a ser de um nível superior do que binários
- Mantenha o conhecimento em plain texts ⇒ São mais fáceis de entender e não precisa de um conhecimento avançado em programação
- Problemas
- Ocupar mais espaço do que um formato binário compressado
- Computacionalmente é mais expendioso interpretar e processar o plain text
- Poder do texto
- Acertividade contra obsolência ⇒ Formas humanas de ler dados e de se autodescrever vão se sobrepor a qualquer outra forma de dado criado.
- Aproveitamento ⇒ Praticamente tudo do universo de computação pode ser operado em texto
- Facilidade em testar ⇒ É possível criar, atualizar ou modificar testes sem term que criar nenhuma ferramente especial para isso.
Shell Games (Jogos do Shell)
- Se você fizer tudo usando seu GUI, e não aproveitando seu shell prompt, você não conseguirá usar toda a capacidade do seu ambiente.
- WYSIWYG x WYSIAYG ⇒ what you see is what you get x what you see is all you get
- GUI é limitado pelas capacidades que o designer pensou para ele.
- Use os poderes dos comandos shell ⇒ Ganhe familiaridade com o shell
Power Editing (Poder da edição)
- Use apenas um editor ⇒ Problema da torre de babel de IDE
- Escolha um editor e o conheça bem, e o use para todas as tarefas de edição.
- Editor Features
- Configurável
- Extensível
- Programável
Source Code Control (Controle do Código Fonte)
- É muito importante ter o controle do versionamento do seu código, quer por alguma ferramenta de versionamento, quer por algum controle temporário do arquivo em edição.
- Quem alterou essa linha de código?
- Qual é a diferença entre as versões?
- Depois de lançar uma versão, deseja-se continuar o software a partir dela, mas e se precisarmos voltar? Conseguimos fazer isso rapidamente e de forma segura?
- Sempre use controle de versionamento de código
- Automação
- Repetição
- Se o seu time não está usando versionamento de código, evangelize-os! (Ou obrigue-os)
Debugging
É doloroso olhar para o seu problema e saber que só você mesmo, e ninguém mais, o causou. Debugging é algo sensível e emocional para muitos desenvolvedores. Ao invés de solucioná-lo, muitos procuram apontar erros e se justificar.
- Conserte o problema, não a culpa ⇒ Não entre em pânico
- É muito fácil entrar em pânico se estamos lidando com algum prazo ou com algum chefe nervoso.
- Não fique achando que “isso não era para ter acontecido”, por que de fato aconteceu.
- Provavelmente você deverá perguntar ao usuário que relatou o problema
- Testes artificiais não irão ser suficientes. Muitas das vezes você terá que fazer testes realistas usando as condições do usuário
- Muitas das vezes o bug acontece no estado atual do programa. Mas as vezes a gente precisa conseguir rastreá-lo ao longo do tempo.
- Não presuma algo, prove algo!
Text manipulation (Manipulação de texto)
- Aprenda uma linguagem de manipulação de texto
- Manutenção do schema de Database
- Java property access
- Geração de teste de dados
- Book writing
- C para interface de Object Pascal
- Geração de documentos web
Code Generators (Geradores de código)
- Escreva código que escreva código
- Geradores passivos de códigos ⇒ executam uma única vez para produzir um resultado
- Geradores ativos de código ⇒ são usados cada vez que o resultado é requerido.
Capítulo 4 - Pragmatic Paranoia (Paranóia Pragmática)
Você não consegue escrever softwares perfeitos, isso deve ser um axioma da vida. Softwares perfeitos não existem. Programadores pragmáticos não confiam em si mesmos e sabem que não escrevem códigos perfeitos. Eles escrevem códigos para se defenderam de suas escritas de código ruins.
Design by Contract (Design por Contrato)
Lidar com sistema de computadores é difícil, com pessoas é mais difícil ainda. Estabeleça contratos com direitos e responsabilidades. Cada função e método no software faz alguma coisa
- Precondições: Uma rotina nunca deve ser chamada se precondições não forem atendidas
- Pós-condições: Loops infinitos não são permitidos, deve ter algo que garanta que ela entregue algo
- Classe de Invariantes: Quando uma rotina começa, nunca se deve conseguir alterar aquilo que não deva ser inalterado
- Se todas as precondições de uma rotina são atendidas, a rotina deve garantir que todas as poscondições e invariantes devem retornar verdadeira assim que completar
- Se algo sair errado, uma exceção deve ser levantada, ou o programa deve ser encerrado.
- Seja rígido com aquilo que você aceita antes de começar, e prometa pouco quanto possível no retorno.
- Erre em favor do consumidor
Dead Programs Tell no Lies (Programas mortos não contam mentiras)
Assim como outras pessoas podem detectar problemas em você antes que você mesmo perceba, com o código acontece a mesma coisa
- As pessoas podem perceber que o seu código não está muito legal antes de você mesmo. Ou o seu teste de contrato. Famoso “ah, mas isso não pode acontecer”
- Quebre com antecedência: Não deixe que o problema estoure em produção.
- Quebre, não jogue no lixo
Assertive Programming (Programação Assertiva)
Há uma luxuria em auto reprovação. Quando nos culpamos nós mesmos, nós sentimos que ninguém mais tem o direito de nos culpar. Se algo não pode acontecer, use asserções para garantir que não irá acontecer.
- Testar não checa todos os possíveis bugs, muitas vezes só conseguimos checar uma parte.
- Seu programa roda em um mundo perigoso, muita coisa pode acontecer além dos meros testes que fazemos
- Desligar asserções quando você entrega um programa para produção é como atravessar uma linha alta sem uma rede porque você já fez isso uma vez.
When to Use Exceptions (Quando usar exceções)
- Use exceções para lidar com erros ⇒ Deixe o fluxo do código claro e jogue todos os erros para o mesmo local (try catch)
- O que é exceção?
- Meu código vai funcionar se eu retirar essa exceção?
- Meu código deveria levantar uma exceção? ⇒ Depende? Porque? ⇒ Vá mais fundo.
- Use exceções para problemas excepcionais
- Error Handlers são alternativas
How to Balance Resources (Como balancear recursos)
- Finalize o que você começou ⇒ Basicamente se sua rotina ou objeto alocam algum recurso, ele deve ser responsável por desalocá-lo.
- Dealoque recursos na ordem oposta em que foi alocada
- Quando você aloca o mesmo recurso em diferentes locais no código, sempre os aloque na mesma ordem.
E aí pessoal, o que vocês acharam? Toda contribuição é bem vinda!