Продуктивнсть в IDE

 Публичный пост
1 августа 2021  1174

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 в трекерах :)

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

Связанные посты
44 комментария 👇
Herman Lyakhovich, Программирую финансы 1 августа в 18:24

Я поддерживаю желание освоить свой инструмент лучше, но конкретно здесь я вижу религию, и мне это претит.

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

А может, отъебёмся от людей и дадим им возможность работать со своими инструментами так, как они привыкли? Или программист хуже работает, если пользуется мышью? Или есть необходимость сэкономить две минуты в день на кликах, потому что опаздывает релиз?

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

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

А еще коллеги впечатляются, щекоча твое самолюбие.

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

  Развернуть 1 комментарий

@herman, Нет здесь никакой религии. Не воспринимай так серьёзно это всё.

  Развернуть 1 комментарий

@sovetov, за отодвигание и переворачивание моей мышки я бы вспылил.

  Развернуть 1 комментарий
Ivan Bogomolov, Программирую программы и все такое 2 августа в 00:12

Господа из JetBrains, нативочка получилась слишком вызывающей, но задумка была неплохой.

  Развернуть 1 комментарий

@c1rno, о, а я все ждал камингаута от автора где он признается что использует Borland Delphi

  Развернуть 1 комментарий

@vfire, свою первую более-менее осмысленную программу я написал на Delphi 7 :)

  Развернуть 1 комментарий

😱 Комментарий удален его автором...

  Развернуть 1 комментарий

@c1rno, но ведь это не наша нативочка... :(

  Развернуть 1 комментарий

Это просто феерия какая-то!

"Хотя знаю ребят, у кого выходит неплохой код на VS Code."

Это что же будет если их на IDE от JetBrains пересадить!? Страшо прдеставить!

Но если без сарказма, то я не очень понимаю как качество кода зависит от IDE.

  Развернуть 1 комментарий

@Hill, это уже было в профункторе

  Развернуть 1 комментарий

@Hill, Такое, наверное, может случиться, если в проекте CI-пайплайн не настроен и нет обязательных линтеров и статического анализа, а в команде каких-то джунов понабрали по объявлениям.

С другой стороны, на то и тимлид, чтобы это настроить (смотрит на лычку автора).

  Развернуть 1 комментарий
Dima Ollyak, софтваре инжениир 2 августа в 09:30

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

Красивое

  Развернуть 1 комментарий

Как человеку, который сидит в вскоде (= не IDE) и не очень волнуется о мнении коллег об этом, мне тяжело понять все пассажи о том, как это необходимо и жить нельзя, не освоив её фишечки). А потом и появляются люди, которые с раннего джунства на IDE и поэтому не понимают, что их крутой питоновский бэкэнд можно запустить через консольку парой строчек, не обязательно для этого всегда запускать огромную бандуру по имени пайчарм :)

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

  Развернуть 1 комментарий

@kadron141, как по мне, у Vscode есть всё необходимое чтобы назвать её IDE - терминал интегрирован, отладчик тоже, intellisense хороший :)

P. S. А уж интеграция с гитом, на мой вкус, вообще лучшая!

  Развернуть 1 комментарий

@TepMex, вскод сам по себе не парсит файлы так глубоко как иде, из-за чего он быстрее, но поиск тупит, поэтому это и редактор. Плюс в вскоде почти наверняка придётся учиться пользоваться консолью, в IDE же все привыкли жать на кнопочку запуска и прописывать конфигурации в менюшке, из-за чего потом некоторые и не понимают, как оно работает под капотом)

  Развернуть 1 комментарий
Миша Гусаров, Инженегр-погромист 1 августа в 19:24

Замечания про языки и «навороченные блокноты» были бы справедливы, если бы не LSP. С тех пор, когда LSP-сервер появился к каждому недохлому языку, проблема «навороченных блокнотов» «где блджад рефакторинги и навигация для Ы#» ушла, а проблемы IDE не пришли.

  Развернуть 1 комментарий

@dottedmag, а как она решилась? LSP сервер - это же не автоматическое решение всех проблем. Этот сервер для незнакомого языка, чтобы он поддерживал что то кроме подсветки тоже кто-то должен сделать, поэтому проблема рефакторинга никуда не ушла. Если LSP сервер это не поддерживает, рефакторинг в vs code тоже не появится.

И я уже не говорю, что с технической точки зрения Language Server Protocol спроектирован так (не знаю специально, или нечаянно) что по сути он сильно затрудняет альтернативные реализации кроме vs code.

  Развернуть 1 комментарий

Если LSP сервер это не поддерживает, рефакторинг в vs code тоже не появится.

Это «если» требуется раскрыть.

И я уже не говорю, что с технической точки зрения Language Server Protocol спроектирован так (не знаю специально, или нечаянно) что по сути он сильно затрудняет альтернативные реализации кроме vs code.

