Блог компании национальный расчетный депозитарий

Интро

Интерес к теме машинного обучения и искусственного интеллекта неуклонно растет. Ежедневно в новостных сводках мы читаем про победу искусственного интеллекта над человеком. Как правило, описывается решение некоторой сложной задачи (челенджа). От жгучего желания воспроизвести результаты статьи во благо человечества (или своего собственного) в 99% случаев отговаривает отсутствие датасета, деталей реализации алгоритма и мощного железа (порой сотни единиц специализированных устройств для тензорных вычислений).

С другой стороны, есть много статей о решении задач машинного обучения на примере нескольких публичных затертых до дыр датасетов: MNIST, IMDB, ENRON, TITANIC. С ними ситуация обратная все вершины уже покорены, алгоритмы известны, можно добиться рекордных цифр даже на простеньком ноутбуке. Снова мимо. Гораздо сложнее найти материал о практическим применении МО для решения повседневных задач. Данная статья, как можно догадаться, как раз из этой серии. На подробном практическом примере попробуем выяснить, можно ли собрать личного интеллектуального помощника (пусть и узкоспециализированного), сложно ли это, какие знания нужны и какие проблемы подстерегают на этом пути.

Примечание: в данной статье основное внимание уделено классическому машинному обучению. Лишь небольшой блок содержит сравнение с нейросетевым подходом (BERT).

Идея

Вплотную подойдя к итоговому заданию курса, я задался вопросом могу ли я сделать что-то более впечатляющее, чем поиск по тексту писем ENRON так называемых POI (points of interest, главных участников исторического мошенничества)? Разумно было выбрать задачу из той же самой области машинного обучения обработки естественного языка (NLP). Она включает в себя широкий спектр задач, таких как машинный перевод, создание вопросно-ответных систем, чат-ботов, суммаризации, классификации и др. Было решено остановиться на классификации: ее качество очень легко измеряется стандартными метриками (Accuracy, Precision, Recall, F1), а обучение можно начинать с сотен образцов. Примером такой задачи может быть то, с чем читатель наверняка уже сталкивался с точки зрения пользователя определить, является ли письмо нежелательным (SPAM or HAM); в этой задаче два результирующих класса, бинарный выбор. Стоит заметить, что распространенные алгоритмы машинного обучения, такие какие логистическая регрессия, метод опорных векторов, нейросети и многие другие, не ограничивают количество возможных классов, тем самым позволяя использовать десятки, сотни, а порой и тысячи возможных классов на выходе алгоритма.

Помимо верхнеуровневого выбора задачи необходимо было определиться с источником входных данных. В своей работе в НРД мы много используем RedMine: в нем хранятся заявки, задачи, ошибки, инциденты, тест-кейсы и т.д Многие сущности сопровождаются детальным описанием, текста в сумме получается в достаточном для экспериментов с ML количестве.
Первая возникшая идея а что если доверить алгоритму распределение новых задач по команде разработки? Типичная заявка на доработку проходит стадии аналитики, согласования, оценки и декомпозиции на подзадачи, разработки, тестирования, опытной и, наконец, промышленной эксплуатации. На этапе передачи заявки в разработку требуется распределить задачи по команде разработчиков. Эксклюзивными знаниями по особенностям системы в одиночку разработчики не обладают (знания стараемся распространять в командах), однако удачное распределение может повысить продуктивность команды в целом. На вход алгоритма могли бы поступать описания задач, на выходе целевые разработчики. После первых экспериментов оказалось, что краткого описания задачи недостаточно и результаты неустойчивы. Сохранив идею классификации сущностей RedMine по разработчикам, было решено перейти к дефектам (ошибкам), вместо задач по доработке. Как оказалось, в дефектах при определенной культуре тестирования вполне достаточно информации для определения целевого разработчика. Итак, формальная постановка задачи такова: имея на входе текстовое описание дефекта требуется с определенной долей вероятности определить, кому из разработчиков ей следует заняться.

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

Выбор данных

