Глава 24 · Что дальше? Roadmap Python-разработчикаSoftware Engineering
Git, review, тестирование, статический анализ, диагностика, упаковка и поставка входят в один рабочий процесс.
Как безопасно менять код
В учебном скрипте иногда достаточно получить верный результат один раз. В проекте нужно ещё и безопасно менять код дальше. Рабочий процесс связывает требования, реализацию, проверку и поставку. Инструменты могут меняться. Требования к процессу остаются: историю изменения можно проследить, отказ можно увидеть, а сборку повторить.
Git и review глубже базовых команд
Изучите чтение истории и diff, ветвление, merge, безопасный rebase локальной ветки, revert, теги и разрешение конфликтов. Цель не в коллекции команд. Вы должны понимать, какой граф коммитов получится и как восстановиться после ошибки. Review проверяет контракт, граничные случаи, тесты, читаемость и операционный риск; стиль кода лучше делегировать автоматическим проверкам.
Тестовая стратегия
| Средство pytest | Что моделирует | Риск неправильного применения |
|---|---|---|
| fixtures | Явную подготовку состояния и ресурсов. | Скрытая сложная fixture делает тест непонятным. |
| parametrize | Один контракт на наборе входов и границ. | Большая таблица может скрыть разные причины отказа. |
| mock / monkeypatch | Контролируемую границу: время, сеть, процесс, API. | Mock внутренних деталей связывает тест с реализацией. |
| coverage | Какие строки или ветви выполнились. | Высокий процент не доказывает качество утверждений. |
Стройте пирамиду по риску: много быстрых тестов чистой логики, меньше интеграционных тестов реальных границ и несколько сквозных сценариев. У теста должна быть причина, наблюдаемое утверждение и контролируемая среда.
Автоматические проверки и диагностика
Ruff может выполнять lint и форматирование, а mypy проверяет согласованность
аннотаций. Выберите правила, зафиксируйте их в pyproject.toml
и запускайте одинаково локально и в CI. Для дефекта соберите минимальное
воспроизведение, прочитайте traceback, поставьте точку останова или добавьте
структурированный лог. Профилировщик нужен после измерения проблемы, а не для
преждевременной оптимизации.
Пакет, версия и поставка
Проекту нужны ясная структура, метаданные, зависимости, build backend и проверка установки собранного wheel в чистом окружении. Через PyPI публикуют Python-пакеты, но не каждому приложению нужна такая публикация. Semantic Versioning полезен, когда проект объявляет публичный API и может последовательно определить совместимые и несовместимые изменения.