Sinais Indicativos de um Mau Desenvolvedor ou Programador
Não quero ser mal interpretado, mas, aprendi com meus próprios erros, e com a experiência (programo desde 1992) passei a identificar sinais de que um desenvolvedor tem melhores ou piores aptidões ou mesmo como classificar um programador pelo seu nível, e não pelas suas qualificaçõs em em uma ou outra linguagem. O objetivo aqui, não é fazer ninguém se sentir mal ou de ter escolhido a profissão errada, eu mesmo já tive esses sinais e trabalhei muito para melhorar. Se você não conhece seus defeitos, como pode corrigi-los? Precisamos de alguém que nos diga essas coisas, mas a maioria dos programadores não tem esse alguém e acaba descobrindo da pior maneira possível. Vamos ver quais são esses sinais e como resolve-los para tornar sua experiência como desenvolvedor mais fácil e agradável?
Na maioria das vezes, nós sabemos o que devemos fazer, mas não fazemos, pois achamos que podemos fazer mais tarde e esse “mais tarde” nunca chega. Este é um sinal comum de um programador preguiçoso e o primeiro passo para se tornar um mau programador. Se você já deixou algo “mal feito” porque era mais rápido, ou porque acreditava que aquilo não ia ser um problema imediato, tá na hora de repensar seus atos, e decidir, se realmente é essa função que você quer exercer profissionalmente, e espera crescer e alcançar um bom cargo em uma grande empresa de desenvolvimento, ou mesmo como o líder técnico em um projeto.
Não entender o objetivo do código
Antes de escrever o código, você deve saber as finalidades do código, o que ele fará, todo código em um computador tem 3 grandes objetivos, receber uma entrada, realizar algum processamento ou tomada de decisão e efetuar uma saída. Indiferente de qual linguagem, do nível dessa linguagem, do tamanho da sua função ou do todo do software, esses 3 pontos estarão presentes. Um editor de texto, recebe o texto digitado pelo usuário, realiza as devidas tratativas, e produz uma saída que pode ser um texto impresso ou um arquivo digital. Uma simples função de soma de uma calculadora, recebe a entrada dos dígitos a serem somados, faz o calculo e devolve o resultado.
Ter em mente tudo o que precisa receber como executar e como precisa ser feito para gerar o resultado correto, são tarefas de um bom programador, seria como executar o código em sua cabeça. Preocupações do programador, devem ser saber se tudo o que é necessário está sendo entregue para que a função do código possa ser executada (validação da entrada), executar as devidas operações e preparar a saída no formato estipulado.
São sintomas de um mau programador, quando você mantem variáveis que nunca são utilizadas, ou que ocupam recursos e que já podem ser descartadas, ou mesmo que possam produzir resultados irrelevantes ou incorretos. Chamar funções irrelevantes para o objetivo como executar funções idempotentes, só para ter certeza que algo foi feito. Corrigir bugs escrevendo alguns comentários sobre o que foi feito ou se referindo a qualidade do que estava anteriormente, manter trechos de comentários contendo partes de código. Executar conversão de valor desnecessária, como primeiro converter um decimal em uma string e depois converter novamente a string em decimal.
Remédios para esse problema, use um depurador (DEBUG) do IDE como auxiliar, ou escreva funções e testes. Inspecione o valor das variáveis antes e depois de mudá-las. Atualmente, muitos CODE EDITORS possuem funções que ajudam a verificar funções e argumentos nunca utilizados, além de tipos de dados em variáveis e dezenas de outras funções, saber utilizar estes e outros recursos é um sinal de que você tem melhor ou pior domínio da efrramenta.
Má compreensão da arquitetura da linguagem
Este é um erro muito comum, e não é a primeira vez que falo dele aqui, um bom programador ou um líder técnico deve saber quando utilizar um recurso ou outro, uma ou outra abordagem, até mesmo uma linguagem diferente.
A programação orientada a objetos é um modelo de programação, assim como a programação funcional, a programação declarativa, ou mesmo o estilo de programação procedural. Muitos programadores ficaram confusos quando mudaram de uma arquitetura para outra, e isso é normal, um bom desenvolvedor precisa ter um melhor entendimento dessa arquitetura e saber quando adotar um ou outro estilo.
Os principais sintomas dessa deficiência são o não seguir por exemplo a OOP e os seus padrões chamando funções / variáveis não estáticas em classes não instanciadas. Escrevendo muitas classes “XXXXManager” com todos os métodos para manipular os campos de objetos com um pequeno método ou nenhum método próprio. Tratar um banco de dados relacional como um armazenamento de objetos. Criação de várias versões do mesmo algoritmo para lidar com diferentes tipos ou formatos de dados. Definir valores individuais (em códigos imperativos) em vez de usar vinculação de dados.
Um bom programador ou desenvolvedor não precisa saber TODAS as linguagens do mercado e conseguir tirar o melhor proveito delas, e sim, saber uma ou duas linguagens com proficiência e de preferência de categorias diferentes (como mostrado nos artigos Quais as competencias necessárias e desejaveis para um desenvolvedor backend e também Competência desejaveis para um desenvolvedor FRONT-END) conforme o desejo ou as competências de sua carreira.
Isso não é algo que você possa superar em um dia. Você precisa praticar, praticar e praticar mais, ter proeficiência em uma linguagem significa saber utilizar ela da melhor maneira possível, linguagens multi paradigma podem tornar o código uma verdadeira bagunça, é responsabilidade do programador ou do gerente de desenvolvimento saber o que deve ficar onde, e ter a arquitetura e o paradigma de desenvolvimentos seguidos a risca.
Leitura de documentação e estudos de técnicas e implementações de algoritmos, design patterns (padrões de projeto) e entendimento da arquitetura para a qual você está desenvolvendo. Se você não entende a arquitetura da linguagem ou os fundamentos que esta utilizando, invista tempo para entender melhor.
Siga o código do programador sênior
Desconfie do seu próprio código, quando sua lógica for pobre, você terá dificuldade e pode fazer confusão com as coisas, escrevendo códigos longos e que na verdade não fazem nada. Não é incomum ver códigos fazendo diversas chamadas a funções IsNull () ou IsNotNull (), ou IsTrue (bool) ou IsFalse (bool) desnecessariamente, ou por exemplo verificar se uma variável do tipo booleano é algo diferente de verdadeiro ou falso, chamar as mesmas funções por exemplo para converter e verificar o tipo de entrada e ao término fazer novamente a conversão para um tipo de saída.
Isso não significa que um desenvolvedor sênior é melhor ou pior, porém, a prática já vai garantir boa parte da lógica, e até mesmo previsão de futuro. Para evitar este problema, se você já usou linguagens ou possui alguma experiência com paradigmas e rotinas diferentes, não carregue velhos hábitos desnecessários de uma linguagem para outra. Tenha confiança em sua lógica, e siga o padrão de lógica do projeto.
Não caia na Armadilha da Recursão
A ideia de recursão é complicada, mas não tão difícil, porém, muitos programadores a temem e a vêem como um fantasma. Usar recursão tornará o código mais limpo e mais eficiente, pense nela como uma escada, você apenas tem que imaginar onde você está e como você irá subir ou descer. Algoritmos iterativos complexos para problemas que podem ser resolvidos recursivamente, como por exemplo manipular a árvore do sistema de arquivos, verificar a condição de base antes e depois da chamada recursiva, funções recursivas que não testam uma condição de base, sub-rotinas recursivas que concatenam ou somam uma variável global ou uma variável de saída de transporte. Todos esses problemas são sinais que você não está usando a recursividade a seu favor.
Para melhorar este ponto execute o código em várias etapas para entender o fluxo completo. Se ocorrer algum estouro de pilha, não se preocupe no momento, vá executando teste e mais testes, com condições que alterem a condição de base para ver as saídas e os resultados. Seu objetivo é ter confiança e um senso completo de onde você está, para onde você está indo e a direção correta para onde quer ir, desse modo você terá real noção e entenderá o que está fazendo.
Melhore sua Habilidade de Pesquisa
Linguagens e frameworks modernos têm amplitude e profundidade impressionantes de comandos e recursos integrados, seu conhecimento para dominar totalmente a ferramenta é tão grande que um bom programador precisará de mais do que alguns anos para consumir e utilizar todos os recursos. Um bom programador sempre procura uma função embutida antes de começar a desenvolver a sua própria, por isso saber pesquisar e entender os recursos nativos que a linguagem escolhida lhe trazem, vai render horas a mais de sono e tranquilidade.
Ficar reinventando mecanismos básicos já integrados à linguagem, como eventos e manipuladores ou expressões regulares, reescrever funções mesmo que em outras bibliotecas para substituir alguma que já esteja desenvolvida e nativa propriamente da linguagem e já fazem parte da estrutura.
Saber utilizar fóruns e comunidades na internet, lembre-se muitos programadores experientes ajudam através desses mecanismos, porém, nós não vamos fazer o seu trabalho, mostrar o real ponto onde tem uma dúvida, saber apresentar a solução em que já vem trabalhando é até um incentivo para que pessoas com mais experiência sintam-se motivadas a te auxiliar. Não existe nada mais desmotivador em um fórum do que lêr uma mensagem do tipo “não consigo fazer XXX, alguém pode me ajudar” onde a pergunta correta seria “Estou fazendo XXX da maneira XYXYXYZ porém estou obtendo o erro YYY quando ocorre ZZZ”.
Usar técnicas antiquadas de maneira persistente, simplesmente porque já estou acostumado com isso, mesmo quando novas técnicas já são comprovadamente melhores nessas situações. Em vez de procurar uma solução simples e direta para um problema, tornar o código complexo e pouco aproveitável, ou realizar dezenas de vezes em pontos diferentes algo que poderia ser feito com menos códigos em muitas etapas, ou que pudesse estar em bibliotecas externas.
Não vá a um programador mais experiente ou simplesmente copie e cole o código diretamente quando receber uma luz ou uma resposta das suas dúvidas, se estiver preso em um problema, não tenha pressa, você pode dar alguns minutos para a cabeça pensar e tentar abordar a lógica e o problema por um angulo diferente. se recebeu uma resposta, mesmo que direta, entenda exatamente como o outro programador executou aquela tarefa. Muitos cursos de programação principalmente os intensivos, seguem uma ordem cronológica, isso tem um motivo didático e você deve seguir esses mesmos passos quando encontrar um problema.
Má compreensão de Ponteiros e Estruturas de Dados
Se você não entende o conceito de ponteiros, vetores e coleções ou objetos, será muito difícil escrever estruturas de dados complexas e APIs eficientes, pois vai gerar um projeto de estrutura de dados pobre e cheio de bugs. Falta de conhecimento para diferenciar entre passagem por valor e passagem por referência em chamadas de método e funções, que podem criar enormes vazamentos de memória, falhas ao implementar listas vinculadas e estruturas de árvores, problemas em encontrar ou corrigir bugs que ocorrem por meio de execução aritmética, incapacidade de escrever código que alterem nós de uma lista ou árvore vinculada sem perder ou excluir dados, ou criando longos e complexos loopings para manipular um enorme volume de dados, fazer cópias de volumes de dados simplesmente porque não sabia manipular um ponteiro ou passagem por referência.
Aprender a usar corretamente ponteiros e outras estruturas de dados é tarefa obrigatória para que você possa evoluir na profissão de programador, portanto, invista seu tempo em aprender estas e outras estruturas de dados para poder tirar os melhores resultados delas e do armazenamento dos dados de maneira correta e sem consumos e vazamentos de memória.