Было бы логично предположить, что большую часть времени специалист по машинному обучению проводит за питьем смузи разработкой алгоритмов, настройкой параметров и, например, созданием новых архитектур нейросетей. Однако на практике порядка 80% процентов времени уходит на работу с данными выборку, чистку, преобработку и т.д. В нашем случае источником данных является RedMine (БД развернута на MS SQL Server). Никакого rocket science на данном этапе нет методично пишется и проверяется запрос, который возвращает данные в удобном для применения в алгоритме виде (плоский CSV-файл):

Для обучения алгоритма используется только склеенный текст описания и заголовка дефекта в RM. ID использовался во время разработки для контроля. Целевой переменной (т.н. label) в данном случае является фамилия и имя разработчика. Кстати, тут и далее задача классификации рассматривается в разрезе систем. В частности, будут приводится результаты работы классификатора на одной из них с примерно 3к примерами и 12 классами (разработчиками).
Имеющиеся данные целесообразно разбить на обучающую и тестовую выборки:

train_data, test_data, train_target, test_target, train_rm, test_rm = \train_test_split(csv_data[:, 0], csv_data[:, 1], csv_data[:, 2], test_size=0.2, random_state=42) 

Примечание: в более поздней версии на части разбивался непосредственно pandas.DataFrame в разрезе колонок.

Подробнее здесь.

Хронология реализации, улучшение метрик, развитие

Алгоритмы машинного обучения не умеют работать с текстом в сыром виде. Являясь по своей природе сложными математическими функциями (отображениями), они требуют на вход числа. Наиболее простым методом преобразования текста в числа является метод "сумка слов" (bag of words). Он подразумевает сопоставление каждому слову некоторого числа. В каждой строке входного корпуса подсчитывается количество уникальных слов, а так же частоты их возникновения. После применения данного метода входной корпус из N образцов превращается в двумерный массив NxM, где M количество уникальных слов. Делается это примерно следующим образом:

vectorizer = CountVectorizer(max_features=20000) # max_features ограничивает сверху M из предыдущего абзаца.train_data_features = vectorizer.fit_transform(train_data).toarray()test_data_features = vectorizer.transform(test_data).toarray()

После этого текст уже готов к подаче в классификатор. В первой версии использовался GaussianNB так называемый "наивный" Байесовский классификатор. Он учится находить зависимости между частотами возникновения в обучающем наборе тех или иных слов и целевой переменной (класса, в нашем случае разработчика). Его достоинства: простота, высокая скорость работы и интерпретируемость результатов. Кстати, наивным он называется потому, что не анализирует взаимное расположение слов, а только частоты. Например, он не поймет, что 'Chicago Bulls' это не быки в Чикаго, а название команды, употребляемое в определенных контекстах. Этот недостаток можно сгладить, об этом далее в статье.

cls = GaussianNB()cls.fit(train_data_features, train_target)prediction = cls.predict(test_data_features)

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

print('Accuracy: ' + str(accuracy_score(prediction, test_target)))print(confusion_matrix(test_target, prediction))print(classification_report(test_target, prediction))

Accuracy это процент верно предсказанных классов, confusion_matrix дает матрицу разброса предсказаний (чем больше на диагонали, тем лучше алгоритм), а classification_report формирует детальный отчет по классам в разрезе терх метрик: precision, recall и f1 score.
На момент первого измерения точность была в районе 0.32. Это намного ниже ожидания. Для исправления ситуации был разработан способ очистки входных текстовых данных.
Каждая строка входного текста была обработана процедурой prepare_line:

stemmer = SnowballStemmer("russian")russian_stops = set(stopwords.words("russian"))def prepare_line(raw_line):    # 1. Удаление ненужных символов и цифр.    raw_line = re.sub('[\';:.,<>#*"\-=/?!\[\]()_|\\\\+%]', ' ', raw_line)    raw_line = re.sub('\\b\\d+\\b', ' ', raw_line)    # 2. Конвертация в lowercase и разбиение по словам.    words = raw_line.lower().split()    # 3. Удаление stopwords + стэмминг.    meaningful_words = [stemmer.stem(w) for w in words if w not in russian_stops]    # 4. Обратное слияние в строку.    return " ".join(meaningful_words)

