Лев Верещагин

cmp-cov: Трекаем покрытие Python-кода во время рефакторинга

2026-04-27T17:23:00+03:00

Когда покрытие кода тестами не 100%, при рефакторинге сложно отслеживать его изменения. Раньше я либо забивал на это, либо копировал секцию с покрытием и сравнивал дифф вручную в VS Code. Вот такие диффы приходилось отсматривать (тут пример игрушечный: я добавил всего один тест!):</p>

13c13</span></span>
<</span> chatbotfront/api/rest/system.py                                  9      1    89%   14</span></span>
---</span></span>
></span> chatbotfront/api/rest/system.py                                  9      0   100%</span></span>
62c62</span></span>
<</span> tests/api/test_system.py                                         3      0   100%</span></span>
---</span></span>
></span> tests/api/test_system.py                                         7      0   100%</span></span>
92,93c92,93</span></span>
<</span> TOTAL                                                         2388    105    96%</span></span>
<</span> ==================================== 208 passed in 44.62s =====================================</span></span>
---</span></span>
></span> TOTAL                                                         2392    104    96%</span></span>
></span> ==================================== 209 passed in 44.35s =====================================</span></span>
</span></code></pre>
Чтобы сделать такие проверки проще и человечнее, написал утилиту cmp-cov</a>. Она сравнивает текущее покрытие с сохранённым baseline. Пример использования:</p>
❯</span> uv</span> run</span> pytest</span> -</span>-cov</span> &&</span> uvx</span> cmp-cov</span> save-baseline</span></span>
#</span>...pytest output...</span></span>
Saved</span> baseline</span> '</span>default</span>'</span> for</span> /Users/lev/web/chat/bot/front</span></span>
  path:</span>    /Users/lev/.cache/cmp-coverage/%2FUsers%2Flev%2Fweb%2Fchat%2Fbot%2Ffront/default/coverage.xml</span></span>
  sources:</span> 85</span> files</span> in</span> /Users/lev/.cache/cmp-coverage/%2FUsers%2Flev%2Fweb%2Fchat%2Fbot%2Ffront/default/sources</span></span>
  total:</span>   95.69%</span></span></code></pre>
Добавил тест, запустил заново — на этот раз c командой diff</code>:</p>
❯</span> uv</span> run</span> pytest</span> -</span>-cov</span> &&</span> uvx</span> cmp-cov</span> diff</span></span>
#</span>...pytest output...</span></span>
Project:</span>  /Users/lev/web/chat/bot/front</span></span>
Baseline:</span> '</span>default</span>'</span> (/Users/lev/.cache/cmp-coverage/%2FUsers%2Flev%2Fweb%2Fchat%2Fbot%2Ffront/default/coverage.xml</span>)</span></span>
Saved:</span>    2026-04-27</span> 17:16:58</span></span>
</span>
Total:</span> 95.69%</span> →</span> 95.69%</span> (+0.00</span>)</span></span>
</span>
↑</span> uncovered</span> →</span> covered</span> (1</span> lines,</span> 1</span> runs</span>):</span></span>
  chatbotfront/api/rest/system.py:14</span></span>
</span>
+</span> new</span> covered</span> (4</span> lines,</span> 1</span> runs</span>):</span></span>
  tests/api/test_system.py:7-10</span></span></code></pre>
Теперь ясно видно, что изменилось в покрытии.</p>
Из похожего есть diff-cover</code></a>, но он показывает покрытие только для строк, изменённых в git diff. Мне же нужно сравнивать покрытие до и после, когда меняется сам код.</p>

Исходный код: github.com/vrslev/cmp-cov</a>.</p>
Попробовать можно так: uvx cmp-cov save-baseline</code>, поменяйте код, затем uvx cmp-cov diff</code>.</p>



Выживание в ИТ
2026-01-13T10:48:48+03:00
Специалисты зарабатывают больше работяг ценой хрупкости и риска перестать быть конкурентно способным:</p>

[...] специалист приобрел много специализированных знаний по низкой себестоимости, чтобы быть конкурентоспособным. Однако, учитывая низкую себестоимость, эти знания не являются надежной основой для дальнейшего профессионального роста; скорее, они одноразовые. Средство выживания для специалиста — это его способность быстро осваивать новые темы, быстро создавать востребованные продукты и затем переходить к следующему. Это называется поверхностным изучением (skimming). Это та же стратегия, которой придерживаются сорняки, если использовать экологическую аналогию. На уровне эксперта, человеку требуется 80–100 часов в неделю, чтобы оставаться конкурентоспособным. Для уровня мастеров это 60–80 часов, а для сохранения компетентности требуется 40–60 часов в неделю.</p>
</blockquote>
— Jacob Lund Fisker, книга «Early Retirement Extreme»</em>



