Como se aperfeiçoar como programador

Encontrei faz um tempo atrás em um blog que acompanhava dois postes muito interessantes sobre como ser aperfeiçoar como programador. O primeiro apontava pra um outro post (em inglês) que sugere exercícios para se aperfeiçoar em programação Orientada a Objetos. O outro post fala um pouco sobre como melhorar seu código e muito sobre como se melhorar como programador. Aqui eu vou falar um pouco sobre esses dois posts, das coisas que mais me chamaram a atenção e que eu achei mais interessante. Porém eu recomendo que leiam os posts originais, pois ambos são muito bons, além de encontrarem mais referencias sobre o assunto.

O primeiro post é como se fosse um manual com 9 exercícios a serem praticados para se aperfeiçoar com programador OO, que por sua vez é um resumo de um capítulo de um livro (mais detalhes no post original). O título traduzido deste post seria Aperfeiçoando Pequenas Classes e Métodos Curtos Orientados a Objetos. A proposta é que se escreva um programa de 1000 linhas com as restrições listadas, restrições que devem ser seguidas a risca. Abaixo uma pequena tradução das regras (me perdoem erros na tradução):

1. Use somente um nível de identação por método. Se você precisar mais do que um nível, você precisa criar um segundo método e chamá-lo a partir do primeiro. Esta é uma das mais importantes das restrições no exercício;

2. Não use a palavra reservada 'else'. Teste a condição com o 'if' e saia da rotina se não for satisfeito. Isto previne um encadeamento 'if-else'; e nenhuma rotina merece esta coisa;

3. Encapsule todas as primitivas e strings. Isto direciona diretamente para "obsessões primitivas". Se você quer usar um integer, você primeiro tem que criar uma classe (até mesmo uma classe interna) para identificação do verdadeiro papel. Portanto o endereço é um objeto e não um integer, por exemplo. Isto produz códigos mais claros e testáveis;

4. Use somente um ponto por linha. Este passo impede você de atingir profundamente em outros objetos para pegar campos ou metodos, e conceitualmente quebrar o encapsulamento. Exemplificando, não faça isso:

Order order = new Order(orderId);
string stateId = order.Customer.Address.StateId;

5. Não abrevie nomes. Isto evita a verbosidade processual que é criado por certas formas de redundância - se que você tem que digitar o nome completo de um método ou variável, é provável que você passa mais tempo pensando em seu nome. E você vai evitar objetos chamados Ordem com métodos intitulado shipOrder(). Em vez disso, seu código terá mais chamadas, como Order.ship().

6. Mantenha as entidades pequenas. Não escreva mais do que 50 linhas por classe e não mais do que 10 classes por pacote. A regra 50 linhas por classe é crucial. Isto não somente força a concisão e mantém o foco da classe, mas também mantém a maioria das classes visíveis em somente uma tela do editor/IDE.

7. Não use nenhuma classe em mais do que 2 variáveis instanciadas. Mais de duas instâncias de variáveis de uma mesma classe é certamente a razão para sub-agrupar essas variáveis em uma classe separada.

8. Use primeiramente classes de coleções. Em outras palavras, qualquer classe que contém uma coleção não deveria conter qualquer outra variável membro. A ideia é uma extensão da obsessão primitiva. Se você precisar que uma classe agrupe coleções, então a escreva desta forma.

9. Não use setters, getters or propriedades. Esta é uma abordagem radical para fazer cumprir o encapsulamento. Isto requer a implementação da abordagem de injeção de dependência e adesão máxima ao "Teel, don't ask" (definido em alguns lugares por "Mande, não peça").

Já o segundo post é uma apresentação de Ryan Davis, e eu acho interessante dividi-lo em 2 partes.

Na primeira o autor fala sobre machucar código, mas o que seria machucar código? Bom, basicamente seria modificar totalmente um código legado que tenha sido mau escrito. Imagine aquele código onde quem codificou gosta de complicar as coisas, escreve um código que somente ele entende, cria rotinas desnecessárias... Imagine agora que você passe a ter que cuidar desse código.

É nesse caso que autor prega que devemos machucar o código, reescrever tudo o que não está bem feito, mudar o design se preciso, em fim, melhorar o sistema de uma forma geral. Eu gostei desta filosofia, e a apoio. Pena existirem lugares onde você não tem liberdade para tal.

Já a segunda parte da apresentação fala sobre como se melhorar como programador, pregando basicamente a auto-disciplina para se manter focando no que é necessário fazer e abstenção de distrações que possam atrapalhar seu trabalho. Levando-se isso em conta, isso serve não só para programadores como para qualquer profissional.

Uma coisa muito importante que é mencionado nessa apresentação é que é necessário "entender a sim mesmo tão bem quanto se entender o código" para se chegar a um auto nível como desenvolvedor, e sugere que você se faça constantemente as seguintes perguntas:

• Como eu faço melhor?
• Como eu não vi aquele bug?
• Onde eu estou perdendo em clareza?
• Como eu posso usar melhor minhas ferramentas?
• Onde eu desperdiço meu tempo?
• Como eu me foco melhor?
• Onde eu estou me segurando?
• Onde eu estou errando?

Bom, existe muitas coisas importantes nessa apresentação, aqui a intenção foi dar somente um gostinho para vocês sentirem, e se gostarem não deixem de ver a apresentação.