[LIVRO] The Pragmatic Programmer - Capítulos 7 e 8 · Pherris

Finalizando a sequência dos 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 (ou até erradas). 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 7 - Before The Project (Antes do Projeto)

Você já teve a sensação de que o seu projeto está condenado antes mesmo de iniciar? Muitas vezes ele pode estar condenado a menos que você estabeleça algumas regras básicas primeiro.

Resolvendo quebra cabeças impossíveis

The Requirements Pit (O poço de requisitos)

Não ajunte requisitos, cave por eles
Os requisitos não vão estar lá quando você for procurar, você terá que fazer um esforço para descobrí-los
Para isso requer algo que é simples e complexo ⇒ A resposta simples é que os requerimentos são coisas que precisam ser cumpridas. Bons requerimentos podem incluir:
- Um registro só pode ser visto por um grupo de pessoas
- Um medidor não pode exceder um valor crítico
- O editor irá marcar algumas palavras chaves que serão selecionadas dependendo do tipo de arquivo a ser editado
No caso do registro que só pode ser visto por um grupo de pessoas irá levar para um regras de permissões e como isso serão relacionadas aos usuários ⇒ O requerimento na verdade não é sobre um grupo de pessoas ver um arquivo, mas sobre as permissões gerais.
Trabalhe com o usuário para pensar como um usuário
Documente os requerimentos
- Abstrações vivem mais do que detalhes ⇒ Não tente prever o futuro, detalhes podem mudar. Foque em abstrações para serem implementadas posteriormente
- Mantenha uma linguagem ubíqua ⇒ Tenha um glossário para o projeto para evitar confusões de definições de termos (pode haver uma diferença entre ‘client’ e ‘customer’ por exemplo)

Solving Impossible Puzzles (Resolvendo quebra-cabeças impossíveis)

Podemos lidar com projetos realmente muito difíceis de lidar, como se fossem quebra cabeças. Soluções “óbvias” não estão funcionando.
O segredo para resolver problemas difíceis é identificar restrições reais (e não imaginadas) ⇒ Restrições reais devem ser honradas, mesmo que sejam estranhas.
Não pense fora da caixa, encontre a caixa ⇒ Saiba onde estão os limites do domínio e das condições.
Not Until You’re Ready (Não até que você esteja pronto)
- Ouça as dúvidas persistentes - comece quando estiver pronto
- Escrever uma especificação é praticamente uma responsabilidade
- Cuidado para não estar procrastinando, ao invés de estar sendo realmente cauteloso
- Muitas coisas são melhores feitas do que descritas
- Como um Programador Pragmático você deve ver os requisitos coletados, designed e implementados de diferentes formas no mesmo processo.

Circles and Arrows (Círculos e Setas)

Não seja escravo de métodos formais ⇒ Existem vários tipos de formatos para esquematizar um projeto, mas não se prenda a isso
A maioria dos métodos formais usam diagramas e algumas palavras específicas para definir partes do projeto. Mas muitos dos diagramas podem ser sem sentido se não forem de fato implementados.
Métodos formais podem encorajar uma especialização que pode não ser necessária. Pode acontecer de levar para uma comunicação pobre e uma perda de esforços. Também pode levar a um embate entre desingners e desenvolvedores.
Ferramentas caras não produzem melhores designs

Capítulo 8 - Pragmatics Projects (Projetos Pragmáticos)

Assim como seus projetos podem ir seguindo, nós precisamos mudar o nosso foco de problemas de filosofias individuais e de código para problemas grandes, do tamanho do projeto.

Pragmatic Teams (Times pragmáticos)

