Código Limpo

Bom dia Trailblazers!!!

Hoje vamos conversar sobre um tema muito controverso no nosso mundo de desenvolvedores e desenvolvedoras.

Código Limpo!!!!!

Minha apresentação no Dreamforce´22 foi sobre isso, Code simple, Code right.

https://reg.salesforce.com/flow/plus/dreamforce22/sessioncatalog/page/Catalog/session/1656082526306001wjCE

Hoje passamos mais tempo lendo nosso código do que escrevendo ele.

Então não faz sentido que nosso código seja limpo, preciso e fácil de ler?

Vamos conversar como pegar um código escrito às pressas e aplicar as melhores práticas para refatorar-lo e limpá-lo.

Já escutei várias vezes a pergunta: Por que temos que arrumar ele se ele esta funcionando?

– Sim faz sentido em não se preocupar com algo que esta funcionando, porém hoje temos que ter certeza de que aquele código esteja entendivel por todos que forem ler ele. Quando digo todos, digo todos mesmo, pois não é mais um desenvolvedor ou desenvolvedora que vai ler ele. Hoje temos admins, consultores, analistas de negócio, arquitetos funcionais entre outros, que desejam verificar o que o códigos está fazendo ou pelo menos deveria.

Aqui segue as práticas recomendadas para escrever código limpo no Salesforce

– Fácil de entender por outros desenvolvedores: legível por outros desenvolvedores além daquele que o desenvolveu.

– Fácil de manter: menores chances de introdução acidental de bugs

– Modificado sem medo de quebrar nada: muitos desenvolvedores se orgulham de tornar o código compacto tentando fazer várias coisas em uma linha o que pode ser impressionante, mas torna o código muito mais difícil de ler e entender

Regras para escrever código limpo

– Mantenha seus métodos curtos

– Não se repita

– Os métodos devem fazer apenas uma coisa

– Nomes claros e reveladores de intenção

– Comente para esclarecer não para explicar

– Deixe tudo melhor do que você encontrou.

Padrões de software acordados

– Convenções de nomenclatura

– Recuo

– Espaço em branco

– Chaves  {} fechadas na mesma linha ou não

Responsabilidade

– Comprometer-se a manter o código limpo como uma equipe

– Reter revisões de código para impor padrões

Pensem sobre isso e reflitam o que você tem a ganhar praticando o código limpo e quais os benefícios que isso pode causar na sua carreira.

Compartilhem conosco suas idéias e opiniões sobre este tema, juntos vamos crescer e evoluir no universo de desenvolvimento Salesforce!!!

No próximo post iremos conversar sobre Convenção de nomenclaturas no Salesforce.

Até a próxima!!!

Formatação de código (Parte 2)

Bom dia Trailblazers!!!

Na última postagem falamos sobre formatação de códigos e recebi algumas mensagens perguntando sobre este tema mas voltado ao aplicativo VSCode.

Sim o VScode tem uma extensão chamada Prettier Extension que faz o papel de deixar tudo mais bonitinho.

O que afinal ele faz dentro do VSCode, em seus termos mais simples, ele remove todo o estilo do seu código e o reescreve da maneira que achar melhor. Podemos até configurá-lo para fazer isso toda vez que salvamos, o que é ótimo, pois nos permite escrever nosso código de maneira natural. Prettier então faz o trabalho braçal para torná-lo compatível com um padrão de estilo. Agora vamos dar uma olhada nas especificidades do que considera ser “bom”.

A maior parte da mágica do Prettier acontece quando o número de caracteres atinge um certo limite – ele tentará dividi-los em várias linhas para aumentar a legibilidade. São 80 caracteres por padrão, o que é uma volta aos velhos tempos de programação por terminais.

Antes

Depois

Prettier faz muito mais para ajudar a manter um estilo consistente:

* Adiciona ponto-e-vírgula

* Uso de cotação consistente

* Vírgulas finais consistentes

* Espaçamento consistente entre declaração de função/método e parâmetros

* Espaçamento consistente para recuo (geralmente quatro ou dois espaços/tabulações)

* Espaçamento consistente entre itens entre colchetes

Isso é um monte de coisas que ele faz, e esta nem é a lista completa.

No entanto, por melhor que seja o Prettier, os computadores são burros e precisam saber explicitamente o que fazer, enquanto nosso código está cheio de contexto e informações implícitas.

Embora o próprio Prettier faça um ótimo trabalho, se ajustarmos nosso próprio estilo de codificação apenas um pouquinho, podemos ajudar a levá-lo para o próximo nível.

