The Pragmatic Programmer - 20nd anniversary edition Este livro é considerado por muitos – eu inclusive – um dos clássicos da computação. Dave Thomas e Andy Hunt escreveram a primeira edição deste livro em 1999 para ajudar seus clientes a escrever software de melhor qualidade e redescobrir o prazer pela programação. As lições contidas no livro tem ajudado gerações de desenvolvedores a melhorar seus skills, independente de linguagem e plataforma. Acessar livro

O segundo capítulo de The Pragmatic Programmer, que trata da “abordagem pragmática”, destaca a importância de criar software fácil de modificar (no original, easy to change [ETC]). Programadores pragmáticos assumem a responsabilidade por isso.

A abordagem pragmática inclui práticas e padrões que garantem o desenvolvimento de software que atende os objetivos do negócio e que seja fácil de modificar e que, por isso, continuará “entregando valor” no futuro.

Why is decoupling good? Because by isolating concerns we make each easier to change. ETC. Why is the single responsibility principle useful? Because a change in requirements is mirrored by a change in just one module. ETC. Why is naming important? Because good names make code easier to read, and you have to read it to change it. ETC! Dave Thomas e Andy Hunt

Programadores pragmáticos sempre avaliam se suas iniciativas  – mesmo que elas sejam, by the book, o certo a ser feito – melhoram ou pioram o ETC.

As “boas práticas” se demonstram realmente boas quando tornam o software mais fácil de modificar.

DRY – Don’t Repeat Yourself 

Os autores destacam que o primeiro passo para criar software fácil de mudar é observar o princípio DRY.

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. Dave Thomas e Andy Hunt

Inicialmente e de maneira ingênua, podemos entender DRY  “apenas” como cuidado especial para não “repetir código”. Na versão revisada do livro, os autores destacam que o conceito é mais amplo. Devemos evitar qualquer replicação de registro conhecimento.

Quem “explica”, por exemplo, em comentários o que já está claro no código, está violando o princípio DRY. Classes com atributos públicos representando dados que poderiam inferidos a partir de outros, violam o princípio. Estruturas de dados “telefone sem fio”, como DTOs idênticas a entidades anêmicas de domínio, violam o princípio.

A violação do princípio DRY prejudica o ETC por demandar “trabalho repetido” para ajustar software a novas demandas de negócio, restrições ou atributos de qualidade.

Ortogonalidade

Observado DRY, os autores defendem que o projeto de componentes deve observar ortogonalidade.

Os autores exemplificam ortogonalidade, em sistemas bem-feitos, com a relação entre interface com o usuário e o banco de dados, onde, a interface poderia ser modificada sem se preocupar com o banco e, também, fazer modificações no banco, sem ter de modificar a interface. Ortogonalidade é importante porque colabora para ETC.

You get two major benefits if you write orthogonal systems: increased productivity and reduced risk. Dave Thomas e Andy Hunt

Boa ortogonalidade autoriza a escrita de testes de unidade e reduz a demanda por testes de integração.

The Art of UNIX Programming The Art of UNIX Programming é um excelente livro com ótimos insights para, entre outras coisas, desenvolvimento de sistemas modulares, observando ortogonalidade. Acessar livro

Reversibilidade

Além de DRY e ortogonalidade, programadores pragmáticos optam por implementar suas decisões de forma que elas sejam reversíveis. Tracy e Hunt destacam que toda decisão difícil de reverter converte-se em obstáculo para o ETC. É um erro assumir que qualquer decisão possa ser “escrita na pedra”.

Reversibility is a good thing, because we don’t always make the best decisions the first time around. We commit to a certain technology only to discover we can’t hire enough people with the necessary skills. We lock in a certain third-party vendor just before they get bought out by their competitor. Requirements, users, and hardware change faster than we can get the software developed. Dave Thomas e Andy Hunt

A reversibilidade pode ser obtida, por exemplo, pelo encapsulamento de APIs e recursos de terceiros e pela componentização cuidadosa.

Deprecating Simplicity 3.0 Nesta excelente palestra, Casey Rosenthal – idealizador da prática de Chaos Engineering – aponta a importância de atacar a irreversibilidade como forma de combater complexidade. Acessar vídeo

Reversibilidade precisa ser um concern arquitetural, base para o evolvability.

Tracer Bullets e protótipos

Em muitos projetos de software o grande inimigo é a incerteza. Ou seja, ao iniciar a implementação, é difícil ter “certeza” de que se está no caminho correto. Programadores pragmáticos “validam hipóteses” com implementações ponta-a-ponta (tracer bullets) e protótipos.

Um antigo chefe (e grande mentor) me ensinou que, as vezes, é preciso “passar uma cordinha” (ele era engenheiro e referia-se a necessidade de, antes de projetar uma ponte, verificar se a ligação nos dois lados faz sentido). Thomas e Hunt usam uma abstração diferente, mas com a mesma intenção – devemos testar o design construindo versões mínimas que “atravessem” todos os componentes.

Look for the important requirements, the ones that define the system. Look for the areas where you have doubts, and where you see the biggest risks. Then prioritize your development so that these are the first areas you code. Dave Thomas e Andy Hunt

Growing Object-Oriented Software, Guided by Tests Um dos conceitos fundamentais desse livro é que devemos iniciar software com um walking skeleton, ou seja, a partir de uma feature que explore a arquitetura end-to-end, inclusive ponderando atividades de build, deploy e teste. Acessar livro

Validar o “todo” antecipa problemas estruturais e favorece o ETC.

Domain Languages

As ferramentas que utilizamos influenciam as soluções que imaginamos. Programadores pragmáticos dão preferência a linguagens que se aproximam do domínio para atenderem melhor ao negócio. Bons exemplos são RSpec, Cucumber e Ansible.

Computer languages influence how you think about a problem, and how you think about communicating. Dave Thomas e Andy Hunt

Domain-Specific Languages Neste livro, Martin Fowler fundamenta o conceito de DSLs e ajuda a estabelecer critérios de adoção e desenvolvimento delas. Acessar livro

Quanto mais onipresente for a linguagem do domínio, melhor.

Estimativas

Programadores pragmáticos preocupam-se em fazer boas estimativas – seja de esforço ou de capacidade para os sistemas que desenvolvem. Além disso, programadores pragmáticos usam “unidades de medida” compatíveis com o nível de acurácia que desejam comunicar.

Perceba, dizer que um determinado trabalho consumirá “117 dias corridos” transmite uma ideia de precisão muito maior do que “aproximadamente 4 meses”. Geralmente, será preferível assumir compromissos em “x meses” do que em “x dias”.

Quase sempre, quando o “negócio” pede uma estimativa de esforço, deseja ter uma “ideia de grandeza” e não uma especificação precisa.

Para fazer estimativas bem-feitas, programadores pragmáticos recorrem a adoção de modelos.

Para pensar…

A essência da abordagem pragmática está na construção de software que é fácil de mudar, de maneira a continuar atendendo os objetivos do negócio ao longo do tempo. No meu entender, ETC é a essência da agilidade.

Software fácil de modificar (ETC) é essencial para a agilidade.

Agile is Dead Em 2015, Dave Thomas, um dos autores de The Pragmatic Programming e um dos autores signatários do manifesto ágil, conduziu uma palestra interessante e, também, polêmica. Nela, ele trata das essências da agilidade e provoca reflexões sobre onde podemos melhorar. Acessar vídeo

E você? Leu The Pragmatic Programmer? Tem ponderações sobre o que entendi? Algo importante que ignorei? Te convido a compartilhar suas visões nos comentários. Vamos aprender juntos!

Em breve compartilho minhas impressões sobre o Capítulo 3!