Você já viu algum desenvolvedor se gabar de ter criado código difícil de ler? Talvez você já tenha se sentido o máximo ao fazer algo assim:
void Run( const std::string& v, int tgt, int start ) { for( ; tgt >= 2 * start + 1; ++start ) Run( v + ' ' + boost::lexical_cast( start ), tgt - start, start + 1 ); std::cout << v << ' ' << tgt << std::endl;} int main() { Run( std::string(), 10, 1 ); getchar();}
(Extraído de http://www.cplusplus.com/forum/lounge/13042/)
Código complexo é código ruim
Bons programadores sabem que a complexidade é sua inimiga. Quando trabalhamos com software de verdade temos de lutar contra ela. A complexidade esconde erros, dificulta a leitura do código e inviabiliza a manutenção. Se nada disso lhe diz muita coisa, pense que o impacto vai diretamente para o seu bolso, principalmente para consultores e freelancers.
Você já precisou dar manutenção em código escrito por você mesmo há muito tempo e teve dificuldades em entender, além de ficar pasmo por ter escrito algo tão hediondo? Será que o cuidado ao produzir código no passado poderia ter lhe poupado de dificuldades e perda de tempo no presente? É claro que sim! E grande esperança há para você se for capaz, hoje, de fazer melhor que antes!
Código complexo é código ruim. Sua manutenção exigirá refatoração abrangente. Você já olhou um programa tão confuso que, antes de modificá-lo, preferia reescrevê-lo completamente?
“Ah, mas pra isso existem os comentários”, você pode argumentar. Não se precipite! Muitos irão lhe contradizer. Processos como o XP enfatizam a necessidade do código ser claro e auto-explicativo. Comentários são por vezes nossos inimigos. Eles podem nos enganar ao declarar algo que o código efetivamente não faz. Em excesso, poluem visualmente o código e tornam nossos fontes mais extensos.
Seja simples
Uma das abordagens para fugir da complexidade é o princípio conhecido como KISS: “Keep It Simple, Stupid!“. Em português poderia ser: “faça isto simples, seu estúpido!”
Resumirei alguns passos deste “programa de reabilitação para programadores”:
- Seja humilde, não pense em si mesmo como um gênio.
- Divida suas tarefas em sub-tarefas: não leve mais do que algumas horas para trabalhar em um código.
- Aprenda muito bem sobre coesão, acoplamento e responsabilidades de classes e métodos.
- Resolva o problema primeiro, codifique a solução em seguida.
- Não tenha medo de descartar código.
Um engenheiro de software experiente deve saber usar as ferramentas à disposição para produzir o resultado desejado com o mínimo de complexidade e esforço. Por outro lado, programadores são apaixonados por “reinventar a roda”. Nos meus primeiros anos, pensava comigo: “para que aprender o framework X se posso escrever o meu?!”. Já reescrevi muitos frameworks. Serviu-me de alguma coisa? Claro! Principalmente em ver minhas limitações e a importância do trabalho alheio!
Exemplo de simplicidade
Pense no cara da direita como você na faculdade e no da esquerda já com alguns anos de experiência.
Conclusão
Quem se importa se o programa leva alguns milissegundos a menos para executar ou se o código é mais “bonito”? O ego do programador?
Um profissional de TI maduro deve se esforçar para aperfeiçoar suas habilidades de comunicação. Isto independe de sua área de atuação, pois todos os artefatos do processo de desenvolvimento, incluindo o código, devem ter qualidade suficiente para cumprir o seu papel e transmitir a informação o mais efetivamente possível.
Além disso, é melhor guardarmos nossas habilidades artísticas para um concurso como o International Obfuscated C Code Contest:
#define _ -F<00||--F-OO--;
int F=00,OO=00;main(){F_OO();printf("%1.3f\n",4.*-F/OO/OO);}F_OO()
{
_-_-_-_
_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_
_-_-_-_
}
