Добро пожаловать в пятую часть нашего удивительного blogпосле и webinar серии! В нашей серии статей мы поможем вам проанализировать все ваши приложения Domino.

Название webinar для этого blogпост был «Не попадите в кювет, потому что вы не знали о препятствиях в исходном коде».

На этот раз мы расскажем, почему, что и как следует анализировать в ваших приложениях Domino.

Предисловие для не разработчиков

Если вы не разработчик: следующее введение может помочь вам лучше понять остальную часть этого сообщения.

Каждая база данных в вашей среде содержит элементы дизайна и код. Это для отображения всех содержащихся в нем документов. Будь то для их создания, редактирования или чтения.

Представления отображают ваши документы в формате списка. Их можно отсортировать и / или разделить на категории. Например, по дате, имени пользователя или тому, что подходит для соответствующего приложения и представления.

Помимо видов стоит выделить еще два элемента дизайна. Они помогут вам создавать, редактировать или читать документы в ваших базах данных:

  • Действия в представлениях (обычно доступны с помощью кнопок или пунктов меню в верхней части представлений)
  • и формы, а также поля в формах

База данных может состоять из многих других типов элементов дизайна. Каждый из них может использовать один или несколько из следующих языков программирования:
@Formulas, LotusScript, JavaScript и Java.

Этот код снова может иметь множество интерфейсов и зависимостей:

  • другие базы данных Notes / Domino,
  • другие приложения, такие как Microsoft Excel или SAP,
  • файловая система - будь то клиенты или серверы -,
  • операционная система,
  • и многие, многие другие зависимости.

Приложение может содержать одну или несколько баз данных и быть доступным на одном или нескольких серверах. Репликация обеспечивает синхронизацию одних и тех же баз данных между серверами. Это приводит к отличной производительности, балансировке нагрузки и высокой доступности в разных регионах / сетях.

Рассматривая оптимизацию, модернизацию или миграцию приложения, вы должны знать:

  • насколько сложно приложение (подумайте о типах и количестве элементов дизайна, а также строк кода),
  • что делает весь код,
  • и будет ли легко работать с кодом в вашем соответствующем проекте.

Итак, начнем с того, почему

Большинство разработчиков не разрабатывали все приложения самостоятельно. Даже если они и сделали (вводная часть!), Скорее всего, это произошло не «вчера», а за пару лет. Вы все еще достаточно хорошо помните код во всех своих приложениях?

Кроме того, у некоторых компаний больше нет даже разработчика Domino. Не говоря уже обо всех, кто на протяжении многих лет помогал создавать современные приложения.

Далее, знание исходного кода приложения отлично подходит для запуска / поддержки его в Domino как есть.

Наконец, вы хотите найти все препятствия, а также полезный код, если не в целом хорошие, плохие и уродливые.

Если вы хотите оптимизировать, модернизировать или перенести свои приложения:

В общем, было бы здорово, если бы вы могли сэкономить драгоценное время, разочарование и подводные камни? Знание заинтересованных сторон ваших приложений, становится гораздо более мощным в сочетании с анализом дизайна и кода ваших приложений.

Узнав своих заинтересованных сторон, вы также узнаете:

  • На кого повлияют любые изменения, внесенные вами в приложение?
  • Как они пострадают?
  • С кем вам следует проконсультироваться, прежде чем начинать вносить изменения?
  • Кто получает выгоду от работы, которую вы делаете?

Что подводит нас к тому, что

Прежде чем мы углубимся в «Что из вашего кода следует анализировать», пожалуйста, запомните: 

Есть много других важных точек данных, которые следует учитывать перед анализом кода: 

  • Какие приложения вы используете наиболее часто и наименее сложные?
    Они быстро окупаются. И не стоит тратить время на приложения, которые никто не использует! Подробнее см. Также здесь и здесь
  • Каким конечным пользователям требуются локальные реплики по соображениям производительности или автономного использования? 
  • Какие приложения используют ваши VIP-персоны или ваши самые важные центры прибыли? 

Это всего лишь пара примеров, о которых следует помнить - можно найти больше. здесь (см. слайды 17-21)

Какой код вам следует анализировать и что в нем искать? 

Все это. Период. Во * всех * ваших приложениях. И для каждого из них это означает 

  • Весь код: @Formulas, Java, JavaScript и LotusScript 
  • Все элементы дизайна (подумайте «контейнеры кода»). Это могут быть формы, подчиненные формы, представления, столбцы, действия, агенты, кнопки, библиотеки скриптов и т. Д. 
  • Особого внимания часто заслуживают следующие элементы дизайна:
    XPages, классы Java, апплеты, файлы Jar, веб-службы, функции составных приложений и т. Д. 

