The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Релиз ChatGPT 3.5 изменил все для нас, программистов. Несмотря на то, что большинство из нас (включая меня) не понимает, как это работает, некоторые из нас используют его чаще, чем Stack Overflow, Google и встроенные функции IDE. Я считаю, что это только начало. Несмотря на то, что только Microsoft знает, что произойдет дальше, позвольте мне попробовать сделать скромное предсказание тоже. Ниже я перечислю, что, по моему мнению, роботы (с Генеративным ИИ на борту) будут делать в будущем. Чем дальше в будущее, тем ниже в списке. Я постарался не повторять то, что уже говорит GitHubNext.
Сообщать о багах. Они будут изучать кодовую базу, анализировать код и, возможно, даже пытаться запускать некоторые тесты, затем отправлять отчеты о багах, когда проблемы очевидны. Они также будут отправлять отчеты о багах, когда они обнаружат код, который сложно понять, неправильно задокументирован, не покрыт автоматическими тестами или имеет уязвимости безопасности. Кроме того, они будут сообщать, когда видят, что код не соответствует конвенциям или лучшим практикам. Они будут писать свои отчеты настолько хорошо и предоставлять столько технических деталей и дополнительных ссылок, что программисты будут предпочитать отчеты от роботов гораздо больше, чем отчеты от людей.
Проверка запросов на включение изменений. Они будут изучать запросы на включение изменений, отправленные в репозиторий (как людьми, так и роботами), и проверять их, делая комментарии по определенным строкам кода, либо критикуя качество кода, либо предлагая лучшие альтернативы. Они будут отслеживать предложения, сделанные ранее, и будут настаивать, когда это необходимо. В конце концов, авторы запросов на включение изменений даже не будут знать, кто их проверяет: человек или робот.
Рефакторинг. Из огромного набора известных микро-рефакторингов они будут выбирать несколько наиболее важных в данный момент и будут отправлять запросы на включение изменений с этими изменениями. Они не изменят функциональность кода или будут делать массовые модификации. Вместо этого они будут улучшать качество кода небольшими шагами, делая его легким для нас, людей, чтобы объединять предложенные изменения. Они не будут делать слишком много изменений, поэтому мы не почувствуем, что управляемы роботами, но на самом деле мы будем. Медленно и постепенно они будут улучшать кодовую базу, делая ее более читаемой, поддерживаемой и понятной … для других роботов.
Определение приоритетов в списке задач. Они будут сортировать задачи и тикеты в соответствующие этапы, определяя, какие из них являются более приоритетными. Они будут решать, какой баг нужно исправить первым и какая функция более важна, чем другие. Используя исторические данные, текущую скорость команды и другие соответствующие метрики, они создадут приоритизированный список задач, соответствующий как краткосрочным целям, так и долгосрочным целям.
Уточнение отчетов о багах. Они будут изучать уже сообщенные баги и уточнять их, предоставляя дополнительную информацию, объясняя код, на который ссылается баг, и предлагая фрагменты кода, которые могут воспроизвести баг. Они выполнят работу, которую большинство программистов слишком ленивы сделать: правильно объяснить баг, чтобы помочь его исправителю.
Документация исходного кода. Они будут находить места в коде, которые трудно понять, такие как сложные функции, большие классы и большие структуры данных. Они будут генерировать блоки документации, а затем отправлять запросы на включение изменений с ними. Люди будут рады принять эти изменения, так как документирование кода другого человека - это рутина и скучная часть работы. Кроме того, поддержание документации в соответствии с исходным кодом - это одна из областей, где наша человеческая небрежность наиболее заметна.
Исправление багов. Исходя из кода, который они уже видят в кодовой базе и списка сообщенных проблем, они будут генерировать исправления и отправлять их в виде новых запросов на включение изменений. Они будут объяснять, что делают исправления, почему улучшение делается таким или иным образом, насколько критично исправление, а также предлагать возможные альтернативы. Мы просто будем их объединять.
Формализация требований. Они будут изучать кодовую базу и комментарии, в которых мы обсуждаем ее, и будут производить формальное определение требований, которые мы реализуем. Затем они сформулируют требования, используя диаграммы Use Case, матрицы требований или даже неформальные текстовые документы, такие как README или Wiki. Они будут поддерживать эти документы в актуальном состоянии на протяжении всего жизненного цикла кодовой базы - то, что мы, люди, часто слишком ленивы делать.
Помощь в обучении. Они будут помогать в процессе обучения новых разработчиков, руководя их через кодовую базу, объясняя архитектурные решения и предлагая персонализированные учебники. Они также помогут нам понять определенные блоки кода, предоставляя интерактивное руководство.
Анализ технического долга. Они смогут анализировать кодовую базу, чтобы определить области, где накапливается технический долг, и предложить шаги по его устранению до того, как это станет проблемой. Они будут создавать тикеты, в которых будут определены наиболее значимые области долга и предложены улучшения.
Очистка документации. Они будут форматировать блоки документации, которые мы, люди, пишем для наших классов и методов, а затем отправлять запросы на включение изменений с этими изменениями. Форматирование документации правильно, с использованием HTML, Markdown, Doxia и многих других форматов, является скучной работой, в которой мы, люди, недостаточно хороши.
Предложение новых функций. Они будут изучать уже реализованную функциональность и будут предлагать дополнительные функции, отправляя тикеты. Они будут объяснять причины таких новых запросов на добавление функциональности, находить надлежащее обоснование и предоставлять примеры взаимодействия пользователей с новой функциональностью.
Документация архитектуры. Они будут изучать кодовую базу, а затем обновлять документацию об архитектуре, которую она реализует. Это то, что программисты обычно забывают сделать или просто не знают, как делать правильно. Роботы будут использовать UML или, возможно, менее формальные инструменты для документирования архитектуры, тем самым облегчая поддержку всего продукта.
Оценка. Они будут оценивать сложность каждого отчета о баге или запроса на добавление функциональности в рабочих часах, календарных днях, или, возможно, в строках кода. Эта информация поможет ком
Translated by ChatGPT gpt-3.5-turbo/36 on 2023-09-30 at 05:13
