То, как мы читаем код, сильно отличается от того, как мы пишем код. Итак, вот почему и как наш текстовый редактор или IDE должен нам помочь.

Чтобы проиллюстрировать этот момент, давайте рассмотрим простое приложение CRUD, реализованное в Java Spring Boot.

Приложение Java Spring Boot обычно состоит из таких классов, как:

  • Контроллеры: обрабатывают входящие запросы и направляют их в соответствующий сервис.
  • Сервисы: реализуют бизнес-логику приложения.
  • Объекты доступа к данным (DAO): отвечают за взаимодействие с базой данных.

Можно сказать, что код пишется «горизонтально».

Однако мы склонны читать код «вертикально» — одну конечную точку за раз, что очень похоже на последовательность, в которой он будет выполняться. Мы выбираем конечную точку и начинаем читать контроллер, затем сервис и, наконец, репозиторий.

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

Файлы для компиляторов, интеллект-карты для людей

Код традиционно пишется в файлах («линейным» способом), потому что так этого требуют компиляторы.

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

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

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

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

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

Что существует

Некоторые из существующих решений проблемы навигации по коду

  • Хлебные крошки и Outline Views — позволяющие быстро переключаться между блоками кода
  • Ссылки GoTo и реализация GoTo

Графики вызовов можно создавать в таких средах разработки, как Visual Studio, Oracle Solaris Studio и IntelliJ (с помощью подключаемых модулей). Я не совсем уверен, почему мы еще не видели ни одного такого расширения для VSCode.

Отдельное упоминание IDE, которая когда-либо была — CodeBubbles.

Чего не существует

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

Скорее, представление графа вызовов, которое не вызывает на ум слов «довольно грустно», когда думаешь об этом.

Сосредоточение внимания на том, что важно

В современных языках программирования, таких как Go, основной единицей кода являются не файлы, а объявления.

  • структуры
  • интерфейсы
  • функции

Следовательно, расположение в файлах является косвенным, что, скорее, вызывает трения как при чтении, так и при записи.

Реализация – это объективное решение. Решение о том, где разместить функцию, очень субъективно.

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

Как должен выглядеть функционально-ориентированный редактор

Как это может стать реальностью

  • Совершенно новая IDE — давайте будем честными, этого не будет
  • Расширение кода VS — может быть создано, однако индексация всей кодовой базы может быть утомительной.
  • Конфигурация NeoVim — моя надежда
  • Существующий текстовый редактор принимает это.

Предсказуемые вызовы

  • Производительность: графы вызовов могут быть абсолютно массивными в больших кодовых базах. Узкое место в производительности было основным фактором, из-за которого функции графа вызовов не могли часто использоваться в прошлом.
  • (Зависит от реализации) Внедрение графовой базы данных. Наиболее логичным способом создания графа вызовов и его оптимального использования было бы сохранение каждой функции в виде узла во встроенной графовой базе данных с ребрами, представляющими вызовы функций. Когда код необходимо скомпилировать, мы можем обновить файлы для изменяемых узлов, создав своего рода этап сборки.

Дополнительные преимущества

  • Граф вызовов, который будет сгенерирован и виден пользователю, можно использовать для обеспечения наиболее оптимального контекста для генеративного ИИ.
  • Режим упорядочения можно расширить, чтобы разрешить определение service-boundaries для разбиения монолитов на микросервисы. Вызовы функций через service-boundaries должны быть заменены автоматически сгенерированным кодом GRPC/Protobuf.