Медленные коллеги при парном программировании раздражают. Эта статья – чек-лист для проверки, насколько с вами приятно работать, там же описано как исправлять проблемы.

Предположения, использованные для написания советов:

  • адекватный работодатель
  • заработная плата велика для пренебрежения производительностью разработчиков

Кратко

У программиста три врага

  • переключения контекста
  • медленный человеческий мозг
  • исключения (IRL)

Железо

Клавиатура

  1. Используйте самую привычную клавиатуру. Лучше, если дома и на работе клавиатуры одинаковые. Чем меньше контекст-свитчинга, тем лучше.
  2. Освойте хотя бы полуслепую печать. Если не умеете в правильную слепую печать - просто смотрите в экран и устраняйте ошибки по мере появления, а не через 20 секунд, написав ещё 3-4 слова. Если взгляд во время печати сфокусирован на клавиатуре - куча ошибок гарантирована.
  3. Используйте копипаст по мере возможности, вместо повторного набора текста. Вы медленно печатаете, какая бы не была скорость ввода текста, это аксиома. Вы человек, а люди ограничены. Для меня ввод ≈12+ символов – триггер для задачи “посмотреть, а нельзя ли это скопировать из близлежащего кода”.

Мышь

Переключение с клавиатуры на мышку зло, но медленная навигация по тексту с помощью клавиатуры - зло ещё большее.

Теперь немного личных наблюдений:

  1. Для меня решением стало использование макбуков с тачпадом, которым действительно можно пользоваться.
  2. Есть решение в виде трекпоинта, многим нравится, но штука своеобразная, к ней нужно привыкать. Во время собеседования в Яндекс, меня спрашивали на чём предпочитаю работать Mac и Windows, сказал Mac, дали Lenovo Thinkpad, перематерился с этой странной штукой.
  3. Мой директор, с которым я раньше часто работал в паре, наверное вылил немало слёз, глядя на 30↓, 30↓, 60↓, page down, в vim, вместо того чтобы просто нормально проскроллить текст дальше. Способа комфортно программировать с мышкой я так и не нашёл, удобных и привычных клавиатур со встроенным тачпадом и местом под ладошки я так и нашёл.
  4. Updated 2024: в хороших IDE вместо ручного скролла гораздо удобнее тыкать в Structure-панель (эдакое оглавление по классам/функциям). Дополнительный повод писать хорошо структурированный код.

Монитор и DE

  1. Видеоповтор удобен для совместного code review.
  2. Смотрите логи на втором перевёрнутом вертикально мониторе, вместо постоянного переключения между окнами.
  3. Перемещать окна мышкой отнимает слишком много времени, а snapping windows по хоткею – нет. Стоит знать хотя бы хоткеи для перемещения окна влево-вправо на полэкрана и на весь экран. Сделать это можно с помощью:
    1. MacOS - shiftit!
    2. Windows - не знаю, вроде из коробки работают Win + стрелки.
    3. Linux - список DE для каждой из которых написано "вы сами знаете".

Вычислительные ресурсы

Деплой и тестирование разрабатываемого софта на локалхосте, не важно, в той же ОС, в докере, в виртуалке будет влиять на отзывчивость DE. Старайтесь этого избегать, лучше выделить меньше ресурсов на рабочую станцию, но крутить виртуалки на сервере, выделенном специально под эти задачи. Если делить такие сервера между разработчиками, конечно, будут конфликты за ресурсы, которые лучше решить превентивно в виде квот, либо (если это осмысленно и есть бюджет) каждому разрабочику выделить по серверу.

Вопрос о том, что дороже - потерянное оплаченное время разработчиков или расходы на железо - решать работодателю (а не вам). К слову: Core i5, DDR4, небольшие SSD, 2Tb HDD и гигабитные свитчи – дешёвые.

