O artigo com o título: Top 10 Traits of a Rockstar Software Engineer é, em minha opinião uma resposta sensata para a pergunta citada acima. O artigo apresenta uma lista de 10 características que definem um engenheiro brilhante. Seguem minhas experiências e pontos de vista sobre cada um dos aspectos citados no artigo:
1. Loves To Code
Acho que isso se aplica a qualquer coisa que uma pessoa possa fazer. Qualquer tarefa é executada melhor quando há uma pitada de paixão envolvida. Você tem que amar o que faz para poder fazer bem feito. Além do mais codificar não é uma ciência exata. Como dito no artigo: "codificar é uma arte", e toda arte precisa de um pouco de paixão para dar certo.
2. Gets Things Done
Essa é um gancho de direita no queixo desse pessoal que sai da faculdade querendo ser SQE (Software Quality Engineer): "There are plenty of technical people out there who talk about software instead writing it". Como pode uma pessoa descrever como construir software sem nunca ter construído um (projetos de faculdade definitivamente não contam). Bons engenheiros resolvem os problemas de forma simples e objetiva. Vale enfatizar: simples e objetiva. Num software em JavaME, um dos requisitos consiste em salvar as configurações do usuário (aproximadamente 5 bytes) em RMS. O que você acharia se, para esta simples tarefa, um engenheiro levasse 2 semanas e entregasse 6 classes, aplicando nelas inúmeros padrões de projetos? Particularmente achei horrível! “Keep it simple, son”. Mas não entenda esse tópico erroneamente. O processo de análise é muito importante e muitas vezes é necessário muita pesquisa e análise para achar a maneira mais simples de implementar um componente específico, mesmo que ele seja pequeno.
3. Continuously Refactors Code
"Coding is very much like sculpting". Que mais posso dizer? Se você não sabe fazer refactoring ou se sabe e não aplica no seu dia-a-dia, a probabilidade do seu código não ser dos melhores é alta. Refactoring é uma disciplina que não pode ser ignorada. Li num livro que os projetos de software deviam ser feitos sempre duas vezes. Que apenas depois de observar os erros cometidos da primeira construção, os engenheiros estariam realmente preparados para implementar o projeto "de verdade". Refactoring tem mais ou menos esse conceito: escreva a primeira versão, observe os erros, rescreva e repita o processo até que você acredite que o código está perfeito. Certamente não estará, mas estará bom o suficiente. De quebra você ainda vai descobrir alguns errinhos que você acabou de cometer, e como está com o código fresquinho na cabeça, vai resolve-los em segundos.
4. Uses Design Patterns
"A good engineer always recognizes and leverages patterns, but is not driven by them." Conheça Design Patterns e saiba aplicá-los inteligentemente. Ao contrário do que muita gente pensa, Designs Patterns não devem ser usados em todas as classes que você criar. Apenas use onde é realmente necessário e útil. Dessa vez, ênfase no "útil". Lembra das seis classes e dezenas de padrões aplicados para conseguir salvar 5 bytes no RMS? Muito cuidado com o uso errôneo dos Patterns. Se quando aplicados corretamente soam como verdadeiras obras de arte, quando aplicados de maneira equivocada podem ser grandes vilões, afinal, quem desconfiaria de um todo poderoso Design Pattern? Eu. Na minha curta vida de desenvolvedor, não vi nenhum padrão ser tão reincidentemente mal aplicado quanto o Singleton. Banir esse Pattern é a solução aconselhada por vários gurus, repetindo uma cruzada semelhante à travada contra o "goto" em 1900 e bolinha. A que ponto chegamos. Portanto, não acredite que padrões de projetos são a solução para tudo. Eles são apenas mais uma ferramenta à disposição e você não vai querer usar uma chave oitavada onde o mais indicado é uma tesoura.
5. Writes Tests
Você não sabe o que isso pode fazer por você e pelo seu software. No final do ano passado minha gerente me deu feedback que eu precisava melhorar minhas habilidades com testes. E ela estava certa. Meus códigos saiam do forno com dezenas de centenas de bugs. E testar é chato. Bom mesmo é escrever código. Então, por que não unir o útil ao agradável e escrever código para testar seu código? Perfeito! No inicio do ano tive de implementar um pequeno banco de dados OO e resolvi aplicar Unit Tests nele. Resultado já faz quase um ano que ele está sendo utilizado, testado e re-testado e apenas 5 manutenções corretivas foram feitas. O primeiro bug só apareceu depois de 3 meses. Nada mal, hein? Fora o benefício de estar muito mais seguro quando minha gerente me perguntou como estava o progresso do desenvolvimento do componente. Eu sabia exatamente onde estavam meus problemas e pude informar com firmeza o andamento do trabalho. Experimente uma vez, e não largue mais.
6. Leverages Existing Code
A chave nesse tópico é: "Não reinvente a roda". Apóie-se em código que esteja pronto e que já tenha sido provado e aprovado. Procure código pronto no próprio projeto, nos projetos antigos e no google. Se já existe um componente pronto para ser usado, por que escrever um novo e ter que gastar preciosas semanas debugando e testando esse componente? Apenas tenha atenção com as licenças dos componentes que você quiser usar.
7. Focuses on Usability
Essa tarefa nem sempre é fácil. Muitas vezes quem define essas coisas não somos nós, mas sim o pessoal de Marketing e Vendas. Mas faz parte dos ossos do ofício pelo menos avisar quando algo não está lá uma Brastemp. De preferência já sugerindo uma possível alternativa. Por outro lado, se a usabilidade depender apenas de nós, pobres engenheiros, o software, quase que certamente, vai ser um fracasso nesse quesito. Tente delegar essa tarefa aos designers, mesmo que eles sejam completos excêntricos, vão produzir melhor resultado que engenheiros. Certamente o ideal é uma aliança entre os três setores.
8. Writes Maintainable Code
O código fonte tem duas funções básicas: implementar uma funcionalidade corretamente e informar claramente como essa funcionalidade está sendo implementada. Fatalmente, alguém, um dia, terá realizar manutenções nesse pedaço de código que você acabou de escrever. E esse alguém pode ser você mesmo. Podemos escolher entre tornar isso um martírio ou apenas em mais uma tarefa a cumprir. Comente seu código, siga os padrões de nomenclatura, e nada de escrever código ofuscado. Apenas mantenha em mente que há a possibilidade de você ter de fazer manutenção no seu próprio código daqui a um ano e que, nessa ocasião, não lembrará mais do que fez. Naturalmente o código estará bem documentado e auto-explicativo.
9. Can Code in Any Language
10. Knows Basic Computer Science
Não tenho o que acrescentar nesses últimos dois tópicos. Você não pode se apegar a uma linguagem, a ponto de não conseguir usar outra. Isso é um erro grave, acima de tudo, profissinalmente. Tampouco pode se dar ao luxo de não conhecer algorítimos de estruturas de dados, conceitos de banco de dados e paradigmas como liguagens estruturadas ou orientadas a objetos.
Aconselho que confiram o artigo na fonte e aproveitem para lê-lo e extrair alguns pontos os quais não mencionei aqui.
