IDE уже прочно вошли в нашу жизнь. И это не только клише для первого предложения. Это аргумент, что пора бы изучить один из основных своих инструментов. Ты уже очень сильно зависим от своей IDE. И вряд ли в ближайшее время перейдешь на другую. И уже никогда не слезешь с IDE в принципе. Поэтому овладеть инструментом будет выгодно.

В чем выгода

Мозг освобождается для задач более высокого порядка. Когда ты несколько раз делаешь одно и то же, появляется мысль об автоматизации? Это как раз оно. Меньше времени уходит на рутинные задачи. Простые рефакторинги не так утомительны. Мгновенные проверки на некоторые типы ошибок и нарушений код-стайла. Не нужно запускать линтеры на каждый пуш.

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

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

Поэтому не жмись и купи IDE, если используешь платную версию. Ты уже окупил ее стократ. Уважай ребят, которые сделали твою работу комфортной.

Дисклеймер

Владение средой разработки — далеко не самый важный навык сильного программиста. Оно лишь повысит продуктивность непосредственного написания кода. Для всего остального есть Код комплит.

Нравоучения

Развивай в себе здоровое любопытство и прививай себе правильные привычки. Прямо по заветам 33 главы Код комплита.

Не спеши отключать Tip of the Day при открытии IDE. Там может быть что-то полезное для тебя.

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

Не стесняйся тыкать в кнопочки и экспериментировать. Это бесплатно. И всегда можно нажать Ctrl+Z. Смотри, как оно работает и как оно может тебе помочь.

Тыкаешь на кнопочку мышкой — узнай хоткей для нее. Иногда достаточно навести мышкой. Иногда нужно найти этот пункт в меню. Иногда — найти команду в поиске по командам или в списке комбинаций клавиш.

Перестань тыкать мышкой на кнопочки. Каждый раз, когда хочется это сделать, найди хоткей и нажми его. (Логика подсказывает, что первыми нужно запомнить хоткей поиска по командам и открытия настроек хоткеев, а также научиться искать по ним.) Выработай такую привычку. Да, это немного мешает работе первое время. Но оно окупится. Когда-то давно я отодвигал и переворачивал мышку у своих коллег и стоял над ними, чтобы они начали наконец использовать клавиатуру. Клавиатурные комбинации должны стать продолжением твоих пальцев.

Если чувствуешь, что делаешь муторную работу, которая может возникнуть и у других разработчиков независимо от проекта, проверь, нет ли на нее специальной фичи в IDE. Чтобы найти какую-то фичу, поищи в списке команд, полазь по менюшкам. Загугли наконец.

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

Сидишь в Емаксе, Виме или другом навороченным блокноте? Не упрямься и переходи на нормальную IDE. Все равно даже с миллионом расширений ты не достигнешь того, что современная IDE умеет из коробки. (Однако к навороченным блокнотам применимы рекомендации из этой статьи, которые не зависят от языка программирования.) Знаешь, как выглядит код хардкорного емаксера, когда его коллеги открывают этот код в IDE? Все подчеркнуто и подсвечено всеми цветами радуги. Везде потенциально неинициализированные и неиспользуемые переменные. Полно опечаток. Некоторые куски кода или целые функции не используются и, следовательно, не проверяются при запусках, от чего в них совсем все плохо. Из-за трудности проведения рефакторингов, хардкорный емаксер их избегают, и код становится запутанным. В целом возникает ощущение копания в чем-то грязном, небрежности автора и наплевательского отношения с его стороны.

Не отказывайся от каких-то фич IDE, потому что они работают недостаточно точно. Это всего лишь алгоритм со своими границами “интеллекта”. Но у него есть одно важное преимущество перед тобой, человеком. У IDE нет “человеческого фактора”. Она не допустит опечаток, не оставит ничего случайно незамеченным, не забудет ничего исправить.

