TMACUL

BOAS PRÁTICAS DE CUSTOMIZAÇÃO (continuação) 13/11/2015

Blog Post created by TMACUL Champion on Jan 1, 2016
BOAS PRÁTICAS DE CUSTOMIZAÇÃO (continuação)
Depois de apanhar bastante com algumas customizações feitas por mim e por outros profissionais, acabei praticando um "checklist" de boas práticas que me ajudam diariamente.

1) QUESTIONE: Atue como analista e não como um simples desenvolvedor. Entenda o problema que precisa de solução. Ache a causa raiz dele. As vezes as demandas chegam ao desenvolvedor já descrevendo a customização que deve ser feita na ferramenta e não o problema real que precisa ser resolvido. Esse simples questionamento pode evitar uma customização desnecessária e propiciar uma simples configuração de funcionalidade na ferramenta.

2) CONSULTE: Duas ou mais cabeças pensam melhor que uma. Essa máxima não é a toa. Nunca pense que você está sozinho e que nenhuma empresa enfrenta o mesmo problema que você. Na maioria das vezes, os problemas são iguais e apenas as soluções aplicadas que são bem diferentes. Muitas vezes a própria ferramenta já previu esta funcionalidade e só você ainda não sabe. Aumente seu "networking" com outros clientes da ferramenta, troque experiências, use e abuse do suporte CA e/ou suporte especializado de empresas parceiras. E não esqueça de frequentar comunidades (Ex.: CA Service Desk Manager (Brasil) no Facebook).

3) CONHEÇA: Tenha no mínimo um profissional na sua empresa dedicado na ferramenta. Capacite-se em processos e ferramentas. É sempre bom ter uma certa autonomia para lidar com a ferramenta e não depender exclusivamente de terceiros para operar/parametrizar/customizar sua ferramenta. Sua opinião também é importante.

4) DOCUMENTE: Já que nenhum desenvolvedor é insubstituível e mesmo se fosse, não teria uma memória de elefante, documente suas customizações. Isso parece uma coisa óbvia mas muitas vezes isso não é feito. Se documentar fora do código, legal. Mas não esqueça que é bem provável que esta documentação fique desatualizada com o tempo. O mais fácil é fazer isso diretamente no código. A pior coisa que pode acontecer é você não saber porque uma customização foi feita ou como ela funciona exatamente. Se não quer transformar seu código HTML/SPEL em um bloco de notas, então no mínimo cite o número da demanda que aquele trecho de código visava atender e quem fez isso.

5) ORGANIZE: Se precisar construir uma nova trigger para o objeto "cr", crie arquivos específicos para isso (Ex.: z_cr.mod e z_cr.spl). Se for modificar arquivos HTMPL/JS já existentes, utilize marcações do tipo <!-- Alterado por Fulano - 21/05/2015 - Demanda #15000 -->. E no final da modificação inclua <!-- Fim da alteração -->. Isso ajudará muito no processo de portar customizações para uma nova versão da ferramenta.

6) IDENTIFIQUE: O prefixo "z" recomendado pela CA para qualquer tipo de customização deve ser sempre utilizado. E nas situações que essa prática não seja possível, cite que o objeto foi modificado com alguma outra assinatura (Ex.: (CUSTOM)). Mesmo que isso seja feito em um campo de descrição de algum objeto. Eu costumo não alterar NADA que tenha sido gerado pela própria ferramenta (Ex.: Novos códigos de status, novas funções, acessos funcionais, etc).

7) TESTE: Se for utilizar SPEL, prefira métodos da própria API ao invés de construir os seus. São mais seguros e dificilmente apresentarão erros nas migrações de versão. A CA sempre toma cuidado para que os métodos projetados em versões anteriores continuem funcionando em novas versões. Mesmo quando novas opções são incluídas. Se for utilizar Javascript, prefira jQuery. Gera código mais limpo e confiável em todos browsers. A não ser que você tenha toda a paciência de testar sua customização com todas as versões de browsers presentes na matriz de compatibilidade de browsers da ferramenta. E além disso, quando possível, utilize funções javascript da própria API da ferramenta ao invés de criar sua funções (Ex.: Ao invés de manipular "AlertMsg", utilize "detailReportValidation").

8) PENSE: É sempre bom pensar muito bem antes de iniciar uma nova customização. Estude o assunto Triggers e entenda bem o seu funcionamento. Existe uma enorme diferença entre uma trigger ON_POST_VAL e uma POST_VALIDATE. E se for customizar na camada web, nunca esqueça que o funcionamento desta customização dependerá da infra do usuário. E a qualidade da experiência dele é muito importante. Os assuntos "Browser" e "Performance Javascript" são bem delicados e precisam ser muito bem avaliados. E não esqueça de avaliar os assuntos "segurança" e "confiabilidade".

9) INTERCEPTE: Intercepte erros o mais rápido possível e não seja o último a saber. Nenhum desenvolvedor fica "assistindo" logs de servidor o dia inteiro. Crie mecanismos para ser notificado automaticamente na ocorrência destes erros. E se isso não for feito na camada web, pior ainda. Faça o tratamento adequado para todos os erros gerados no frontend e backend.

10) COMPARTILHE: Faça o seu usuário participar ativamente no processo de homologação de uma customização. Compartilhe sua responsabilidade com ele. Compartilhe código com outros desenvolvedores. Esta é uma forma eficaz de obter "gratuitamente" novas funcionalidades da ferramenta e ao mesmo tempo, gerar conhecimento e experiência.

Até a próxima.

 

Publicado Originalmente: 13 de novembro de 2015 às 12:42

Em: CA SDM Brasil - facebook

Por: daniel-bighelini

Outcomes