Decidi então fazer um review do ultimo livro que li, já começo dizendo que tenho sempre boas impressões dos livros do Kent Beck, e desta vez, não foi diferente.

Neste livro, entramos no mundo das tidyings que são pequenas mudanças que não alteram o comportamento das nossas aplicações. Elas são semelhantes às refatorações, mas menores em escopo e impacto, ou conforme descrito no livro “pequenas refatorações fofas e difusas que ninguém poderia odiar”.

Agora vou tentar fazer um pequeno apanhado capítulo a capítulo.

1. Guard Clauses

Descreve algumas técnicas de organização que sugere adicionar guard clauses às rotinas. O retorno antecipado para reduzir a lógica condicional aninhada. Este conselho também é semelhante à técnica Substituir Condicionais Aninhados por Cláusulas de Guarda do livro Refatoração , embora o autor não a faça referência.

2. Dead Code

A defesa da exclusão do código morto nesse capítulo, parece bem óbvia não é? Infelizmente muitos devs ainda não usam as ferramentas de gerenciamento de código da forma mais adequada. Portanto sim, por favor, sejam legais e excluam códigos que não são utilizados.

3. Normalize Symmetries

Basicamente, tenha a mesma solução para problemas iguais em pontos diferentes do sistema.
Muitas vezes os mesmos problemas podem ter soluções diferentes quando o sistema vai ganhando um tamanho maior, e fica confuso para quem está a ler o código.

4. New Interface, Old Implementation

Para diminuir a complexidade, no capítulo é sugerida a criação de uma nova interface que simplifique assim a interação com a antiga implementação.

5. Reading Order

Reordenar partes do arquivo para que seja mais fácil de entender para quem está lendo.

6. Cohesion Order

Quando um sistema está a crescer muito e requer a alteração de vários pontos amplamente dispersos no código, você pode ficar tentado a refatorar o código existente para torná-lo mais coeso. A sugestão é apenas colocar o código coeso um ao lado do outro antes de uma refatoração maior e recomenda a dissociação apenas quando:

Porém, pode não ser viável por vários motivos:

• A dissociação pode ser um esforço intelectual (você não sabe como fazê-lo).
• A dissociação pode exigir muito tempo/dinheiro (você poderia fazê-lo, mas não pode se dar ao luxo de aproveite esse tempo agora).
• A dissociação pode ser uma extensão do relacionamento (a equipe sofreu tantas mudanças quanto ele pode lidar agora).

7. Move Declaration and Initialization Together

A maioria das linguagens modernas incentiva a declaração e a inicialização juntas. Portanto, por favor, sinta-se incentivado a mantê-las juntas.

8. Explaining Variables

Em vez de usar uma expressão complexa na inicialização de uma estrutura ou na invocação de um método, o autor recomenda o uso de variáveis ​​bem nomeadas para extrair as subexpressões. Este conselho é semelhante à técnica Extract Variable do livro Refactoring.

9. Explaining Constants

Substitua números mágicos por uma constante simbólica.
Se você tiver uma constante definida em um módulo, não será necessário importar esse módulo apenas para reutilizar essa constante.

10. Explicit Parameters

Recomenda-se a passagem de parâmetros explícitos em vez de passar um mapa que pode incluir muitas propriedades não relacionadas. Ou seja, não passe uma estrutura de dados composta quando uma rotina usa apenas partes dela.

11. Chunk Statement

Técnica recomenda adicionar uma linha em branco entre partes do código que estão extremamente relacionadas. Porém, você pode usar outras técnicas de refatoração, como Move Method ou outras.

12. Extract Helper

Técnica em que você extrai uma parte do código que tem interação limitada com outro código para uma rotina auxiliar. Nesse caso, o autor cita o Extract Method do livro Refactoring .

13. One Pile

Quando dividir um código em vários pedaços minúsculos, o autor recomenda colocar o código em uma única pilha e depois organizá-lo.

14. Explaining Comments

A sugestão é comentar apenas o que não é óbvio no código da perspectiva do leitor. Outros usos de comentários podem ser TODO quando um código apresenta um bug ou requer alterações para outras limitações.

15. Delete Redundant Comments

Acho que esse capítulo deveria fazer parte do anterior, basicamente sugere a eliminação de quaisquer comentários óbvios no código.

16. Separate Tidying

Faz parte da segunda parte do livro que descreve como a organização se encaixa no ciclo de vida de desenvolvimento de software.
Ao fazer alterações para organizar, você terá que considerar o tamanho dessas mudanças, de quantos PRs você precisará e se deve combinar vários PRs para estruturar.

17. Chaining

Pequenas etapas de organização e baseadas em várias técnicas de organização discutidas na primeira parte do livro.

18. Batch Size

Quantos PRs relacionados à estrutura e ao comportamento para organização devem ser feitos antes da integração e implantação?
Quanto mais PRs forem feitos com as alterações o custo e o risco também aumentam, devido aos conflitos no merge.
A recomendação é: PRs menores para reduzir o custo de revisão e reduzir o custo de arrumação, porém as equipes terão que encontrar o equilíbrio.

19. Ritmo

A sugestão é gerenciar o ritmo para tidying em PRs onde cada mudança leva alguns minutos ou uma hora antes de permitir as mudanças de comportamento desejadas. O autor cita o princípio de Pareto e argumenta que 80% das alterações ocorrerão em 20% dos arquivos, então você pode acabar tocando no mesmo código para arrumar, por isso o autor sugere arrumar em pequenos incrementos.

20. Getting Untangled