Прощай IDE ее ошибки. Она же указывает тебе на твои ошибки и помогает их исправить. На всякий случай проверяй результаты рефакторингов через поиск по всем файлам. И всегда смотри дифф перед пушем. Хотя этот совет и без IDE полезен.

Адаптируйся под IDE. Да, придется немного прогнуться под глупую бездушную машину. Но это ради твоего же блага.

Пиши код так, чтобы машина его лучше понимала и точнее рефакторила. Это обычно означает, что не нужно использовать магию. Простой код без магии оценит не только IDE, но и твои коллеги. И не только потому что им будет проще его понимать. Они тоже используют IDE, и тоже должны читать твой код, прыгать по нему туда-сюда и редактировать.

Настраивай код-стайл и линтеры с учетом IDE. Настраивай IDE “навстречу” им. В идеале должно быть так, чтобы ты нажал хоткей автоформатирования, и оно отформатировалось так, чтобы линтер остался доволен. И наоборот, чтобы код, который проходит линтер, вызывал минимум вопросов у IDE. Часто авторы код-стайлов руководствуются своими вкусами в плане внешнего вида кода. Но если попытаться учесть все конкретные требования, в том числе и возможность настроить под него IDE, то простора для вкусов не останется. Но это тема для другой статьи.

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

Старайся использовать близкие к дефолтным настройки и клавиатурные комбинации. Во-первых, меньше мороки с настройкой нового компьютера под себя. Во-вторых, когда ты будешь сидеть с коллегой за его компьютером, ты сможешь что-то делать в IDE и подсказывать ему клавиатурные комбинации. У него наверняка дефолтные хоткеи. Когда-то давно я пересел с Нетбинс на Пайшарм, поставил себе схему хоткеев от Нетбинса. И всех своих коллег-стажеров (тех же самых, которых я лишал мышки) учил хоткеям из этой же схемы. Прошло уже много лет, я сам пересел на дефолтную схему, а они как привыкли к той, так и сидят.

Наверное, тебе надоели нравоучения и ты хочешь конкретики. Сейчас будет.

Конкретика

Тут я перечислю все, о чем вспомнил за выходные. Скриншотов, конкретных хоткеев и инструкций не будет. Просто напишу, как бывает, чтобы ты знал, что так можно. Скорее всего, половину ты знаешь. Что не знаешь, загугли и поищи в меню и поиске по командам твоей IDE. Возьми что-то, что кажется тебе наиболее интересным и нужным и старайся использовать, пока ты в каждом подходящем случае не будешь вспоминать что так можно. Потом бери что-то еще.

Визуальные помощники

Подсветка синтаксиса. Подсветка каждой переменной своим цветом.

Вертикальные линии на рекомендуемую и предельную длину строки. Горизонтальные линии между методами.

Подсветка фона в зависимости от уровня вложенности.

Фолдинг. Можно фолдить методы, классы, сложные выражения, импорты. Должны быть хоткеи, чтобы сфолдить или расфолдить все или конкретный метод. Лично я не пользуюсь, мне приятнее видеть код целиком и прыгать по нему с помощью средств навигации. Но видел тех, кто пользуется активно.

Навигация

Поиск по классам, функциям и методам, вообще любым именам.

Поиск использований метода, класса, переменной, файла.

Переход к определению (или определениям). Переход к методу (переопределенному или абстрактному) родительского класса и обратно к методам дочерних классов.

Вперед-назад как в браузере. Например, перешел к определению метода, почитал, вернулся обратно. Окно с недавно отредактированными или открытыми файлы и участками кода.

Букмарки. Можно помечать разные места в коде и прыгать между ними. Я не пользуюсь, мне хватает перемещения по истории мест.

Поиск путем набора текста в окне со структурой проекта, в окне структуры файла, в списке найденного и любых других окнах и списках.

Выделение текущего файла в окне со структурой проекта, метода — в окне со структурой файла.

Строка-панелька с путем к файлу, с папками, внутри которых он находится. По ним обычно можно тыкать, чтобы перейти туда-сюда и открыть контекстное меню. Есть хоткей, чтобы ее выделить.

