Escreva um teste e você tem uma aplicação que não vai falhar naquele ponto, naquele dia – porque você vai esquecer de rodar aquele 1 teste sempre que alterar a aplicação. Desenvolva toda sua aplicação com TDD e você terá uma aplicação mais confiável e com um design melhor.

Utilize um scrum board, e faça reuniões diárias, e o projeto terá transparência. Pratique o Scrum por inteiro e você terá mais transparência, mais software entregue, melhor integração no time, mais visibilidade sobre os resultados, mais confiança no planejamento.

Refatore sempre e você terá código limpo. Refatore de vez em quando… se você conseguir.

Escreva um post no blog hoje, outro daqui um mês ou dois, outro vai saber lá quando e você terá um blog que ninguém visita. Escreva no blog sempre que encontrar alguma coisa que a comunidade pode crescer ao ler, dedique tempo a ele, não deixe ele morrer sem posts, invista no conteúdo, aprenda a escrever, e você terá um blog que é referência, e que ganha visitantes mês a mês.

Escreva um artigo em uma revista hoje, dê uma palestra ano que vem, responda uma pergunta no fórum daqui um uns meses, participe de vez em quando de uma reunião do grupo de usuário que você é parte e você será um consumidor de informação que eventualmente publica alguma coisa. Já é mais do que a maioria, mas se você quer realmente fazer diferença publique artigos com regularidade, palestre sempre que for convidado e busque eventos para contar o que sabe, participe ativamente de um fórum, assuma uma posição de moderação, tome uma posição de liderança do grupo de usuários que participa (seja cuidando da revista, do podcast, do dojo, moderando o fórum, etc). Você será reconhecido na comunidade, as pessoas vão lembrar de você, e quem sabe você até não é nomeado MVP.

Faça exercícios essa semana inteira. Semana que vem faça alguns dias, depois não faça mais. Você perdeu seu tempo. Faça com uma frequência definida, e você vai entrar em forma.

Toque um instrumento sempre e você tocará bem. Toque de vez em quando e você só vai fazer barulho.

.

.

.

Disciplina é chave em praticamente todas as disciplinas humanas. Não espere grandes resultados em atividades que você não se dedica. Fazer pela metade geralmente é igual ou quase igual a não fazer nada. Vai iniciar um projeto ágil? Faça direito, aplique as praticas recomendadas, elas estão lá por um motivo. Vai estudar padrões de projeto? Aprofunde-se no assunto, leia livros, pratique. Só assim você vai ser um desenvolvedor, analista, gestor melhor.

Ou entendemos isso ou continuamos eternamente na mediocridade.

Voltando no assunto do princípio da responsabilidade única, eu já havia dito para dar aos seus métodos uma única razão para mudar. Há um motivo a mais: acoplamento temporal.

Isso acontece quando você tem uma função que faz mais de uma coisa, ou seja, tem mais de um motivo para mudar.

Por exemplo, você tem uma classe produto, que tem uma propriedade "Preco". Alguém chama o método "EntrarEmPromocao". Esse método calcula o percentual de desconto com base em algum cálculo complexo, e aplica o desconto na propriedade "Preco".

Pronto, você tornou sua classe mais difícil de testar. Como eu faço para testar somente o cálculo de desconto? Preciso configurar o preço antes? Ok, separo o cálculo:

void CriarDesconto()
{
    //algum calculo, que no final seta:
    this.Preco -= algumValor;
}
public void EntrarEmPromocao()
{
    CriarDesconto();
    //faz outras coisas relacionadas à promoção
}

Agora está separado. Mas o método CriarDesconto ainda faz muita coisa. Ok, então você separa mais. Cria um método "CriarDesconto", e outro "AplicarDesconto", assim:

private decimal _desconto;
void CriarDesconto()
{
    //algum calculo, que no final seta:
    _desconto = algumValor;
}
void AplicarDesconto()
{
    this.Preco -= _desconto;
}

Depois disso é só chamar no método EntrarEmPromocao:

public void EntrarEmPromocao()
{
    CriarDesconto();
    AplicarDesconto();
}

Ainda assim: como eu testo isso? Tenho que checar a variável privada _desconto? Complicado… Além disso, em que ordem as funções devem ser chamadas? Primeiro eu aplico, ou primeiro eu crio? Até faz algum sentido, mas comecem a imaginar isso em alguns domínios mais complexos…

O jeito é criar um acoplamento temporal, as classes são obrigadas a trabalhar juntas durante um tempo para obter o resultado desejado:

decimal ObterDesconto()
{
    //algum calculo, que no final retorna:
    return algumValor;
}
void AplicarDesconto(decimal desconto)
{
    this.Preco -= desconto;
}

Pronto, não tem como chamar AplicarDesconto sem saber o valor do desconto. Tudo resolvido. A chamada fica clara, assim:

public void EntrarEmPromocao()
{
    var desconto = ObterDesconto();
    AplicarDesconto(desconto);
}