Os auto-formatadores para nosso código são um excelente ponto de partida para uma maneira bem estilizada e intuitiva de entender as bases de código. No entanto, nós, desenvolvedores, podemos dar um passo além, desenvolvendo bons hábitos para usar em conjunto com nosso auto-formatador para melhorar ainda mais nossa intenção em nosso código. Estes são um pouco mais subjetivos, mas esperançosamente fáceis de entender e integrar em seu fluxo de trabalho.

Aqui seguem dois links para te ajudar com a instalação e configuração da extensão.

https://www.alphr.com/use-prettier-vs-code/#:~:text=Here’s%20how%20to%20configure%20the,Save%E2%80%9D%20when%20you%20are%20done

https://www.youtube.com/watch?v=Gmz27agvLYg

https://www.youtube.com/watch?v=cQqvoUxKIYQ

Agrupando Blocos Lógicos

Isso envolve o uso de quebras de linha para agrupar suas linhas de código em blocos de código menores e logicamente relacionados. Agora, o que queremos dizer quando dizemos logicamente agrupados? Isso pode ser bastante subjetivo e não há uma resposta correta aqui, mas considero isso como linhas de código que estão (aproximadamente) trabalhando na mesma coisa.

Digamos, por exemplo, que estamos definindo um grande número de campos em um registro de contato – poderíamos considerar todos os campos de endereço de correspondência como um bloco lógico. Isso também pode ser aplicado a variáveis ​​de instância, agrupando aquelas passíveis de serem trabalhadas em conjunto ou com tema semelhante.

Quebras de linha antes das declarações de fluxo de controle

Primeiro, vamos definir as instruções de fluxo de controle (qualquer um dos seguintes):

• If/else statements
• Switch statements
• Do while loops
• While loops
• For loops
• Break statements
• Continue statements
• Return statements
• Throw statements
• Try/Catch/Finally blocks

Todas as instruções acima são usadas para definir blocos de código condicionais ou para controlar o fluxo através deles. Uma vez que essas declarações têm um grande impacto sobre como nosso código se comporta, indicar claramente isso para uma leitura é fundamental para a legibilidade. Fazemos isso simplesmente introduzindo quebras de linha antes dessas declarações, no entanto, evitamos uma quebra de linha antes dessas declarações se elas forem a primeira linha de código dentro de seu bloco.

Apesar de sua aparente simplicidade, a formatação do código é um dos aspectos mais importantes de uma base de código. A falta de padronização pode levar rapidamente a um código difícil de manter e propenso a erros, simplesmente porque pode ser difícil para os desenvolvedores entender a intenção original ou simplesmente o que realmente está acontecendo em uma seção do código.

Os padrões de formatação de código ajudam a aliviar esses problemas, introduzindo políticas em toda a empresa sobre como nosso código deve ser. Isso nos ajuda a integrar novos desenvolvedores com mais eficiência e reduz as frustrações do desenvolvedor ao trabalhar em códigos mais antigos.

Já que “o que é melhor” pode ser uma questão altamente subjetiva (e quase certamente levará a divergências), adotar um formatador de código opinativo como o Prettier pode ser uma maneira rápida e indolor de implantar padronizações em qualquer número de desenvolvedores – tudo sem prejudicar as pessoas sentimentos sobre qual estilo é o melhor!

Espero que isso possa te ajudar muito na forma de trabalhar pensando no geral e não apenas em como você entende o código.

Bom aqui finalizamos nossos posts a respeito de formatação de códigos, qualquer dúvida não deixe de fazer suas perguntas e comentários a respeito destes artigos.

Até a próxima!!!

Formatação de código (Parte 1)

Bom dia Trailblazers!!!

Gostaríamos de cada vez ver este grupo crescer, então por isso, por favor compartilhem nas suas redes sociais este canal, tanto aqui da comunidade do Trailhead mas também da Trailblazer (link no final)  logo logo teremos muitas coisas novas e surpresas, como presentes para os participantes e vouchers para certificações, então se não entrou no grupo Trailblazer, entra já.

Hoje iremos conversar sobre formatação do código.

Porque devemos nos preocupar em formatar nosso código?

Primeira coisa que vem na nossa cabeça é para ficar mais bonito, hehehehe, também.

Porém o objetivo principal e mais correto é para facilitar a leitura e suas estruturações. Com isso você criará uma forma mais rápida de verificar seu código, para possíveis alterações, revisões, atualizações ou apenas para tirar dúvidas. E não somente suas porém o melhor de tudo para os outros.

Tenha em mente que qualidade gera lucros futuros.

* Indentation (recuo) – facilita a divisão do seu código implementando a separação por espaçamentos e alinhamentos.

* Spaces (espaços) – facilita a leitura também de uma forma clara.