Строка-панелька с путем к тому месту в файле, где расположен курсор, breadcrumbs. Класс, метод, циклы, условия. В XML/HTML там теги.

Блейм-аннотейт системы контроля версий. Пункты контекстного меню “annotate this revision” и “annotate previous revision”. Коммит месседж во всплывающей подсказке. Можно прыгать по истории и понимать, почему оно так было сделано и кого блеймить. (Ты же поддерживаешь красивую историю и описываешь причины изменений в теле коммит-месседжа?)

Редактирование текста

Все, что можно сделать с текстом независимо от языка. Этими фичами обладают также Емакс, Вим и другие блокноты, навороченные и не очень.

Поиск и замена. Внутри файла и по проекту. Можно делать простейшие рефакторинги. Алгоритм замены прост и понятен. Обычно можно какие-то вхождения заменять, а какие-то пропускать. Пробуй нажимать Enter, F3, стрелки.

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

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

Поиск и множественное выделение (некоторых) результатов поиска. Поищи хоткей, который выделяет все вхождения слова, на котором у стоит курсор. Либо можно сделать поиск по файлу и нажимая некоторые кнопочки или хоткеи и выделять или не выделять данное вхождение. Можно так что-нибудь переименовать, заэкстрактить или заинлайнить переменную. Потом можно закрыть поиск и начать набирать что-то. Буковки будут набираться во всех местах вхождений одновременно. Выглядит очень эффектно. Может быть быстрее, чем поиск и замена, и алгоритм проще.

Комплит слова из открытых файлов. Работает везде, в том числе в строках и комментариях. Жмешь хоткей, и IDE подсказывает слова из открытых файлов, правда не всегда выпадающим списком, а просто циклически перебирает. Как и обыкновенный автокомплит, помогает избегать опечаток при повторном наборе какого-то имени. Заменяет нормальный автокомплит, когда IDE до него не догадывается.

Попробуй выделить текст и нажать на скобку. В некоторых редакторах выделенный текст облачится в скобки этого типа.

Перемещение строк вверх-вниз. Пробуй разные сочетания Ctrl, Alt, Shift и стрелок вверх-вниз.

Индент. Пробуй Tab и Shift+Tab.

Другие хоткеи на удобное редактирование на уровне слов и символов. Например, удаление слова вперед или назад, удаление целой строки, перемена букв слева и справа от курсора. Не пользуюсь, потому что у меня Вим-режим, там все это есть от Вима.

Темплейты. Набираешь короткую строчку, а тебе ее разворачивают в какой-нибудь типовой стейтмент: цикл по списку, условие на null и т.п. У меня не прижилось. Но уверен, что кому-то подойдет.

Редактирование кода

Все, что может сделать IDE, которая понимает язык.

Выделение целых выражений, стейтментов, методов, классов. Курсор стоит где-нибудь в центре переменной, нажимаешь хоткей и IDE выделяет всю переменную. Потом выражение с ней, потом еще большее выражение, потом — весь if, метод, класс...

Перемещение целых выражений, стейтментов, методов, классов вверх-вниз. Примерно как со строками, только поинтеллектуальнее.

Автокомплит. Набираешь 1-2 буквы каждого слова в названии класса и вам подсказывают то, что нужно. Например, чтобы получить CommadFacadeFactory, нужно набрать Cofafa или даже cff. В настройках можно подкрутить регистрозависимость. Автокомплит бывает из разных мест. Иногда он появляется сразу: локальные имена, методы после точки. Иногда надо нажать Ctrl+Space или даже Ctrl+Space,Space, чтобы поискалось по всему проекту и само заимпортировалось. Пробуй выбирать нужный вариант на нем нажимать Enter, Tab или Ctrl+. .

