Dominando Programação

Tradução de Mastering Programming de Kent Beck.

Depois de anos observando mestres em programação, percebi alguns padrões em suas formas de trabalhar. Depois de anos treinando talentosos (mas nao mestres) programadores, notei a ausência dos mesmos padrões. Percebi o quanto utilizar estes padrões podem fazer diferença.

A seguir, de que forma programadores eficientes usam seus preciosos 3e9 segundos de passagem aqui no planeta.

O segredo é fazer seu cérebro extender. O programador normal aprende a resolver problemas grandes resolvendo muitos problemas ao mesmo tempo. Os mestres aprendem a resolver problemas ainda maiores resolvendo menos problemas por vez. Parte do segredo está em subdividir de forma que integrar as soluções separadas é um problemas menor do que tentar resolvê-las de uma vez.

Ninja Jiraya

Tempo

• Particionar. Pegue um grande projeto, divida-o em partes menores e reorganize-as da forma que se adeque ao seu contexto. Eu sempre consigo dividir os projetos em partes menores e achar novas permutações de tal forma a se adequar a diferentes necessidades.
• Uma coisa de cada vez Somos tão focados preocupados com eficiência que reduzimos a quantidade de feedbacks para evitar retrabalho. Isto acaba por criar situações difíceis de depurar que no fim das contas tem um custo maior do que o retrabalho que foi evitado.
• Que funcione, funcione direito e funcione rápido. Exemplo de Uma coisa de cada vez, Particionar e Mudanças Fáceis.
• Mudanças Fáceis. Quando se deparar com uma mudança difícil, transforme-a em fácil (isto pode ser difícil), então execute a mudança fácil (e.g. Particionar, Uma coisa de cada vez, Concentração, isolamento). Exemplo de Particionamento.
• Concentração. Se você precisar mudar várias coisas, primeiro organize o código para que a mudança possa ser feita em apenas um elemento.
• Isolamento. Se a mudança é apenas em parte de um elemento, extraia esta parte de forma que este sub-elemento mude por completo.
• Calcular referência. Comece projetos medindo o estado atual do universo. Isto vai contra nosso instinto de engenheiros em começar a colocar a mão na massa, porém quando você tem uma referência você vai saber exatamente se você está fazendo algo útil.

Aprender

• Preveja o que acontecerá. Antes de rodar seu codigo, diga em voz alta o que irá acontecer.
• Hipótese Concreta Quando um programa nao esta funcionando corretamente, estruture exatamente o que você acha que está errado antes de realizar qualquer mudança. Se você tiver duas ou mais hipóteses, ache um diagnóstico diferencial.
• Remova informações irrelevantes. Quando reportar um bug, ache o caminho mais curto para reprodução. Ao isolar um bug, encontre o test case mais curto. Ao testar uma nova API, comece pelo exemplo mais simples. “Todas essas coisas não devem ser importantes” é uma pressuposição cara quando se está errado. (e.g. existe um problema na versão mobile, mas você reproduz usando curl).
• Múltiplos planos. Caminhe entre planos livremente. Talvez seja um problema de projeto, nao um problema de testes. Talvez seja um problema de pessoas, nao um problema técnico. [trapaças acontecem, isto é sempre verdade].

Transcenda a lógica

• Simetria. Coisas que sao praticamente as mesmas podem ser divididas em partes parecidas e partes que sao claramente diferentes.
• Estética. A beleza é uma ladeira difícil de subir ao mesmo tempo é libertador ignora-la. (e.g. agregar várias funções em uma mesma linha criando uma bagunça).
• Ritmo. Esperar o momento certo, poupar energia e evitar desordem. Agir com intensidade quando for o momento certo.
• Custo Benefício. Todas as decisões estão sujeitas a avaliação de custo-benefício. É mais importante saber no que sua decisão depende do que qual caminho você vai tomar ( ou que caminho você tomou ontem).

Risco

• Lista da diversão. Quando uma ideia lhe ocorrer, anote-a e volte ao trabalho. Revisite esta lista na sua hora de descanso.
• Alimente suas ideias. Ideias sao como passarinhos assustados. Se você assustá-las elas vão parar de vir ate voce. Quando tiver tempo, alimente suas ideias. Invalide-as o mais rápido possível, mas baseie-se em dados, não em uma baixa auto-estima.
• 80/15/5. Gastar 80% do seu tempo em atividades de baixo risco e que deem um retorno razoável. Gastar 15% do tempo em atividades de alto risco e retorno alto. Gaste 5% do seu tempo em coisas que te agradem, não importa o retorno. Ensine a próxima geração a fazer os 80%. Na hora que alguém estiver pronto para assumir, um dos seus experimentos dos 15% (ou, mais raramente, um dos seus experimentos dos 5%) terá sido pago e se tornara agora seus novos 80%. Repita.

Conclusão

O esboço acima mostra o fluxo que aparentemente vai desde redução de riscos gerenciando o tempo e aumentando o aprendizado a correr riscos calculados usando todo o cérebro e fazendo uma triagem rápida de ideias.