Блокчейн

Редактор кода: WebStorm и VS Code

Прочитано0%

Квизы0/6

Уровень 1 · Новичок

Зачем это нужно

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

Редактор кода — второй инструмент блокчейн-разработчика после терминала, и в отличие от терминала он не универсален: их много, они разные, и выбор между ними новичку обычно объясняют лозунгами вместо аргументов. Разберёмся по делу: чем редактор кода отличается от блокнота, чем WebStorm отличается от VS Code, как открыть проект так, чтобы заработали поиск и переход по коду, какие семь сочетаний клавиш окупаются в первый же день на всех трёх системах — и почему в блокчейн-проекте цена неаккуратного плагина или забытого файла с ключом выше, чем в любом другом.

Проект, на котором всё показано, — тот же, что и в прошлой главе: TypeScript-контракт из js-contract-sdk и локальная сеть Waves Enterprise рядом, с её REST API на порту 6862.

• Зачем это нужно
• Чем редактор кода отличается от блокнота
• WebStorm или VS Code
  • Студенческая лицензия JetBrains
• Установка и первый запуск
• Открывают папку, а не файл
• Карта окна
• Горячие клавиши, которые окупаются в первый день
  • WebStorm
  • VS Code
  • Мультикурсор: когда он экономит минуты
• Расширения и плагины: что реально нужно
  • Про доверие к чужому коду
• Ключи, seed-фразы и облачные помощники
• Встроенный терминал и встроенный git
• Типичные ошибки новичка
  • 1. Открыт файл, а не папка
  • 2. Правка «боевого» файла в редакторе без git
  • 3. Не настроены автосохранение и форматирование при сохранении
  • 4. Секреты открыты «просто чтобы посмотреть»
  • 5. Незакоммиченные изменения на другой машине
• На чемпионате
• Куда дальше: проверенные ресурсы
• Челлендж ⭐
• Что должен уметь

Чем редактор кода отличается от блокнота

Программа — это текст, и набрать его можно хоть в «Блокноте». Разница не в том, что редактор красивее, а в том, что блокнот видит буквы, а редактор кода — код: он разбирает файл по правилам языка и держит в памяти модель всего проекта.

Слева блокнот: ровный серый текст, опечатка и незакрытая скобка найдутся только при запуске. Справа редактор: подсветка, подчёркнутая ошибка, автодополнение — до запуска.

Шесть вещей, ради которых редактор и ставят:

• Подсветка синтаксиса. Ключевые слова, строки, числа и комментарии окрашены по-разному. Это не украшение: строка, случайно оставшаяся незакрытой, немедленно окрашивает половину файла в цвет строки — ошибку видно боковым зрением, без единого запуска.
• Автодополнение. Набрал node. — и получил список того, что у этого объекта вообще есть. Для работы с SDK это важнее, чем кажется: имена методов не приходится держать в голове или искать по документации, а опечатка вроде balanse вместо balance подчёркивается сразу.
• Переход к определению. Курсор на имени функции, одно сочетание клавиш — и ты в том файле и на той строке, где она объявлена. В чужом проекте это основной способ читать код: не листать файлы глазами, а прыгать по связям.
• Поиск по всему проекту. Не по открытому файлу, а по всем файлам сразу, с фильтром по маске имён и с заменой. Найти, где вообще упоминается порт 6862 в конфигах сети, — вопрос трёх секунд.
• Встроенный терминал. Тот же самый терминал системы, только в нижней панели окна: npm install, docker compose up -d, git status — без переключения между окнами и без потери текущей папки.
• Встроенный git. Список изменённых файлов, построчный diff, история — рядом с кодом, а не в отдельной программе.

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

Отвечено вопросов: 0 из 4

Почему подсветка синтаксиса — не косметика, а рабочий инструмент?

Что даёт переход к определению (go to definition) при чтении чужого проекта?

Чем поиск по проекту отличается от поиска внутри открытого файла?

Зачем нужен встроенный терминал, если системный терминал уже есть?

Отвечено верно: 0 из 4

WebStorm или VS Code