Автоформатирование. Набираешь код, который валиден с точки зрения языка, но забиваешь на пробелы, отступы (в Питоне — не всегда), длину строки, переносы. И нажимаешь почаще хоткей автоформатирования. Настройки формата следует выставлять максимально жесткие, чтобы было как можно меньше способов отформатировать один и тот же кусок кода. Так можно будет писать меньше, а результат автоформатирования будет красивый. Есть разные настройки автоформатирования, можно форматировать весь файл или только измененный код. Чтобы IDE выдавала приемлемый результат, избегай сложных многострочных выражений, особенно внутри условий, циклов и других специальных стейтментов.

Упорядочивание импортов и удаление ненужных. Иногда нужно постараться, чтобы IDE и линтеры одинаково сортировали импорты. У меня в Питоне получилось, но потребовалось немножко вникнуть и поприседать.

Рефакторинг

Поищи меню с рефакторингами твоей IDE.

Экстракт переменных и методов. Выделяешь часть выражения, жмешь кнопочку — вот и переменная создана. И все такие же выражения на нее заменились. То же самое, но с куском кода и методом, но тут пока у IDE не очень хорошо получается.

Инлайн — обратное действие, заменить переменную или метод на соответствующее выражение.

Переименования. Часто вместо этого делают поиск и замену. Бывает, что IDE переименовывает лишнее.

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

Перемещения классов и методов между файлами с аккуратной работой с импортами. Перемещение методов в родительский или дочерний класс.

Выделение интерфейсов и родительских классов.

Инспекции

Видишь подчеркивания, выделения цветом букв и цветом фона? Это ворнинги — результат инспекций (проверок) IDE. Где-нибудь сбоку еще могут быть значки на каждую строку с проблемой. А в каком-нибудь уголке — значок общего состояния файла.

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

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

Не отключай их. Раньше я выборочно отключал некоторые, потому что они редко мне помогали или проверяли соблюдение правил, предназначенных для школьников. Например, я разрешал переназначать некоторые билт-ины в Питоне, но когда сам попал в неприятную ситуацию, удалив переменную type, но оставив if type is not None, резко передумал. Пускай я буду чуть-чуть тратить время на придумывание других имен, но буду чувствовать себя спокойнее с более строгими инспекциями.

Избавляйся от ворнингов дочиста. В том числе и от орфографических ошибок. Если IDE не знает слов, то наверняка можно их добавить в специальный словарь. Хорошо, если словарь можно закоммитить.

Коммить настройки инспекций. У всех, кто пользуется той же IDE, будут одинаковые настройки. И вы с коллегами будете меньше раздражать друг друга новыми ворнингами после чекаута.

Инспекции особенно актуальны, если у тебя есть стажеры или те, для кого код — не основное занятие: аналитики, тестировщики, админы. Настрой их на максимально строгий уровень. Приучи всех всегда разбираться, почему IDE что-то подсвечивает. Соблюдение всех best practices позволит избежать вопросов “а почему у вас так?” от опытных ребят, недавно пришедших в твой проект.

Главное — жать хоткеи перехода по ворнингам туда-сюда. Также используй окно всех ворнингов в проекте. Они там появляются либо автоматически, либо после запуска инспекций на всем проекте. До тех пор, пока есть ворнинги, запускать что-либо нет смысла. Все быстро свалится из-за опечатки или недоредактированного кода.

Запуск и дебаг

Запуск одной кнопкой. Прагматик программер учит нас запускать тест минимальным количеством нажатий. В IDE возможно сделать все одним хоткеем.

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

Запуск файла или теста, в котором сейчас стоит курсор.

Запуск последней конфигурации.

Брейкпоинты. Научись ими пользоваться. Их можно настроить очень хитро. Например, добавить условие или сказать, что один брейкпоинт работает только после срабатывания другого. Пошаговый дебаг. В том числе и удаленный. Watch. Call stack. Исполнение произвольного кода и изменение переменных на лету.

На крайний случай, в IDE есть копирование текущего пути, абсолютного или относительного. Можно что-то запустить и вне IDE.

История изменений внутри IDE

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

Интеграция с системами контроля версий