Правильный анализ обоих элементов дизайна приложения и код отвечает на два важных вопроса: 

  1. Где находится весь ваш код? Сколько где? А что это за код? 
  2. Что делает этот код?

Следующие два примера показывают ценность анализа дизайна и кода: 

а) Чем больше форм, полей и кода имеет приложение, тем больше времени потребуется на его модернизацию или миграцию. 

б) Приложение, использующее код Java, не является идеальным кандидатом для перехода на SharePoint. Да, это частично зависит от того, что делает соответствующий код. Тем не менее, это помогает вам ранжировать ваши приложения иevent подводные камни.

ЧТО МЫ ДЕЛАЕМ вы должны искать в своем коде 

Поиск в коде может быть чем угодно, от удовольствия до разочарования. 

После экспорт дизайна ваших приложений в DXL (Язык Domino XML), вот три совета, которые помогут вам начать: 

  1. Запустите блокнот или что-то подобное и исследуйте результат. Чтобы получить первое представление, попробуйте найти часть своего кода, выполнив поиск по его частям. Также ищите имена пользователей, имена серверов и т. Д. 
  2. Попробуйте LotusScript Manager или Source Sniffer из OpenNTF
    (* не * используйте Lotus Analyzer! У него скрытый дизайн и телефоны дома) 
  3. Pro-Challenge: разделите код из DXL на документы в базе данных Notes. Это облегчает категоризацию, поиск и постобработку (например, для подсчета элементов дизайна). 

Если вы попробовали что-либо из вышеперечисленного, возможно, вы заметили пару недостатков: 

а) Ваши поисковые запросы также совпадают с комментариями / замечаниями в вашем коде. 

б) Комбинированные поисковые запросы, такие как @Db (столбец ИЛИ поиск), требуют в первую очередь решения вышеуказанных проблем.
(= нарезка кода на документы Notes / Domino или базу данных SQL). Раздельные поиски приводят к дублированию результатов. Это, в свою очередь, очень сильно противоречит вашей цели - проверять как можно меньше кода. 

c) Ваши поисковые запросы также соответствуют коду, который вы не искали. Например: 

  • Поиск по запросу «Открыть» находит NotesDatabase [Object] .Open и NotesStream [Object] .Open. 
  • Поиск «@DbLookup» включает поиск в той же базе данных, где находится код. Тем не менее, вам может потребоваться поиск только в других / внешних базах данных. Или ваш результат также включает запросы, не относящиеся к Notes, например ODBC. Тем не менее, вы можете искать только в заметках. 

Итак, бпрежде чем продолжить поиск, мы должны оптимизировать код

Для получения хороших результатов поиска мы должны удалить все комментарии из всего кода. Да, комментарии хорошо иметь в своем коде, чтобы лучше понять его позже. Но они искажают наши результаты поиска. 

На следующих рисунках показано, как разработчик может комментировать в LotusScript и @Formulas: 

В @Formulas комментарии начинаются с REM, за которым следует любое количество пробелов (= пробелы или табуляции). Далее идет собственно комментарий, заключенный в двойные кавычки или фигурные скобки.

Мы уже подготовили все для БЕСПЛАТНОЙ проверки.

Вся эта статья поможет вам понять и провести собственную независимую аналитику приложений. Тем не менее, вы можете сэкономить драгоценное время и начать действовать быстро. Все, что тебе нужно сделать, это зарегистрируйтесь на наш готовый к игре iDNA Applications песочница. Как только вы зарегистрируетесь, все, что вам нужно сделать, это войти в систему и перейти на наш готовый мгновенный поиск кода. Конечно, он не показывает ваши собственные приложения, но дает вам хорошее представление о том, как должен работать поиск кода.

Для тестирования используйте текстовый поиск с использованием «florian», «vogler», «server», «/ acme», «/ O = acme» и «workflow». Также попробуйте поиск по регулярному выражению, например «(? Iw) @db (lookup | column)».

Теперь давайте действительно погрузимся в ЧТО искать * во * (дизайне и) коде ваших приложений:

Если вы хотите оптимизировать

  • Ищите GetNthDocument - он медленнее, чем GetFirst / GetNextDocument
  • Ищите жестко заданные имена серверов, имена пользователей, имена файлов базы данных, IP-адреса, адреса электронной почты, идентификаторы реплик и т. Д.
  • Искать старый код (@ V2If, @ V3Username, @ V4UserAccess, @UserPrivileges, @IfError)
  • Независимость от кода: найдите свои наиболее часто используемые / популярные базы данных и подарите им немного любви. Сделайте их красивее и современнее!

Если вы хотите модернизировать

  • Проверьте, зависит ли приложение от классов NotesUI *. Это не работает в веб-браузерах и требует доработки.
    Проверьте код, который не поддерживается в браузерах. Подсказка: выполните поиск в справке Designer по запросу «Вы не можете использовать эту функцию в веб-приложениях».
  • Есть ли уже много кода, предлагающего поддержку браузера?
    т.е. @WebDbName, @BrowserInfo, @ClientType, Domino @DbCommands,…
  • Ваше приложение / код полагаются на печать? Это может быть сложно из браузера
  • Проанализируйте свой код на предмет того, работает ли он в HCL Nomad
    • Приложение зависит от XPages, Java или ODBC? Это не работает с HCL Nomad.
    • Использует ли приложение вызовы C-API? Если да, то работает ли код также на iOS и Android?
    Требуются ли для вашего приложения какие-либо сторонние клиентские расширения?
  • Независимо от кода: найдите свои наиболее часто используемые / популярные базы данных и подарите им немного любви. Сделайте их красивее и современнее!

Если вы хотите перейти

  • Сколько форм, полей, представлений и т. Д. Есть в приложении? Не выбирайте в первую очередь самое сложное.
  • Ваше приложение зависит от кода или элементов дизайна, которые плохо работают на вашей целевой платформе?
    Например: Java <> SharePoint, слишком много папок <> SharePoint. C-API. Частная или общедоступная адресная книга, почта (отправка и) шифрование. Используйте LSX, ODBC, DB2, DOS / cmd, OLE, файлы, каталоги, MIME, ссылки на документы и т. Д.
  • Зависит ли приложение от других баз данных?
    Подумайте о @DbLookups, которые подключаются к другим базам данных (например, не используя, например, ««: «« в качестве сервера: имя файла). То же самое касается New NotesDatabase, GetDatabase, .Open, .OpenWithFailover, .OpenIfModified, .OpenByReplicaID, [FileOpenDatabase], [Compose] и т. Д.
  • Независимо от кода и миграции: немного полюбите одну из ваших оставшихся баз данных, сделайте ее красивее и современнее.

Наконец, давайте посмотрим, КАК лучше всего искать ваш код.

Следующее - действительно жуткий материал. Если вы не разработчик, можете пропустить этот раздел!

Частично мы уже рассмотрели, почему поиск кода только с (под) строками не уведет вас слишком далеко. Во многих случаях он совпадает слишком много или слишком мало. Мы также выяснили, почему перед поиском кода необходимо удалить все комментарии.

Кроме того, при поиске кода очень, очень, очень важно следующее:
НЕ ищите код, думая о том, как бы вы его разработали. Подумайте шире, и вы будете очень удивлены, узнав, как пишут другие люди.

Итак, что может быть лучше для поиска кода, чем просто совпадение подстрок?

Полнотекстовый индекс, поддерживающий подстановочные знаки, такие как «*» (звездочка), позволяет вам продвинуться в игре. Например, при поиске «@ dbcolumn * OR @ dblookup *» - но отсутствует поддержка точного отрицания. Точное отрицание частей кода жизненно важно, например, для поиска только @DbLookups, которые не указывают на одну и ту же базу данных.

Следующий @DbLookup ищет данные из той же базы данных, в которой выполняется код. Это делается с помощью ««: «» в качестве второго параметра:

Следующий @DbLookup ищет данные из «локальной» адресной книги (клиентской или серверной, в зависимости от того, где она запущена):

Искать любой @DbLookup, который ищет данные из «names.nsf», довольно просто. Даже с использованием только подстановочных знаков: @dblookup (: «Names.nsf»). Пока вы не встретите такой код:

Теперь нам внезапно нужно искать код в нескольких строках - да, мы видели такой код.

Еще хуже становится то, что переменные, не говоря уже о @functions, вступают в игру в качестве параметра:

Приведенный выше код ищет данные из той же базы данных. Переменная ht_filename является результатом @Subset (@DbName; -1). Это снова приводит к имени файла базы данных, в которой выполняется код.

