Então eu acordei essa manhã e me alimentei com o elemento que provem vida aos programadores: café.
Eu achava que seria um dia comum… que passaria a maior parte do tempo olhando para letrinhas coloridas, somente aplicando o que eu já sabia. Porem, em um dos últimos e-mails que eu havia marcado com a tag “para ler hoje” me deparei com dois links interessantíssimo enviados por um amigo também programador.
Um deles falava sobre um tal de “DRY” e o outro sobre um tal de “KISS”. A primeira vista pareciam mais uma dessas siglas que nós programadores usamos tanto… Ao ler com atenção percebi que se tratavam de conceitos para tornar meu trabalho mais produtivo. Sendo assim, resolvi aplica-los naquele dia para ver se valeria o esforço de aprender algo novo.
Para minha surpresa, no meio da tarde eu já havia terminado muito mais tarefas do que era acostumado a terminar em sexta-feiras. Eu havia terminando principalmente de escrever código nas linguagens que ainda estou aprendendo, como Ruby, ou tentando algo novo no jQuery (framework de JavaScript). Eu havia aprendido mais!
Nesse dia sobrou tanto “tempo livre” que o usei para escrever minha experiência com esses conceitos novos. Obrigado ao amigo Case que me falou sobre “Do Repeat Youself” e “Keep It Stupid, Stupid“.
Ficou parecido com uma historinha? Era a intenção. É uma historinha, a idéia é trabalhar em cima da seguinte frase:
Tentar a perfeição na primeira implementação é completa especulação. É extremamente difícil julgar a clareza de código que não está escrito, ou a performance de código que você não pode executar.
Wearing Out My Delete Key de James Golick, que eu já havia citado no último post.
Se estúpido for ter o trabalho pronto, o programa rodando e uma nova linguagem aprendida, eu vou ser um pouco estúpido.
Lembro de várias vezes que por otimizações prematuras, que por tentar o “jeito certo” ou a “lógica perfeita” eu não consegui terminar um projeto experimental (prova de conceito).
Porém, me repetindo a mim mesmo eu consigo jogar o que se passa na minha cabeça para o código. Deixo de me preocupar (em um primeiro momento) com os vários conceitos (como o DRY e KISS verdadeiro) que surgem quase todos os dias, esqueço que outra pessoa irá ler meu código, e assim eu simplesmente consigo antes de mais nada, faze-lo. Comentar é um passo após.
Quando você ler novamente sobre otimizações prematuras e o quanto isso é prejudicial, deixe de pensar somente na questão de performance, pense também nas otimizações que metodologias e a aplicação de conceitos trazem, pense se no primeiro momento eles são realmente necessários.
Assim provavelmente você vai se tornar mais produtivo, vai ter mais prazer ao “machucar código”. Mas lembre-se que agindo dessa forma, refatorar se torna muito mais importante. Quando olhar para o “problema lógico” resolvido, volte aos problemas que você teria tentado resolver antes. Lembre-se das questões para quais algumas metodologias foram criadas, agora é a hora de resolve-los, hora de refatorar código: quando ele já está pronto!
RSS
