Transcription
Вы, вероятно, видели тысячи постов генеральных директоров в LinkedIn, в которых говорилось, что код дешев, и они могут двигаться быстрее, чем когда-либо прежде. Но происходит то, что ИИ просто ускорил энтропию программного обеспечения. Другими словами, кодовые базы разваливаются быстрее, чем когда-либо прежде. Потому что каждый раз, когда вы вносите изменение, которое не учитывает всю кодовую базу, вы, вероятно, вводите мелочи, странные вещи, которые затрудняют изменение кодовой базы. И со временем это просто накапливается и накапливается, пока вы не получите огромный клубок грязи. Небрежная, небрежная грязь, которую невероятно трудно обратить вспять, если вы не знаете, как это сделать.
Я уже делал видео об этом, знакомя людей с идеей глубоких модулей. И это видео больше фокусируется на профилактике, на том, как вы можете предотвратить достижение вашей системы этой точки. Давайте теперь сосредоточимся на лечении. Как вы можете взять кодовую базу, которая кажется не подлежащей ремонту, и спасти ее. И вы можете сделать это с помощью некоторых старых добрых основ программного обеспечения, а также моего навыка улучшения архитектуры кодовой базы. Мы пройдемся по тому, что делает этот навык, повторим некоторые термины, которые мы рассматривали в другом видео, а затем возьмем это и применим к реальной кодовой базе. И это, кстати, часть моего репозитория навыков GitHub, который в настоящее время имеет 41,5 тыс. звезд. Безумие.
Теперь одна из вещей, которую я недавно добавил в этот навык улучшения архитектуры кодовой базы, — это глоссарий терминологии. Наличие общего словаря с ИИ очень важно, потому что это означает, что вы можете общаться, используя один и тот же язык. Вы можете понимать язык друг друга и быть гораздо более точным в том, что вы запрашиваете. Эта терминология здесь очень полезна, и я потрачу часть этого видео, чтобы объяснить, что на самом деле означают все эти термины. Честно говоря, простое понимание этих вещей на глубоком уровне сделает вас лучшим разработчиком программного обеспечения. Итак, давайте начнем с разговора о модулях.
Модуль — это единица чего-либо в вашем приложении. Это может быть набор компонентов React, которые вместе образуют страницу. Это может быть набор функций внутри вашего приложения, которые полностью отвечают за аутентификацию. Или это может быть просто логгер, который вы выбрали, например, логирование в консоль, логирование в файл или логирование в сторонний сервис. В хорошей кодовой базе эти модули общаются друг с другом, и они общаются друг с другом через свои интерфейсы. Интерфейс — это все, что вызывающий абонент должен знать, чтобы правильно использовать модуль. Например, если это модуль аутентификации, то у него может быть метод входа в систему. У него может быть метод выхода из системы. И эти методы являются интерфейсом этого модуля.
Методы — это не единственное, что важно. Интерфейс также включает в себя некоторую неопределенную информацию о том, как вызывать модуль. Так, возможно, это и документация. Реализация — это то, что находится внутри модуля, что он на самом деле делает, когда вы вызываете вход в систему или выход из системы. И вот это — основная примитивная единица, о которой мы говорим, модули, которые имеют интерфейсы и реализации, разбросанные по всему вашему приложению. Эти модули могут быть либо глубокими модулями, либо мелкими модулями. Глубокий модуль скрывает множество реализаций за относительно простым интерфейсом. Мелкий модуль имеет сложный интерфейс и, по сути, не так много реализации за ним. Эти идеи взяты из книги Джона Астероута «Философия проектирования программного обеспечения», которую я рекомендую вам приобрести.
Глубокие модули считаются лучше мелких, потому что они скрывают больше информации от вызывающего абонента. Другими словами, человек, который вызывает это, или функция, которая вызывает это, должен знать только об этом крошечном интерфейсе, и он получит доступ ко всей этой реализации. Прекрасно. И вот что мы описываем как глубину. Количество поведения, которое вызывающий абонент может использовать на единицу интерфейса, который ему приходится изучать. Действительно хорошие библиотеки с открытым исходным кодом, такие как Tanstack query или что-то подобное, имеют действительно хорошие глубокие модули. Другими словами, они скрывают много сложности за супер простым интерфейсом.
Эти модули затем взаимодействуют друг с другом и имеют зависимости друг от друга. Например, этот модуль может взаимодействовать с этим модулем здесь, который затем взаимодействует с этим модулем выше, и этим модулем выше. И между ними есть эти графы зависимостей. Эти промежутки между этими модулями называются швами. Это место, где интерфейс модуля находится в приложении. Эти швы обычно являются местом, где вы будете проводить модульное тестирование или интеграционное тестирование. Например, если бы мы хотели протестировать этот модуль в изоляции здесь, то мы бы добавили мок или что-то еще прямо на этом шве. Таким образом, определение того, где будут находиться ваши швы в вашем приложении, имеет решающее значение для получения хорошей архитектуры.
Когда вы обнаруживаете, где находится шов в вашем приложении, вам нужна конкретная вещь, модуль, который удовлетворяет этому интерфейсу. Это то, что я буду называть адаптером, который я беру из гексагональной архитектуры. Например, если у вас есть какое-то приложение, которое зависит от работающих часов, то вы можете захотеть иметь часы, обычные часы внутри здесь, используя фактические живые часы. А затем внутри некоторых тестов вы можете захотеть иметь адаптер, который является фальшивыми часами. Оба они удовлетворяют интерфейсу в этом шве. И это означает, что вы можете использовать фальшивые часы в тестах. Так что вам не придется буквально ждать 2 недели, пока ваши тесты закончатся. Вот как швы и адаптеры работают вместе.
Преимущество всего этого заключается в том, что эти глубокие модули имеют два основных свойства или два основных преимущества, которые вы получаете от них. Но сопровождающие, люди, поддерживающие этот модуль, получают локальность изменений в этом модуле и ошибки, а также все исправления, связанные с ними. Они концентрируются в одном месте в этом глубоком модуле. Если они разбросаны по нескольким разным модулям, то у вас низкая локальность. Вам нужна высокая локальность, группировка и совместное размещение вещей, которые важны и часто меняются вместе. Люди, использующие этот модуль, получат больше рычагов, чем глубже модуль. Другими словами, больше возможностей на единицу интерфейса, который им приходится изучать. И поэтому, когда мы говорим об улучшении наших кодовых баз, мы стремимся к этим двум атрибутам.
Итак, достаточно знаний. Мы знаем основные правила игры. Теперь давайте улучшим кодовую базу. Кодовая база, которую мы собираемся рассмотреть, — это моя кодовая база менеджера видеокурсов, которая является репозиторием программного обеспечения, которое я фактически использую для записи этого видео. Эта кодовая база насчитывает около 1500 коммитов. И я бы не сказал, что это клубок грязи, но я также не сказал бы, что она идеальна. Это приложение React router. Оно использует effect.ts под капотом. Итак, давайте приступим. Я открою новую сессию Claude здесь и запущу свой навык улучшения архитектуры кодовой базы. Я отключу автоматический режим. Автоматический режим делает некоторые забавные вещи с этими потоками в стиле «человек в цикле», и поэтому я не хочу, чтобы он был включен. Мы видим, что он исследует и просматривает код. Это то, что ему поручено делать в первую очередь. Вот оно. Исследуйте архитектуру на предмет возможностей углубления. Обычно плохая кодовая база — это та, которая имеет множество мелких модулей или та, которая имеет очень плохие рычаги для этих модулей или плохую локальность, где много всего разбросано по разным местам.
Хорошо, он вернулся с некоторыми кандидатами. Давайте увеличим размер экрана и, надеюсь, Claude Code не уничтожит себя. Хорошо, я полагаю, мы не будем увеличивать размер экрана. Спасибо за это, Claude Code. Мы видим, что он определил шесть возможностей углубления. Эти кандидаты довольно трудно объяснить, потому что они требуют знаний о моем репозитории. Но мы видим здесь, что он говорит, что есть концепция, у которой нет единого шва. Другими словами, есть две реализации этой точки вставки, и они существуют параллельно. И шов, в котором они должны совпадать, не протестирован. По сути, это означает, что фронтенд может внести некоторые изменения, но бэкенд, поскольку у него есть отдельная параллельная реализация, может быть не синхронизирован с ним. Так что я думаю, что это действительно хороший кандидат для рефакторинга в один модуль. Мы получаем локальность, и он говорит, что здесь мы получим локальность. Правило порядка вставки клипов находится в одном месте. Так что давайте посмотрим на это. Давайте на самом деле скажем, да, я хотел бы выбрать один здесь. Это кажется хорошим кандидатом. Так что давайте запустим это и посмотрим, что он скажет.
Хорошо, Клод меня троллит. Он говорит: «Я хотел бы выбрать один». Я имел в виду «один». Отлично. Хорошо. Итак, он вернулся с конкретным кодом с обеих сторон, чтобы обосновать это. И он входит в сессию допроса. И в этой сессии допроса мы можем взять идеи отсюда и начать обсуждать, каким может быть лучшее решение. Здесь есть хорошее предложение: «У бэкенда нет конца». Давайте не будем воспринимать это слишком буквально. В конечном итоге вы делаете с этим навыком то, что обсуждаете потенциальное предложенное решение, и он затем предложит форму. И как только все это будет сделано, вы можете взять это и поместить это в виде проблемы GitHub в ваш трекер проблем, который затем может быть подхвачен AFK-агентом. Вам следует посмотреть мое видео о San Castle, если вы заинтересованы в этом.
Теперь, в ходе обычной разработки, я бы прошел и вдумчиво ответил на каждый из этих вопросов по очереди. Но поскольку я снимаю видео, и это немного искусственно, я скажу: «Не могли бы вы просто выбрать рекомендуемые ответы на каждый из этих вопросов?» И это должно ускорить нас до фактического внесения изменений или потенциального создания проблемы из этого. Итак, теперь он вернулся с предложенной формой модуля. И он также просит проверить определенную часть реализации, где конец свернут, и набросать фактический интерфейс TypeScript. Да, сделайте и то, и другое. Это звучит отлично. Давайте отправим это и посмотрим, что он скажет.
Хорошо, он выяснил необходимую деталь реализации и вернулся с предложенным дизайном. Итак, каждая из этих функций будет, по сути, интерфейсом для этого модуля. И поэтому мы можем обсудить это с ИИ и выяснить. Он снова вернулся с двумя проектными решениями, по которым он хочет получить мой отзыв. И здесь, я думаю, вы получите представление о том, как работает этот навык, и о типах разговоров, которые вы в конечном итоге ведете с ИИ на основе этого. Если я хочу превратить это в проблему, которую мой AFK-агент подхватит, я могу использовать два PRD или две проблемы здесь. И, кстати, если вы заинтересованы в этих навыках, о которых я говорю, то вам следует посетить этот сайт здесь, ссылка на который приведена ниже. Я собираюсь создать настоящий сайт документации для этих навыков. А пока у меня есть информационный бюллетень, на который вы можете подписаться, чтобы получать последние обновления, а также советы и ресурсы для получения максимальной отдачи от агентов.
Важно заметить здесь, насколько этот навык требует от вас, пользователя. Это не AFK-навык, который вы можете просто запустить и просто полагаться на него для постоянного улучшения вашей кодовой базы. Это требует от вас, программиста, сидящего над LLM, принятия решений. Я думаю об агентах как о действительно, действительно хороших тактических программистах. Они способны быстро действовать и вносить изменения, но им нужен кто-то на уровне выше них, кто является стратегическим программистом. И именно это делает этот навык. Он позволяет сержанту бегать по кодовой базе и искать потенциальные возможности для улучшения, но затем вы, генерал, должны внести фактические изменения и решить, что хорошо для долгосрочного здоровья кодовой базы.
Я рекомендую вам запускать этот навык, знаете ли, каждые пару дней, особенно в быстро меняющейся кодовой базе, вы найдете множество возможностей для углубления кодовой базы. И чем глубже вы сделаете эти модули, тем больше рычагов вы получите от них. А рычаги также означают тестирование. Если у вас есть набор действительно хороших четких швов в вашей кодовой базе, то вы сможете писать действительно хорошие тесты вокруг этих хороших глубоких модулей. И чем лучше ваши тесты, тем лучше будет результат работы агента.
Последняя мысль: многие люди спрашивают меня, как начать использовать ИИ в устаревшей кодовой базе. И устаревшая кодовая база, вероятно, будет иметь много мелких модулей. Я имею в виду, мы говорим об устаревших кодовых базах. Что мы действительно имеем в виду, так это плохие кодовые базы. Кодовые базы, в которые трудно вносить изменения. И вам действительно нужно, прежде чем вы начнете вносить изменения в устаревшую кодовую базу, иметь обвязку вокруг кодовой базы, чтобы убедиться, что ваши изменения ничего не испортят. Для этого вам нужны тесты, тестирующие действительно хорошие глубокие модули, которые имеют большой рычаг и локальность. Так что запуск улучшения архитектуры кодовой базы — отличное место для начала.
Спасибо за просмотр, ребята, и я надеюсь, что это ответит на некоторые ваши вопросы о том, как решить эту бесконечную проблему ИИ, который просто выходит из-под контроля и создает ужасные кодовые базы. Надеюсь, вам понравятся навыки. Следуйте по ссылке ниже, если хотите найти больше из них. Итак, спасибо за просмотр, и я увижу вас в следующем видео.