Como ser um bom desenvolvedor

Sem dúvida, uma pergunta que recebo recorrentemente é: “Fernando, como ser um bom desenvolvedor?”. Obviamente que não existe uma fórmula mágica, vou compartilhar um pouco do que aplico na minha vida e espero que você consiga bons resultados.

 

Código limpo

Código limpo consiste basicamente em fazer exatamente o que o título diz: ter um código limpo. Código é como uma piada, se você tem que explicar, não é tão boa assim. Até mesmo um código ruim pode funcionar, e – acredite – eu vivo isso no meu dia a dia, tendo que manter um código funcionando que foi escrito por pessoas sem conhecimentos básicos da plataforma Salesforce. Por exemplo, muitas das Triggers que existem na plataforma hoje não são capazes de trabalhar com Bulk Insert. Eu sei que é triste, tem horas que chega a dar vontade de chorar, mas faz parte do nosso mundo de desenvolvimento e você nunca vai encontrar um código perfeito. A partir do momento que você começar a mexer nesse tipo de código, cabe a VOCÊ deixá-lo limpo.

Em toda a minha trajetória como desenvolvedor, eu coloquei a seguinte premissa: se eu tiver que mexer num arquivo que está porco, quando eu acabar eu devo tê-lo deixado ao menos apresentável. Não digo perfeito, mas ele tem que estar melhor do que estava quando eu o encontrei. Dessa forma eu consigo ir colocando as coisas em ordem, mesmo que em pequenas doses.

Se você gosta de uma boa leitura, eu recomendo o livro Código Limpo. Habilidades Práticas Do Agile Software de Robert Martin. Não costuma ser um livro barato, mas eu tenho certeza que ao final da leitura, você verá que valeu cada centavo. E não, não estou ganhando nada pela indicação, mas tenho certeza que todos que lerem vão me agradecer.

 

Nome de variáveis

O nome de um variável deve, ou ao menos deveria, descrever exatamente para que ela serve. Algumas abreviações são bem vindas, mas vamos tentar colocar um limite racional. Imagine uma variável que vai armazenar uma lista de contas, qual seria o melhor nome para ela?

private List<Account> ListaDeContas;
private List<Account> lstC;
private List<Account> lAccounts;
private List<Account> AccountsList;

Eu sei que isso é muito subjetivo, mas eu prefiro a última opção, pois o nome diz o que é, sem ler todo o código para entender quem adiciona o que nesta lista. Você poderia dizer: “Mas Fernando, a primeira também deixa claro o que ela é”. Sim, deixa, mas falarei mais abaixo sobre a utilização do inglês em programação e você vai entender porque eu prefiro a última opção.

O nome da variável deve deixar claro o seu papel e isso evita confusões na maioria das vezes. Às vezes acabamos seguindo um padrão universal, mesmo sem saber. Exemplo: quem nunca fez um for com uma variável i que atire a primeira pedra! Mas afinal, você sabe porque se usa i e não outra letra qualquer? O i vem de Index. Tenho certeza que você vai se lembrar disso na próxima vez que for escrever um loop com for. :)

 

Programe na língua dos computadores

Sabemos que o inglês não é só a língua falada por todos os cantos da terra, como também é a língua dos computadores. A maioria das linguagens de programação são baseadas nesse idioma, inclusive suas documentações. Até mesmo a linguagem de programação Lua, criada por brasileiros, utiliza como base o inglês. Existem exceções, como a Logic Basic, que é uma linguagem baseada em Português. Mas veja como até as exceções acabam se rendendo, afinal o próprio nome da linguagem é em inglês :)

Eu poderia te dar inúmeros motivos para escrever seu código em inglês, mas para minha sorte, meu grande amigo Lucas Caton já fez isso, então sugiro que você assista a este vídeo:

Mantenha o seu código organizado

Essa sem dúvida é a parte que mais me incomoda como desenvolvedor. Já não basta encontrar códigos sem pé nem cabeça, ainda ter que ficar entendendo onde começa e onde termina cada coisa é sem dúvida a pior parte. Veja alguns exemplos do que encontro no meu dia a dia.

Notem a falta de padrão nos nomes das variáveis lstProductsIdsAnexados e selectedContatos. Ambas são listas, porém cada variável segue o padrão que convém :/

Quem nunca comentou um trecho de código? Fazer isso para testar algum efeito colateral é ok, agora subir isso para o servidor não faz sentido. Para mantermos um histórico de alterações no código, devemos utilizar um sistema de controle de versão, como o Git por exemplo. Deixar trechos de código comentados só dificultam ainda mais o entendimento do mesmo.

Não importa o quão simples seja, sempre mantenha consultas SOQL em um arquivo a parte. Isso facilita os testes e separa as responsabilidades. Apesar de não conseguirmos aplicar 100% do conceito de desenvolvimento SOLID no Salesforce, sugiro que você pesquise sobre, isso fará você repensar muitas coisas que você faz no dia a dia.

 

Trailhead

Se você ainda está se perguntando “Como ser um bom desenvolvedor”, vale lembrar que já escrevemos aqui no blog vários posts sobre a importância de iniciar o Trailhead, o qual vai te ajudar a conhecer melhor a plataforma Salesforce. Isso é sem dúvida algo fundamental para ser um bom desenvolvedor Salesforce.

 

Certificações

Por último, se você já passou pelo Trailhead, o próximo passo é conseguir a sua certificação. Ter uma certificação não significa necessariamente que alguém seja um bom desenvolvedor, mas isso te ajudará a trabalhar nas melhores empresas, ao lado de bons profissionais. Também já escrevemos alguns posts sobre certificações, sugiro que de uma olhada nos posts desta categoria. Atualmente eu só tenho uma certificação Microsoft, a qual conquistei na época em que atuava fortemente como desenvovedor C# .NET. Porém estou pegando firme para tirar as minhas de Salesforce; vou começar pela Admin e seguir para as de Dev I e Dev II.

Bom, espero que este post ajude você de alguma forma a encontrar o caminho de como ser um bom desenvolvedor. Deixe nos comentários o que você concorda e também o que você discorda, vamos criar uma discussão saudável a respeito. Até o próximo post! :)