Convier — это бесплатная платформа для объединения и анализа данных, предназначенная для высокопроизводительных команд и отдельных лиц. Мы все еще находимся в закрытом бета-тестировании, но если вы хотите попробовать, перейдите на https://convier.no/#/beta. В этом посте кратко рассматривается, как мы используем его для поиска и исправления проблемных путей в нашей кодовой базе.

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

Поскольку наш продукт растет все быстрее и быстрее, все легко ускользает. Беспорядочный график вызовов со ссылками туда и обратно по базе кода может помочь определить, где что-то пошло не так, но они становятся огромными. Недавно мы начали добавлять в платформу графы вызовов (сгенерированные с помощью java-callgraph) для выявления и удаления проблемных путей кода между парами классов или методов. Наша функция поиска пути позволяет просматривать большие графы на обычном оборудовании практически в режиме реального времени. Это помогает нам определить пути кода, которые следует подвергнуть рефакторингу, и экономит огромное количество времени на просмотре ссылок на код.

Недавний пример этого возникает, когда мы изучали пути кода, ведущие к коду, который подключается к внешним базам данных SQL (ExternalDataStoreSql). Мы вытащили все направленные пути между основным классом сервера и этим классом, используя наш поиск графа путей:

Этот результат выделяет класс DataConfigResource, так как он имеет много входящих ссылок, которые, по-видимому, вызывают некоторые странные циклы. Этот класс отвечает за управление конфигурацией приложения в виде кода с защищенными ветвями, запросами на включение и ожидаемой историей версий. Конфигурация включает в себя модель данных, подключенные источники данных, сопоставление физического и виртуального представления данных и аналитику.

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

  • Пусть DataWriteResource использует только ProjectManager, как и другие ресурсы
  • Устраните необходимость для LocalAgentServer вызывать DataConfigResource.
  • Устраните необходимость для TaskCreator вызывать DataConfigResource.
  • Удалите необходимость для DataConfigResource вызывать ResolutioUtils.

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

Это было простое описание того, как мы используем нашу платформу для исследования нашего кода. На данный момент это специальный процесс, но мы видим потенциал для непрерывного приема, автоматического анализа и сравнения как часть нашей непрерывной интеграции.

Мы планируем опубликовать много подобных сообщений по мере приближения к запуску; Следите за нами в LinkedIn, чтобы быть в курсе: https://www.linkedin.com/company/convier.