В ней применены стразу насколько подходов, а именно:

• удаление незначащих символов, знаков пунктуации и прочего мусора. От чисел в чистом виде так же было решено отказаться. Числа, примыкающие к словам, было решено оставить ввиду специфики предметной области. Например, упоминание кодовых названий MT103 или ED807 вполне важная фича в нашей предметной области.
• конвертация текста в lowercase. Напрашивается само собой, однако сам по себе CountVectorizer этого не делает.
• удаление стоп-слов (слов, которые не несут смысловой нагрузки, таких как междометия, союзы, частицы)
• использование основ слов (stem) вместо самих слов. Позволяет сократить словарь возможных слов за счет удаления всего многообразия окончаний русского языка. Забегая вперед можно сказать, что стемминг так же повысил стабильность скора классификатора на кроссвалидации. В перспективе возможно использование лемматизатора.
  В дальнейшем алгоритм был обернут в класс SteamCleanTransformer, который можно использовать в пайплайнах scikit-learn.

class StemCleanTransformer(TransformerMixin):    def __init__(self, column_num=0):    self.stemmer = SnowballStemmer("russian")    self.russian_stops = set(stopwords.words("russian"))    self.column_num = column_num    def prepare_line(self, raw_line):    # 1. Удаление ненужных символов и цифр.    raw_line = re.sub('[\';:.,<>#*"\-=/?!\[\]()_|\\\\+%]', ' ', raw_line)    raw_line = re.sub('\\b\\d+\\b', ' ', raw_line)    # 2. Convert to lower case, split into individual words    words = raw_line.lower().split()    # 3. Удаление stopwords + стэмминг.    meaningful_words = [self.stemmer.stem(w) for w in words if w not in self.russian_stops]    # 4. Обратное слияние в строку.    return " ".join(meaningful_words)    def transform(self, X, y=None, **fit_params):    result = np.array(X, copy=True)    if len(result.shape) == 1:    for i, _ in enumerate(result):    result[i] = self.prepare_line(result[i])    else:    for row in result:    row[self.column_num] = self.prepare_line(row[self.column_num])    return result    def fit_transform(self, X, y=None, **fit_params):    self.fit(X, y, **fit_params)    return self.transform(X)    def fit(self, X, y=None, **fit_params):    return self

Использование нового метода очистки подняло accuracy с 0.32 до 0.55, почти двукратный прирост.

Далее была выполнена попытка перейти на метод опорных векторов (в scikit-learn это класс SVC), не давшая значительного прироста. Оборачиваясь назад, можно сказать, что SVC требовал более точной настройки гиперпараметров, которая на тот момент не могла быть проведена из-за незрелости проекта. К нему еще вернемся.

Следующим шагом было использование n-грамм при векторизации. В частности, было выбрано значение 2: если ранее каждое слово представляло собой отдельный токен в словаре, то теперь так же будут учитываться все пары соседних слов. Регулируется параметром ngram_range в CountVectorizer:

vectorizer = CountVectorizer(ngram_range=(1, 2), max_features=20000)

Возвращаясь к примеру с Chicago Bulls теперь в словаре будет и Chicago, и Bulls, и Chicago Bulls (как отдельный токен). Это подняло accuracy с 0.55 до 0.63. Весомый прирост для такой простой правки.

Последним значимым шагом по повышению качества оценки до начала фактической эксплуатации был отказ от CountVectorizer в пользу TfidfVectorizer. Это немного более продвинутый алгоритм векторизации, который учитывает количество вхождений того или иного слова в документе, а так же во всем обучающем наборе. Подробнее здесь. Он имеет совместимый с CountVectorizer интерфейс и так же поддерживает n-граммы. Ввиду этого переход на него абсолютно прозрачный:

vectorizer = TfidfVectorizer(ngram_range=(1, 2), sublinear_tf=True, max_features=20000) # про sublinear_tf см. документацию

Это позволило повысить метрику оценки качества с 0.63 до 0.68.

Еще одна неудачная попытка использовать pymystem3 (Яндекс) в качестве лемматизатора (преобразование слова в исходную форму; обычно работает немного лучше стемминга). По странной причине под Windows стемминг одной строки инпута занимает примерно одну секунду при сравнимом качестве. Под Linux таких проблем не было обнаружено.