Ao fazer mudanças de comportamento, você poderá ver muitas oportunidades para ajustar as mudanças de estrutura, mas isso pode resultar em uma combinação de mudanças de estrutura e comportamento. Nesse caso, você pode ficar tentado a criar um único PR para todas as alterações, o que pode estar sujeito a erros; dividir a arrumação em PRs separados, o que pode acrescentar mais trabalho; descarte suas alterações e comece novamente com a tidying.

21. First, After, Later, Never

Este capítulo discute a organização em relação a uma mudança de comportamento no sistema. Vamos lá:
Never
Quando o código não exige mudança de comportamento ou um velho mantra “se não está quebrado, não conserte”.

Later
Geralmente é uma fantasia, mas basicamente você terá que estimar o trabalho de tidying.

After
Quando o código estiver confuso e você precisar alterar o mesmo código novamente em breve, para que seja mais barato arrumar agora e o custo da tidying seja proporcional ao custo da mudança de comportamento.

First
Quando simplificará a mudança de comportamento com benefícios imediatos, desde que o custo possa ser amortizado com mudanças futuras.

22. Beneficially Relating Elements

A terceira seção do livro que discute o design de software, o custo das mudanças, as compensações com o investimento na estrutura do software e os princípios para fazer mudanças.
Neste capítulo design de software é definido como “elementos relacionados de forma benéfica”, onde os elementos podem ser compostos e ter subelementos como átomos->moléculas->cristais, e os elementos podem ter limites.
Os elementos podem ter relações com outros elementos, como Invokes, Publishes, Listens, Refers, etc., e os elementos se beneficiam mutuamente na criação de sistemas maiores.

23. Structure and Behavior

O software cria valor ao fornecer o comportamento atual e como ele pode ser estendido para mudanças futuras. O autor mostra como o software pode agregar maior valor ao oferecer suporte a opções de extensão.

24. Economics: Time Value and Optionality

No capítulo, ele conta como aprendeu sobre a natureza do dinheiro por meio de uma série de projetos relacionados a finanças.

25. A Dollar Today > A Dollar Tomorrow

Um dólar hoje é mais valioso do que um dólar amanhã porque você não pode gastar o dólar futuro ou investi-lo.
À medida que o comportamento do software cria valor e ganha dinheiro agora, ele incentiva a organização após a organização excessiva.

26. Options

Algumas definições em termos de design de software com opcionalidade:

• Quanto mais volátil for o valor de uma possível mudança de comportamento, melhor.
• Quanto maior a duração do desenvolvimento, melhor.
• Quanto mais barato o software custar no futuro, melhor.
• Quanto menos trabalho de design para criar uma opção, melhor.

27. Options Versus Cash Flow

O fluxo de caixa descontado tende a ganhar dinheiro mais cedo e não arrumar primeiro e as opções do outro lado tendem a gastar dinheiro agora para ganhar mais dinheiro depois ou arrumar first/after/later. O autor recomenda tidying primeiro quando:

cost(tidying) + cost(behavior-change after tidying) < cost(behavior-change without tidying)

Porém, em alguns casos, você pode querer arrumar primeiro, mesmo que o custo com arrumar primeiro seja um pouco mais alto.

28. Reversible Structure Changes

As alterações estruturais são geralmente reversíveis, mas as alterações comportamentais não são facilmente reversíveis, por isso requerem revisões e validações mais rigorosas. Alterações de design, como a extração de um serviço, não são reversíveis e requerem planejamento cuidadoso.

29. Coupling

O acoplamento impulsiona o custo do software e quanto mais elementos forem acoplados, maior será o custo da mudança.
Além disso, alguns acoplamentos podem ser em cascata, onde cada elemento desencadeia mais alterações para elementos dependentes.
Em resumo, é essencial compreender as mudanças dependentes antes de arrumar tudo.

30. Constantine’s Equivalence

O autor usa a distribuição da lei de potência (gráfico em forma de sino) para representar graficamente o custo por tempo que cresce lentamente, depois rapidamente e depois diminui.

cost(change) ~= cost(big change)

cost(big change) ~= coupling

cost(software) ~= coupling

31. Coupling Versus Decoupling

Ter algum acoplamento é inevitável, porém o acoplamento pode não se tornar um problema. Por exemplo, você pode tentar reduzir o acoplamento em uma parte do software, mas ele muda para outras partes. Isso significa que você deve tentar encontrar um equilíbrio avaliando as compensações com o custo da dissociação.

32. Cohesion

Ao desacoplar, você pode agrupar subelementos sob o mesmo elemento contendo mais coesão e mover elementos não relacionados para fora do grupo. Quando os subelementos são alterados em conjunto, beneficiam de coesão com facilidade de alteração e análise.

33. Conclusion

Kent Beck incentiva a organização do código, mas alerta contra fazer muito. Confesso que tenho que me conter mais.. hehehe
Ele resume que “arrumar primeiro” é impactado pelo custo da mudança, pelas receitas que gera, pela forma como o acoplamento pode ser reduzido para tornar as mudanças mais rápidas e como irá adicionar coesão para que as mudanças tenham um âmbito menor. 

Minha opinião

Esse livro diz muito sobre qualidade e velocidade de entrega de software que cada equipe precisa enfrentar.

Recomendo muito esse livro, é bem conciso, contém alguns insights muito úteis, o tamanho dos capítulos tornam a leitura mais agradável e não deixa de ser muito educativa.

Espero que tenha conseguido resumir bem o que absorvi de cada capítulo e conto com vocês pra discutí-los.

Abraços.