Для того, чтобы оставаться конкурентно способным в ИТ, явно не нужно 80–100 часов в неделю — это перебор. Но общий посыл правда интересный (хоть и несколько заезженный).</p>
Как не оказаться в дураках? В целом, советы тоже уже заезжены, вот, что говорит ChatGPT:</p>



Знания быстро устаревают.
Технические навыки в разработке — «дешёвые единицы знания»: язык, фреймворк, подход. Через 2–5 лет многое нужно осваивать заново.</p>
</li>

Главный навык — быстрое обучение.
Разработчик постоянно забывает старое и переучивается под новые технологии. Специализация не даёт устойчивой опоры, важно уметь адаптироваться.</p>
</li>

Конкуренция не только по навыкам.
Когда многие дошли до нужного уровня, решение о найме опирается на вторичные факторы: коммуникация, «фит», презентация, стрессоустойчивость.</p>
</li>

Карьера — это пирамида, а не лестница.
Выше меньше мест, и рост зависит не только от компетенции. Легко попасть в роль, где сложно быть компетентным (эффект Питера).</p>
</li>

Выгорание — системный риск.
Специалисты, идентифицирующие себя с одной технологией, сильнее страдают, когда рынок меняется или знания обесцениваются.</p>
</li>

Стратегия выживания — метанавыки.
Ценнее не «знать Django», а уметь:</p>

учиться быстро</li>
мыслить архитектурно</li>
понимать принципы систем</li>
эффективно использовать AI-инструменты</li>
развивать софт-скиллы</li>
</ul>
Это вещи, которые устаревают медленнее всего.</p>
</li>

ИТ по сути — про адаптацию.
Разработчик успешен тогда, когда не привязан к инструменту, а способен решать задачи и переключаться между технологиями без боли.</p>
</li>
</ol>
</blockquote>


View Transitions и Speculation Rules
2025-12-30T14:31:34+03:00
Приятно видеть, как современные функции CSS меняют веб-разработку: It's time for modern CSS to kill the SPA - Jono Alderson</a></p>
View Transitions и Speculation Rules отлично подходят для простых сайтов. Они предлагают нативные решения браузера для плавной навигации и оптимизации производительности без сложности SPA. Кстати, сайт vrslev.com уже использует правила предсказания для более быстрой загрузки страниц.</p>


Любая аугментация — это одновременно и ампутация
2025-12-28T16:31:11+03:00
Большинство технологий — это обоюдоострый меч:</p>

Говоря о влиянии технологий на отдельного человека и общество в целом, любая аугментация — это одновременно и ампутация</strong>.</p>
</blockquote>
— Нил Стивенсон</a>, «Заметки об ИИ из Новой Зеландии» (via Саймон Уиллисон</a>)</p>


Автоматическая аннотация функций Python одной комбинацией клавиш в VS Code
2025-07-24T00:49:28+03:00
Я посмотрел это видео</a> от Энтони Соттиле</a> о полезном инструменте для автоматической генерации аннотаций функций: auto-type-annotate</a>. Он, в свою очередь, вдохновлён не поддерживаемым инструментом PyAnnotate</a>.</p>
Вдохновившись этим, я добавил</a> собственную комбинацию клавиш в VS Code: теперь при нажатии Cmd+K, а затем Cmd+M, аннотации волшебным образом появляются у [некоторых] функций!</p>