Точно так же в следующем примере кода выполняется поиск данных из локальной адресной книги:

Лучшее решение для поиска кода было бы, если бы можно было разобрать код. Это позволит нам разрешить значение ht_filename в приведенных выше примерах. Однако мы не нашли для этого умного решения.

Мы нашли умное решение для поиска кода с точным отрицанием:

Мы используем регулярные выражения.

Следующее регулярное выражение - огромный шаг вперед. Это позволяет нам искать любой @DbLookup, который не ищет данные из той же базы данных, из которой он запускается:

@dblookup([^;];(?!””(:””)?).*
@dblookup (Открытая скобка должна быть экранирована в регулярных выражениях, поэтому \ (
[^;] *;за которым следует «что угодно, кроме точки с запятой» до следующей точки с запятой.

Искать «. *;» Было бы неправильно, так как это выражение было бы жадным. Он будет искать до последней точки с запятой.
(?! ”” (: ””)?)Затем отрицание «», за которым следует еще один необязательный: «« - второй параметр может быть либо «», либо ««: «»
.*до конца строки

В этом примере все еще требуется тонкая настройка

  • также поддерживают любое количество пробелов практически везде,
  • и обслуживать ситуации, когда @dbname или @subset (@dbname; 1): @ subset (@dbname; -1) используют одну и ту же базу данных
  • и находите только те @DbLookups, для которых Class - «» или «Notes» (без учета регистра)

В качестве бонуса вы также можете найти @dblookups, используемый в LotusScript Evaluates. Часто при этом также нужно избегать кавычек.

Регулярное выражение, которое соответствует всем вышеперечисленным требованиям (за исключением синтаксического анализа кода), является… возможно, самым уродливым, что вы увидите сегодня: 

Я мог бы продолжать и продолжать часами

Если вы прошли через действительно жуткий материал, описанный выше: снимаю перед вами шляпу! Вы - разработчик супергероев и сторонник регулярных выражений.

Хорошая новость для всех читателей: мы в panagenda уже сделали много тяжелой работы. И мы любим делиться.

Если вы посмотрите на наши iDNA Applications песочница, ты найдешь более 70 готовых регулярных выражений. Они ищут более 300 различных результатов кода. Вы можете БЕСПЛАТНО использовать все эти шаблоны в своем собственном решении для поиска кода.

И на всякий случай, если у вас есть более разумная идея, чем использование регулярных выражений, или вы придумали какие-то новые или улучшенные регулярные выражения: сообщите нам, и мы, в свою очередь, поделимся с community.

In case you don’t have the time to build your very own код search solution:

Есть ряд сторонних решений, которые могут помочь. Некоторые из них доступны на OpenNTF. Некоторые из них являются коммерческими решениями, как и наши собственные. panagenda iDNA Applications.

Подводя итог

Правильный анализ ваших приложений служит трем основным целям:

  • Экономия (много) времени, разочарований и денег
  • Сосредоточение на правильных вещах и осведомленность
  • Обеспечение успешного преобразования вашего ландшафта Domino

Оптимизация, модернизация или миграция

  • Что бы вы ни делали, не забудьте отдать должное хотя бы одному из ваших приложений Domino. Это окупится. Много ти

Далее в нашей серии

Отчеты о проделанной работе. Они являются частью каждого проекта, и их неинтересно производить. Вы должны делиться не только своим прогрессом. Вы также должны предоставить проектным командам данные, необходимые им для работы. Это сложно координировать, и это никогда не заканчивается. Но отчеты о проделанной работе могут быть вам другом, когда вы сообщаете об успехе!

Проекты миграции и модернизации очень дороги и очень заметны. С самого начала на вас будет много глаз. Ожидания будут высокими. Как сделать так, чтобы ваш проект не провалился? Иногда не получается. Некоторые проекты обречены еще до того, как они начнутся. Вы должны знать, прежде чем уйти.

С этого момента круг приложений, над которыми мы работаем, будет постоянно расширяться. Каждый шаг будет более затратным, а разумное планирование принесет еще большие выгоды.

Об этой серии:

Многие компании по всему миру взяли на себя обязательство HCL Notes/Domino* годами. Они знают, какие преимущества приносят эти отношения. Кроме того, Notes / Domino находится в центре их процессов и того, как они работают. Несмотря на все это, лица, принимающие решения в области ИТ по всему миру, начинают предвидеть будущее, в котором Notes / Domino могут играть меньшую роль или вообще не играть.

* ранее IBM Notes / Domino