Единица 4 / 12

Обзор кода, рефакторинг и технический долг

Прибыль:

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

В разработке программного обеспечения код читается гораздо больше, чем пишется. Строка кода пишется один раз, но читается, модифицируется и дополняется десятки раз в течение месяцев. Вот почему обзор кода (проверка чужого или собственного кода на предмет логики, читабельности и безопасности) и рефакторинг (улучшение структуры кода без изменения его поведения) лежат в основе инженерии. ИИ становится мощным «вторым глазом» для этих двух задач: он быстро обеспечивает читаемость, указывает на упущенные из виду проблемы логики и безопасности и разбивает большой рефакторинг на более мелкие безопасные шаги. Но есть важнейшее правило: рефакторинг не должен менять поведение, и единственное, что гарантирует это, — это тестирование.

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

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

Использование ИИ в обзоре структурированного кода

Когда время ограничено, необходимо сосредоточиться на проблемах с наибольшим риском. Автоматический форматтер решает такие проблемы форматирования, как отступы и интервалы; Вы должны уделять человеческое внимание логике, безопасности и поведению в крайних случаях. При проведении обзора ИИ попросите список приоритетов, а не просто шквал отзывов.

  1. Дайте простор. Какой код, что делать, в каком контексте он работает.
  2. Укажите приоритетную ось. На первом месте точность и безопасность, на втором — читаемость.
  3. Попросите конкретную корректировку. «Почему проблема» и «рекомендуемое решение» для каждого результата.
  4. Вы проверяете выводы. ИИ также выдает ложные срабатывания; Сверьте каждый результат с кодом и тестированием.

Подсказка для структурированного обзора: «Изучите следующую функцию, как старший инженер. Перечислите результаты в порядке важности и отметьте их следующими тегами: [КРИТИЧЕСКАЯ] логика/безопасность, [СРЕДНИЙ] крайний случай/производительность, [НИЗКАЯ] читабельность/имя. Для каждого результата: зачем спрашивать, конкретное предложение по исправлению. НЕ ПРОПУСКАЙТЕ проблемы с форматированием/отступами, автоматический инструмент справится с этим. Код: [код]»

Подсказка для проверки, ориентированной на безопасность: «Проверьте этот код только в целях безопасности: отсутствие проверки входных данных, риск внедрения, отсутствие контроля авторизации, утечка конфиденциальной информации, небезопасные значения по умолчанию. Добавьте пример сценария атаки к каждому результату. Если проблем с безопасностью нет, четко укажите: «Я не обнаружил никаких критических проблем безопасности». Код: [код]»

Внимание: то, что ИИ говорит «нет проблем», не является доказательством отсутствия проблемы. ИИ может давать ложноотрицательные результаты; может обойти реальную проблему безопасности. Проверка ИИ дополняет, а не заменяет проверку человеком и тестирование безопасности. В критически важном для безопасности коде последнее слово остается за компетентным инженером.

Рефакторинг с сохранением тестов

Золотое правило рефакторинга: сначала тестируйте, потом меняйте. Прежде чем исправлять код, должны быть тесты, которые блокируют текущее поведение, чтобы вы сразу знали, если изменение что-то сломает. Не нарушайте порядок при рефакторинге ИИ.

  1. Проверьте текущее поведение. В противном случае попросите ИИ провести «тест характеристики» (тест, который фиксирует текущее поведение таким, какое оно есть).
  2. Исправляйте это небольшими шагами. Тестирование должно оставаться зеленым на каждом этапе.
  3. Запускайте его после каждого шага. Лови регресс как можно раньше.

Подсказка плана безопасного рефакторинга: «Следующая 60-строчная функция делает слишком много и ее трудно читать. Я хочу провести ее рефакторинг БЕЗ изменения ее поведения. Сначала: перечислите, какие тестовые примеры мне нужны, чтобы зафиксировать текущее поведение. Затем: разбейте рефакторинг на небольшие шаги, каждый из которых может быть выполнен, пока тесты зеленые. Пока не пишите код, сначала дайте план. Код: [код]»

Слабая подсказка/Сильная подсказка

