O cenário é bem conhecido: você tem um prazo apertado e precisa entregar o desenvolvimento o mais rápido possível para dar tempo de testar, empacotar e fazer o deploy em produção. Isso quer dizer: horas extras, acabaram-se os fins de semana, vai comer pizza no escritório. Já viu esse filme? Pois é, eu já o vi várias vezes.
O que a grande maioria dos developers fazem neste cenário? Sentamos a bunda na frente do computador e começamos a produzir código impiedosamente. Funcionamos como máquinas durante nossas horas mais produtivas e praticamente dormimos em cima do teclado enquanto aguardamos o sistema inteiro compilar para executarmos aquele cenário complicado de testes.
Por que isso está errado? Por que chegamos ao fim do desenvolvimento com um código completamente atrapalhado. Resolve o problema mas é o que eu chamo de código peido: só você aguenta ele. Você torna-se dono de uma parte importante do sistema no qual só você mexe e isso é péssimo pois você não vai pegar novos projetos, vai ficar preso no legado quando o sistema no qual você trabalha tornar-se legado até ser demitido por que o sistema legado não justifica mais um time de desenvolvimento.
Uma coisa que aprendi a duras penas foi desenhar o código antes de efetivamente escrevê-lo. Existem diversas técnicas para fazer isso. Use a que for mais atraente para você. O desenho do código serve como uma direção a ser seguida. Isso te obriga a organizar seu código de uma maneira racional e a, pasme, escrever bem menos código do que sair programando igual a um doido.
Desenhar o código é bem diferente de programar em Word. Muita gente acha que desenhar o código é primeiro escrever um documento enorme de especificação para depois escrever código. Na minha ótica, isso é fazer o trabalho duas vezes. Desenhar o código é criar uma base estrutural primeiro para depois preenchê-la com o código que irá efetivamente realizar o trabalho.
Normalmente eu uso um quadro branco para criar alguns diagramas. Gosto de dividir responsabilidades e tento, sempre que possível, componentizar ao máximo o que precisa ser feito. Este é, no entanto, um trabalho interativo. Simplesmente não dá para você tentar desenhar tudo na largada. Eu faço um desenho mínimo e vou refinando-o à medida em que o desenvolvimento flui.
Não fico me prendendo a técnicas ou linguagens específicas para desenvolver esses diagramas. A ideia é criar um guia que me oriente durante a escrita do código. Assim, uso o diagrama mais simples possível para organizar a forma como cada componente será escrito. Gosto de usar um quadro branco pois me obriga a pensar no que estou fazendo justamente por que dá trabalho desenhar à mão. Quando não tenho quadro branco, uso papel e lápis.
Pode parecer meio retrógrado, mas há um motivo para eu fazer tudo à mão: isso me obriga a ordenar o redemoinho de pensamentos que estão na cabeça, me dando foco e minimizando o estresse. Hoje a minha vida é minimização de estresse pois o estresse é um dos grandes responsáveis pela baixa produtividade.
Bom, se o diagrama que fiz ficou importante, tiro uma foto dele com meu telefone e guardo a foto para consulta posterior. Afinal, o que está no quadro branco é para ser apagado. Bem, essa é a forma como eu faço. E isso não é importante. O importante é que você reserve parte do tempo para desenhar a estrutura do seu código antes de começar. Isso vai facilitar sua vida, deixar seu desenvolvimento mais fluido e, com a prática, vai te economizar uma montanha de tempo.
A principal característica do desenho do código é a disciplina que você impõe à sua codificação. Fica mais fácil escrever o código e você naturalmente passa a criar estruturas mais racionais, facilitando a leitura de quem vier depois para manter o código que você codificou (pelo amor de Deus, CODAR não existe no português!).