Простые DSL, которые работают
2025-07-08T14:34:43+03:00
Год назад я выпустил auto-typing-final</a> — исправитель и линтер, реализующий правило из руководства по стилю</a> сообщества Python Raiffeisenbank России: «используйте typing.Final</code> для констант». Сейчас он интегрирован во всей нашей кодовой базе (даже есть расширение для VS Code).</p>
Вдохновлённый работой над Ty в Ruff</a> и PR Карла Мейера с фреймворком тестирования на основе Markdown в Ruff</a>, где показано, как встроенные примеры тестов в Markdown могут упростить и тестирование, и документацию.</p>
Чтобы упростить и тесты, и документацию, я реализовал</a> простой внутренний DSL на основе Markdown для определения сценариев преобразований прямо в тексте:</p>
###</span> Множественные присваивания с </span>`</span>Final</span>`</span></span>
</span>
```</span>python</span></span>
a</span>:</span> Final</span> =</span> 1</span>  #</span> удалить («удалить» означает, что нужно убрать «Final». Есть ещё «вставить» — обратное действие)</span></span>
a</span> =</span> 2</span></span></code></pre>
Такие примеры заменили сложную параметризацию с многострочными строками.</p>
Почему этот внутренний DSL работает:</strong></p>


Повышает ясность. Заголовки описывают каждый тестовый случай, а блоки кода с разделителями отделяют входные данные, ожидаемые изменения и аннотации.</p>
</li>

Единый источник истины. Один и тот же фрагмент Markdown одновременно управляет параметризацией pytest и служит пользовательской документацией.</p>
</li>
</ul>
Вывод#</a>
</h2>
Небольшие DSL, подобные этому, работают эффективно: их легко парсить, читать и писать.
Этот пример доказывает, что порой самые простые инструменты оказывают наибольшее влияние.</p>


Декларативный Homebrew
2024-05-14T14:51:08+03:00
Мне важно поддерживать единообразную среду разработки на обоих моих MacBook — рабочем и личном. (Именно поэтому я использую</a> mise и храню dotfiles</a> в репозитории.)</p>
Ранее меня беспокоил один момент в этом процессе — поддержание актуальности установленных пакетов Homebrew. Раньше я время от времени запускал команду make dump</code>, которая обновляла Brewfile с помощью brew bundle dump</code>. Проблема заключалась в том, что состояние файла всегда отставало от реального состояния системы.</p>
Теперь у меня есть функция Fish, которая обновляет Brewfile при каждом выполнении потенциально разрушительной команды brew:</p>
function</span> brew</span></span>
  command</span> brew </span>$</span>argv</span>; </span>and</span>\</span></span>
  switch</span> $</span>argv</span>[</span>1</span>]</span></span>
    case</span> install uninstall reinstall tap untap</span></span>
      brew</span> bundle dump</span> --file</span> $</span>DOTFILES_ROOT</span>/Brewfile</span> --force</span></span>
  end</span></span>
end</span></span></code></pre>


mise-en-place: среда разработки в мире cargo
2024-05-11T09:46:33+03:00
Пару дней назад я открыл для себя mise</a> (произносится как «meez»). Это универсальный менеджер версий инструментов, похожий на asdf или pyenv, а также менеджер окружения, как direnv, который отличается высокой скоростью работы, надёжностью, декларативной конфигурацией и таким же удобством использования, как у cargo.</p>
Я отказался от hatch</a>, который ранее использовал исключительно для загрузки Python из python-build-standalone</a> с помощью команды hatch python install all --update</code></a>. Я также перестал использовать Node из Homebrew и удалил собственные скрипты из dotfiles, которые синхронизировали установки pipx между рабочим и личным ноутбуками.</p>
Мой ~/.config/mise/config.toml</code> теперь выглядит так:</p>
[</span>tools</span>]</span></span>
python</span> =</span> [</span>"</span>3.12</span>"</span>,</span> "</span>3.11</span>"</span>,</span> "</span>3.10</span>"</span>,</span> "</span>3.9</span>"</span>,</span> "</span>3.8</span>"</span>]</span></span>
node</span> =</span> "</span>lts</span>"</span></span>
usage</span> =</span> "</span>latest</span>"</span>  #</span> требуется самим mise</span></span>
"</span>pipx:maturin</span>"</span> =</span> "</span>latest</span>"</span></span>
"</span>pipx:poetry</span>"</span> =</span> "</span>latest</span>"</span></span>
"</span>pipx:pypi-command-line</span>"</span> =</span> "</span>latest</span>"</span></span>
"</span>pipx:watchfiles</span>"</span> =</span> "</span>latest</span>"</span></span>
</span>
[</span>settings</span>]</span></span>
experimental</span> =</span> true</span>  #</span> бэкенд pipx находится в экспериментальном режиме</span></span></code></pre>
Кроме того, я начал использовать функцию управления окружением от mise. Файл .mise.local.toml</code> с переменными окружения, специфичными для компании, я разместил в директории с рабочими репозиториями:</p>
[</span>env</span>]</span></span>
PIP_INDEX_URL</span> =</span> "</span>...</span>"</span></span>
CERT_PATH</span> =</span> "</span>...</span>"</span></span>
GITLAB_TOKEN</span> =</span> "</span>...</span>"</span></span>
...</span></span></code></pre>
Пока что всё работает отлично.</p>


Привет 🎉
2024-02-02T20:16:52+03:00
Привет! 👋</p>
Меня зовут Лев, я самоучка-разработчик из России. Я начинаю свою первую работу через неделю, и мне не терпится познакомиться со многими новыми вещами. Именно поэтому я решил документировать свои знания в формате TIL (Today I Learned).</p>
Следите за обновлениями, до скорой встречи!</p>