List Issues Suggestions1 Discussions Insights

Рабочее место бэкендера: VS Code, инструменты, первый проект

Настройка среды с нуля на Windows: редактор, расширения, терминал, Python, git, Docker, uv. К концу — папка проекта, готовая принять первую строку кода.

python vscode uv git docker

v4 0 stars 0 forks 0 watchers 1 branch 1 run Public

Ссылки перенесены из markdown в описаниях в структурное поле refs — теперь это данные, а не текст. Описания стали короче, в них остались только команды и различия между Windows и macOS.v42 weeks ago4

Зачем это всё

Настроенный редактор экономит больше времени, чем любой приём программирования: он подсвечивает опечатку до запуска, показывает тип под курсором и форматирует файл сам.

Это не подготовка к работе — это уже работа. В MIT есть отдельный курс The Missing Semester of Your CS Education, созданный ровно потому, что программы учат алгоритмам, но не инструментам, хотя за инструментами человек проводит сотни часов за учёбу и тысячи за карьеру.

Порядок шагов важен: сначала редактор, потом инструменты, потом проверка каждого по отдельности. Если проверять всё разом в конце, непонятно, что именно не встало.

Список работает и на Windows, и на macOS. В поле команды — вариант для Windows, в описании рядом — команда для macOS. Ссылки на официальные страницы загрузки прикреплены к шагам — на случай, если пакетный менеджер не работает.

Подготовка

Пакетный менеджерRecommended

Windows: ничего делать не надо — winget встроен в систему. Проверь командой ниже.

macOS: поставь Homebrew — команда установки есть на главной странице. После установки он напечатает две строки, которые надо выполнить, чтобы brew попал в PATH — не пропусти их, это самая частая ошибка. Проверяется командой brew --version.

Why: Пакетный менеджер ставит программы одной командой и потом обновляет их все разом. Главное — такую установку можно записать и повторить на другой машине, а «скачать и кликнуть далее» — нельзя.

$winget --version

Check

Команда пакетного менеджера твоей системы отвечает версией
На macOS: выполнены строки про PATH, которые напечатал установщик

Homebrew — установка (macOS)

Редактор

Установить VS Code

Windows: команда ниже. При установке вручную отметь галочку «Add to PATH».

macOS: brew install --cask visual-studio-code. Если ставишь вручную — перетащи приложение в папку Applications, иначе часть функций работать не будет.

Why: VS Code — редактор, который становится полноценной средой разработки за счёт расширений. В отличие от тяжёлой IDE, ты сам решаешь, что в нём будет.

$winget install Microsoft.VisualStudioCode

Check

VS Code запускается
В окне «About» видна версия редактора

Скачать VS Code Настройка на macOS

Проверить, что команда code доступна в терминале

Открой новый терминал — старый не знает об изменении PATH.

Если команда не найдена на Windows: переустанови с галочкой «Add to PATH».

Если на macOS: открой VS Code, нажми Cmd+Shift+P и выполни команду «Shell Command: Install 'code' command in PATH».

Why: Дальше мы будем ставить расширения командами. Без code в PATH придётся кликать мышью по магазину расширений, а такую настройку невозможно повторить на другой машине.

$code --version

Check

Команда напечатала три строки: версию, хеш коммита и архитектуру
Терминал был открыт заново после установки

Расширения

Поставить расширение Python

Команда одинаковая на Windows и macOS.

Расширение даёт подсветку, переход к определению, запуск и отладку. Вместе с ним автоматически приезжает Pylance — проверка типов и автодополнение.

Why: Pylance находит ошибки статически: обращение к несуществующему атрибуту или неверный тип аргумента видно до запуска. Это дешевле, чем ловить то же самое, гоняя программу.

$code --install-extension ms-python.python

Check

В панели Extensions расширение Python отмечено как установленное
Там же появился Pylance — он ставится как зависимость, отдельно его ставить не надо

Python на Marketplace

Поставить Ruff

Команда одинаковая на обеих системах.

Линтер и форматтер в одном инструменте. Тот же самый, который будет проверять код в проекте, — важно, чтобы редактор и проект ругались одинаково.

Why: Форматтер отвечает за единообразие (отступы, кавычки, переносы), линтер — за подозрительные места (неиспользуемая переменная, затенение имени). Разные задачи, но здесь один инструмент.

