Nós desenvolvedores odiamos os “sobrinhos” não apenas porque eles destroem o mercado, cobrando mais barato pelo trabalho. Mas porque, geralmente, eles arrumam emprego e daí somos obrigados a dar manutenção no código deles. O que nos leva a seguinte pergunta: Você odeia o sobrinho, mas será que você não programa como um?
so·bri·nho (latim sobrinus, -a, -um, primo direito)
substantivo masculino
Indivíduo que cobra baratinho para fazer aquele programinha ou sitezinho.
Martin Fowler, em mais de um dos seus aforismos geniais, disse:
“Qualquer idiota pode escrever código que um computador entenda (…)”
Fazer código, juntar blocos, fazer as coisas funcionarem é, de modo geral, fácil. Mas nenhum profissional escreve um programa apenas para funcionar. Isto é o mínimo que se espera dele. Um profissional escreve um programa para dar lucro. E não importa qual é o seu modelo de negócio, você sempre passará mais tempo fazendo a manutenção do software do que o escrevendo de fato. E o tempo gasto na manutenção influencia diretamente nos seus lucros.
E é aqui que separamos os sobrinhos dos profissionais: O sobrinho está preocupado apenas em ver o software funcionando (software entregue). Ele não pensa no amanhã, ou seja, na manutenabilidade do sistema. Ele quer o dinheiro dele hoje para poder gastar tudo em toddynho e em camionetes. Já o profissional sabe que, se não for ele mesmo, outra pessoa terá que fazer a manutenção do código.
Eu já programei como sobrinho — quem nunca? — mas estou saindo dessa vida, com a ajuda dos amigos e família. E como eu sou teu amigo, vou compartilhar um pouquinho do caminho das pedras:
Estude gestão de projetos!
Não estou falando para você decorar o PMBOK. Mas você precisa conhecer o mínimo. É a forma mais fácil de você se comunicar com o teu gerente de projeto (ou de você gerir o seu próprio projeto). As empresas que valem a pena trabalhar estão mais preocupadas com a gestão dos seus projetos. Esta é uma das responsáveis pela saúde do produto final e da empresa. Se SCRUM, Kanban, Agile e XP são termos desconhecidos pra você, pode ficar desesperado: você é um sobrinho!
Conheça OO e algum outro paradigma
Se você sequer saber o que é Orientação a Objetos, pelo amor de Deus, sai daqui e leia um livro sobre o assunto. Se você já conhece, ótimo! Que tal aprender outro? Aprender outro paradigma vai abrir os seus horizontes. E principalmente te dar a oportunidade de intercambiar ideias. De repente, alguma coisa do paradigma funcional possa te ajudar em OO?
Conheça e SAIBA os padrões de projeto
Se você programa OO, é possível que até mesmo que já os esteja usando. Se este é o seu caso, com certeza está um semi-parto. Assim, o famoso livro Padrões de Projeto pode ser uma mão na roda. É uma teoria que foi desenvolvida na prática e que, se implementada, pode facilitar muito as coisas pra você. Também te aconselho a dar uma olhada no material criado pelo André Celestino que demonstra como aplicar padrões de projeto em Delphi(!!!).
Pense CLEAN CODE!
Muita gente pensa que é perfumaria essa história de utilizar padrões de nomenclatura para variaveis, objetos, units; criar milhões de classes para matar o que parece ser uma mosca… O Clean Code vai te dizer que não é apenas perfumaria. Um código limpo e legível, respeitando uma série de princípios da própria orientação à objetos, cria uma inestimável economia de tempo na leitura e na produção de código.
Deixe o programa pensar em tempo de execução!
Pense que o seu programa pode criar código por você! E não estou falando daquele “pograminha” (sic) que gera os DTO’s pra você. Estou dizendo que, se escrever uma linha de código, você pode chamar uma View qualquer, que recebendo só o nome de uma tabela, já cria todo o CRUD pra você. Isto só pra ficar num exemplo. Como isso é possível? Através de Reflection, RTTI e todas essas features que permitem que o software “pense sobre a sua própria existência”. Mas com certeza, só isso não torna a mágica possível. É aí que padrões fazem todo o sentido e a diferença (lembra das “perfumarias” do Clean Code?).
Perfeito é melhor que feito
Refatorar não é só trocar a gambiarra de lugar. Retirar essa dívida técnica do seu código é importante. Contudo fazer essas alterações inadvertidamente é muito perigoso. Existem técnicas (e livros sobre elas) para fazer o refactoring. Conheça-as o quanto antes. Não importa se você vai apenas mudar os nomes das variáveis ou a tecnologia de acesso à dados.
Seja poliglota
E não estou falando de saber falar inglês. Aprenda outras linguagens de programação. Vejo muita gente dizendo que “Ah, mas o Delphi está copiando o Java”, “Ah, mas o C# está copiando o Java”. Quando o que realmente importa é “Quais boas soluções da linguagem X eu posso usar na linguagem Y? É implementável?”. Aprender novas linguagens de desenvolvimento também é aprender novas formas de resolver problemas.
Enfim…
Tem mais? Claro que sim! Estar em contato com profissionais, por exemplo, é importantíssimo. Para se inteirar das novidades, conseguir aquela indicação, mas também para conseguir um feedback do seu trabalho. E assim fazer esse caminho das pedras ter mais paradas, mas também ficar mais suave!