Podemos usar as ideias que vimos até aqui para os times
No Broken Windows ⇒ Qualidade é um problema do time. O mais diligente dos desenvolvedores terá que lidar com problemas de qualidade envolvendo o time, e não só isso, mas ter ânimo para tal, gastando tempo consertando problemas.
- Times não devem tolear broken windows, ou seja, aquelas imperfeições que ninguém conserta. O time deve tomar a responsabilidade pelo produto.
Boiled Frogs ⇒ Times que não são vigilantes podem acabar como o sapo que morreu cozido na água que foi se fervendo gradativamente. Pessoas acham que alguém está lidando com um problema, ou que o tech lead deve ter aceitado uma mudança que um usuário está querendo.
- Faça questão que todos do time monitorem as mudanças no ambiente, talvez colocando alguém como responsável por averiguar possíveis mudanças.
- É preciso estar ciente das mudanças, caso contrário a água vai ferver e você não vai sentir.
Comunicação ⇒ O pior para um time é não ter uma comunicação efetiva. Desde acharem várias coisas sem saber se de fato deve seguir dessa maneira, até ninguém se comunicar em uma reunião.
- Documentação e linguagem são bagunçadas, cada um usa termos diferentes para a mesma coisa.
- Times de bons projetos são estruturados e são preparados para qualquer tipo de reunião.
DRY ⇒ Duplicações podem levar a pesadelos. Quando o projeto começa a crescer, tente deixar alguém responsável pela biblioteca do projeto. Se for muito grande, estabeleça pontos focais para evitar duplicações.
Ortogonalidade ⇒ As coisas em um projeto não devem andar de formas isoladas. Simplesmente não dá. Trabalhe em função de uma funcionalidade e não de funções de um cargo.
- Deixe que os times se organizem de forma autônoma
- É necessário duas cabeças, uma que vá pensar de forma administrativa e outra de forma técnica, para impedir que padrões sejam deixados de lado.

Ubiquitous Automation (Automação ubíqua)

All on Automatic ⇒ Não use procedimentos manuais
- Pessoas não são tão repetitivas quanto computadores o são. Coisas que deveriam funcionar começam a parar de funcionar porque não automatizamos procedimentos
Testes de Regressão ⇒ Seja capaz de testar todo o projeto com apenas um botão
Build Automation
1. Confira o código fonte no repositório
2. Crie um projeto do zero com um número da versão
3. Crie uma imagem distribuível
4. Execute testes específicos
Approval Procedures
- Alguns projetos possuem workflows administrativos variados que devem ser seguidos

Ruthless Testing (Teste implacavelmente)

Muitos desenvolvedores odeiam testar ⇒ Muitas vezes os testes que eles fazem são enviesados.
- Teste cedo, durante e automatizado
Devemos testar desde cedo quando fazemos um código ⇒ Se não o código começa a crescer e vai ficando cade vez mais difícil testar
Quanto mais cedo um bug for encontrado, mais barata é a sua medicação ⇒ Code um pouco, teste um pouco
- Coding não está finalizado até que todos os testes estejam executados
- Unit tests
- Integration tests
- Validação e verificação
- Exaustão de recursos, erros e recuperação
- Testes de performance
- Testes de usabilidade
Use sabotadores para testar seus testes
Não tem como sabermos se nossos testes estão testando todo o código de forma suficiente
- Podemos até usar alguma ferramente de coverage testes
Ache bugs uma única vez ⇒ Se você está tendo o mesmo bug mais de uma vez, é porque seus testes não estão bons.

It’s All Writing (É tudo sobre escrever)

A tinta mais branda é melhor do que a melhor memória
Desenvolvedores não ligam muito para documentação ⇒ Programadores pragmáticos abraçam a documentação como parte integral do seus processo de desenvolvimento
- Escrever uma documentaçõa pode ser fácil por não duplicar esforços, ou perder tempo e mandar a documentação o mais próximo do código, se possível
Dois tipos de documentação: interna e externa
- Comentários em código ⇒ Código deve ter comentários, mas não muitos. Comente coisas que não são tão óbvias como funcionalidades.
  - Nomes de variáveis devem ser escolhidas com cuidado, devendo ter algum significado, e ter cuidado para não significar algo diferente do que você tenha planejado
- Sua documentação precisa ser de fácil acesso e não se perder. Não adianta querer imprimir a documentação e engavetá-la ou até mesmo deixá-la se perder. Coloque-a na web ou algo do tipo.

Great Expectations (Grandes expectativas)

Gentilmente exceda as expectativas dos seus usuários
Comunique e alinhe expectativas
Faça a milha extra ⇒ Trabalhe perto dos seus usuários, compartilhe suas expectativas e os comunique do que você está fazendo para que eles não se surpreendam quando o projeto for entregue. NÃO TENTE SURPREENDER SEU USUÁRIO.

Pride and Prejudice (Orgulho e prejuízo)

Assine seu trabalho ⇒ Programadores pragmáticos não esquivam de suas responsabilidades. Antes nós nos regozijamos em aceitar novos desafios e aumentarmos nossas expertises.

E aí pessoal, o que vocês acharam? Toda contribuição é bem vinda!