[LIVRO] The Pragmatic Programmer - Capítulo 2
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 do post anterior:
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 2 - A Pragmatic Approach (Uma Abordagem Pragmática)
Abordagem pragmática: Como desenvolvedores estamos suscetivos a cometermos alguns tipos de erros por não buscarmos aplicar algumas abordagens/boas práticas de codificar
The Evil of Duplication (O Mau da Duplicação)
Muitas das vezes achamos que a manutenabilidade do código começa quando lançamos a aplicação. Pensamos que a manutenção significa corrigir bugs e adicionar features. Mas isso está errado. Programadores devem estar em recorrente modo de manutenabilidade. Muita coisa muda enquanto estamos fazendo uma aplicação, quer ideias, quer pessoas, quer o ambiente, quer tecnologia.
Somos suscetíveis a cair no erro de ficar duplicando o nosso conhecimento deixando as coisas de canto. DRY (Don’t Repeat Yourself)
- Toda parte de conhecimento deve ter uma única, não-ambígua, representação dentro do sistema
- Por que duplicação acontece?
- Duplicação imposta - Normalmente acontece por algum tipo de integração com diferentes documentações. O código deve ser a sua documentação. Muitos comentários indicam mal código, é difícil de se entender. Não é interessante ter um código e ter uma documentação detalhada sobre. Ao mudar um, será necessário mudar o outro
- Duplicação inadvertida - Erro de design
- Muitas das vezes ignoramos o DRY tentando buscar uma melhor performance ou entrega de demanda. A questão é que não vemos diretamente o impacto de alguma alteração de duplicatas.
- Duplicação impaciente - Muitas das vezes vamos precisar de algo similar ao que já implementamos.
- Duplicação entre desenvolvedores - Muitas das vezes acontece quando desenvolvedores não se comunicam e fazem features iguais sem reaproveitar o que já existia
- Make it Easy to Reuse
- Observação pessoal: só “duplique” um código caso haja claramente diferentes responsabilidades.
- Ex.: criação e edição de alguma entidade no frontend. A página pode ser muito similar, inclusive igual, mas são responsabilidades diferentes. Então podemos inclusive ter o mesmo código para ambos. Mas se um precisar mudar, não irá afetar o outro.
Orthogonality (Ortogonalidade)
Ortogonalidade se refere a eixos que são ortogonais entre si, ou seja, uma mudança em um, não afetará o outro. Muitas das vezes teremos sistemas não-ortogonais, mas isso precisa ser proposital.
Benefícios da ortogonalidade
- Ganho de produção
- Redução de riscos
- Mantenha seu código desacoplado: Módulos não precisam mostrar nada desnecessário para outros módulos e não depende de implementações de outros módulos
- Evite dados globais
- Evite funções similares
Reversibility (Reversibilidade)
Nada é mais perigoso do que uma ideia que só você teve. Engenheiros preferem soluções simples e singulares. Muitos gerentes preferem a ideia de solução simples da engenharia, a questão é que tudo muda e está suscetível a mudança.
- Mudanças não precisam ser draconianas ou imediatas, mas podem acontecer progressivamente. Mudanças críticas não são facilmente reversíveis
- Ex.: digamos que estejamos usando um modelo client-server, mas por questões financeiras, eles querem usar uma versão standalone. Visto que é apenas uma questão de deploy, esse tipo de mudança não deveria levar mais do que alguns dias.
- Nunca há decisões finais - Arquitetura flexível
- Use interfaces
- Faça as coisas serem facilmente reversíveis
Tracer Bullets (Balas rastreadoras)
Podemos usar balas rastreadoras quando estamos caçando no escuro, onde é deixado um rastro pirotécnico por onde passa. O feedback é imediato, efeitos externos são minimizados.
Quando estamos fazendo algo que nunca tenha sido feito, ficamos às cegas. Não é possível simplesmente especificar e planejar tudo, estaremos muito suscetíveis a erros. O código acaba surgindo das trevas.
- Desenvolvimento rastreável é consistente com a ideia de que o projeto nunca é finalizado. Sempre haverá mudanças e funcionalidades a se adicionar.
- Vantagens
- Usuários veem algo funcionando rapidamente
- Desenvolvedores criam uma estrutura para trabalhar em cima
- Tem uma plataforma de integração
- Sempre há algo para demonstrar
- Há um melhor sentimento de progresso
Prototypes and Post-it Notes (Protótipos e Notas de Post-it)
- Muitas industrias/empresas usam protótipos para tentar novas ideias
- Coisas para serem prototipadas
- Arquitetura
- Novas funcionalidades de um sistema existente
- Estruturas ou conteúdos de dados externos
- Componentes de terceiros
- Problemas de performance
- Design de interface de usuário
- Prototipe para aprender
- Corretiva
- Completativa
- Robustes
- Estilo
- Como não usar protótipos: deixe bem claro a todos que você está fazendo um código descartável. Protótipos podem animar pessoas a darem continuidade em algo que não será continuado.
Domain Languages (Linguagens de domínio)
- Os limites de uma linguagem são os limites de um único mundo
- Linguagens de computação influenciam em como você irá pensar sobre um problema e como você irá se comunicar.
- Programe perto do domínio do problema: code em um nível de abstração alto, para entender o problema requerido
- Crie uma “mini-linguagem” própria para escrever as soluções dos problemas.
Estimating (Estimando)
- Estime os prazos para evitar surpresas
- Quão acurado é acurado suficiente?
- Sempre é uma estimativa, as vezes mais acurada do que outras.
- Sempre pergunte para alguém que já fez a tarefa para você ter uma estimativa mais exata
- O que está sendo pedido? Detalhe as informações, faça estimativas de cada item para totalizar
- Crie modelos do sistema
- Quebre o modelo em componentes
- Cheque os requerimentos
- Analise os riscos
- Design, implementação e integração
- Validação com os usuários
E aí pessoal, o que vocês acham? Toda contribuição é bem vinda!