Com isso, a função ObterDesconto é plenamente testável, e não tem mais efeitos colaterais.

Efeitos colaterais são coisas que acontecem quando você não esperava. Você chamava CriarDesconto e ela setava o valor do preço. Isso é um efeito colateral. Agora há responsabilidades claras. Um método obtem o desconto, o outro aplica. Posso testar separadamente.

Estou no meio de uma consultoria, o cliente me pede para ver o código. Eu vou ver o código, claro. Eu olho a classe, olho os métodos, não entendo nada.
"ClienteDB". Isso é nome de classe? O que será que quer dizer? Deixa eu ver o nome das funções. "ObterDados". Nossa, que dados serão esses? Devem ser do cliente, e deve ter alguma coisa a ver com um banco de dados (tem o tal "DB" no final). Mas retorna booleano! Será que esses dados são da conexão com o banco de dados? Não, não, tem um método aqui chamado "Configurar". Configurar… o quê? Será que é a conexão também? Ou será que é configurar o cliente?

Vou então examinar as variáveis. Dentro de um método encontro variáveis com nomes muito interessantes:

1. "obj";
2. "oCliente";
3. "i";
4. "cmp".

Agora ficou fácil!

O mesmo acontece quando estou dando aula. Vem o aluno e me mostra a classe. "Quarto". Métodos: "dormir" e "acordar". O quarto pode dormir? Tudo bem, são alunos, eles podem. Aí é legal, o aluno entende que está aprendendo, aproveita as sugestões e vai em frente, no próximo ele acerta. Mas programadores experientes?

Nomear classes (e funções, propriedades, eventos, ou seja, estruturas em geral) é importante. Se você não consegue dar um nome para sua classe, talvez ela esteja violando o princípio da responsabilidade única. Ou talvez ela não tenha um conceito sólido. De qualquer forma, não dê qualquer nome, é pior. Dê um nome expressivo.

Não se esqueça de que o usuário final da aplicação não é o único. O próximo desenvolvedor que vier depois de você dar manutenção na aplicação também é usuário, só que de outro ponto de vista.

Além disso, não use notação húngara em objetos de negócio. Se você gosta muito de notação húngara, use apenas em objetos de GUI, como txtNome, para textboxes. Não crie "oCliente", ou "objCliente", ou "cliNovo". Não crie "intAnos". Se são anos, só podem ser inteiros, chame de "anos"! Se é um cliente novo, chame de "clienteNovo". Fica mais fácil de ler.

Entrando em uma questão mais de estilo pessoal:

Não use underline/underscore para definir nomes. Nada pior que "nome_completo". Use lower CamelCase para variáveis e campos, como "nomeCompleto", e upper CamelCase para classes, métodos, eventos e propriedades "NomeCompleto", "Andar()", "Click". E use this (C#)/Me(VB) quando acessar campos ou propriedades de uma classe.

Enfim, torne seu código legível (questões de estilo – CamelCase, húngara, underline, etc), e expressivo (usando nomes que explicam a estrutura que nomeiam). O mundo inteiro agradece.

Já fui perguntado algumas vezes qual provedor uso para hospedar este site, domínio, e-mails, etc. Então decidi compartilhar com vocês porque sem dúvida é muito mais barato do que as opções que temos aqui no Brasil, já que é um provedor nos Estados Unidos. Seu nome é Godaddy, e é um dos maiores provedores de lá. Só para vocês terem uma idéia, a hospedagem mais simples deles custa 5 dólares por mês, ou seja, pouco mais de dez reais. E o domínio é uns 10 dólares por ano. E você leva 10 GB de espaço, 300GB de transferência, SQL Server, MySQL, controle total sobre o domínio, 25 subdomínios, e 100 contas de e-mail. Ainda pode usar ASP.Net 3.5 e PHP, tem total controle sobre as aplicações no IIS. O IIS já é versão 7.0 e você leva ainda 50 usuários de FTP.

E a performance dos caras é excelente. É óbvio que a latência é maior do que se estivesse hospedado aqui no Brasil (fica em torno de 200ms), mas ainda assim é pequena, e na verdade não faz a menor diferença, ainda mais no mundo de banda larga como o nosso. Essa latência é mais ou menos a mesma latência do Youtube. Nada mal, certo?

Comparando com qualquer provedor brasileiro, você paga uns 20 reais (o dobro) para ter 5GB de espaço (a metade), e uns 100 GB de transferência (um terço). Mas não tem SQL Server. Resumindo: perde em mais ou menos um quarto do valor, sem contar as funcionalidades…

Se você comparar as contas intermediárias (é uma dessa que eu tenho), você pode hospedar quantos domínios quiser (eu hospedo alguns vários, incluindo o recém criado dotnetarchitects.net), e o espaço sobe para 150 GB (15 vezes mais), e a transferência para 1.5 TB (5 vezes mais), por somente 7 dólares, ou seja, 15 reais. Ainda assim é mais barato que as contas básicas que temos aqui no Brasil. Uma conta dessas aqui no Brasil passa de 100 reais. Não dá nem para considerar.

Para o e-mail eu uso Google Apps. Porque? Por vários motivos: porque foi o primeiro a dar um suporte decente a e-mails pessoais, porque a interface do meu e-mail pessoal (@giggio.net) é a mesma do Gmail (e eu adoro essa funcionalidade de agrupar mensagens de um mesmo assunto como se fossem uma conversa – e de fato são), porque é grátis, e porque meus e-mails pessoais saem sem propaganda nenhuma. E eu tenho direito a 25 e-mails de 7GB cada um. Sete! Gigabytes. Isso dá quase 200 GB de espaço de e-mail. De graça. Ok, eu aceito ver umas propagandazinhas, vale o custo, afinal ainda ganho interface mobile, SMTP, IMAP, POP e tudo aquilo que o Gmail tem. E ainda ganho mais um monte de frescuras do Google, que mal uso, como GTalk interno para o domínio, Google sites, Google Calendar, etc, etc. Tudo com o branding Giggio.net (você troca o logo do Google/Gmail pelo seu). Legal, não é? E o melhor: grátis.

E posso usar Google Apps porque o Godaddy me libera controle total sobre o DNS, então eu aponto meus registros de e-mail para onde bem entender. Hoje botamos o servidor de Subversion do .Net Architects no ar em 15 minutos com o controle de DNS. Até SPF eu tenho no meu domínio, ou seja, você nunca vai receber um spam do domínio giggio.net. Tudo isso por 10 reais por mês, e com uma interface fácil de usar. Fala se isso não faz você desistir de ficar com um e-mail @gmail.com ou @hotmail.com e ter o seu próprio, e abandonar o Wordpress e o Blogger e hospedar você mesmo seu blog, podendo customizar o que você quiser com um software excelente como o Blogengine.net (que roda esse blog e o .Net Architects) ou o Screwturn wiki.

Fica aqui então a dica. Vamos de "um PC em cada mesa", para "um domínio por pessoa".

Observação: gostaria de ressaltar que não tenho nenhuma relação com a Godaddy, isto aqui é só uma dica mesmo. Pago mensalidade como todo mundo e não recebo nada por contar aqui que o serviço dos caras é bom.

O inglês tem um ditado:

"If it ain't broke, don't fix it. "

Quer dizer: "Se não está quebrado, não conserte."

Essa frase devia ser gravada em aço e pendurada em todas as salas onde acontecem atividades ligadas à Engenharia de Software. Cada vez que colocamos a mão em uma linha de código que estava funcionando perfeitamente "só para arrumar um negócio" trazemos um risco gigantesco ao processo como um todo. Não fazemos aplicações cheias de funções independentes, fazemos sistemas que trabalham interligados, com funções que dependem umas das outras.

Esse princípio anda de mãos dadas com o YAGNI (You ain't gonna need it), que sugere que você não adicione funcionalidades, até que elas sejam necessárias.

Todos nós passamos por essa tentação. Aqui no Brasil ela vem com as famosas 2 palavras "Já que":

• "Já que" eu vou arrumar esse cadastro, já vou indentar direito esse código.
• "Já que" eu vou ter mexer nessa inclusão, vou arrumar também a alteração para manter o padrão.
• "Já que" vou incluir uma coluna na tabela, vou aproveitar e trocar a chave que está errada.

Já viu o que acontece depois... Você identou o código e sem querer esbarrou em alguma tecla: pau! Você modificou a rotina de alteração para manter o tal do padrão, e arrancou sem querer uma regra de negócio: pau! Você trocou a chave da tabela, e um cadastro que ninguém sabia que existia (alguém sempre usa...) passou a dar problema: pau!

Se você vai alterar um aplicativo, trate o trabalho como um reparo em uma peça de cristal. Segure-o com cuidado, repasse o plano do que vai fazer, e não mexa onde não deve!

A microsoft liberou de graça um curso de e-learning a sua escolha. Tem que escolher até dia 31/3. Utilizem o link abaixo e aproveitem:

http://www.microsoft.com/learning/elearning/free/default.mspx

Eu já fiz alguns e-learnings deles e são muito didáticos. Vale a pena.

Eu assino o blog da Sara Ford principalmente por causa das dicas sobre Visual Studio, que ela chama de "Did you know..." e já está no número 158. Ninguém aguenta ler tudo de uma vez, mas uma dica por dia traz saúde e alegria! ;)

A última foi bem legal e trouxe de volta uma coisa que sempre senti falta no Visual Studio e que só o VB6 tinha: a possibilidade de criar um projeto de teste sem precisar salvar. Quem usava o VB6 lembra como era: Inicia o Visual Studio, cria um projeto, escreve o código de teste, depura, verifica, e acabou. Se ficou legal, você salva, se não, fecha a IDE e esquece o código, que não vai ficar poluindo sua máquina. Excelente, não?

A configuração está no seguinte caminho: Tools > Options > Projects and Solutions > General > Save new projects when created (desabilite).

Thanks, Sara!