Представьте город, в котором нет ни одной карты. Улицы есть. Дома стоят. Но чтобы понять, как добраться с вокзала до больницы, нужно пройти весь маршрут пешком. Или спросить местного жителя, который помнит всё на память.
Большой программный проект устроен примерно так же. Файлов тысячи. Функций десятки тысяч. Каждая что-то вызывает, что-то получает, что-то возвращает. Новый разработчик открывает папку с исходниками и видит огромную кучу улиц без карты.
Обычно это решается так: садишься рядом со старым сотрудником, и он за несколько часов объясняет, как тут всё устроено. Или читаешь документацию, если она вообще есть и если она не устарела.
Проблема в том, что человек уходит. Документация устаревает. А код остаётся.
Что такое граф кода?
Граф кода это и есть та самая карта. Только не для улиц, а для функций и данных.
Инструмент читает весь проект, находит все функции, все переменные, все вызовы и соединяет их связями. Получается сеть узлов, где можно задать вопрос и получить ответ за секунды.
Например: «Кто вызывает функцию send_email?» Не надо искать по всему проекту вручную. Граф знает.
Или: «Есть ли путь от данных пользователя до SQL-запроса без проверки?» Человек может искать такой путь несколько дней. Граф проходит по всем связям за минуту.
Почему это не то же самое, что поиск по коду?
Поиск по тексту находит совпадения. Граф понимает связи.
Это как разница между поиском слова «вокзал» в книге и открытием карты города. В первом случае ты знаешь, что слово есть. Во втором знаешь, как туда добраться и что рядом.
Код работает так же. Функция execute может быть безопасной, а может принимать данные от пользователя без проверки. Текстовый поиск видит только слово. Граф видит, откуда пришли данные.
Откуда берётся граф?
Инструмент разбирает каждый файл, строит несколько структур и объединяет их в одну модель.
Первая структура показывает, как устроен текст кода: функции, условия, циклы. Вторая показывает, в каком порядке выполняются команды. Третья отслеживает, как значения переменных передаются между функциями. Четвёртая фиксирует зависимости между разными частями логики.
Когда всё это собрано вместе, можно задавать точные вопросы и получать точные ответы. Не примерные, не «возможно где-то здесь», а конкретные: вот функция, вот путь, вот место.
Зачем это нужно на практике?
Три ситуации, когда граф кода меняет то, как работает команда.
Первая. Приходит новый разработчик. Вместо недели погружения он открывает граф, задаёт вопросы и за день понимает, где в проекте что находится.
Вторая. Служба безопасности просит проверить код перед релизом. Вместо ручного аудита или потока ложных срабатываний от классического анализатора граф показывает реальные опасные пути.
Третья. Технический долг накопился и непонятно, с чего начинать. Граф показывает, сколько кода вообще не вызывается, где самые сложные функции и что изменение одного места затронет в других.
Код это не просто текст. Это живая система связей. Карта этой системы называется граф свойств кода. И именно с ней работает КодГраф.
В следующей статье мы опишем наш опыт аудита собственной кодовой базы.
Подписывайтесь и ищете нас:
Официальный сайт: https://codegraph.ru/
Яндекс Дзен: https://dzen.ru/codegraph
Telegram @codegraph_ru