Exemplo

Estão errados os primeiros exemplos? 

Não, porém qual dos dois exemplos de cada ponto tem uma leitura visual mais clara de blocos?

* Blank lines (linhas em branco) – colocação de linhas em branco aumentam a leitura finalizando seções de códigos que estão logicamente relacionados.

– 2 linhas em branco

Adicione duas linhas em branco entre as seções de um arquivo de origem. Sempre adicione entre a definição de classe e interface/wrapper classes no Salesforce.

– 1 linha em branco

Use uma linha em branco entre os métodos, entre a variável de nível de classe e o método. Use entre a seção lógica dentro de um método para melhorar a legibilidade.

São os pequenos detalhes que muitas vezes fazem a grande diferença e poupam muito tempo na verificação do código.

No próximo iremos falar de layouts.

Gostaria de convidar você a fazer parte dos nossos alertas de reuniões virtuais e presenciais, acesse  o link do Trailblazer Grupo , de um JOIN lá. Assim você receberá os alertas das futuras reuniões e encontro que faremos mensalmente.

Qualquer dúvida, sugestões, críticas e idéais, sinta livre para fazer aqui no nosso grupo.

Até a próxima!!!

After Dreamforce’22 recap!!!

I’d like to start the week by sharing some visions that were very clear in Dreamforce’22.

In addition to the direct API with Whatsapp that shocked many, there are more things coming to light from Salesforce.

One of them is the DevOps Center.

They are investing a lot in centralizing the platform itself in terms of acting as a CI/CD tool.

Of course, it still has a long way to go before it starts to be a tool of first choice for companies that want to implement a process of excellence in CI/CD.

However, they are on the way to improve it a lot. From its release to Dreamforce’22 many changes and updates were made and these were extensively demonstrated in San Francisco.

That’s why I would like to suggest to all developers to start, if you haven’t already, to look more carefully at this solution, because many good and new things are on the way to make our lives easier.

Here follows some links:

– DevOps SalesforceBEN

– Salesforce Blog on DevOps

– TDX22 demo (video)

– Complete setup (video)

This topic will be largely covered by Salesforce, so if you have more information please share it with us!!!!

Code simple, Code right. – simple code, correct code. (Part 2)

To recap from my last post:

Best Practices.

– know how to name the class, its variables, constants, methods…

– know how to comment and not create an explanatory book or not comment on anything

– knowing that the method should only perform one thing in each method

– know that the variables have to be based on the intent of your need

– know that the use of constants should be minimalist and private

– knowing that not only do we have to create the code but that we really care about the coverage of this code.

Another super important point is the separation of points of attention. (SOC – separation of concerns).

Why use declarative mode of code mode.

Oops, but we are developers and we want to code. Developers don’t always code in the Salesforce world!!!

But that’s a conversation for another time.

This point of attention is what separates the impact of your work in an org, what makes it relevant and well structured.

Here we talk about what to do and not how to do it.

For example.

Visual presentation mode.

Declarative – layouts, flow, record type, formulas, reports, dashboards.

Coding – Apex, Visualforce page, lightning component.

What this example tells us, tells us how the developer should know how to choose the best way to build the requested functionality.

In the best way to use what the system provides, in the fastest and most acceptable way of structural architecture.

That’s why I always say that a developer shouldn’t just think like a developer and execute.

We have to have a critical and questioning point, like an architect has.

Thus, the combination of best practices and HOW-TO will transform us into Solution Developers and not requirements deliverers.

Code simple, Code right. – simple code, correct code. (Part 1)

Why talk about this topic?
Simple, because every day we see huge development errors due to the need to deliver quickly and directly.

There is no longer a concern with the quality of the work, but with the speed of it.

And with that we see technical debts grow at an alarming rate, we see customers leave the Salesforce platform saying that it doesn’t work, that it has a lot of problems, that there’s no way to work the way they want and excuses go around.

But is this 100% true? In my opinion and experience, NO!!!

I say yes, about 35% to 40% at most… The rest are development problems and poor consulting performance.

Good, but my focus is on the quality of the code and not on other extra code factors.

When I say good code matters a lot, I mean basic programming principles.
– understandable
– practical maintenance
– does not create fear of breakage in your modification
– scalable and reusable

If we developers focus on delivering code with these characteristics, the amount of technical debt related to code would decrease dramatically.

And how to do it?
Simply using Best Practices.

– know how to name the class, its variables, constants, methods…
– know how to comment and not create an explanatory book or not comment on anything
– knowing that the method should only perform one thing in each method
– know that the variables have to be based on the intent of your need
– know that the use of constants should be minimalist and private
– knowing that not only do we have to create the code but that we really care about the coverage of this code.