$code --install-extension charliermarsh.ruff

Check

Ruff виден в списке установленных расширений

Ruff на Marketplace Документация Ruff

Поставить Docker и GitLensRecommended

Команда одинаковая на обеих системах.

Docker покажет контейнеры и их логи прямо в редакторе. GitLens показывает, кто и когда менял конкретную строку.

Why: Оба нужны не сразу, но ставятся один раз. GitLens особенно полезен, когда начнёшь разбираться в чужом коде: строка перестаёт быть безымянной.

$code --install-extension ms-azuretools.vscode-docker --install-extension eamodio.gitlens

Check

Оба расширения в списке установленных

Docker на Marketplace GitLens на Marketplace

Почему ставим по одному, а не пакетом «всё для Python».

Каждое расширение — работающий процесс и потенциальный источник конфликта: два форматтера начнут переписывать файл друг за другом, и ты будешь гадать, почему код прыгает при сохранении.

Ставя по одному, ты знаешь, кто за что отвечает, и понимаешь, что отключать при странном поведении.

Терминал

Открыть встроенный терминал

Windows: Ctrl + ` (клавиша с обратным апострофом, слева от единицы).

macOS: Ctrl + ` (именно Control, не Command).

Либо меню View → Terminal на обеих системах.

Why: Отдельное окно консоли — лишнее переключение и лишний шанс запустить команду не в той папке. Встроенный терминал открывается сразу в папке проекта.

Check

Терминал открылся в нижней части окна редактора
В нём виден путь к текущей папке

Понять, какая оболочка запущена

В правом верхнем углу панели терминала написано имя оболочки. Запомни его.

Windows: обычно PowerShell, реже Command Prompt или Git Bash.

macOS: по умолчанию zsh. Проверить можно командой echo $SHELL.

Why: Оболочки ведут себя по-разному: разный синтаксис переменных, разные кавычки, разные разделители в путях. zsh и bash близки, а PowerShell отличается сильно: команды из статей чаще всего написаны под bash и в нём не работают. Половина загадочных ошибок новичка — это команда не из той оболочки.

Check

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

Инструменты

Проверить Python

Нужна версия 3.12 или новее.

Windows: команда python --version. Ставь с python.org, не из Microsoft Store. При установке отметь «Add python.exe to PATH».

macOS: команда python3 --version — именно python3. Системный Python старый и трогать его нельзя — ставь свой: brew install python@3.12 либо позже через uv python install 3.12.

Why: На Windows версия из Microsoft Store работает в песочнице: часть инструментов её не находит. На macOS опасность другая: системный Python используется самой системой, и установка в него пакетов может сломать системные утилиты.

$python --version

Check

Команда напечатала версию 3.12 или выше
Это не системный Python и не версия из Microsoft Store

Скачать Python Python для macOS

Убедиться, что запускается именно тот Python

Команда покажет все найденные интерпретаторы в порядке приоритета. Первый в списке — тот, который запустится.

Windows: where python

macOS: which -a python3

Why: На машине часто оказывается несколько Python: системный, от пакетного менеджера, из старой установки. Запускается первый по PATH, и пакет, поставленный в одно окружение, «пропадает» при запуске из другого. Это одна из самых частых и самых непонятных проблем новичка.

$where python

Check

Ты видишь список найденных интерпретаторов
Понимаешь, какой из них запускается по умолчанию

Проверить git

Windows: при установке можно оставить настройки по умолчанию — вместе с git приедет Git Bash.

macOS: проще всего xcode-select --install — git входит в Command Line Tools. Либо свежее версией: brew install git.

Why: Git — не «сохранялка файлов», а машина времени. Без него любая попытка что-то поменять сопровождается страхом сломать работающее; с ним эксперимент бесплатен.

$git --version

Check

Команда напечатала версию git

Скачать git git для macOS

Проверить Docker

Windows: скачать с сайта или winget install Docker.DockerDesktop.

macOS: brew install --cask docker-desktop. При ручной загрузке выбери правильную сборку: Apple Silicon для M1–M4 или Intel для старых машин. Посмотреть свой процессор: ⌘ → «Об этом Mac».

