Octopus развернут спонсируется этот пост. Insight Partners является инвестором в Octopus Deploy и TNS.
В прошлом месяце GitClear опубликовал анализ 211 миллионов строк кода в своем отчете о качестве кода филота AI. Одним из ключевых выводов является то, что рефакторические сигналы сбиваются, в то время как дублирование кода и отток увеличивается. Фактически, 2024 год — это первый год, когда введение повторного кода больше, чем рефакторическая деятельность.
Эта тенденция объясняется ростом помощников по кодированию ИИ, и если она продолжится, мы могли бы направиться к программному кризису.
Раса по принятию ИИ
Если вы работаете в разработке программного обеспечения, кто -то сказал вам, что «ИИ не заменит разработчиков; Разработчики, использующие ИИ, заменит разработчиков, которые этого не делают ». Сообщение ясно: либо используйте ИИ, либо вы направляетесь к смене карьеры. Более позитивные сообщения предполагают, что мы можем удалить работу по труду — задачи, которые требуют высокого повторения и мало думают.
Недавнее обследование переполнений в области развития стека показало, что более 60% разработчиков в настоящее время используют ИИ в рамках своей работы, и больше планируют это сделать. Основной мотивацией для принятия ИИ является повышение производительности. Как показывает отчет Gitclear, драматическим недостатком желания повысить производительность является то, что вы можете снять свою велосипедную цепь, чтобы быстрее торговаться.
В случае разработки программного обеспечения мы сейчас быстро ускоряем скорость изменения в наших кодовых базах. В 2025 году прогнозируется, что скорость изменения будет почти вдвое больше, чем число до-аи (2021).
Ускоряющая скорость изменений, включая прогнозируемое общее количество 2025 года. Изображение из Octopus Deploy. Источник данных: Gitclear.
Этот скачок в производительности, вероятно, считается отличной новостью многими, особенно теми, кто продает ИИ. Однако мы должны помнить мудрость наших предшественников. Производительность обеспечивает плохое представление о работе знаний и была постоянно неуловимой в своих измерениях.
«Конечно, нет ничего такого бесполезного, как делать с большой эффективностью, что вообще не следует делать». — Питер Друкер, 1963.
Выбросить хорошую практику
До того, как мы стали одержимыми производительностью, были некоторые основополагающие практики, которые индустрия программного обеспечения оказалась очень ценной. Одним из них является рефакторинг. Вы строите более надежные системы, когда вы постоянно пересматриваете свой код, чтобы поддерживать компоненты свободно связаны и убедиться, что вы определяете концепции только один раз. Вы бы держали вещи вместе, если они изменится по той же причине и разделит их на части, если у них были разные драйверы для перемен.
Моя книжная полка скрипает под весом литературы по дизайну программного обеспечения Кента Бек, Эмили Бач, Мартина Фаулера, Роберта С. Мартина, Майкла Фетерса, Ребекки Парсонс, Стива Макконнелла и других. Эти книги содержат длительные методы и практики, которые жизненно важны для успешного программного обеспечения в течение длительного времени. Помощники кодирования не меняют основы разработки программного обеспечения.
Если мы ускоряем скорость изменений, мы должны соответствовать этому, не отставая от внутренней структуры программного обеспечения. Другими словами, чтобы это привело к успешной долгосрочной стратегии разработки программного обеспечения, мы должны иметь возможность рефакторировать в том же темпе, что и изменять код.
Но в отчете подчеркивается, что в настоящее время это не так.
Рефакторическая деятельность отслеживается с использованием категории изменений, называемой «перемещенный код». Именно здесь фундаментальная логика остается прежней, но была перетасована, чтобы улучшить дизайн кода. Это включает в себя классические узоры рефакторинга, такие как «метод извлечения» или «переменная переименования», которые обычно автоматизируются инструментами разработчика, чтобы гарантировать, что они являются безопасными рефактованными рефакториями (не говоря уже о практике разработки, управляемой тестированием, должна означать, что ваши тесты будут ловить любые случайные изменения поведения).
С 2021 года доля изменений рефакторирования резко упала с 24% до ниже 10%. В то же время количество копий/вставленных строк кода или дублирования увеличилось с ниже 10% до почти 15%.
Драматическая потеря рефакторинга и восхождение на дублирование.
Прогноз на 2025 год заключается в том, что мы достигнем точки, когда рефакторинг мертв, что составляет чуть более 3% от изменений кода. Наше программное обеспечение будет продолжаться в течение некоторого времени, прежде чем последствия этого станут ясными.
Урок приходит слишком поздно
Мне напоминают о организации, где я успешно заменил хаотичный, хрупкий процесс с непрерывной доставкой. Установленными ключевыми методами были автоматизация тестирования, автоматизация развертывания, а также система сплошного мониторинга и оповещения. Сочетание этих инструментов значительно повысило надежность и повысило уровень доверия между разработчиками и заинтересованными сторонами.
После того, как я ушел, команда решила, что управление тестовыми данными является нежелательной задачей. Они удалили сценарий базы данных, который работал в тестовых средах для сброса данных в известное состояние. В течение многих месяцев интеграционные тесты все еще работали и продолжали бы работать, если бы никто не изменил тестовые данные для тестовой записи, настроенной для тестирования интеграции.
Как только данные тестирования были избалованы, команда столкнулась с жестким выбором. Они могли бы воссоздать сценарий управления тестовыми данными, обновлять его, чтобы он работал со всеми изменениями в базе данных, которые они внесли. В качестве альтернативы они могут удалить неудачные тесты. Под давлением, чтобы предоставить функции (и оставаться «продуктивными»), команда удалила тесты.
Удаление тестов не оказывает непосредственного влияния. Эта функция продолжала работать в течение некоторого времени, но в конечном итоге были введены ошибки, а затем стали повторяющейся проблемой.
Это проблема, которая возникает, когда вы выбираете производительность в течение долгосрочной устойчивости. Требуется много времени, чтобы понять, что есть ущерб. Когда воздействие прошлых решений очевидно, часто может быть слишком поздно, чтобы смягчить его.
Полет против падения
Помощники кода ИИ обеспечивают идеальные условия для параболической скорости программного обеспечения. Подобно тому, как рейсы самолета нулевой гравитации, которые используют параболическую кривую, чтобы обеспечить ощущение невесомости, помощники кода заставляют нас поверить, что мы летим, когда мы фактически следуем баллистической траектории в свободном падении.
Чтобы ИИ устойчиво повысила вашу производительность, вы не можете позволить ему диктовать качество вашего кода.
Основанный в 2012 году, Octopus Deploy помогает командам DevOps более чем 3500 организаций ускорить надежные, повторяемые и прослеживаемые развертывания для мульти-облачных, гибридных и локальных сред. Осьминог объединяет сотни технологий, включая Azure, AWS, GCP и Kubernetes. Insight Partners является инвестором в Octopus Deploy и TNS. Узнайте больше последних из Octopus Deploy Trending Stories Youtube.com/thenewstack Tech, быстро движется, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Стив Фентон-Octonaut в Octopus Deploy, руководство по сообществу DORA и шестикратный Microsoft MVP с более чем двух десятилетий опыта в доставке программного обеспечения. Он написал книги о TypeScript (Apress, Infoq), развертывании Octopus и веб -операциях …. Подробнее от Стива Фентона
