Communication Engineering Чаты, почта и code review
0%
Communication Engineering

Чаты, почта и code review

Как выбирать асинхронный канал, снижать дробление контекста и писать полезные комментарии к коду.

Либо ты планируешь свою жизнь, либо она с тобой случается.
Николай Мрочковский — «Экстремальный тайм-менеджмент»
Асинхронные сообщения собираются в темы, решения и проверяемые изменения кода.
Communication Engineering · async

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

Чат

Чат подходит для короткого уточнения, оперативного сигнала и координации. Он плохо подходит для долгоживущего решения.

Хорошее сообщение содержит:

  • тему в первой строке;
  • необходимый контекст;
  • конкретный вопрос или просьбу;
  • срок и причину срока;
  • ссылку на подробный артефакт.

Если ветка стала длиннее экрана, спор повторяется или появляются несколько альтернатив, соберите состояние в документ. Встреча нужна не автоматически: иногда достаточно одного резюме.

Почта

Почта полезна для формальной внешней коммуникации, широкого объявления и сообщения, которое должно пережить чат. Тема письма является интерфейсом:

  • [Решение до 18 июля] Контракт интеграции
  • [Для информации] Итоги миграции
  • [Действие] Подтвердить владельцев до пятницы

Один тред — одна развивающаяся тема. Если цель изменилась, создайте новое письмо.

Code review

Ревью — проверка изменения и передача инженерного контекста. Оно не должно быть соревнованием в стиле.

Полезно маркировать комментарии:

  • blocker: риск корректности, безопасности, данных;
  • question: нужен контекст;
  • suggestion: улучшение, не блокирующее merge;
  • nit: мелочь;
  • praise: решение, которое стоит повторять.

Комментарий объясняет причину:

blocker: при повторной доставке этот вызов создаст вторую оплату. Нужен idempotency key или проверка существующей операции. Тестовый сценарий: два одинаковых события.

Фраза «переделай» не передаёт модель.

Ответственность автора

Автор изменения:

  • описывает цель и риск;
  • ограничивает размер PR;
  • указывает способ проверки;
  • сам делает первый проход;
  • отвечает на комментарии решением или аргументом;
  • не закрывает замечание без ясности.

Ревьюер:

  • отвечает в согласованный срок;
  • читает контекст до деталей;
  • отделяет стандарт от вкуса;
  • предлагает пример там, где формулировка неоднозначна;
  • не требует несвязанный рефакторинг внутри задачи.
Было

«Почему здесь вообще так? Выглядит ужасно».

Стало

«question: я ожидал единый источник статуса в Payment. Сейчас поле дублируется в Order, поэтому состояния могут разойтись. Это временная совместимость или выбранная модель? Если второе, давай зафиксируем инвариант тестом».

Эффект

Автор может ответить на технический риск, не защищая собственное достоинство.

Правило эскалации канала

Переходите из async в синхронный разговор, если:

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

После разговора верните решение в письменный артефакт.

Один проход

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

Куда дальше

Нашли неточность? Выделите фрагмент текста — рядом появится жучок.

Нужен разбор именно вашей ситуации?

Статья описывает общий случай. Если у вас частный — можно разобрать его отдельно, платно. А если не хватает целого материала, предложите тему: её оплачивают вскладчину, и она выходит открытой для всех.

Доска запросов
Дальше