We could go a long way here, but these are some of the most basic things we see errors when we access an org and do a technical scan.

Next week I will go into more depth on these best practice points.

How to think about Requirements resolution process!!!

In preparation for my presentation at Dreamforce’22, I was reviewing some articles that I have set aside for reference and as ideas for professional changes and improvements.
And one thing always catches my attention.
Requirements resolution process.
It seems simple and complex at the same time, and it is. I would like to share some points of how I do to use this process in a more productive way.

1- Analysis Phase
simplify the request in the best understandable way, separating it into blocks of information. Many times we receive a request that seems like a book, but to better understand and make our brain start thinking in a more logical way about what we are about to do the division into blocks of information helps to start the process of thinking about what is being asked.

2- Solution Thinking
After this initial analysis and its divisions, we will already have a clearer idea of what we will be working on and our brain is already thinking about how to solve this demand. In this phase we will put the probable solutions for this demand, regardless of their complexity or form of execution, the important thing is to have these solutions listed.

3- Finding the best possible solution
Already with all the thought process and reasoning of the solution for the demand, we will have a fundamental step that is the separation of the solutions and the choice of the best one for that request.
It must be simple, efficient, easy to maintain, and acceptable in terms of the architecture standards followed for development. Remembering that each company has its own standards and ways of working with developments in Clouds and Salesforce Applications.
– simple, what is the easiest way to solve this request? code, flow, formula? we should focus on the practical part of the solution.
– efficient, not always the most complex, just as simple sometimes is not. Here we must think not only about solving the request, but also about the overall medium to long term flow of your action.
– sustainable, what will happen to it if some demand for change comes or some new process is implemented similar to it? can it be adapted or reused? how much effort will we have to change it or adapt it?
– is it the best choice to follow? is this the result I expect or better than what they expect? here the phase of communicating what will be done is primordial, because for us it is the best way to follow but for those who requested it, maybe not due to the result that will be presented in the end.

4- Development phases
after finding the best solution we must think about the steps for its modeling and construction. my suggestion here would be to start at the end asking the question “to reach my final result what would be the previous step until the final result”. this question must be answered until the arrival of the initial phase, so we’ll go more smoothly to the next step.

5- Mapping the steps and elements in the development
With the answers on how to execute each step of the development now we will put on paper each element to execute this step. This is usually where we will invest more time to find out how to perform the action needed at this stage.

6- Assembling and Testing
here is the most fun part of the process, putting everything together and testing…. assembling will be easy but testing will be the “cat’s eye”. mentally we are prepared to execute the ideal test for our solution and the test will be the correct or rather the desirable way to go in the end. But the error tests, most of the time, we don’t execute them as we should. And here comes the mapping of the negative factor, the one of how not to do or execute the process.

7- Implementing
Here we are usually divided into stages of implementation and several times executed by other teams or people. In this phase we put together our package, change set or whatever name you have in the company you work for. But the important thing is to put all the elements you used to create the solution so that it can be implemented in the higher environments until it is implemented in production.

Simple huh!!! On paper yes, but in real life we know that it is not always flowers and our path is more painful and complicated.
But I sincerely hope that this article will make your life or path smoother.
Remember that the developer may be a future architect. Why not think like one right away? Who will gain the most from this is you.

Trailhead, first stop place for Salesforce learning.

Why Trailhead is the first stop place for Salesforce learning?

Well, easy question to answer.

This place provide us, today, all the levels learning material, all Salesforce cloud learning material, all Salesforce tools learning material and all Salesforce applications learning material.

From beginning to Advance level, you will learn reading and doing the hands-on exercises.

I personally love this place and try to connect every single day to check the new stuffs.

But  Trailhead isn’t only a learning place. There is a place to connect to Salesforce communities, check about all the Salesforce applications, get Certification information and much more.

I have a video to assist you to create a Trailhead access, please go there and start your fun journey to Salesforce world.

Salesforce, where do I start?

I started to study Salesforce in 2012, since there a lot things happened in this beautiful world.

Salesforce is growing and growing every single day, this give us the necessity to be ahead of the curve when our customer arrive with them pain points.

We need to keep studying every single day and Salesforce facilitate our life.

www.trailhead.salesforce.com

This is the place i spend a lot time in my weeks, looking for some details that can help me to solve business pains or learn something new about Salesforce applications and clouds.

I really suggest to go there and create a account with fresh develop org and start to learn day-by-day and enjoy the fun way applied in this learning site.

If you have questions how to create a develop org or trailhead account here are 2 videos that will help you.

Please feel free to send me your feedback, comments and suggestions.

Let’s grow together !!!