Оба инструмента пишут один и тот же код и дают один и тот же результат. Разница — в том, сколько всего готово из коробки и сколько приходится собирать самому.

WebStorm — специализированная IDE для JavaScript и TypeScript от JetBrains, той же компании, что делает IntelliJ IDEA. Она изначально знает package.json и npm-скрипты, понимает декораторы SDK, умеет запускать и отлаживать Node.js, содержит встроенный HTTP-клиент для запросов к REST API и полноценную панель Version Control. Ничего доустанавливать для обычной работы не нужно. Плата за это — вес: WebStorm тяжелее, дольше стартует и заметно дольше индексирует проект в первый раз.

VS Code — бесплатный и лёгкий редактор от Microsoft. Из коробки он умеет меньше, но почти всё недостающее ставится расширениями за пару минут: поддержка TypeScript в нём есть сразу, а отладка Node, работа с REST и всё остальное — по мере надобности. Стартует быстро, ест мало памяти, спокойно живёт на слабом ноутбуке.

Это не религиозный спор и не выбор на всю жизнь. Обе программы поддерживают одни и те же файлы, а проект не хранит внутри себя ничего, что мешало бы открыть его в другом редакторе; конфигурации запуска и настройки хранятся в служебных папках (.idea/ у JetBrains, .vscode/ у VS Code), которые обычно даже не попадают в репозиторий. Переучиться с одного на другой — вопрос вечера, потому что понятия одинаковые, отличаются только сочетания клавиш и названия панелей.

💡Совет

Практическая рекомендация трека: если у тебя есть учебная почта колледжа — бери WebStorm, на площадке и в этом курсе показывают его. Если машина слабая (4 ГБ памяти) или лицензии нет — бери VS Code: он не «версия для бедных», а полноценный рабочий инструмент, просто с ручной сборкой набора расширений.

Студенческая лицензия JetBrains

WebStorm платный, но для студентов и преподавателей у JetBrains есть бесплатная лицензия на все продукты — она оформляется по учебной почте (адрес в домене учебного заведения) или по документу, подтверждающему учёбу. Лицензию нужно продлевать раз в год, пока учишься.

JetBrains для студентов и преподавателей

Официальная страница бесплатной образовательной лицензии: условия, способы подтверждения статуса (учебная почта, ISIC, документ), продление раз в год.

WebStorm — установка

Официальное руководство по установке WebStorm для Windows, macOS и Linux, включая Toolbox App и системные требования.

Visual Studio Code — установка

Официальная страница установки VS Code: установщики для трёх систем, обновления, платформенные особенности.

Установка и первый запуск

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

Windows

WebStorm. Скачай .exe и пройди установщик. Единственное место, где стоит задержаться, — галочки в конце: «Add bin folder to PATH» (позволит запускать webstorm . из терминала) и ассоциации с типами файлов.

VS Code. Скачай User Installer — он ставит редактор в профиль пользователя и не требует прав администратора. В установщике включи «Add to PATH» и, по желанию, пункты контекстного меню «Open with Code» для файлов и папок.

Обе программы дальше обновляются сами; отдельная утилита JetBrains Toolbox App удобна, если в будущем понадобится не только WebStorm, но и другие IDE JetBrains.

macOS

WebStorm. Скачай .dmg (отдельные сборки для Apple Silicon и Intel — сайт определяет процессор сам) и перетащи программу в папку Applications. При первом запуске macOS спросит подтверждение — это нормально для только что скачанного приложения.

VS Code. Скачай .zip, распакуй и перетащи Visual Studio Code.app в Applications. Чтобы работала команда code . из терминала, открой палитру команд и выполни Shell Command: Install 'code' command in PATH.

Ubuntu

WebStorm. Два официальных пути: распаковать .tar.gz и запустить bin/webstorm.sh либо поставить через Toolbox App. Второй вариант удобнее: он сам следит за обновлениями и создаёт ярлык в списке приложений.

VS Code. На Ubuntu ставится .deb-пакетом из официального сайта — двойным кликом или командой:

sudo apt install ./code_*_amd64.deb