Эксплуатация

Для получения практической пользы от реализованного классификатора требовалось создать инфраструктурную обвязку. В частности, требовалось наладить взаимодействие с внешним миром. Была создана некоторая обвязка по взаимодействию с БД RM (чтение), а так же с API RM (запись). Было введено разделение по системам: на каждую заводился отдельный инстанс классификатора, обучающийся на собственном наборе данных. Задачи определения ответственного разработчика были поставлены на расписание. Это можно было считать официальным началом функционирования системы. По мере работы, конечно же, вносились изменения. Вот некоторые из них:

• В определенный момент возникла идея получать топ Z предсказаний. Причин было несколько разработчики уходят в отпуск, на больничный, уходят от дел, переключаются между системами и так далее. В таких случаях проще точным алгоритмом выбрать наиболее подходящего кандидата. При реализации вскрылся серьезный недостаток GaussianNB классификатор не использует сглаживание (Laplassian smoothing), ввиду чего отсутствие или наличие одного единственного слова в тексте может на 100% отвечать за выбор класса. Проблема была решена использованием MultinomialNB. Кстати топ 3 предсказание дает скор в районе 0.95.

  
  

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

  
  

with shelve.open('filename') as persistent_storage:    persistent_storage[str(rm_number)] = prediction

Идеально подходит для хранения пар ключ-значение в небольшом проекте.

• Было решено вернуться к методу опорных векторов (SVC). При подключении каждой новой системы в качестве клиента сервиса определения ошибок выполнялись контрольные замеры метрик. Выяснилось, что в некоторых системах наивный Байесовский алгоритм стремится "нагрузить" некоторых особо часто встречающихся в тестовом наборе разработчиков, оставляя без внимания остальных. Особенно это хорошо было видно в confusion matrix. Практическим путем было выявлено, что метод опорных векторов при должном выборе параметра C дает гораздо более уместную оценку. Кстати, чтобы SVC предсказывал вероятности, требуется выставить специальный параметр probability в True

  
  

• SVC, в отличие от MultinomialNB, требовал куда больше времени на обучение. Ввиду этого пришла идея сохранять обученные модели на диск. Для этого используется joblib из sklearn.externals (внутри работает через pickle). Примерно так выглядит код сохранения и чтения:

  
  

from sklearn.externals import joblib...joblib.dump(classifier, filename)...joblib.load(filename)

Помимо этого, был создан специальный класс для хранения кэша моделей. Подход стандартный если модели нет, то создать, сохранить в кэш, вернуть результат; если есть вернуть из кэша.

• Для повышения удобства работы, стандартизации операций над обучающей и тестовой выборкой, а так же более прозрачного сохранения/загрузки в файл/из файла, был использован специальный класс Pipeline из библиотеки scikit-learn. Он позволяет инкапсулировать в себе несколько шагов обучения с произвольной вложенностью. Иногда строятся очень большие цепочки. Выдержка из реализации:

pipeline = make_pipeline(    StemCleanTransformer(),    TfidfVectorizer(ngram_range=(1, 2), sublinear_tf=True, max_features=20000),    SVC(kernel = 'linear', C=10, gamma='auto', probability=True))

Очистка, векторизация и предсказание инкапсулированы в одну цепочку.

• Всегда есть ложка дегтя. Ввиду сложностей по работе с некоторыми вендорами пришлось предусмотреть т.н. NonML версию алгоритма. Она определяет разработчика по формальным параметрам, решенным задачам у того же родителя и т.д. Всегда интересно, какой алгоритм определения окажется сильнее.

  
  

• Периодически производится обновление датасетов и переобучение. В общем и целом тренд на рост количества данных, однако бывают и сокращения за счет отключившихся разработчиков.

  
  

• За несколько лет накоплено больше данных. На той системе, по которой мы изначально измеряли accuracy, значение естественным образом поднялось до 0.76.

  
  

Результаты

