Мелкие трюки в программировании

Мелкие трюки в программировании

Каждый день инженерная продуктивность на удивление во многом зависит от небольших кусков знаний: осознание того, что в языке существует определённая возможность; понимание, что необъяснённая задержка TCP вероятно связана с настройкой TCP_NO_DELAY и алгоритмом Nagle; знание правильной команды git для выхода из затруднения; или трюк с sed для переписывания файла.

В одном смысле это очевидно: все полученные знания состоят из более мелких кусков информации. Конечно, эти мелкие куски имеют значение.

Но есть такие куски знаний, которые особенно ценны и не требуют большой поддерживающей инфраструктуры сознания. Не нужно ничего знать о Python, чтобы запустить python3 -m http.server и поднять простой сервер в каталоге, но это всё равно может немного облегчить работу. Вот несколько примеров:

• Вероятно, известно, что ctrl + r позволяет искать в истории команд терминала, но если установить fzf, можно настроить так, чтобы ctrl + r выполнял нечёткий поиск. Для большей мощности существует atuin, который заменяет историю шелла базой данных SQLite с поиском. per-directory-history позволяет переключаться между поиском команд, запущенных в определённом каталоге, и поиском всех предыдущих команд. Также можно настроить, сколько истории хранить: вопрос на stackoverflow.
• Можно выполнить SELECT без FROM. Это полезно для тестирования того, как работает функция в базе данных, или для напоминания себе, как работает SELECT TRUE <> NULL.¹
• PostgreSQL и MySQL поддерживают explain analyze, который действительно запустит оптимизируемый запрос и предоставит гораздо больше информации о его производительности.
• В регулярных выражениях \b, утверждение границы слова, облегчает поиск начал или концов слов.
• Можно использовать логарифмы с метриками, чтобы получить представление о распределении значений интересующего поля:

  const bucket = Math.floor(Math.log10(userInGroupCount))
  metrics.increment("my_metric", { bucket });
  

• Современный JavaScript поддерживает Array.flatMap, Object.entries и Promise.withResolvers.
• В Node.js можно держать соединение открытым с внешним ресурсом, создав https.Agent и передав его в HTTP-запросы: fetch(url, {method, agent}). Это может резко сократить задержку.
• git log -S pattern ("git pickaxe") выдаёт все коммиты, которые добавили или удалили строку в кодовой базе. Это особенно полезно со старыми кодовыми базами! (git log -G pattern работает аналогично, но также показывает, когда строка была перемещена.)
• Подобно cd -, можно использовать git checkout - для переключения на предыдущий HEAD.
• Вероятно, не нужно find. Множество команд find можно заменить глобами, такими как **/*.md. Большинство шеллов поддерживают это из коробки, но в bash нужно включить это с помощью shopt -s globstar.
• По аналогии, большинство захочет использовать rg (ripgrep) вместо grep, ack или ag.
• Функции продвинутого автодополнения zsh не включены по умолчанию:

  if type brew &>/dev/null; then
      FPATH="$(brew --prefix)/share/zsh/site-functions:${FPATH}"
  fi
  autoload -Uz compinit
  compinit
  

Вполне возможно, что все эти трюки уже известны! Или же можно работать в области, где все эти небольшие трюки совершенно бесполезны. Даже если это конкретный набор трюков не пригодится, наверняка накопился собственный запас трюков за годы, которые облегчают работу.

В компании ещё больше знаний оказывается таким мелким, высокорентабельным куском:

• Для отладки $PROBLEM используй $DATA_SOURCE.
• $PERSON знает много о $AREA и рад помочь, если что-то не получится.
• Есть хорошая документация про $HARD_THING $OVER_HERE.
• Когда случается $THING, это означает, что нужно вручную масштабироваться.
• Для перезагрузки сервиса с сохранением запросов запусти $THIS_COMMAND.
• Эта $UTIL облегчает написание сценариев для $THAT_PROBLEM.

В одной компании делился трюком в Slack каждый день с инженерной командой — как техническими, так и специфичными для компании, — и людям это нравилось. Даже если знать 9 из 10 трюков, этот 10-й документ или техника могут сэкономить время! А один трюк в день — правильное количество, чтобы не перегружать людей информацией и иногда вызвать полезную дискуссию. Если быть более опытным инженером в компании, стоит рассмотреть что-то подобное.