Пакет сам подключает репозиторий Microsoft, поэтому дальше редактор обновляется вместе с системой обычным sudo apt upgrade.

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

⚠️Важно

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

Открывают папку, а не файл

Самая частая ошибка первого дня: студент делает File → Open, выбирает contract.ts и получает окно, в котором почти ничего не работает — ни поиска по проекту, ни перехода к определению, ни git. Редактор тут не виноват: ему показали один файл, а не проект.

Один открытый файл — редактор не знает ни соседей, ни зависимостей, ни git. Открытая папка проекта — работают индексация, поиск и панель git.

Корень проекта — это папка, в которой лежат package.json (манифест проекта из прошлой главы) и скрытая папка .git. Именно её открывают. После этого редактор:

• строит индекс — читает все файлы и зависимости из node_modules, чтобы знать, где что объявлено;
• включает поиск и замену по проекту — искать есть где только тогда, когда известны границы проекта;
• подхватывает git — .git лежит в корне, и панель Version Control сразу показывает ветку и изменения;
• читает настройки проекта — tsconfig.json, .editorconfig, конфиг форматтера; открытый в одиночку файл ни к каким из них не привязан.

Нажми на часть выражения

💡Совет

Проверить, что открыт именно проект, а не файл, можно за секунду: в дереве слева должен быть виден package.json, а в статусной строке (внизу) — имя текущей ветки git. Нет ветки — открыта не та папка.

Карта окна

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

Пять зон окна: дерево файлов слева, редактор в центре, панель git и панель проблем справа, встроенный терминал снизу.

Зона	WebStorm	VS Code	Зачем
Дерево файлов	Project	Explorer	видеть структуру проекта и открывать файлы
Редактор	вкладки в центре	вкладки в центре	собственно код
Поиск по проекту	Find in Files	Search	найти строку во всех файлах сразу
Терминал	Terminal	Terminal	npm, docker, git без выхода из окна
Git	Version Control (Commit, Git log)	Source Control	что изменилось, diff, коммит, история
Проблемы	Problems	Problems	все ошибки и предупреждения проекта списком

Панель Project — Alt+1 (⌘1 на macOS), терминал — Alt+F12 (⌥F12), панель коммита — Alt+0 (⌘0). Все панели у JetBrains пронумерованы: цифра с Alt открывает и закрывает соответствующую.

Панель проблем стоит открыть отдельно и посмотреть на неё внимательно: она показывает не только ошибки открытого файла, а весь список замечаний компилятора TypeScript по проекту. Пока в ней что-то красное, npm run build тоже не соберётся — экономит один прогон сборки.

Горячие клавиши, которые окупаются в первый день

Учить сотню сочетаний бессмысленно. Есть семь, которые экономят время каждый час работы. Ниже — раскладка для Windows и Linux (там сочетания совпадают) и отдельно для macOS.

WebStorm

Действие	Windows / Linux	macOS
Найти файл по имени	Ctrl+Shift+N	⇧⌘O
Поиск по всему проекту	Ctrl+Shift+F	⇧⌘F
Найти вообще всё (Search Everywhere)	Shift дважды	Shift дважды
Переход к определению	Ctrl+B	⌘B
Переименовать символ	Shift+F6	⇧F6
Форматировать код	Ctrl+Alt+L	⌥⌘L
Закомментировать строку	Ctrl+/	⌘/
Мультикурсор: добавить курсор	Alt+Shift+клик	⌥⇧клик
Палитра действий (Find Action)	Ctrl+Shift+A	⇧⌘A

VS Code

Действие	Windows / Linux	macOS
Найти файл по имени (Quick Open)	Ctrl+P	⌘P
Поиск по всему проекту	Ctrl+Shift+F	⇧⌘F
Палитра команд	Ctrl+Shift+P	⇧⌘P
Переход к определению	F12	F12
Переименовать символ	F2	F2
Форматировать документ	Shift+Alt+F	⇧⌥F
Закомментировать строку	Ctrl+/	⌘/
Мультикурсор: добавить курсор	Alt+клик	⌥клик
Мультикурсор на все совпадения	Ctrl+Shift+L	⇧⌘L