На момент публикации статьи система функционирует уже 4 года. За это время произошло порядка 5500 назначений на целевого разработчика, что по факту трансформируется в ~5.2 человеко-месяца сэкономленного времени (из расчета: 10 минут в среднем на переключение контекста/чтение описания/переназначение, рабочий день 8 часов, 22 рабочих дня в месяц).

Это серьезная экономия, ведь робот не страдает от переключения контекста и реагирует практически мгновенно. Так же стоит заметить, что примерно пятая часть из назначений робота была выполнена вне рабочего времени (в нашей организации это с 10 утра по 19 вечера). В классификации участвуют 5 внутренних систем с количеством разработчиков от 6 до 27, средний скор находится в районе 0.75 (максимум 0.9, минимум 0.68).

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

Сравнение с BERT

Недавно возникла идея проверить более продвинутые и тяжелые NLP-модели на этой задаче. В качестве подопытного был взят мультиязычный BERT из пакета transformers от HuggingFace. Скор по точности получился несколько хуже, чем достигнутый по итогам описанного в статье пути. Это ни в коем случае не означает, что BERT хуже. Скорее вывод в том, что частная задача вполне может решаться классическим методом на околопредельной точности.

Аутро

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

Использованные средства: Python 3, scikit-learn, nltk, SQL.

Финансовые компании находятся в поисках лучших решений, которые оптимизируют внутренние процессы разработки, разовьют IT-инфраструктуру в соответствии с требованиями бизнеса и позволят им выводить на рынок лучшие конкурентные продукты. Так, два года назад мы ступили на путь перевода разработки ЦФТ-банк на платформу CFT Platform IDE. Среди коллег по цеху ходят слухи, что это процесс невероятной сложности, ввиду чего не решаются приступить к делу. На своем примере мы докажем, что это вполне подъемный процесс и для вашей команды.

Процесс разработки ПО в НРД в большинстве случаев характерен наличием нескольких команд разработчиков, которые лавируют между проектами, занимаясь разными модулями одной или даже разных систем. В работе у нас постоянно большое количество доработок и приходится держать несколько dev и test-контуров с разными версиями системы. Таким образом, всегда есть необходимость доступа к централизованному хранилищу кода с поддержкой версионности, обеспечением автоматической сборки и установки. Для системы ЦФТ-Банк на протяжении многих лет таких возможностей не было.

Это порождало лишние затраты на подготовку сборок, merge-изменений и т.д. Часто возникали случаи порчи программного кода, т.к. следить за правильностью версиии той или иной программной компоненты могли только сами разработчики в полностью ручном режиме. Однако поменять подход к разработке для системы ЦФТ-Банк было невозможно ввиду существования безальтернативной среды разработки для этой системы, по своему интерфейсу и возможностям отставшей от жизни лет на 15.

Решение наших проблем было предложено ЦФТ с выводом на рынок в 2018 г. новой платформы разработки для своих систем, которая называется CFT Platform IDE (она же Admin 2.0, или сокращённо A2).

Ключевые отличия новой платформы разработки

Внешне разработчик получает среду, реализованную на основе Eclipse Platform, которая гораздо симпатичнее архаичного Администратора словаря данных.

Для сравнения редактирование кода в старой среде (Администратор словаря данных):

Редактирование кода в Admin 2.0:

Но основным преимуществом новой платформы разработки для нас явилась возможность хранения программного кода системы, а также экранных форм, описаний типов и прочего в виде множества текстовых файлов. Именно это позволяет выгружать код в систему контроля версий (в нашем случае Git) со всеми её возможностями, которых нам так недоставало ранее при разработке для ЦФТ-Банк.

Таким образом, разработчикам ЦФТ-Банк стала доступна возможность комфортно отслеживать историю изменений каждого объекта, включая не только время редакции, но и сравнение старой и новой версий через встроенный компонент либо с помощью любого внешнего средства типа Araxis Merge. Тому, кто не знаком с ЦФТ-Банк, это покажется удивительным, но ранее о таком приходилось только мечтать, храня историю изменений лишь в виде комментариев в коде.

Приятными бонусом послужила возможность синтаксической проверки кода без соединения с БД, а также удобная навигация (переходы в вызываемые процедуры по щелчку в месте вызова), быстрый контекстный поиск по проекту.

