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, Requirement Matrix или даже неформальных текстовых документов, таких как README или Wiki. Они будут поддерживать эти документы в актуальном состоянии на протяжении всего жизненного цикла кодовой базы - что-то, что мы, люди, часто слишком ленивы делать.
Ввод в работу. Они будут помогать в процессе ввода новых разработчиков, проводить их через кодовую базу, объяснять архитектурные решения и предлагать персонализированные учебные материалы. Они также помогут нам понять определенные блоки кода, предоставляя интерактивное руководство.
Анализ технического долга. Они смогут проанализировать кодовую базу, чтобы определить области, где накапливается технический долг, и предложить шаги по его смягчению до того, как он станет проблемным. Они будут отправлять задачи, где будет определены самые большие “территории долга”, и будут предлагать улучшения.
Очистка документации. Они будут форматировать блоки документации, которые мы, люди, пишем для наших классов и методов, а затем отправят запросы на включение изменений с изменениями. Форматирование документации правильно, с использованием HTML, Markdown, Doxia и многих других форматов, является скучной работой, в которой мы, люди, часто ошибаемся.
Предложение новых функций. Они будут изучать уже реализованный функционал и будут предлагать дополнительные возможности, отправляя задачи. Они будут объяснять причины таких новых запросов на функционал, находить правильное обоснование и предоставлять примеры того, как пользователи будут взаимодействовать с новой функциональностью.
Документирование архитектуры. Они будут наблюдать за кодовой базой, а затем обновят документацию о реализованной архитектуре. Это то, что программисты обычно забывают сделать или просто не знают, как сделать правильно. Роботы будут использовать UML или, возможно, менее формальные инструменты для документирования архитектуры, делая весь продукт более легким в обслуживании.
Оценка. Они будут оценивать сложность каждого отчета об ошибке или запроса на функционал в человекочасах, календарных днях или, возможно, в количестве строк кода. Эта информация поможет команде принимать решения о планировании.
Прогнозирование. Анализируя
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-16 at 15:51