На обеих системах Docker должен быть не просто установлен, а ЗАПУЩЕН — значок кита в трее или в верхней панели.

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

$docker run --rm hello-world

Check

Команда скачала образ и напечатала приветствие
Значок Docker активен, а не серый
На macOS: скачана сборка под свой процессор

Скачать Docker Desktop Через Homebrew (macOS)

Установить uv

Windows: winget install astral-sh.uv

macOS: brew install uv либо официальный установщик: curl -LsSf https://astral.sh/uv/install.sh | sh

После установки закрой терминал и открой заново.

Why: uv — единый инструмент: ставит сам Python, управляет зависимостями, запускает команды проекта. Заменяет связку из нескольких и работает на порядок быстрее. Дальше весь проект будет жить через него.

$winget install astral-sh.uv

Check

Установка завершилась без ошибок
Терминал открыт заново после установки

Установка uv — все системы Документация uv

Проверить uv

Команда одинаковая на обеих системах.

Если команда не найдена — терминал ещё помнит старый PATH. Закрой все терминалы и открой новый. На macOS при установке через скрипт проверь, что в PATH добавился ~/.local/bin.

Why: Это последняя проверка перед созданием проекта. Дальше все команды пойдут через uv, и его недоступность остановит работу на первом же шаге.

$uv --version

Check

Команда напечатала версию uv

Проект

Создать папку проекта по короткому пути

Никаких пробелов, никакой кириллицы, не на Рабочем столе и не в облачной папке.

Windows: mkdir C:\dev\shop — не в OneDrive.

macOS: mkdir -p ~/dev/shop — не в iCloud Drive и не в папке «Документы», если у тебя включена синхронизация Рабочего стола и Документов.

Why: Многие инструменты разбирают путь по пробелам как разделителям аргументов — путь распадается на части. С кириллицей проблема в кодировке. Ошибка выглядит не как «плохой путь», а как «файл не найден», и ищут её долго. Облачная синхронизация добавляет своё: она конфликтует с файлами, которые часто меняются.

$mkdir C:\dev\shop

Check

В полном пути к папке нет пробелов
В полном пути нет кириллических символов
Папка не в облачном хранилище и не на Рабочем столе

Открыть папку в VS Code

File → Open Folder, либо командой из терминала.

Windows: code C:\dev\shop

macOS: code ~/dev/shop

Why: VS Code работает именно с папкой, а не с отдельными файлами: от неё он отсчитывает пути, ищет настройки и запускает терминал. Открытый «просто файл» лишает тебя половины возможностей редактора.

$code C:\dev\shop

Check

В боковой панели видно имя папки проекта
Встроенный терминал открывается сразу в этой папке

Включить форматирование при сохранении

Windows: Ctrl+Shift+P → «Preferences: Open Workspace Settings (JSON)»

macOS: Cmd+Shift+P → та же команда

Добавь настройку editor.formatOnSave со значением true и назначь Ruff форматтером для Python.

Why: Спор об оформлении кода — самый бессмысленный из возможных. Когда формат ставит инструмент, спорить не о чем, а в pull request видны только смысловые изменения, а не переставленные пробелы.

Check

Файл .vscode/settings.json создан в папке проекта
editor.formatOnSave включён

Настройки VS Code

Проверить, что форматирование работает

Создай файл check.py, напиши в нём строку с намеренно кривыми отступами и лишними пробелами, сохрани. Оформление должно поправиться само. После проверки файл удали.

Why: Настройка, которую не проверили, считается неработающей. Это правило пригодится дальше во всём: конфиг без проверки — это предположение, а не факт.

Check

После сохранения оформление файла изменилось само
Проверочный файл удалён

Почему кириллица и пробелы в пути к проекту — проблема, если система их спокойно разрешает?

Чем линтер отличается от форматтера?

Ты поставил пакет, а при следующем запуске его нет. Самая вероятная причина?

Готово

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

Что дальше: git и GitHub — ключи, клонирование, первая ветка. А затем первый pull request целиком, на безобидной правке README, чтобы к моменту появления настоящего кода механика уже была в руках.

Если какой-то шаг не сошёлся — не переходи дальше. Незакрытая проблема в окружении не рассасывается, а всплывает через две недели в самый неудобный момент.