Где сочетания расходятся. Совпадают ровно два: поиск по проекту (Ctrl+Shift+F) и комментирование строки (Ctrl+/). Всё остальное разное, и знать об этом полезно заранее, чтобы не решить, что «в этой IDE такого нет»:

• быстрый переход к файлу: Ctrl+Shift+N в WebStorm против Ctrl+P в VS Code;
• переход к определению: Ctrl+B против F12;
• переименование: Shift+F6 против F2;
• форматирование: Ctrl+Alt+L против Shift+Alt+F;
• палитра: у WebStorm это Find Action (Ctrl+Shift+A) — поиск по действиям IDE; у VS Code палитра команд (Ctrl+Shift+P) — то же самое по смыслу, но она же и главная точка входа почти во всё остальное;
• мультикурсор: Alt+Shift+клик против Alt+клик — разница в одну клавишу, и именно на ней спотыкаются те, кто пересел с одного редактора на другой.

Мультикурсор: когда он экономит минуты

Мультикурсор — несколько точек ввода одновременно: то, что ты печатаешь, появляется во всех сразу. Он не «фокус ради фокуса», а самый быстрый способ сделать однотипную правку в десяти строках подряд — например, дописать префикс к списку переменных окружения в .env.example или превратить столбик значений в массив.

Два режима, которые стоит знать:

• курсор по клику — Alt+Shift+клик в WebStorm, Alt+клик в VS Code: ставишь курсоры руками там, где нужно;
• курсор на все совпадения — Ctrl+Shift+L в VS Code (в WebStorm — Ctrl+Alt+Shift+J): выделяешь слово и получаешь курсор на каждом его вхождении в файле.

Второй режим часто путают с переименованием, но это разные вещи: мультикурсор — тупая правка текста в текущем файле, переименование — осмысленная правка символа во всём проекте. Для имени функции нужен второй, для десяти одинаковых строк в конфиге — первый.

Отдельно про переименование: Shift+F6 и F2 — это не «заменить текст». Редактор понимает, что переименовывается именно этот символ, и правит его во всех местах, где он используется, не трогая одноимённые строки в комментариях и чужих переменных. Поиск с заменой такого не умеет — он работает с текстом, а не со смыслом.

✨Интересный факт

Если ты уже привык к чужой раскладке, менять привычку не обязательно: в VS Code есть расширение IntelliJ IDEA Keybindings, а в WebStorm — готовая схема VSCode в настройках Keymap. Обе переносят сочетания целиком, включая мультикурсор.

Отвечено вопросов: 0 из 4

Чем переименование символа (Shift+F6 в WebStorm, F2 в VS Code) отличается от поиска с заменой?

Какие два сочетания совпадают у WebStorm и VS Code на Windows?

На macOS в таблицах вместо Ctrl почти везде стоит ⌘. Что это значит на практике?

Зачем нужна палитра — Find Action в WebStorm или палитра команд в VS Code?

Отвечено верно: 0 из 4

Расширения и плагины: что реально нужно

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

• Поддержка языка. TypeScript в VS Code работает сразу, дополнительных расширений не нужно. Что стоит поставить отдельно — подсветку для форматов вокруг кода: Docker (для docker-compose.yml из прошлой главы) и YAML.
• EditorConfig. Файл .editorconfig в корне проекта задаёт отступы, переносы строк и кодировку — одинаково для всех, кто открывает проект, в любом редакторе. WebStorm читает его из коробки; VS Code — с расширением EditorConfig for VS Code.
• Форматтер. Для JS/TS-проектов это обычно Prettier. Он приводит код к единому виду по правилам проекта, а не по вкусу автора.
• Git-интеграция. Встроена в обе программы. Дополнительные расширения вроде истории построчного авторства ставят по вкусу, но без них можно жить.

EditorConfig

Формат файла .editorconfig и список редакторов с поддержкой из коробки — одинаковые отступы и переносы строк для всей команды.

Prettier — установка

Официальная инструкция: установка форматтера в проект как зависимости, чтобы код у всех форматировался одинаково, а не по настройкам конкретного редактора.

