Oi pessoal, como vocês estão ? Espero que todos estejam bem.
Estou trilhando mais um caminho na minha jornada de desenvolvedor agora em uma plataforma multitenancy
Force.com e desenvolvendo na linguagem Apex.
Estou desenvolvendo algumas customizações no
Salesforce para uso de soluções para a consultoria em que eu trabalho para alguns projetos e quais são as características principais desta poderosa ferramenta.
Para ajudar vocês nesta jornada, estarei disponibilizando alguns links e discriminando algumas referências para facilitar um pouco mais na sua caminhada.
Todo o administrador deve ser um pouco desenvolvedor, e todo desenvolvedor deve ser um pouco administrador.
O que eu quero dizer com a frase a cima, e que muita das soluções não precisam ser necessariamente customizadas em nível de interface, o Salesforce possui muitos recursos que abrangem que o próprio administrador do sistema possa criar essas mesmas customizações não dependendo somente de desenvolvimento. Então fica essa dica antes de começar a desenvolver estude bem a ideia de como fazer, esgote todas as possibilidades de criar via administração qualquer solução.
Existe algo pronto que eu não preciso fazer gostei da ideia.
Existe várias soluções que estão na App Exchange do Salesforce prontinhas, que você não precisa escrever nenhuma linha de código, mas utilize com sabedoria.
Um bom administrador ou desenvolvedor deve conhecer os limites da ferramenta em que está customizando.
Isto é algo que você tem que levar para sempre e que é importantíssimo quando desenvolver qualquer tipo de customização dentro do Salesforce, ele possui alguns limites pois ele trabalha em uma plataforma multitenancy onde existe vários gerenciamentos de recursos, se isso não for pensado previamente poderá haver vários problemas de performance e até exceções que vão dar muita dor de cabeça.
Teste, reteste e pense sempre em sua cobertura de teste quando desenvolver.
Quando você está desenvolvendo suas Triggers, Classes e métodos Apex entre outros pense sempre em refatorar, porque estou dizendo isso ? Isso é algo que vai te ajudar no momento de migrar as customizações na Org's de desenvolvimento para produção, e lembre-se que a cobertura de código deverá ser 75% para poder realizar o Deploy de qualquer customização que for transferida através de Change Set's.
Para poder testar preciso ter algo para poder testar, crie Mocks.
No momento do desenvolvimento de qualquer teste vocês precisarão dos cenários de testes, antes de começarem a desenvolver peçam antecipadamente o que aplicação deve realmente fazer. Pense em vários cenários que possam seguir vários fluxos que ativem as exceções, validações. Não existe essa de um cenário só, o certo deverá ser vários que atendam os principais fluxos, isso é importantíssimo será o medidor de qualidade do código.
Um bom padrão de nomenclatura, é uma garantia de sucesso para administrador e o desenvolvedor.
Quando a equipe desenvolvimento estiver desenvolvendo mesmo com a correria, dedique um tempo na nomenclatura de todos os objetos que deverão ser criados e de todas as classes, isso ajudará muito na organização, pelo menos nem que seja meia hora. Vocês vão perceber o ganho quando tiver umas 200 Classes. 😆
O administrador e desenvolvedor tem que achar as soluções juntos.
Isso é primordial estou falando em um Pair Programming, isso faz parte também da primeira citação onde os dois devem ter quase o mesmo conhecimento, digo a vocês que vai ser muito difícil desenvolver sem o administrador da ferramenta, que cria os campos e outros processos de fluxo de trabalho e de negócio não estar do seu lado, você pode bater em um
Process Builder ou
Workflow do Salesforce quando executar sua trigger ou um método, sem saber. Então nada de ficarem separados um deve esta do lado do outro, ou perto ou se comunicarem todos os dias tirando todas as dúvidas.
Utilizar um Padrão vai definir o sucesso na manutenção e no desenvolvimento.
Então é bom se preparar para desenvolver em um determinado padrão de arquitetura, e nível de programação e a nível de documentação, saiba utilizar com sabedoria, lembre-se de cada objeto e classe e suas responsabilidades. Existem vários padrões de arquitetura, mas na minha opinião o que se encaixa melhor na maioria das customizações é o de
Service Layer.
Espero que tenham gostado dessas dicas, no início me serviriam de grande ajuda.
Um Abraço.
Referências:
https://trailhead.salesforce.com/
https://developer.salesforce.com/blogs/
https://www.youtube.com/watch?v=n9amswhOxJw&list=PLRXcsQvlIqgipsM0VADllCPdT75L4iDLI
https://developer.salesforce.com/page/Apex_Enterprise_Patterns_-_Separation_of_Concerns
