Boas festas

23.dezembro.2008

Boas festas aos leitores desse espaço. Depois do Natal eu volto.

Cheers!

Anúncios

Links para hoje

22.dezembro.2008

Boa leitura 😉


Refactoring

15.dezembro.2008
Dei uma refatorada nos posts antigos. Acho que agora ficaram mais legíveis.

Só falta descobrir o porquê da imagem de fundo não ser carregada corretamente em algumas situações.

Update: Corrigi a questão da imagem de fundo. Era uma tag HTML que não foi fechada.


Backlog para 2009

12.dezembro.2008
Nunca gostei de resoluções de ano novo. Sempre fiquei com a impressão de que são listas feitas já sabendo que não serão cumpridas. Perder peso, mudar de emprego, perder peso, comprar um carro, perder peso, terminar a faculdade, ou começar, ou fazer a pós, ou simplesmente perder peso.

Esse ano resolvi fazer uma lista semestral de resoluções. A idéia é simples: pra mim, um ano é tempo demais para se ter um feedback rápido. Como ainda tenho tendências procrastinadoras (poucas ;-)), prefiro trabalhar com prazos curtos e metas realistas, mesmo que ambiciosas. No segundo semestre tirei as duas certificações que eu queria e finalmente dei entrada num lugar para morar.

Como eu fiz para me mexer? Simples. Bastou dar um passo. O outro foi um pouco menos difícil, o outro menos, e assim por diante. O ponto é criar uma inércia benéfica para conseguir o que se quer. Claro, ter listas para não perder as metas de vista é sempre bom. Hoje eu até acho que uma lista de coisas que não serão feitas é ainda melhor do que nenhuma lista de coisa nenhuma.

Para o primeiro semestre de 2009, quero dar pelo menos uma palestra em alguma faculdade ou evento, e estou me preparando para pelo menos mais uma certificação. Isso é ser realista. Uma meta um pouco mais agressiva seria conseguir três certificações durante o ano que vem. Possível, mas vamos dar um passo por vez.

Enfim, se alguém precisar de um palestrante em algum evento de proporções modestas, pode contar comigo.

(Propaganda, é? Há!)


Sem comentários

11.dezembro.2008
Antes de mais nada: o que vou escrever aqui não se aplica a linguagens de ‘baixo nível’, como Assembly, por exemplo. Se você utiliza Java, Delphi, C#, Ruby ou qualquer outra que possa ser chamada de ‘alto nível’, pode continuar lendo.

Comecemos com uma ordem: não comente seu código.

Plaft. O impacto da ordem e os trolls agitam os dedos para começar a criticar.

Para que servem os comentários no código? Ensinaram na escola que é para informar suas intenções aos outros programadores. Teoricamente, quando o próximo coitado abrir o seu código, ele vai entender perfeitamente todas aquelas amarrações e voltas lógicas que você deu no código, apenas se guiando pelos comentários. Genial, não?

Agora, me mostre um só código legado, daqueles sem testes e que passaram na mão de pelo menos vinte estagiários, que tem os comentários perfeitamente atualizados e consistentes com a abordagem utilizada no código. Pois é, esse é o segundo problema que encontramos ao usar comentários. O primeiro, se você ainda não percebeu, é o retrabalho de ter que escrever código e em seguida escrever comentários para explicar o que o código faz.

Claro que ainda não te convenci. Anos de vício não se perdem em uma leitura. “Tudo bem, é só apagar aquele comentário que não faz sentido”. Vou usar um exemplo que encontrei aqui mesmo, no projeto em que trabalho.

O que a linha abaixo quer dizer?

int t = 0;

Nem mais, nem menos. Para mim, está sendo declarada e inicializada uma variável t. Para que serve, eu não faço idéia.

Vamos então comentar o código. Claro, assim o próximo sujeito que der manutenção nesse código vai entender perfeitamente o que estou tentando fazer aqui.

// tentativas de login
int t = 0;

Opa, bem melhor agora, não concorda? É óbvio que t é exatamente a mesma coisa que tentativas de login. Claro. Como não pensei nisso antes? Assim, no meio do código, basta você encontrar a variável, voltar ao local onde ela foi declarada e ler o porquê dela existir. Ou então, você pode ser uma pessoa bem legal e comentar cada linha onde a variável é utilizada. Se você for mais legal ainda, logo você terá um código de 300 linhas, sendo que 160 delas são só comentários. Legal mesmo.

Só que eu não sou um cara legal. Eu tenho preguiça de escrever comentários. Eu acho que um código de 300 linhas com 160 linhas de comentário é uma nojeira difícil de ler. Eu acho uma perda de tempo ter que reescrever comentários para cada linha que eu altero do código. É demorado, pouco produtivo e sujeito a erros. “E então, espertão. Como você faria?”

int tentativasDeLogin = 0;

Que tal assim? Sem comentários, sem nenhuma explicação adicional. Apenas código, puro e simples. O código se torna uma forma clara e concisa de documentação.

Ferramentas como NetBeans, Eclipse e Visual Studio, automatizam o ato de renomear um membro da classe dentro do escopo correto, o que honestamente, me faz desacreditar em qualquer argumento a favor do uso de comentários em detrimento da legibilidade do código.

Por falar em legibilidade, vou começar a inserir linhas entre os parágrafos. Pelo menos para mim isso ajuda muito na hora de ler textos maiores. Espero que te ajude também.

😉


Entrevistando

10.dezembro.2008
Acabei de sair de uma entrevista para trabalhar aqui na empresa. Basicamente, não tinha mais ninguém para entrevistar o rapaz e eu fui escalado em cima da hora.

De repente pode ser um tiro no pé dizer isso, mas eu sinceramente detesto fazer entrevistas. Deve ter algum meio mais fácil, prático e não-traumático de se fazer isso.

Imagino que o cara deva ter faltado no trabalho, pegou trânsito para chegar atrasado aqui e estava um calor desgraçado. Eu fiquei até mais tarde, estressei com a empresa de consultoria por não ter colocado o telefone do candidato no currículo, apliquei uma prova que eu não sei se realmente avalia alguma coisa relevante ao cargo, fiz meia dúzia de perguntas e dispensei o cidadão.

Acho que, nessa hora, o melhor a fazer para os dois lados é ser claro e objetivo, sem enrolar e sem tentar ser o que não é. Deixei claro, ao ser questionado, que não sou eu quem contrato, nem avalio os currículos. No lugar dele eu teria me perguntado “mas então, que diabos estamos fazendo aqui?”. É o que me perguntei.

Enfim. Boa sorte ao colega, dando certo aqui na empresa ou em qualquer outro lugar.


Clean Code Talks

09.dezembro.2008
Miško Hevery, o cara responsável por ensinar os desenvolvedores da Google a manter seus códigos limpos e testáveis e, acidentalmente, meu atual mestre na arte de desenvolver software de modo claro e com qualidade, publicou uma palestra sobre o uso de polimorfismo para substituir IFs e SWITCHs. O que pode parecer nada além do básico de orientação a objetos acaba sendo negligenciado ou esquecido no ambiente real de desenvolvimento.

Espero que seja tão útil para vocês como tem sido para mim.   

Share and enjoy 😉