СЛАБАЯ: «Сделайте этот код лучше». (Результат: неясно, что улучшить; ИИ вносит произвольные изменения, может изменить поведение молча.) СИЛЬНО: «Проведите рефакторинг этой функции расчета платежей для удобства чтения. ОГРАНИЧЕНИЕ: поведение должно оставаться точно таким же, возвращаемые значения не должны меняться. Разделите длинную функцию на значимые служебные функции, увеличивая магические числа до именованных констант. Перечислите изменения поэлементно и объясните, ПОЧЕМУ каждый элемент не меняет поведение. Код: [код]»

В мощной подсказке четко указано, что ограничение «поведение должно оставаться точно таким же» и что необходимо улучшить. Без этого ограничения ИИ может изменить логику во имя «улучшения» и произвести тихий регресс.

Управление техническим долгом

Подход

В краткосрочной перспективе

в долгосрочной перспективе

игнорирование долга

быстрый прогресс

Паралич технического обслуживания, работа команды замедляется

переписать все

Постоянная разработка функций

Неопределенная доходность, высокий риск

Измеренный, защищенный тестированием рефакторинг

незначительное замедление

Устойчивая скорость

Самый здоровый способ — третий: сделайте долг видимым (отслеживайте его в списке), начните с того места, где он болит больше всего, и проверяйте каждое исправление. ИИ является хорошим помощником в выявлении и определении приоритетности статей долга, но какой долг платить — это бизнес-решение.

Мини-кейсы

Случай 1 — Тихая регрессия. Разработчик говорит ИИ «упростить эту функцию»; ИИ неправильно переводит условие и расчет возврата нарушается. Поскольку тестирования нет, ошибка возникает через 3 недели при жалобе клиента. Команда проделывает ту же работу: сначала пишет тест характеристики и обнаруживает ошибку с помощью красного теста при первом запуске.

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

Случай 3 — Ложное срабатывание. ИИ говорит: «Эта переменная никогда не используется, удалите ее»; Однако он используется косвенно через механизм переменного отражения. Если инженер не проверит предложение на соответствие тесту, оно будет удалено и произойдет ошибка времени выполнения. Каждое открытие ИИ должно быть подтверждено перед реализацией.

Распространенные ошибки

  • Рефакторинг без тестирования. Не остается ничего, что могло бы гарантировать сохранение поведения.
  • Применение результатов ИИ без их проверки. Бывают как ложноположительные, так и ложноотрицательные результаты.
  • Трата человеческого времени на проблемы с форматом. Сосредоточение внимания на задачах, которые можно решить с помощью автоматизированных инструментов, затмевает реальные риски.
  • Принимая ответ «Нет проблем» в качестве гарантии. ИИ может обойти уязвимости; требуется человеческий анализ.
  • Пытаюсь погасить весь долг сразу. Крупные переписывания рискованны; Предпочтительны шаги, которые измерены и защищены тестированием.

В итоге

Проверка кода и рефакторинг определяют долговечность кода. ИИ — это мощный второй глаз и генератор планов: он предоставляет приоритетные выводы, сценарии безопасности и планы мелкошагового рефакторинга. Но рефакторинг не должен изменить поведение, и только тестирование гарантирует это. Сверяйте каждое заключение ИИ с кодом и тестированием; Не воспринимайте ответ «нет проблем» как доказательство. Сделайте технический долг видимым и погашайте его взвешенными, защищенными тестами шагами.

Задача приложения

Возьмите 40-70 строк, довольно сложную функцию, которая у вас есть (или попросите ИИ ее сгенерировать). Сначала следуйте подсказке структурированного обзора и отсортируйте результаты по категориям [КРИТИЧЕСКИЙ]/[СРЕДНИЙ]/[НИЗКИЙ]; Вручную сверьте хотя бы один результат с кодом. Затем, получив подсказку плана безопасного рефакторинга, сначала сгенерируйте и запустите характеризационные тесты, затем примените рефакторинг небольшими шагами и убедитесь, что тесты остаются зелеными на каждом этапе.

контрольный список

  • [ ] Я структурировал обзор с помощью тегов приоритета (критический/средний/низкий).
  • [ ] Я проверил по крайней мере одно заключение ИИ по коду/тесту.
  • [ ] Перед рефакторингом я протестировал текущее поведение.
  • [ ] Я вносил изменения небольшими шагами и проводил тесты на каждом этапе.
  • [ ] В приглашении я указал ограничение «Поведение должно оставаться прежним».
  • [ ] Я подтвердил, что результаты безопасности требуют подтверждения человеком.