Отмечу, что новый админ оказался в хорошем смысле более привередлив к синтаксическим конструкциям в коде. Среди наших локальных доработок были выявлены очень странные выражения, например, что-то наподобие:

• ::MAIN_DOCUM вместо ::[MAIN_DOCUM],
• select md(md%id: rSelf) in ::[MAIN_DOCUM] all where md.[IN_FOLDER]=this bulk, причём в откомпилированном коде PL/SQL слова bulk нет, что с ним, что без него компилируется одинаково,
• Pragma macro(Ошибка!) вместо Pragma error(Ошибка!).

Непонятно, как Администратор словаря переваривал подобное без ошибок. Причём, если первые 2 примера представляют собой безобидный мусор, то последнее явная ошибка, которая приведёт к некорректной работе программы.

И ещё одной особенностью Admin 2.0 является, благодаря интеграции с Git, функционал получения списка изменений на основе сравнения 2-х веток.

Это позволяет выполнять развёртывание этих изменений в целевую БД. Затем изменения из БД можно выгрузить по тому же списку элементов, используя старый Администратор проектов, в mdb-файл, если их необходимо передать для установки в БД, куда разработчик не имеет прямого доступа. Однако более интересным вариантом является подготовка и развёртывание изменений в новом формате. Он представляет из себя zip-архив, внутри которого находятся текстовые файлы с кодом, а также некоторая метаинформация. Побочным эффектом является возможность просмотреть и даже изменить код в передаваемой поставке без установки в какую-то БД, что в случае с mdb-форматом было невозможно. Но самое основное сохранение в этот новый формат из Git-репозитория и развёртывание в БД Admin 2.0 предусматривает делать и в безинтерфейсном режиме, что позволяет настроить автосборку и автоустановку, т.е. наконец говорить о CI/СD в применении к доработкам ЦФТ-Банк. Правда, данную тему я планирую подробно раскрыть уже в следующей статье.

Особенности перехода на новую платформу

Материальный вопрос

Первое, с чем пришлось столкнуться получение лицензий на рабочие места. На каждое рабочее место разработчика требуется отдельная лицензия, которая привязана сразу и к железу ПК, и к учётной записи пользователя. Если у вас в компании тоже несколько изолированных сетей, где есть сервера с ЦФТ-Банк, и ведётся разработка на них, то на одного разработчика потребуется купить несколько лицензий Admin 2.0. Стоимость одной лицензии на момент написания статьи составляет 125 у.е./мес., или около 8 тыс. руб. по внутреннему курсу. За первоначальную покупку на данный момент деньги не взимаются. Лицензии распространяются в виде файлов, а не смарт-ключей, что позволяет без проблем развернуть среду даже на виртуальной станции.

До покупки можно договориться о предоставлении тестовых лицензий. В нашем случае были получены 6 лицензий со сроком действия 4 месяца на бесплатной основе. Условия обсуждаются с персональным менеджером индивидуально.

Настройка рабочих мест и БД

Серверную часть IDE можно устанавливать и в рабочее время, но правильней будет, если в момент установки не будут открыты на редактирование программные объекты ЦФТ, т.к. основное в обновлении это новый механизм соответствующих блокировок.

Клиентская часть это, по сути, Eclipse с расширениями CFT Platform IDE, устанавливается без прав администратора ПК. Только заранее должна быть установлена JRE не ниже 8-й версии. Доступ к обновлениям IDE на сайте ЦФТ теперь открытый, без авторизации. Можно настроить обновления непосредственно через сайт, либо из локальной сети. Например, из сетевой папки или с использованием менджера репозиториев вроде Nexus. Мы выбрали вариант сетевой папки как самый простой в настройке, не требующий доступа в Интернет со всех рабочих мест, надёжный, что важно при настройке тяжелых обновлений, и гибкий ввиду возможности выкладывать обновления по своему расписанию.

Выгрузка кода локального приложения