Операционная система

  1. Используйте ОС, принятую за стандарт в компании. Причины:
    1. В случае проблем смогут помочь коллеги.
    2. В случае, если очередь быть “руками” с клавиатурой будет у коллеги, ему будет легче действовать в той же ОС, что и у него (минус 1 context switching).
    3. Хоткей для переключения языков однако для меня остаётся неразрешимой проблемой. Купил ноутбук специально чтобы не пользоваться чужими компами, когда помогаю, а сидеть рядом со своим. Так себе решение.
    4. Если возникнет проблема в той ОС, которую любите и установили на работе – будьте добры, решайте её самостоятельно в нерабочее время, либо отрабатывайте время на её устранение потом. В противном случае это можно считать воровством времени у работодателя. Скажу за себя - на работе принята за стандарт Ubuntu, но мне комфортнее использовать MacOS. Недавно я потратил полтора часа на то, чтобы заработал graphviz. В Ubuntu это работает из коробки. Я не считаю, что работодатель должен платить за это.
  2. Стартайтесь не ломать рабочую ОС. А если собрались делать то, что способно вывести её из строя и приведёт к простою - заготовьте резервную копию. Рекомендую использовать побайтовое копирование дисков для этой задачи. Из этого + того, что диски дешёвые, следует ещё один вывод:
    1. Никогда, ничего и нигде не удаляйте.
    2. Перед удалением копируйте на долгосрочное хранение.
    3. Через 3 года если не понадобилось - так и быть, удалите.

Инструменты

Используйте те же инструменты, что и приняты в компании

Глобальное правило - “все ножницы должны быть одинаковыми”.

Используйте те же настройки инструментов, что и приняты в компании.

Не холиварьте на тему “табы, пробелы”, это не ваша забота. Если портите людям код или люди вам - проблема не в том, что используются стрёмные стандарты, проблема в том, что стандарты не используются автоматически. То, что кажется, как надо правильно – не важно.

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

  1. Делай как принято в языке.
  2. Делай как принято в компании.
  3. Делай как принято в команде.
  4. Делай как принято в проекте.
  5. Делай как принято Вами.

Обзаведитесь набором джентельмена

Набор джентельмена избавляет от непродуктивной работы и нужен для каждого используемого языка.

  1. Редактор. Если будете долбить по стрелкам клавиатуры чтобы обернуть слово в кавычки, вручную заменять названия переменной в нескольких местах, искать глазами как называется нужный вам метод в доке или исходниках (а не в предложениях автокомплита), писать доку, а после коммита править потому что “ой, поехало всё, чёртов markdown” - вы будете бесить напарника. У меня к слову есть ещё пара нерешённых проблем, но я их игнорирую:
    • я не нашёл хорошей замены выполнению произвольных консольных команд для преобразования выделенного текста, как в vim (:%!sort -u)
    • я понимаю как работает замена по умным регуляркам только в vim (что-то в духе :s/something/& - это &/g)
  2. Средство запуска программы. Ок, некоторые программы требуют сложного окружения (и в докер их не положить), но многие программы легко можно запустить прямо на своей рабочей станции. Если это одна из них, а вы ради этого переключаетесь из редактора в консоль (а потом снова запускаете редактор, а он говорит вам о том, что уже запущен и читает этот файл, вы закрываете его, а потом восстанавливаете старую сессию с помощью fg) - вы будете бесить напарника.
  3. Отладчик. Когда в +/- крупной системе вы добавляете принты входящих данных в каждую функцию из трейсбэка ошибки, которую вы лечите, чтобы понять какие аргументы всё поломали и где что-то пошло не так - вы будете бесить напарника.
  4. Профилировщик. В большинстве случаев, когда вы заметите, что код тормозит и задумаетесь “мм, а где же, найду-ка я это половинным делением с помощью принтов с датой” - вы будете бесить напарника.
  5. Средство запуска тестов. Если вы пишите код в одном месте, а запускаете тесты в другом, при этом периодически “ой, чот не запускаются, ща поправлю” - вы будете бесить напарника.
  6. Средство работы с VCS (git, например). Если вы пишите код в одном месте, потом начинаете в другом проходиться по совершённым изменениям, а потом в третьем писать коммит, почёсывая голову “а чо ж я собственно поменял” и “а точно ничего лишнего не зацепил” - вы будете бесить напарника.
  7. Средства для рефакторинга. Если перемещаете методы между классами или извлекаете тело цикла в метод вручную, а потом “ой, тут пара мест сломалась, ща починю ручками” - вы будете бесить вашего напарника.
  8. Линтер. Если вы будете замечать банальные ошибки только при вызванной вручную компиляции или в рантайме - вы будете бесить вашего напарника.
  9. Хоткеи. Само собой максимум из всех этих действий должен делаться хоткеями, которые вы помните. Лучше, если они стандартные и их помнит и ваш напарник.

Заключение

Надеюсь эти простые советы, частично дублирующие старую добрую книжку “Программист-прагматик, путь от подмастерья к мастеру” помогут вам не бесить ваших коллег. Или меня.