https://microsoft.github.io/language-server-protocol/implementors/tools/

  Развернуть 1 комментарий

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

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

Я вот перелез с Goland/Webstorm/Pycharm -> VS Code (стал слишком перегуженным и сложным) -> а теперь уже перелажу на дев версию nvim с lsp, с новыми модными и очень быстрыми lua плагинами вроде telescope и tree sitter, которые не томозят основой редактор. И десяток других быстрых мелких плагинов. И я пока что доволен. Но ни кого не агитирую - это ужасно так жить. В любом случае, уж очень сильный идеалогический посыл в самом начале - что надо привязываться к фичам в своей IDE.

А так - изучайте свои инструменты, да.

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

Дефолтные настройки часто неудобны, неоптимальны и вообще 21 век на дворе, можно создать на гитхабе реп где хранить свои настройки и bash скрипт, который накатывает твои настройки на новую систему.

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

Упаси господь кого-то чему-то учить, если они тебя об этом не попросили, да и еще говорить как кому-то работать. Это нарушает свободу человека и вообще. Удаленка счас везде, не представляю как я к кому-то буду подсаживаться и учить его жизни. Окей - созвон, шаринг экрана или какой-нибудь плагин для парного программирования. И совместно что-то сделать и обсудить. Но учить человека нажимать на кнопки? Ну мы ведь не в десткому саду.

  Развернуть 1 комментарий

@gwgjga6dQ4Wnve1N,

Упаси господь кого-то чему-то учить, если они тебя об этом не попросили, да и еще говорить как кому-то работать.

Вот это прямо хочу плюсануть отдельно.

  Развернуть 1 комментарий

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

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

  Развернуть 1 комментарий

@sergevkim,
Часто фактор, ограничивающий производительность это не время - а условное внимание (в терминах Дорофеева - мыслетопливо).
Поэтому возможность сделать рутинные вещи на одной мышечной памяти может здорово сэкономить ресурсы для тех самых задач типа "придумать".

  Развернуть 1 комментарий

@sergevkim, И да, и нет.

Вопрос не в общем bandwidth из мозга в код, вопрос в latency в критические моменты: в момент, когда вошёл в поток и понимаешь, как решать задачу, ВНЕЗАПНО узким местом становится человекомашинный интерфейс.

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

  Развернуть 1 комментарий

@sergevkim, IDE помогает читать код не меньше (а может и больше), чем его писать

  Развернуть 1 комментарий

@sergevkim, написание кода - это действительно очень маленький процент времени, и тоже непонятно, зачем оптимизировать. Самая большая оптимизация тут - десятипальцевый слепой набор на двух языках, остальное уже не очень надо.

Но! Фичи IDE незаменимы при отладке, тестировании, сопровождении и погружении в большую кодовую базу. Все эти глобальные поиски, отладчики, профайлеры, терминалы, встроенный гит с красивыми диффами и блеймами - всё красиво и в одном окошке.

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

  Развернуть 1 комментарий

@sergevkim, плюсую, видимо тоже грейда не хватает.
У меня ощущение, что IDE часто больше ворует внимание, чем помогает экономить.

Отдельная боль -- модные IDE (vscode и pycharm) добавляют скрытые состояния в модель мира в котором будет запускаться код. Я перестал знать, запустится ли только что написанное, или pycharm снова продолбался и не обновил код на удаленной тачке.

  Развернуть 1 комментарий

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

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

  Развернуть 1 комментарий

Дополню еще: самый большой минус в IDE у меня - тормоза (причем на норм конфигурациях). Пока там что-то заиндексируется, обновится, обработается - просто нереально бесит! Я хочу открывать проект и в ту же секунду видеть подсветку кода, через 0.01 секунды после нажатия клавиши видеть появившийся символ и все такое. И чтобы оно всегда работало с такой скоростью, вне зависимости от размера проекта.

На мой взгляд, самое наинеудачнейшее решение в IDE от JetBrains (пост, кажется, неявно подразумевает их) - это их написание на Java, хз даже, что может быть более худшим выбором языка и платформы для программы, которая должна работать быстро.

  Развернуть 1 комментарий

@nightlord189, у емакса есть разделение на демон(сервер) и клиент, 0.01с вполне достигаются :-)

  Развернуть 1 комментарий

  Развернуть 1 комментарий
Alexander Burluka, Софтваре девелопер 2 августа в 09:21

"Полно опечаток. Некоторые куски кода или целые функции не используются и, следоавтельно".
Not sure if trolling, как говорится.

  Развернуть 1 комментарий

@a-a-b, спасибо, попрваил.

  Развернуть 1 комментарий

@sovetov, Чёто ржу:-) Ты опечатался в заголовке, после рассказов о том, как у старообрядцев полно опечаток в коде, и в комментарии о том, что ты исправил опечатку. Ну да, продуктивная продуктивность - не читать то, что пишешь, срочно всем на IDE!

  Развернуть 1 комментарий

