Fazer um balanço das personalizações da sua organização
Objetivos de aprendizagem
Após concluir esta unidade, você estará apto a:
- Identificar o valor comercial e tecnológico da avaliação do estado atual.
- Identificar o que procurar em uma base de código.
- Identificar como examinar os processos e a personalização declarativa.
Na obra “Reason in Common Sense” (Razão no senso comum), o poeta e filósofo George Santayana escreveu: “Aqueles que não conseguem lembrar o passado estão condenados a repeti-lo”. O mesmo se aplica às equipes que criam aplicativos. Dedicar tempo a identificar o que foi criado em sua organização — e por que foi criado, e quais padrões foram usados à medida em que foi criado — lhe prepara para o sucesso futuro.
Começar os esforços de adoção observando o estado atual de sua organização permite identificar claramente os problemas antes de começar a fazer alterações. Por exemplo, identificar a dívida técnica — essas decisões de implementação que faziam sentido antes, mas que agora estão impedindo a inovação. Você também pode encontrar oportunidades de se envolver melhor com as partes interessadas certas e fazer ajustes em suas equipes antes que os processos estejam muito adiantados.
Olhar para a maneira como você tem trabalhado antes de começar a mudar tem muitos dos mesmos benefícios para a sua tecnologia e para as equipes de fornecimento de aplicativos. Também pode lhe dar a oportunidade de identificar que problemas ou frustrações em seus sistemas atuais são criados por ferramentas ou tecnologias ultrapassadas — e que problemas decorrem de questões humanas. Estes problemas relacionados ao aspecto humano são os que você realmente precisa resolver antes de tentar adotar qualquer nova tecnologia ou funcionalidade.
Então, como você começa a examinar a sua organização como ela se encontra hoje?
Examine seu código
Examinar sua base de código pode parecer assustador. Especialmente se você é novo em uma organização ou se sua organização tem muito código. Mas compreender como as diferentes partes da sua organização se relacionam entre si é uma parte essencial e necessária para identificar como começar a gerenciar sua organização em unidades mais precisas e significativas.
Então, o que você procura em seu código?
Tipo de código | O que procurar | Perguntas a fazer |
|---|---|---|
Acionadores | 1. Padrões de acionador 2. Lógica do acionador | Sua organização tem um acionador por objeto? Existe lógica comercial ou de aplicativo escrita diretamente em um acionador? Os acionadores “entregam” lógica ou funcionalidade para outras classes (também chamados de manipuladores de acionador)? |
Classes do Apex | 1. Convenções de nomenclatura 2. Comentários 3. Versão de API | As classes do Apex utilizam prefixos comuns ou mesmo namespaces para agrupar unidades de código? As classes têm nomes semelhantes, com base na funcionalidade? A finalidade e a autoria do código estão documentadas nos comentários? As classes têm comentários que ajudam a esclarecer a funcionalidade? Quais versões de API as classes utilizam? |
Testes do Apex | 1. Padrões/unidades de teste 2. Cobertura de código 3. Tratamento de dados de teste | Como os testes se relacionam com o outro código? Cada classe tem seu próprio teste? Seus testes estão organizados em grupos funcionais? Há partes de sua base de códigos não cobertas por testes? Seus testes dependem de fatores de dados comuns ou de recursos estáticos? Algum de seus testes usa a anotação “seeAllData=True” ou roda em uma versão de API anterior a 24? |
Componentes e eventos do Lightning | 1. Convenções de nomenclatura 2. Comentários 3. Controladores do Apex 4. Versão de API | Os componentes utilizam prefixos comuns ou mesmo namespaces para criar grupos? Os componentes têm nomes claros, relacionados à funcionalidade? Os eventos do Lightning são eventos de aplicativo ou eventos de componente? A finalidade e a autoria dos componentes e eventos estão claramente documentados nos comentários ou nos arquivos de documentação do Aura? Os componentes utilizam controladores do Apex? Quais versões de API os componentes e eventos usam? |
Visualforce | 1. Convenções de nomenclatura 2. Comentários 3. Controladores do Apex 4. Versão de API | As páginas e componentes do Visualforce usam prefixos comuns ou até mesmo namespaces para criar grupos? As páginas têm nomes claros, relacionados à funcionalidade? As páginas usam controladores do Apex? Quais versões de API as páginas utilizam? As páginas são usadas com algum modelo de e-mail? |
Estas peças ajudam a identificar padrões dentro do código em sua organização. Mas pode ser que estas técnicas não o ajudem a entender cada peça de sua base de código. Ou, se sua base de códigos não parecer estar consistentemente organizada, você pode precisar tentar outras maneiras de descobrir como o código de sua organização está conectado.
É aqui que a nova API de Dependência pode ajudar. Ao executar novos tipos de consultas, você pode identificar como seu código e metadados estão organizados. Você pode, por exemplo, olhar um componente do Lightning em uma determinada página, ou o controlador do Apex de uma determinada página do Visualforce, e rastrear todas as outras peças de metadados que de alguma forma se conectam a esse controlador do Apex ou componente do Lightning. Você também pode usar estas consultas para identificar os pedaços de metadados que não estão mais em uso e decidir se é seguro excluí-los.
Examine seus processos e sua personalização declarativa
E as personalizações declarativas que você realizou em sua organização? Como você pode começar a olhar para coisas que você criou com cliques e não com código?
Uma maneira de começar é usar o Salesforce Optimizer. Esta ferramenta pode recomendar maneiras de melhorar alguns dos recursos em sua implementação do Salesforce. Depois de analisar seu relatório do Optimizer, você pode analisar mais profundamente os processos de sua organização e as personalizações declarativas.
Então, o que você deve procurar?
Tipo de personalização | O que procurar | Perguntas a fazer |
|---|---|---|
Fluxo/fluxo visual | 1. Convenções de nomenclatura 2. Padrões relacionados a objetos 3. Versões ativas/inativas 4. Lógica de fluxo 5. Telas de fluxo | Os fluxos utilizam prefixos ou nomes semelhantes para criar grupos? Os fluxos têm nomes claramente relacionados à funcionalidade? Os fluxos têm descrições claras e atualizadas? Com que objeto(s) um fluxo interage? Qual é a relação entre fluxos inativos ou versões de fluxo e fluxos ativos? Os fluxos colocam funcionalidades comuns em subfluxos, ações invocáveis ou ações rápidas? Se os fluxos têm telas, elas são baseadas em componentes do Lightning? As telas dependem de certos objetos e campos? Existem automações desatualizadas que precisam ser transformadas em fluxos? |
Objetos e campos | 1. Convenções de nomenclatura 2. Tipos de registro 3. Layouts de página 4. Permissões 5. Substituições de ação | Foram criados objetos personalizados que duplicam o comportamento de objetos padrão? Várias unidades de negócios usam os mesmos objetos ou campos? A lógica de negócios e as validações são diferenciadas por tipos de registros? Os objetos e campos têm descrições claras e atualizadas? |
Você quer criar uma noção clara de como seus processos e personalizações declarativas têm sido bem organizados até o momento. Se você achar que sua organização não é tão organizada quanto gostaria, tudo bem. Agora é o momento de identificar os lugares onde sua equipe pode trabalhar para aumentar a qualidade e desenvolver alguns padrões que podem ajudá-lo a construir uma organização mais saudável e avançar. Você também pode identificar os projetos que você quer enfrentar primeiro, para limpar peças de sua organização.
Fique ligado
Nos próximos meses, adicionaremos mais recursos e oportunidades para colocarmos em prática estes conceitos. Você poderá explorar metadados desemaranhados, criar pacotes e aprender mais sobre o gerenciamento de pacotes desbloqueados.
