Блог

Голосовое кодирование: пишите документацию и комментарии, говоря

Миф голосового кодирования

Когда разработчики слышат «голосовое кодирование», большинство представляют себе, как кто-то диктует синтаксис Python вслух: «def пробел calculate underscore total открыть paren items закрыть paren colon...» Это не голосовое кодирование. Это пытка.

Реальное голосовое кодирование — это не замена клавиатурного ввода на синтаксис. Это использование вашего голоса для большой части разработки программного обеспечения, которая на естественном языке: документация, комментарии, сообщения коммитов, описания PR, разбивки задач, обновления Slack и обзоры кода.

Соотношение естественного языка к синтаксису в большинстве работы разработки выше, чем осознают большинство разработчиков. Тщательный разработчик может потратить:

  • 20% на написание кода
  • 30% на написание документации и комментариев
  • 15% на написание описаний проблем и содержания PR
  • 20% на Slack, электронную почту и встречи
  • 15% на обзор кода и планирование

Это 80% работы, где голосовой ввод либо быстрее, чем печать, либо одинаково эффективен. 20%, который является фактическим синтаксисом, остаётся на клавиатуре.

Что диктовать как разработчику

Комментарии кода

Комментарии — это чистый естественный язык. Написание чёткого комментария, объясняющего, почему функция существует, какие граничные случаи она обрабатывает, или что должно знать вызывающее лицо, легче говорить, чем печатать.

Рабочий процесс: Навигируйте к местоположению комментария в редакторе, нажмите клавишу быстрого доступа, произнесите объяснение, отпустите. Режим Clean удаляет слова-паразиты и выдаёт чистую прозу.

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

Документация и README

Файлы README, документация API и встроенные комментарии JSDoc/docstring — это именно то место, где голосовой ввод преуспевает. Вы пишете для человека-читателя в естественной прозе — то же самое, что вы бы сказали, если бы кто-то попросил вас объяснить код.

Говорение документации функции при просмотре кода выдаёт лучшую документацию, чем печать её. Вы описываете то, что видите естественно, без трения перевода мысли в нажатия клавиш.

Сообщения коммитов

Хорошие сообщения коммитов — это короткая проза: что изменилось и почему. Говорение сообщения коммита быстрее, чем печать одного, и режим Clean гарантирует, что оно читается хорошо.

Описания запроса на вытягивание

Описания PR — проблема, решение, план тестирования, примечания рецензента — это именно тот вид структурированного содержания, который режимы обогащения Telvr хорошо справляются. Режим Dev Task выдаёт эту структуру нативно.

Пример: Нажмите клавишу быстрого доступа, переключитесь на режим Dev Task, скажите «исправлено состояние гонки в потоке обработки платежей, проблема была в том, что два одновременных запроса могли оба проверить баланс перед вычитанием одного из них, добавлены блокировку строк уровня базы данных вокруг транзакции, добавлен тест, который порождает две одновременные попытки платежа», отпустите. Результат — структурированное описание PR с проблемой, решением и примечаниями тестирования.

Описания проблем и описания задач

Написание подробного отчёта об ошибке или спецификации функции печатанием скучно. Говорение её естественно при просмотре проблемы быстрее и часто выдаёт более полные описания, потому что вы не борётесь с механическими затратами на печать.

Обновления Slack и команды

Обновления прогресса, блокировки, резюме standup — это разговорные по природе. «Я закончил рефакторинг auth вчера, сегодня я работаю над интеграцией платежей, заблокирован получением учётных данных теста для окружения sandbox, буду просить Sarah.» Это полный standup за 15 секунд речи.

Настройка для рабочих процессов разработчика

Конфигурация клавиши быстрого доступа

Клавиша быстрого доступа Telvr по умолчанию (Option + Space на Mac) хорошо работает для разработчиков, потому что она не конфликтует с большинством ярлыков IDE. Если вы предпочитаете что-то другое, клавиша быстрого доступа настраивается.

