No primeira parte desta série, falamos sobre como os ambientes Notes/Domino vêm crescendo organicamente em empresas ao redor do mundo ao longo de décadas. Também destacamos o papel desempenhado pelos “Citizen Developers” nesse crescimento. É fácil para não programadores criar seus próprios aplicativos usando modelos. Eles podem até modificar o design e a funcionalidade sem codificação.
O resultado foram os números de banco de dados/aplicativos disparando nos anos dourados do Notes. À medida que mais modelos se tornaram disponíveis, esse desenvolvimento foi ainda mais impulsionado!
O desafio que enfrentamos nos projetos de hoje não é apenas se os bancos de dados são usados ou não. Os gerentes de projeto e desenvolvedores precisam saber para que servem esses aplicativos, quais funções eles fornecem e como eles se integram aos processos de negócios. Um grande desafio, pois eles provavelmente usam apenas uma fração desses aplicativos pessoalmente. Uma maneira de enfrentar esse desafio é aproveitar a semelhança entre os bancos de dados para reduzir o esforço necessário.
Apenas 5-10% do seu código-fonte pode ser único. E daí?
Uma classificação muito alta de código duplicado é muito comum em ambientes do Notes. No panagenda vimos até 97% de duplicação de código em ambientes de clientes.
Há uma boa razão para números tão altos. Os modelos de design em aplicativos Domino são amplamente usados. Modelos padrão como bibliotecas de correio, discussão e documentos são os favoritos. Faz sentido e deve ser incentivado. É mais eficiente incorporar suas funções principais do que desenvolvê-las continuamente do zero.
Na verdade, uma vez que você saiba onde seu código duplicado pode ser encontrado, a duplicação de código pode ser usada para acelerar seus esforços de migração e modernização do Notes!
Usando recortar e colar para acelerar seus projetos de migração e modernização
Poucas pessoas estão cientes desses números. Como eles poderiam ser? Informações como essa são quase impossíveis de coletar. Uma vez que você o tenha, porém, pode ser uma ferramenta extremamente poderosa.
Imagine que seus desenvolvedores conheçam todos os locais de um único bloco de código desde o início. Eles poderiam escrever uma correção, uma vez, para um aplicativo ou modelo. Depois disso, um simples recortar e colar pode ser usado para aplicar essa correção onde for necessário!
Pense no potencial de redução do tempo gasto na codificação quando até 90% da sua codificação pode ser feita com recortar e colar! Não apenas o tempo e o esforço são reduzidos significativamente, mas o perfil de habilidade de parte de seus desenvolvedores muda.
Encontre seu código duplicado – a chave para acelerar
O painel de código-fonte no iDNA mostra rapidamente quanto código está duplicado em seu ambiente. Você instantaneamente começa a ter uma ideia do potencial de acelerar o desenvolvimento em seu próprio ambiente.
Imagine que você está passando por um projeto de migração de e-mail. Você está procurando por aplicativos que podem quebrar quando o sistema de correio muda. Como você pode encontrar essa informação?
Não é difícil. Basta ir ao Catálogo de Banco de Dados. Clique no botão Filtrar. Aqui você pode selecionar “Insights". Insights são problemas potenciais que descobrimos para você durante a análise do código-fonte.
Agora você sabe onde seu recortar e colar precisa ir
Com base neste princípio de código compartilhado, iDNA Applications cria automaticamente “Clusters de semelhança de código”. Eles mostram quais bancos de dados compartilham o mesmo código-fonte e quanto desse código-fonte eles têm em comum.
Nossa experiência em projetos de clientes destacou três use cases onde a duplicação de código e a similaridade podem ser utilizadas para o máximo impacto:
- Encontrar os templates originais usados por aplicativos que não possuem um “Master Template” configurado oficial. Saber quais aplicativos compartilham a mesma estrutura interna e o grau em que essa estrutura é compartilhada significa que você pode criar um roteiro comum para lidar com esses aplicativos.
- Identificando diferenças de design entre instâncias de modelo e banco de dados. Seus aplicativos foram modificados de seus modelos originais? Você vai querer saber! Eles podem exigir mais recursos de programação para processá-los adequadamente em seu projeto. Quando você souber, seus desenvolvedores estarão onde e quando forem necessários.
- Separando aplicativos baseados em modelos padrão IBM daqueles que não são. Muitos aplicativos serão baseados em modelos padrão. Já existirão ferramentas de desenvolvedor que automatizam sua entrega em qualquer projeto. Eles tendem a ser mais fáceis e rápidos de processar.
Não se preocupe. É cuidado para você. São vitórias mais rápidas sem levantar um dedo.
Conheça seu código antes de pegar a estrada do projeto
Ter uma compreensão completa de suas aplicações e suas código cria tantas oportunidades para você. Só conseguimos cobrir alguns:
- Economize tempo
- Melhore a eficiência do desenvolvimento
- Reduza os custos
- Acelere seu projeto
- Melhorar o planejamento e a alocação de recursos
- Minimize o risco de falha
Dê uma olhada na Caixa de areia iDNA e veja você mesmo as possibilidades que esperam por você ou visite nosso Knowledge Base para mais detalhes técnicos.
Surgindo em nossa série
Agora temos uma compreensão básica da tarefa à frente em termos de uso e design. Os próximos passos são sobre colher os frutos mais fáceis e identificar possíveis obstáculos antes que eles se tornem problemas sérios.
Discutiremos a importância de identificar as partes interessadas, a melhor forma de compartilhar nossas histórias de sucesso e o que você precisa para manter o escopo do projeto real.
Registre-se agora para o os próximos webinars or assistir anterior webinars.
Sobre esta série:
Muitas empresas em todo o mundo estão comprometidas com HCL Notes/Domino* por anos. Eles sabem os muitos benefícios que vêm desse relacionamento. Além disso, o Notes/Domino está no centro de seus processos e de como eles funcionam. Apesar de tudo isso, os tomadores de decisões de TI em todo o mundo estão começando a vislumbrar um futuro em que o Notes/Domino pode ter um papel reduzido ou nenhum papel.
*anteriormente IBM Notes/Domino
