Bem-vindo à parte #5 do nosso incrível blogpostar e webinar Series! Em nossa série, ajudamos você a analisar todos os seus aplicativos Domino.
O título do webinar para esta blogpost foi “Não acabe em uma vala porque você não estava ciente dos obstáculos em seu código-fonte”.
Desta vez estamos compartilhando Por que, o que e como se deve analisar em seus aplicativos Domino.
Um prefácio para não desenvolvedores
Se você não for um desenvolvedor: A introdução a seguir pode ajudá-lo a entender melhor o restante deste post.
Cada banco de dados em seu ambiente contém elementos de design e código. Isso é para exibir todos os documentos nele contidos. Seja para criar, editar ou lê-los.
As exibições exibem seus documentos em formato de lista. Estes podem ser classificados e/ou categorizados. Por exemplo, por data, nome de usuário ou o que for adequado para o respectivo aplicativo e visualização.
Além das vistas, mais dois elementos de design merecem destaque. Eles ajudam você a criar, editar ou ler documentos em seus bancos de dados:
- Ações nas visualizações (geralmente disponíveis por meio de botões ou opções de menu na parte superior das visualizações)
- e Formulários, bem como campos em formulários
Um banco de dados pode consistir em muitos outros tipos de elementos de design. Cada um deles pode usar uma ou várias das seguintes linguagens de programação:
@Formulas, LotusScript, JavaScript e Java.
Esse código novamente pode ter uma variedade de interfaces e dependências:
- outros bancos de dados Notes/Domino,
- outros aplicativos, como Microsoft Excel ou SAP,
- o sistema de arquivos – seja em clientes ou servidores –,
- o sistema operacional,
- e muitas, muitas outras dependências.
Um aplicativo pode compreender um ou vários bancos de dados e estar disponível em um ou vários servidores. A replicação mantém os mesmos bancos de dados sincronizados entre os servidores. Isso resulta em ótimo desempenho, balanceamento de carga e alta disponibilidade entre regiões/redes.
Ao olhar para otimizar, modernizar ou migrar um aplicativo, você deve saber:
- quão complexo é um aplicativo (pense em tipos e número de elementos de design, bem como linhas de código),
- o que todo o código faz,
- e se o código será fácil de trabalhar em seu respectivo projeto.
Então, vamos começar com Por que
A maioria dos desenvolvedores não desenvolveu todos os aplicativos por conta própria. Mesmo que tenham (chapeau!), provavelmente não aconteceu “todo ontem”, mas ao longo de alguns anos. Você ainda se lembra do código em todos os seus aplicativos bem o suficiente?
Além disso, algumas empresas nem têm mais um desenvolvedor Domino. Muito menos todos os que ajudaram a construir o cenário de aplicativos de hoje ao longo dos anos.
Em seguida, conhecer o código-fonte de um aplicativo é ótimo para executá-lo/mantê-lo no Domino como está.
Finalmente, você deseja encontrar todos os obstáculos, bem como código útil, se não em geral, o bom, o ruim e o feio.
Se você deseja otimizar, modernizar ou migrar seus aplicativos:
Em suma, não seria ótimo se você pudesse economizar tempo valioso, frustração e armadilhas? Conhecendo as partes interessadas de seus aplicativos, torna-se muito mais poderoso quando combinado com a análise do design e do código de seus aplicativos.
Depois de conhecer seus stakeholders, você também saberá:
- Quem será afetado por quaisquer alterações que você fizer em um aplicativo?
- Como eles serão afetados?
- Quem você deve consultar antes de começar a fazer mudanças?
- Quem está recebendo o benefício do trabalho que você está fazendo?
O que nos leva ao que
Antes de mergulharmos em “O que do seu código você deve analisar”, lembre-se:
Há muitos outros pontos de dados importantes a serem considerados antes de analisar o código:
- Quais são seus aplicativos mais usados e menos complexos?
Estes pagam rápido. E você não deve perder tempo com aplicativos que ninguém usa! Para mais detalhes, consulte também SUA PARTICIPAÇÃO FAZ A DIFERENÇA e SUA PARTICIPAÇÃO FAZ A DIFERENÇA. - Quais usuários finais precisam de réplicas locais por motivos de desempenho ou uso offline?
- Quais aplicativos seus VIPs ou seus centros de lucro mais importantes usam?
Estes são apenas alguns exemplos a serem lembrados - mais podem ser encontrados aqui (veja os slides 17-21).
Agora, qual código você deve analisar e o que deve procurar nele?
Tudo isso. Período. Em *todos* seus aplicativos. E para cada um deles, isso significa
- Todo o código: @Formulas, Java, JavaScript e LotusScript
- Todos os elementos de design (pense em “contêineres de código”). Estes podem ser formulários, subformulários, visualizações, colunas, ações, agentes, botões, bibliotecas de scripts, etc.
- Os seguintes elementos de design geralmente merecem atenção especial:
XPages, Java Classes, Applets, arquivos Jar, Web Services, recursos de aplicativos compostos e similares
Análise adequada de ambos os elementos de design do aplicativo e código responde a duas perguntas essenciais:
- Onde está todo o seu código? Quanto é onde? E que tipo de código é?
- O que esse código faz?
Os dois exemplos a seguir mostram o valor de analisar o design e o código:
a) Quanto mais formulários, campos e códigos um aplicativo tiver, mais demorado será para modernizá-lo ou migrá-lo
b) Um aplicativo usando Java Code não é um candidato ideal para migrar para o SharePoint. Sim, isso depende em parte do que o código correspondente faz. No entanto, ajuda você a classificar seus aplicativos eevent armadilhas.
O QUE você deve procurar no seu código
Pesquisar no código pode ser qualquer coisa, de divertido a frustrante.
Depois de exportando o design de seus aplicativos para DXL (Domino XML Language), aqui estão três dicas para você começar:
- Abra o bloco de notas ou similar e explore o resultado. Para ter uma primeira impressão, tente encontrar parte do seu código pesquisando partes dele. Além disso, procure por nomes de usuários, nomes de servidores e similares
- Experimente o LotusScript Manager ou Source Sniffer do OpenNTF
(*não* use o Lotus Analyzer! Ele tem design oculto e telefones para casa) - Pro-Challenge: Divida o código do DXL em documentos em um banco de dados do Notes. Isso facilita a categorização, pesquisa e pós-processamento (para contar elementos de design, por exemplo)
Se você tentou alguma das opções acima, pode ter notado algumas falhas no caminho:
a) Suas pesquisas também correspondem a comentários/observações em seu código
b) Pesquisas combinadas como @Db(Column OR Lookup) pedem primeiro a abordagem acima do pró-desafio
(=fatiando o código em documentos do Notes/Domino ou em um banco de dados SQL). Pesquisas separadas levam a resultados duplicados. Isso, por sua vez, funciona muito contra seu objetivo de revisar o mínimo de código possível.
c) Suas pesquisas também correspondem ao código que você não estava procurando. Por exemplo:
- A pesquisa por "Open" localiza NotesDatabase[Object].Open e NotesStream[Object].Open
- A pesquisa por “@DbLookup” inclui pesquisas no mesmo banco de dados em que o código reside. No entanto, você pode querer apenas pesquisas em outros bancos de dados externos. Ou seu resultado também inclui pesquisas que não são do Notes, como ODBC. No entanto, você pode procurar apenas pesquisas do Notes.
Soluçoantes de continuarmos nossa busca, devemos otimizar o código
Para bons resultados de pesquisa, devemos remover todos e quaisquer comentários de todo o código. Sim, é bom ter comentários em seu código para melhor entendê-lo novamente mais tarde. Mas eles distorcem nossos resultados de pesquisa.
As imagens a seguir ilustram como um desenvolvedor pode comentar no LotusScript e @Formulas:
Em @Formulas, os comentários começam com um REM, seguido por qualquer quantidade de espaço em branco (= espaços em branco ou tabulações). Em seguida, vem o comentário real entre aspas duplas ou colchetes.
Já preparamos o acima para você testar GRATUITAMENTE
Este artigo inteiro ajuda você a entender e executar sua própria análise de aplicativos independente. No entanto, você pode querer economizar um tempo valioso e se mover rapidamente. Tudo que você tem a fazer é inscreva-se no nosso pronto para jogar iDNA Applications sandbox. Assim que você se registrar, tudo que você precisa fazer é fazer o login e navegar até o nosso pesquisa instantânea de código pronta. É verdade que não está mostrando seus próprios aplicativos, mas dá uma boa ideia de como a pesquisa de código deve funcionar.
Para testar, use a pesquisa de texto usando “florian”, “vogler”, “server”, “/acme”, “/O=acme” e “workflow”. Além disso, tente uma pesquisa de expressão regular como “(?iw)@db(lookup|column)”.
Agora vamos realmente mergulhar no QUE procurar *em* todo o código (de design e) de seus aplicativos:
Se você deseja otimizar
- Procure por GetNthDocument – é mais lento que GetFirst/GetNextDocument
- Procure por nomes de servidor codificados, nomes de usuários, nomes de arquivos de banco de dados, endereços IP, endereços de e-mail, IDs de réplica, etc.
- Procure por código antigo (@V2If, @V3Username, @V4UserAccess, @UserPrivileges, @IfError)
- Independente do código: Encontre seus bancos de dados mais usados/populares e dê um pouco de amor a eles. Deixe-os mais bonitos e modernos!
Se você deseja modernizar
- Verifique se um aplicativo depende muito das classes NotesUI*. Isso não funciona em navegadores da web e precisa de algum retrabalho
Verifique se há código que não é compatível com navegadores. Dica: procure na ajuda do Designer por “Você não pode usar esta função em aplicativos da Web”. - Já existe muito código sugerindo suporte ao navegador?
ou seja, @WebDbName, @BrowserInfo, @ClientType, Domino @DbCommands, … - Seu aplicativo/código depende da impressão? Isso pode ser um desafio a partir de um navegador
- Analise seu código para saber se ele funciona em HCL Nomad
- A aplicação depende de XPages, Java ou ODBC? Isso não funciona em HCL Nomad.
- O aplicativo usa chamadas C-API? Se sim, o código também funciona em iOS e Android?
- Independente do código: encontre seus bancos de dados mais usados/populares e dê um pouco de amor a eles. Deixe-os mais bonitos e modernos!
Se você deseja migrar
- Quantos formulários, campos, visualizações etc. tem um aplicativo? Não escolha o mais complexo primeiro.
- Seu aplicativo depende de código ou elementos de design que não funcionam bem em sua respectiva plataforma de destino?
Por exemplo: Java <> SharePoint, muitas pastas <> SharePoint. C-API. Catálogo de endereços privado ou público, Mail (Enviar e) Criptografar. UseLSX, ODBC, DB2, DOS/cmd, OLE, arquivos, diretórios, MIME, links de documentos, etc. - Um aplicativo depende de outros bancos de dados?
Pense em @DbLookups que se conectam a outros bancos de dados (não usando, por exemplo, ““:““ como server:filename, por exemplo). O mesmo vale para New NotesDatabase, GetDatabase, .Open, .OpenWithFailover, .OpenIfModified, .OpenByReplicaID, [FileOpenDatabase], [Compose] etc. - Independente de código e migração: dê um pouco de amor a um dos seus bancos de dados restantes, torne-o mais bonito e moderno.
Finalmente, vamos ver COMO pesquisar melhor seu código
Em parte, já abordamos por que pesquisar código apenas com (sub)strings não o levará muito longe. Corresponde muito ou pouco em muitos casos. Também analisamos por que é necessário remover todos os comentários antes de pesquisar seu código.
Além disso, o seguinte é muito, muito, muito importante ao pesquisar código:
NÃO procure por código pensando em como você o teria desenvolvido. Pense mais amplo e você ficará surpreso ao aprender como outras pessoas codificam.
Então, quais são as melhores abordagens para pesquisar código do que apenas correspondências de substring?
Um índice de texto completo com suporte a curingas como „*“ (asterisco) leva você um pouco mais longe no jogo. Por exemplo, ao pesquisar por „@dbcolumn* OR @dblookup*“ – mas falta suporte para negação precisa. Negar com precisão as partes do código é vital para, por exemplo, encontrar apenas @DbLookups que não apontem para o mesmo banco de dados.
O seguinte @DbLookup procura dados do mesmo banco de dados em que o código é executado. Ele faz isso por meio de ““:““ como segundo parâmetro:
O próximo @DbLookup procura dados do livro de endereços „local“ (cliente ou servidor, dependendo de onde ele é executado):
Procurar por qualquer @DbLookup que procure dados de “names.nsf“ é muito fácil. Mesmo com apenas curingas: @dblookup(:“nomes.nsf“). Isso até você encontrar um código como este:
Agora, de repente, precisamos procurar código em várias linhas – sim, já vimos código assim.
Onde fica ainda pior é quando variáveis, muito menos @functions, entram em jogo como parâmetro:
O código acima procura dados do mesmo banco de dados. A variável ht_filename é o resultado de @Subset(@DbName;-1). Isso novamente resulta no nome do arquivo do banco de dados no qual o código é executado.
Da mesma forma, o exemplo de código a seguir pesquisa dados do catálogo de endereços local:
A melhor solução para pesquisar código seria se alguém pudesse analisar o código. Isso nos permitiria resolver o valor de ht_filename nos exemplos acima. No entanto, não encontramos uma solução inteligente para isso.
O que encontramos uma solução inteligente para a pesquisa de código com negação precisa:
Usamos expressões regulares.
A expressão regular a seguir é um grande passo à frente. Ele nos permite procurar qualquer @DbLookup que não pesquise dados do mesmo banco de dados de onde ele é executado:
@dblookup([^;];(?!””(:””)?).*| @dblookup( | O colchete aberto precisa ser escapado em expressões regulares, daí o \( |
| [^;]*; | seguido por „qualquer coisa menos um ponto e vírgula“ até o próximo ponto e vírgula. Procurar por „.*;“ seria errado, pois essa expressão seria gananciosa. Ele pesquisaria até o último ponto e vírgula. |
| (?!””(:””)?) | Em seguida negando ““, seguido por outro opcional :““ – o segundo parâmetro pode ser ““ ou ““:““ |
| .* | até o fim da linha |
Este exemplo ainda requer alguns ajustes para
- também suporta qualquer quantidade de espaço em branco praticamente em todos os lugares,
- e atende a situações em que @dbname ou @subset(@dbname;1):@subset(@dbname;-1) usam o mesmo banco de dados
- e encontre apenas aqueles @DbLookups para os quais a classe é ““ ou „Notes“ (não diferencia maiúsculas de minúsculas)
Como pontos de bônus, você também pode encontrar @dblookups usados no LotusScript Evaluates. Muitas vezes, as aspas também precisam ser escapadas.
A expressão regular que atende a todos os requisitos acima (exceto para análise de código) é… possivelmente a coisa mais feia que você verá hoje:
Eu poderia continuar e continuar por horas
Se você conseguiu passar pelas coisas realmente assustadoras acima: tiro o chapéu para você! Você é um desenvolvedor de super-heróis e sobrevivente de expressão regular.
A boa notícia para todos os leitores é: Nós da panagenda já fizeram uma boa parte do trabalho pesado. E, nós amamos compartilhar.
Se você der uma olhada no nosso iDNA Applications sandbox, Você vai encontrar mais de 70 expressões regulares prontas. Estes procuram mais de 300 descobertas de código diferentes. Você pode usar todos esses padrões em sua própria solução de pesquisa de código GRATUITAMENTE.
E apenas no caso de você ter uma ideia mais inteligente do que usar expressões regulares ou apresentar algumas expressões regulares novas ou aprimoradas: Por favor, avise-nos e, por sua vez, compartilharemos com o community.
Caso você não tenha tempo para construir seu próprio código solução de pesquisa:
Existem várias soluções de terceiros que podem ajudar. Alguns deles estão disponíveis no OpenNTF. Algumas delas são soluções comerciais como a nossa panagenda iDNA Applications.
Resumindo
Analisar adequadamente seus aplicativos atende a três objetivos principais:
- Economizando (muito) tempo, frustração e dinheiro
- Focar nas coisas certas e estar por dentro
- Possibilitando a transformação bem-sucedida de seu cenário Domino
Otimização, modernização ou migração
- Faça o que fizer, não se esqueça de dar um pouco de amor a pelo menos uma de suas aplicações Domino. Ele vai te pagar de volta. Muitos ti
Próximo em nossa série
Relatórios de progresso. Eles fazem parte de todos os projetos e não são divertidos de produzir. Não é apenas o seu progresso que você precisa compartilhar. Você também deve fornecer às equipes de projeto os dados de que precisam para realizar seu trabalho. É difícil coordenar e nunca termina. Mas os relatórios de progresso podem ser seus amigos quando você relatar sucesso!
Os projetos de migração e modernização são extremamente caros e de alto perfil. Desde o início, muitos olhos estarão em você. As expectativas serão altas. Como você pode evitar que seu projeto falhe? Às vezes você não pode. Alguns projetos estão condenados antes mesmo de começar. Você deve saber antes de ir.
Daqui em diante será uma ampliação contínua do círculo de aplicações em que estamos trabalhando. Cada passo será mais custoso e um planejamento prudente trará benefícios cada vez maiores.
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