Рекомендуемая настройка для разработчиков:

  • Держите руки на домашней строке
  • Используйте комбинацию двух клавиш, чтобы предотвратить случайную активацию в терминале
  • Избегайте клавиш быстрого доступа, которые конфликтуют с вашей IDE (проверьте карты ключей VS Code или JetBrains)

Выбор режима

Для рабочих процессов разработчика:

  • Режим Clean: Общие комментарии, проза документации, сообщения Slack
  • Режим Dev Task: Описания PR, спецификации проблем, резюме технических требований
  • Режим Meeting Notes: Заметки постспринт-ретроспективы, резюме обсуждений дизайна
  • Режим Email: Коммуникация с клиентом на техническом уровне, обновления статуса для нетехнических заинтересованных лиц

Интеграция IDE

Telvr использует вставку текста на уровне системы, что означает, что она работает в любом текстовом поле в любом приложении. Это включает:

  • VS Code (редактор кода, интегрированный терминал, поиск, комментарии)
  • JetBrains IDE (IntelliJ, WebStorm, PyCharm)
  • Zed, Neovim (когда в режиме вставки)
  • Linear, Jira, GitHub (в браузере)
  • Терминал (при вводе текста, отличного от команды, такого как сообщения git commit)

Нет плагина для установки. Любое редактируемое текстовое поле честная игра.

Рабочий процесс разработчика в реальном мире

Вот как выглядит сеанс разработки с голосовым вводом на практике:

Утренний standup в Slack: Нажмите клавишу быстрого доступа, скажите вчерашний прогресс + план на сегодня + блокировки, отпустите. Готово за 20 секунд.

Написание кода: Клавиатура. Обычный рабочий процесс разработки.

Добавление комментария к сложной функции: Навигируйте на правую строку, нажмите клавишу быстрого доступа, произнесите объяснение естественно, отпустите.

Создание проблемы GitHub для ошибки: Откройте новую проблему, нажмите клавишу быстрого доступа с режимом Dev Task, опишите ошибку и шаги воспроизведения, отпустите. Озаглавьте проблему, отправьте.

Написание сообщения коммита: git commit в терминале, нажмите клавишу быстрого доступа в открывающемся редакторе (или передайте в файл), произнесите описание коммита, отпустите.

Написание описания PR: Откройте форму PR, нажмите клавишу быстрого доступа с режимом Dev Task, объясните, что делает PR и почему, отпустите. Добавьте примечания рецензента, если нужно.

Ответ на технический вопрос в Slack: Нажмите клавишу быстрого доступа, объясните технического решение или концепцию вслух, отпустите. Режим Clean выдаёт понятное объяснение без необходимости печатать осторожно.

Реальность производительности

Самые большие выигрыши от голосового ввода в разработке исходят не из сырой скорости, а из снижения трения. Документация часто откладывается или полностью пропускается, потому что печатание её кажется накладной расходов на вершину фактической работы кодирования. Когда написание комментария или docstring занимает 15 секунд речи, а не 2 минуты осторожной печати, порог для добавления его значительно падает.

Лучше задокументированный код, более полные описания PR и более полные отчёты о проблемах часто являются практическим результатом голосового ввода разработчика — не просто более быстрое выполнение одних и тех же привычек.

Одна неделя для новой привычки

Получить голосовой ввод в рабочий процесс разработки:

День 1: Используйте голос только для сообщений Slack. Ничего больше.

День 3: Добавьте сообщения коммитов. Произнесите описание в редактор терминала.

День 5: Добавьте встроенные комментарии. Начните рассказывать сложные функции, когда закончите их писать.

День 7: Добавьте описания PR с режимом Dev Task. Заметьте, что вы пишете более полные описания, чем раньше, потому что говорение быстрее, чем печать.

После двух недель привычки установлены и голосовой ввод кажется естественным, а не трудоёмким.