Для создания проекта, с которым будет работать Admin 2.0, нам нужно выгрузить из БД в папку с набором текстовых файлов описание объектов, являющихся нашими локальными доработками, а также, условно говоря, ссылки на объекты, от которых наши доработки зависят.

Отмечу, что при большом объёме локального приложения среда разработки начинает тормозить, поэтому в такой ситуации необходимо будет деление исходников на актив и архив. К счастью, в лимит мы вписались при немалом объёме локала. Однако стоит учесть объём оперативной памяти рабочих станций. Согласно документации требуется не менее 16Гб, хотя некоторое время части наших разработчиков удавалось работать и на 8Гб памяти, надо было лишь отрегулировать объём памяти java-приложения в файле eclipse.ini.

Что касается выгрузки процедура несложная, т.к. все необходимые скрипты, такие как для подсчёта объёма приложения, для получения списка объектов и другие входят в комплект поставки.

Адаптация кода

Адаптация заключалась в дополнении того, что не собрал скрип, например, прогрузились не все ссылки на таблицы в чистом Oracle, некоторые ТБП со сложным подчинением в единичных случаях не подгрузились типы ссылок или массивы. Также надо было слегка подчистить код (см. примеры выше). Но самое главное подстроить код под новые особенности:

• все простые представления были автоматически преобразованы в pl/plus (т.к. работу с простыми представлениями Admin 2.0 не поддерживает). При этом нередко это происходило с ошибками, которые надо было устранять (например, т.к. вызов интерфейсных пакетов напрямую теперь не поддерживается пришлось переделать вызовы в стиле pl/sql (типа Z$MAIN_DOCUM...) на pl/plus (типа::[MAIN_DOCUM]...));
• в Admin 2.0 была исключена поддержка inline-вставок pl/sql кода конструкции в фигурных скобках {}, и лишь недавно эту поддержку вернули;
• Admin 2.0 не поддерживает выражение between в sql запросах, которое использовалось у нас в нескольких представлениях (что странно, т.к. это стандартная конструкция, в том числе для чистого pl/sql);
• проявившиеся ошибки в мёртвых кусках кода. У нас было несколько процедур, где часть кода отсекалась посредством return, либо if false, или же макросом IF_DEF. Оптимизатор или макрокомпилятор отсекали код, который уже не анализировался на наличие ошибок. Некоторые такие куски стали невалидными, т.к. изменились вызываемые процедуры и используемые ТБП, просто компилятор их не видел. Admin 2.0 стал обращать внимание и на эти куски.

Результат

Серьёзных проблем при адаптации не было. Нам посчастливилось познакомиться поближе со своим кодом. В процессе мы выявили недочёты в IDE и даже в технологическом ядре (в компиляторе), которые сейчас ЦФТ уже исправил.

Большую помощь нам оказали специалисты ЦФТ, которые оперативно реагировали на возникшие проблемы, а в случае замедления процесса внедрения с нашей стороны всячески нас стимулировали и поддерживали интерес. После всех этих подготовительных действий мы запросто настроили интеграцию Eclipse с Git и выгрузили в него код текущей версии.
Нам потребовалось создать регламент ведения разработок, т.к. разработчикам ЦФТ-Банк пришлось привыкать работать совершенно в ином стиле: правильно маркировать коммиты, работать в нужной версии и пр. Сама методика работы стала соответствовать общим стандартам разработки в IT-компании.

Несмотря на первоначальное снижение скорости разработки, Admin 2.0 был сразу встречен в нашем коллективе с большим энтузиазмом. За 1-2 месяца активной работы все привыкли к новой среде, а эффективность возросла.

Сегодня Admin 2.0 до сих пор находится на стадии активных доработок, но это гораздо менее сырой продукт, чем 2 года назад. Например, только недавно появилась поддержка работы с группами доступа, пока работающая с ошибками. Также развёртывание в безинтерфейсном режиме может завершаться с ошибками при наличии в коде макросов. Большинство недочетов, которые мы фиксируем, ЦФТ устраняет в пределах месяца. За эти 2 года мы использовали отличную возможность повлиять на развитие Admin 2.0. Сегодня компании, которые задумали подобный переход, смогут пройти этот путь ощутимо быстрее.