@a-a-b, я токсичный ублюдон, я знаю :-)

  Развернуть 1 комментарий

@a-a-b, Это потому что браузер - это не IDE. А вот был бы WebCode с плагином для vas3k, линтером и рефакторингом постов...

  Развернуть 1 комментарий

Для C# и Java без IDE действительно почти невозможно работать.

Но в остальном согласен с предыдущими комментаторами - лучше не начинать карьеру сразу с IDE, это как учиться плавать только с кругом и утонуть сразу, как только поплывешь без него.

Я вообще перешел с ide на vs code и всем доволен (фичи те же, а тормозит меньше). И на саблайм перешел бы, если бы он поддерживал терминал прямо в окне, как vs code. Думаю даже свой блокнотик с терминалом на go написать (чтобы блокнот не в электроне работал, как vs code).

А автоматизировать команды можно Makefile и терминал.

  Развернуть 1 комментарий

@nightlord189, плюсую makefile. мне постоянно тыкать в него не мешает даже работа в IDE.

  Развернуть 1 комментарий

А как же множественные курсоры? Попробовав раз - жму и сейчас!
!


https://medium.com/@adrior/множественные-курсоры-в-vs-code-3af4f5085b36

  Развернуть 1 комментарий
Андрей Писков, человек-оркестр (директор по IT-продуктам) 2 августа в 00:24

TLDR;

  1. Read the fucking manual (к ОС, IDE и прочим инструментам, в которых проводишь большую часть жизни).
  2. Поставь vim-плагин к IDE, браузеру и операционке. Вот пост на вастрике.
  3. В конфиг vimrc забинди все часто используемые ide-команды, чтобы не было аккордов (хочешь вынести в отдельный метод нажми подряд пробел e; хочешь сбилдить — пробел b и т. д.). Для каждой ide аналогичный. Так, неважно какая операционка или IDE, везде код редактируется, рефакторится и навигируется одинаково.
  4. Profit.
  Развернуть 1 комментарий

@piskov, мне что-то от рекомендаций использовать vim или vim-плагины аж припекает. Ну рили? От того, что я сдвину руку вправо, возьму мышку, наведу ее чуть-чуть выше, кликну, потом снова руку на клавиатуру и напишу текст вместо того, чтобы ввести какое-нибудь сочетание символов, которое сделает то же самое, только без мышки - я стану быстрее программировать? Или лучше укладываться в дедлайны?

Ей-богу, как веганство, кроссфит или как держать под раковиной компост.

  Развернуть 1 комментарий

@sergeydragan,  Это не про эффективность. А про идеалогический экстаз от выверенности твоих нажатий на кнопочки. Вот представь наслаждение как пальчики бегают по кнопочкам - а ты при этом сидишь довольный, на окружающую действительность от этого становится чуть похер, да. Люди еще ради этоого собирают себе оротлинейные сплит клавиатуры, а некоторые еще и на BEAKL 15 переходят. Тренировки месяцами - и все ради тактильного, идеалогического и принципиального удовольствия.

  Развернуть 1 комментарий

@sergeydragan, вы просто не в теме = нужно попробовать. Когда составите мнение на практике, тогда и вопросы отпадут.

Да, это действительно так эффективно (экономит подчас х20, смотря что редактируете). И нет, это не месяцы тренировок — от силы пара недель.

Дополнительно доставляет, что где бы ни были (какая операционка, какая IDE), у вас всегда одни и те же команды (а не, как минимум, разница между ctrl и cmd)

  Развернуть 1 комментарий

@piskov, Спаведливости ради, на базовые хоткеи вим и правда просто перейти. А вот полноценно - регистры, text objects, vim marks, макросы итд - это не так просто, чтоб оно все появилось в мышечной памяти. Особенно если не владеть десятью пальцами. Да и опять же - редактриуем текст мы очень редко, по сравнению с чтением кода, концепутальным продумыванием, общением, прогоном тестов, инфарструктурной херней итд... Преимуществ нет вообще. Это прежде всего про удовольствие, и гиковость, чем про какую-то эффективность и я бы не советовал это всего людям в наше времена. Только если очень хочется.

  Развернуть 1 комментарий

@gwgjga6dQ4Wnve1N,

Это прежде всего про удовольствие, и гиковость, чем про какую-то эффективность

Вот прям совсем нет :-)

  Развернуть 1 комментарий
Марат Ямалиев, мечтаю закрыть все тикеты 2 августа в 15:02

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

  Развернуть 1 комментарий
Yury Katkov, миддл формошлёп 3 августа в 08:51

😱 Комментарий удален его автором...

  Развернуть 1 комментарий

😱 Комментарий удален его автором...

  Развернуть 1 комментарий

😎

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

Что вообще здесь происходит?


Войти  или  Вступить в Клуб