Про доверие к чужому коду

Расширение — это чужая программа, которая запускается внутри редактора с твоими правами и видит все открытые файлы. В блокчейн-проекте это не абстрактная угроза: рядом с кодом лежат ключи ноды, .env с секретами и, возможно, seed-фраза тестового аккаунта.

Три правила, которые стоит соблюдать всегда:

• ставить расширения только из официального магазина редактора и смотреть на автора, количество установок и дату последнего обновления;
• не ставить «на всякий случай» — каждое расширение это код, который выполняется у тебя;
• относиться с подозрением к расширениям, которые просят доступ к сети или обещают «автоматически подписать транзакцию» — ни одному инструменту разработки не нужен твой приватный ключ.

⚠️Важно

Оба редактора спрашивают, доверяешь ли ты открываемой папке (Workspace Trust в VS Code, аналогичный запрос в JetBrains). Это не формальность: в проекте могут быть настройки, которые запускают команды при открытии. Чужой репозиторий, скачанный по ссылке, первый раз открывай в режиме ограниченного доверия и не жми «Доверяю» не глядя.

Отвечено вопросов: 0 из 4

Что даёт файл .editorconfig в корне проекта?

Почему к установке расширений стоит относиться осторожнее, чем к установке обычного приложения?

Что такое Workspace Trust и зачем редактор спрашивает про доверие к папке?

Нужно ли ставить расширение для TypeScript в VS Code, чтобы работать с контрактом из прошлой главы?

Отвечено верно: 0 из 4

Ключи, seed-фразы и облачные помощники

Отдельный раздел, потому что в блокчейн-разработке ошибка здесь необратима: приватный ключ или seed-фраза — это и есть доступ к аккаунту, и отозвать «уже утёкшее» нельзя, можно только выпустить новый ключ и перевести всё на него.

Что пересекает границу репозитория, а что остаётся только на машине: код и .env.example — в git, .env, keystore и seed-фраза — никогда.

Правила простые и не обсуждаются:

• Секреты не лежат в коде. Ни ключа, ни seed-фразы, ни пароля от keystore ноды в файлах проекта быть не должно — даже «на минутку, потом уберу». Значения живут в .env (или в переменных окружения системы), а в репозиторий кладут .env.example — тот же список имён переменных, но с пустыми значениями.
• .env и ключи — в .gitignore. Иначе первый же git add . отправит их в историю. Напомним из главы про .gitignore: файл, который git уже отслеживает, добавление строки в .gitignore не отменяет — его нужно сначала убрать из индекса.
• Утёкший ключ считается скомпрометированным навсегда. Удалить коммит недостаточно: копии истории уже могли уехать к другим и в CI-логи. Единственная правильная реакция — выпустить новый ключ, а старый вывести из обращения.
• Облачные помощники и подсказчики кода отправляют содержимое файлов на сервер. Это их принцип работы, а не злой умысел. Поэтому файл с ключами не открывают в редакторе с включённым облачным помощником, и уж тем более не вставляют seed-фразу в чат «чтобы проверить формат».
• Скриншот — тоже утечка. Отчёт о работе, снятый вместе с открытым .env в соседней вкладке, стоил кому-то ключей чаще, чем взломы.

⚠️Важно

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

Встроенный терминал и встроенный git

Встроенный терминал — это тот же bash или PowerShell, что и в отдельном окне, с одним отличием: он открывается сразу в корне проекта. Поэтому npm install, npm run build, docker compose up -d и git status выполняются там же, где лежит код, — и невозможно случайно запустить сборку не в той папке.

Панель git показывает то же самое, что git status и git diff, но в удобном виде: список изменённых файлов, построчное сравнение, поле для сообщения коммита, кнопки Commit и Push, дерево истории. Отметить нужные файлы и написать сообщение мышью быстрее, чем набирать пути руками.

Но команду знать всё равно надо, и на это есть три причины:

• На чужой машине и на сервере графики нет. Нода Waves Enterprise живёт в Docker, часто на удалённой машине, куда ты попадаешь по SSH — там только терминал.
• Кнопка скрывает, что именно произошло. Кнопка «Update» в разных редакторах делает то git pull --rebase, то git fetch + merge. Если не знать, чем они отличаются (глава про удалённые репозитории), разбирать последствия придётся вслепую.
• Сообщения об ошибках — терминальные. Когда push отклонён с ! [rejected] ... (fetch first), читать придётся ровно тот текст, который разбирали в главе про удалённые репозитории, — независимо от того, какой кнопкой ты нажал push.

Что удобно делать именно панелью, а не командой:

• смотреть diff перед коммитом — построчное сравнение слева-справа читается лучше, чем git diff в терминале, особенно на длинных файлах;
• собирать коммит из части изменений — отметить галочками нужные файлы (а в JetBrains — и отдельные куски файла) быстрее, чем перечислять пути в git add;
• листать историю файла — кто и когда менял конкретную строку, с переходом к тому коммиту.

Рабочая привычка большинства разработчиков — смешанная: смотреть diff и собирать коммит в панели, а pull, push, rebase и разбор конфликтов делать командами, потому что там видно, что происходит.

✨Интересный факт

У WebStorm есть встроенный HTTP-клиент: файл с расширением .http прямо в проекте, в котором запросы к REST API ноды (например, GET http://localhost:6862/blocks/last) лежат рядом с кодом и запускаются кнопкой. Удобно тем, что такие файлы можно закоммитить и передать команде — в отличие от истории запросов в отдельной программе.

Отвечено вопросов: 0 из 4

Чем встроенный терминал отличается от системного?

Почему знать git-команды нужно, даже если пользуешься панелью Version Control?

Ты выполняешь npm install во встроенном терминале, а зависимости ставятся не туда. Что вероятнее всего произошло?

Зачем WebStorm-файл с расширением .http держат в репозитории проекта?

Отвечено верно: 0 из 4

Типичные ошибки новичка

1. Открыт файл, а не папка

Симптом: не работают поиск по проекту, переход к определению и панель git; импорты SDK подчёркнуты красным, хотя npm install выполнен.

Причина: редактору показали одиночный файл — он не видит ни package.json, ни node_modules, ни .git.

Что делать: закрыть и открыть заново корневую папку проекта (File → Open), дождаться окончания индексации.

2. Правка «боевого» файла в редакторе без git

Симптом: конфиг ноды или контракт «почему-то сломался», а как было — вспомнить не получается.

Причина: файл правится вне репозитория (например, прямо в папке запущенной сети), поэтому истории изменений нет и сравнить не с чем.

Что делать: любые файлы, которые ты правишь, должны лежать в репозитории под git. Тогда git diff показывает, что именно изменено, а git checkout возвращает исходное состояние. Единственное исключение — файлы с секретами: они не в репозитории, и для них резервная копия делается вручную и хранится отдельно.

3. Не настроены автосохранение и форматирование при сохранении

Симптом: git diff показывает сотни изменённых строк, хотя ты поменял одну; ревью превращается в разгребание пробелов.

Причина: форматтер прогнал по всему файлу отступы, отличающиеся от тех, с которыми файл был закоммичен, — обычно потому, что у автора и у тебя разные настройки, а .editorconfig в проекте нет или он не соблюдается.

Что делать: договориться о правилах в .editorconfig и форматтере проекта, а не в личных настройках редактора; форматировать при сохранении только тогда, когда эти правила приняты всей командой. Если файл уже переформатирован целиком — не смешивать это с содержательной правкой: отдельный коммит «форматирование» читается, смешанный — нет.

4. Секреты открыты «просто чтобы посмотреть»

Симптом: в соседней вкладке редактора висит .env или файл с seed-фразой, а рядом включён облачный помощник; или тот же файл попал в скриншот отчёта.

Причина: секреты воспринимаются как обычный текст проекта, потому что лежат в той же папке.

Что делать: держать их вне проекта либо закрывать вкладку сразу после правки; помощников на таких файлах отключать. Правило простое: файл, содержимое которого нельзя показать чужому человеку, не должен быть открыт в момент, когда ты показываешь экран.

5. Незакоммиченные изменения на другой машине

Симптом: «на моём ноутбуке работало» — а в репозитории нужного файла нет.

Причина: файл создан и сохранён, но не добавлен в коммит; редактор показывает его нормально, потому что смотрит на диск, а не на git.

Что делать: перед концом работы смотреть панель Version Control (или git status) целиком: непроиндексированные файлы там перечислены явно.

Отвечено вопросов: 0 из 4

Импорты SDK подчёркнуты красным, хотя npm install выполнен, и поиск по проекту не работает. Что проверить первым делом?

git diff показывает сотни изменённых строк после правки одной. Что чаще всего произошло?

Почему правку конфига прямо в папке запущенной сети, вне репозитория, считают ошибкой?

Файл сохранён, редактор показывает его содержимое, но у напарника после git pull файла нет. Почему?

Отвечено верно: 0 из 4

На чемпионате

Задание на площадке почти всегда начинается с чужого кода: готовый проект контракта, конфиги сети, где-то в них нужно разобраться и что-то доделать. Времени ровно столько, сколько его нет.

• Навигация — это баллы. Участник, который ищет нужную функцию через Ctrl+Shift+N и Ctrl+B, читает чужой проект в разы быстрее того, кто открывает файлы мышью по одному. Разница за модуль — десятки минут, а критерии оценки считают выполненные пункты, а не потраченные усилия.
• Раскладка машины на площадке может отличаться от твоей. Компьютер выдают организаторы, и на нём может стоять другая ОС и другой редактор. Поэтому в этой главе таблицы сразу для трёх систем: полезно помнить не только «свою» комбинацию, но и её пару.
• Форматирование и .editorconfig спасают на командных модулях. Когда трое пишут в один репозиторий, единые правила отступов — это отсутствие бессмысленных конфликтов слияния в конце дня.
• Секреты в репозитории — это не только риск, но и снятые баллы. Критерии оценки командных и индивидуальных модулей регулярно включают пункт про безопасность конфигурации; ключ в git log эксперт видит сразу.
• Встроенный терминал экономит переключения. Всё в одном окне: правка контракта, npm run build, docker compose up -d, проверка REST API ноды. На демонстрации решения это ещё и выглядит собранно.

Куда дальше: проверенные ресурсы

• Meet WebStorm — JetBrains — официальный обзор окна IDE: панель Project, редактор, встроенный терминал.

• WebStorm — карточка горячих клавиш (Windows/Linux, PDF) — полный список сочетаний по умолчанию, откуда взяты хоткеи этой главы.

• WebStorm — карточка горячих клавиш (macOS, PDF) — то же самое для раскладки macOS.

• WebStorm: Search Everywhere — как устроен поиск по файлам, действиям и настройкам одним окном.

• WebStorm: встроенный терминал — настройка оболочки, вкладки, запуск команд из окна IDE.

• WebStorm: работа с git — панель Version Control, коммиты, diff и история изменений.

• WebStorm: HTTP-клиент — файлы .http для запросов к REST API прямо из проекта.

• WebStorm: плагины — установка, отключение и удаление плагинов, что важно знать про источники.

• VS Code: интерфейс окна — из чего состоит окно: Activity Bar, Explorer, редактор, панель.

• VS Code: горячие клавиши — как устроены сочетания и как их менять, включая готовые схемы других редакторов.

• VS Code: карточки сочетаний (Windows, macOS, Linux — PDF) — печатная шпаргалка для Windows; на сайте есть версии для macOS и Linux.

• VS Code: встроенный терминал — вкладки, разделение панелей, выбор оболочки.

• VS Code: работа с системой контроля версий — панель Source Control, diff, коммиты, ветки.

• VS Code: магазин расширений — как устроен магазин, на что смотреть перед установкой.

• VS Code: Workspace Trust — режим ограниченного доверия при открытии чужого проекта.

• JetBrains для студентов и преподавателей — бесплатная образовательная лицензия и способы подтвердить статус.

• EditorConfig — единые правила отступов и переносов строк для всей команды.

• Prettier — установка — форматтер как зависимость проекта, а не как личная настройка редактора.

• GitHub Docs: игнорирование файлов — как устроен .gitignore и что делать с файлом, который git уже отслеживает.

• Видео и материалы сообщества — ниже — ролики по теме и ссылки от студентов и преподавателей смотри в самом низу страницы.

Челлендж ⭐

Ступень 1. Возьми проект контракта из прошлой главы (или любой TS-проект с package.json) и пройди маршрут «навигация без мыши»: открой корневую папку, найди файл contract.ts по имени (Ctrl+Shift+N или Ctrl+P), встань курсором на любой декоратор и перейди к его определению, вернись назад, найди по всему проекту строку 6862, открой встроенный терминал и выполни в нём git status. Засеки время: со второго раза маршрут занимает меньше минуты.

Ступень 2 ⭐. Настрой проект так, чтобы секреты физически не могли уехать в репозиторий. Создай .env с переменной NODE_API_KEY (значение придумай), добавь .env в .gitignore, положи рядом .env.example с той же переменной и пустым значением. Проверь, что git status не показывает .env, а .env.example — показывает. Затем ответь письменно: что нужно было бы сделать, если бы .env уже был закоммичен неделю назад и история успела уехать на GitHub?

Решение (сначала попробуй сам)

Ступень 2 — команды:

printf 'NODE_API_KEY=super-secret-value\n' > .env
printf 'NODE_API_KEY=\n' > .env.example
printf '.env\n' >> .gitignore
git status --short
# ?? .env.example   — виден
# .gitignore        — изменён
# .env в списке отсутствует: git его игнорирует

Если бы .env был закоммичен неделю назад: во-первых, ключ считается скомпрометированным — его выпускают заново и выводят старый из обращения, это первое и обязательное действие. Во-вторых, файл убирают из отслеживания (git rm --cached .env) и добавляют в .gitignore — иначе строка в .gitignore ни на что не влияет, git продолжает следить за уже отслеживаемым файлом. В-третьих, чистка истории (например, через git filter-repo) — вещь полезная, но она не отменяет первый пункт: копии истории уже могли уехать в чужие клоны, в форки и в логи CI.

Сводная проверка по всей главе: 12 вопросов, 5:00 на всё, без подсказок по ходу. Вопросы показываются по одному, ответ изменить нельзя. Если время выйдет — экзамен завершится с тем, что успел ответить. Пересдавать можно сколько угодно раз.

Что должен уметь

• Объяснять, чем редактор кода отличается от блокнота, и называть шесть возможностей, ради которых его ставят: подсветка, автодополнение, переход к определению, поиск по проекту, встроенный терминал, встроенный git.
• Сравнивать WebStorm и VS Code по существу — что готово из коробки, чем платишь за это, и почему выбор не окончательный.
• Оформлять бесплатную образовательную лицензию JetBrains и понимать, что её нужно продлевать.
• Ставить редактор на Windows, macOS и Ubuntu официальным способом и включать команду запуска из терминала (code ., webstorm .).
• Объяснять, почему открывают папку проекта, а не файл, и проверять по двум признакам (package.json в дереве, ветка в статусной строке), что открыт корень.
• Показывать на карте окна пять зон — дерево файлов, редактор, поиск, терминал, git — и называть их именами обоих редакторов.
• Пользоваться семью сочетаниями клавиш в раскладках Windows/Linux и macOS и знать, где сочетания WebStorm и VS Code расходятся.
• Отличать переименование символа от поиска с заменой и объяснять, почему первое безопаснее.
• Собирать минимальный набор расширений (язык, EditorConfig, форматтер, git) и объяснять риски чужих плагинов и режим доверия к папке.
• Держать .env, keystore и seed-фразы вне репозитория, понимать, что утёкший ключ меняют, а не «удаляют коммитом», и не открывать секреты в редакторе с облачными помощниками.
• Узнавать четыре типичные ошибки — открыт файл вместо папки, правка вне git, форматирование, раздувающее дифф, несохранённые в коммит изменения — и знать, что делать в каждой.