Коммиты и чекауты. Когда делаешь коммит, есть возможность коммитить по кусочкам, как это делает git commit -p.

История, общая и по файлу.

Пуши и фетчи. Одним хоткеем.

Может быть удобный 3-way merge.

IDE может подсвечивать измененные, добавленные и untracked файлы в окне со структурой проекта.

Лично я больше предпочитаю использовать Гит в его чистом виде. Но кому-то нравятся гуевые инструменты для этого. Попробуй найти эту функциональность в своей IDE. Вдруг затянет.

Языки программирования

Хуже всего обстоят дела с Плюсами. На большом проекте на Плюсах все ужасно тормозит. Незлоупотребление шаблонами и авто-типами помогает. IDE часто не догадывается, откуда брать инклюд и вообще есть ли инклюд какого-то хедера. Pre-compiled headers еще больше усложняют задачу, когда некоторые разработчики забывают добавлять инклюды явно. Плюсовые IDE часто заточены под конкретную систему сборки и совсем разваливаются, если используется что-то хитрое. Раньше я успешно использовал Visual Studio.

Наиболее активно я работаю с Питоном. Насколько я вижу, до Пайшарма пока ничего не дотягивает. Хотя знаю ребят, у кого выходит неплохой код на VS Code. Из-за динамической типизации и утятничества Пайшарм не всегда точно проводит рефакторинги и ищет лишние использования имен. Простой код без магии и аннотации типов помогают.

Неплохо IDE работают с XML/HTML, JS, SQL.

Очень хорошо, конечно, обстоят дела с Джавой. С ней я последний раз работал очень давно. Но даже тогда там сложно было допустить какую-то опечатку или глупую ошибку. Особенно если использовать аннотации для null. Вербозность самого языка компенсируется инструментами. И, кажется, у крутого джависта на 5 символов исходного кода приходится одно нажатие клавиши.

Хардкор

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

Регулярки в поиске

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

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

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

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

И на тебя будут смотреть снизу вверх.

Макросы

Это работает так. Включаешь запись макроса. Редактируешь код. IDE записывает за тобой нажатия клавиш. Останавливаешь запись. И потом воспроизводишь макрос, когда хочешь.

Очень приятно смотреть, как оно само за тебя код редактирует. Коллеги тоже впечатляются. У меня Вим-режим, пользуюсь его макросами. Поэтому не знаю особенностей макросов в самих IDE.

Макросы иногда криво воспроизводятся, если во время записи был автокомплит. Разберись, как твоя IDE себя ведет.

Макросы надо очень аккуратно писать, думая о том, как эти же нажатия клавиш скажутся на аналогичных кусках кода.

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

Макросы, особенно если запускать один внутри другого, — это мощный инструмент.

Вим-режим

Если вдруг так случилось, что ты умеешь в Вим, то во многих IDE есть возможность включить этот режим. Из коробки или специального плагина. (Для Емакса, может быть, тоже есть схема хоткеев или плагинчик.)

Самая большая проблема — Вим-режим везде плохо работает. Я пробовал в разных IDE. Абсолютного комфорта и уверенности, близкой к Виму, я нигде не почувствовал. Но в последнее время эту функциональность везде потихоньку доводят до ума. Да и я привык. Поэтому работаю без раздражения.

К чему нужно быть готовым:

• Везде статусная строка Вим-режима и всей IDE — это одна и та же строка. И одно часто перетирает другое.
• Клавиатурные комбинации конфликтуют. Приходится от чего отказываться, а что-то — перенастраивать. Например, я не пользуюсь Ctrl+F и Ctrl+B, поэтому отдал их IDE. А с Ctrl+R уже проблемы.
• Возникают проблемы на стыке специальных возможностей IDE и Вим-режима. Например, может быть такое, что в IDE сделал хитрое выделение, но непонятно, в каком режиме в данный момент находится Вим-плагин.
• Да, и нужно уметь в собственно Вим.

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

Заключение

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

Спасибо за внимание.