#40: Спэшл: Эргономика, NeoVim и TDD

[00:00] Илья: Здоровый программист — это человек, который задумался о своём здоровье.

[00:04] Александр: Общение не на встречах намного более продуктивно. Оно становится конструктивным, появляются ссылки, пруфы. Это всё можно отследить, это всё можно вынести в документацию.

[00:13] Илья: Я знаю, что я буду иногда заходить на сервер, и мне надо будет менять конфиги. «Нано? Как-то позорно перед пацанами — нано запускать». Я такой: я буду Vim запускать.

[00:21] Александр: Если вы хотите написать комментарий, что «а в IDEA можно вот так», — ребят, я знаю. Я семь лет на IDEA пишу, не надо это писать. В Java-комьюнити нет инструмента, который тупо форматирует код. Мы не можем из консольки просто взять и сказать «отформатируй код». Нету такого. А то, как в Java устроена работа с пакетами, — это IDEA делает вообще невероятную работу.

[00:44] Александр: Здарова, меня зовут Саша Пахомов, это оффлайн-подкаст «Тысяча фичей». Сегодня у меня в гостях Илья Ильиных, мы разговариваем про кучу всего. Получилось суперинтересно — я подводку записываю в конце, так что уже знаю. Мы поговорили про NeoVim, про клавиатуры, про эргономику, про IntelliJ IDEA, про Go, про менеджеров и так далее. Просто супер-супер-супер выпуск. Включайте его на телевизорах, на макбуках, заваривайте чай, кофе или что покрепче — и наслаждайтесь двумя часами оффлайн-подкаста.

[01:15] Александр: Привет, Илья.

[01:16] Илья: Привет, Саш.

[01:17] Александр: Сколько тебе лет?

[01:18] Илья: Мне двадцать… 25 лет.

[01:23] Александр: 25, отлично. Мне 26, мы почти ровесники. Хотел вначале поговорить про здоровье, про здоровье программиста в частности, потому что у тебя канал — если кто не смотрел, ребят, переходите, все ссылки будут в описании. Замечательный канал, «Куда войти» называется, даже вот на маечке есть логотип.

[01:39] Илья: На маечке, да. Её мне подарили, это не сам делал.

[01:42] Александр: Классный логотип. И там затрагивались — по крайней мере, в комментариях под одним из видео я видел — вопросы про здоровье, про посадку, про то, как ты себя ощущаешь, когда сидишь. Мы плавно, конечно, перейдём к сплит-клавиатурам, но вот если бы ты начал описывать, что для тебя здоровье программиста, — как бы ты это описал?

[02:02] Илья: Я бы описал так: здоровый программист — это человек, который задумался о своём здоровье. Безусловно, ты можешь заниматься спортом. Я, кстати, тут грешу, я не прям спортсмен: у меня есть небольшое снаряжение, такой гир, который я использую дома, чтобы потренироваться, — но это буквально в рамках зарядки. Я думаю (это моё мнение, я не врач), что гораздо продуктивнее сделать своё рабочее место эргономичным. Я всё равно буду сидеть 8 плюс часов, потому что я работаю программистом, — так пусть рабочее пространство помогает мне экономить здоровье. Тогда и выхлоп будет больше, и результата я быстрее достигну, потому что за то же время работа будет продуктивнее. Поэтому первый шаг, я считаю, — задуматься о том, как я работаю, как я сижу, что плохого есть в моих текущих привычках и что я могу поменять, чтобы сделать лучше. И тут, наверное, надо ещё сходить к врачу. Я не ходил — буквально дженерик-вопросы и ответы находил в интернете. Например, у меня монитор стоит абсолютно напротив глаз.

[03:04] Александр: Давай сначала опрессуем проблему. Вот что не так в классической посадке за ноутбуком? Допустим, передо мной ноутбук, я в него вот так смотрю — примерно такая у меня посадка. Я думаю, процентов 70 людей, которые нас смотрят, именно так и сидят. Расскажи, что сейчас в моей посадке не так.

[03:21] Илья: Ну, сутуло; то, что ты смотришь вниз, что у тебя плечи не расправлены. А чтобы их расправить, нужны подходящие клавиатуры. И монитор на самом деле очень близко к глазам стоит — и вниз, и близко, это тоже очень важно, особенно с моим-то зрением. Ещё, скорее всего, когда ты сидишь с ноутбуком, его можно поставить на коленки, и он хорошенько припекает. Это вредно для репродуктивной системы, поэтому я не буду тут дальше распинаться — погуглите, но всё время держать там тепло не очень полезно. И скорее всего, когда мы сидим за ноутбуком, некоторые люди не контролируют, как долго это делают. Это тоже надо контролировать, чтобы не засиживаться, чтобы шея не затекала, чтобы глаза не уставали, — делать перерывчики. Но это отдельная тема. Я бы сказал, это основные поинты. Наверное, ещё высота стола: я его специально подбирал так, чтобы, когда стул стоит, руки у меня были ровно под прямым углом. Но это уже скорее про клавиатуру и её постановку. И ещё по-хорошему какие-нибудь накладки под кисти, чтобы они были не на весу и не передавленные, а то может быть проблема с кистью, туннельный синдром и так далее. Надо делать, чтобы всё было максимально эргономично. Некоторые ещё ставят клавиатуры под вертикальным углом — это ещё полезнее, потому что это более естественное положение для кистей. Я пока до этого не дошёл, но когда-нибудь дойду, потому что знаю клавиатуру, которая это поддерживает.

[04:46] Александр: Так, вот мы берём классическое положение. Первое, что мы делаем, ты сказал, — поднимаем монитор на уровень глаз и отдаляем.

[04:52] Илья: Да. И получается, посадка станет уже ровнее. Плечи всё равно будут идти вперёд, потому что надо печатать на клавиатуре, — и тут важный момент, что клавиатуру можно отделить от ноутбука, а можно продолжать печатать на ноутбуке. Ещё я использую именно один монитор, потому что не хочу перефокусироваться с одного на другой. Я знаю, многим удобно два, и это можно сделать эргономично — например, поставить их так, чтобы расстояние было одинаковым, — но я таким не занимался. У меня один монитор, на нём довольно крупный шрифт, чтобы я вообще никак не напрягался. Тем более, забегая вперёд, Vim легко масштабируется. Когда мне удобно, тогда такой шрифт и ставлю: смотрю логи — делаю мелкий, чтобы больше влезало; пишу код — делаю крупный, потому что дальше функции или теста мне обычно смотреть не надо, и можно вообще расслабиться и печатать на сплите, у меня довольно ровно стоит клавиатура.

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

[06:06] Илья: В привычку входит, и потом ты понимаешь, что что-то не то происходит.

[06:10] Александр: А когда ты сидишь ровно и тебе комфортно — ну действительно, как книжку когда читаешь, ты отрегулируешь нормальное расстояние, и глазам комфортно. И так же можно регулировать не расстояние, а шрифт. Я тоже так делаю: у меня довольно крупный шрифт, правда, монитора нет — есть просто MacBook, и я его ставлю повыше.

[06:31] Илья: На подставочку?

[06:32] Александр: Да. И вообще супер. Один монитор, мне кажется, это тема, потому что на моём текущем этапе взаимодействия с компьютером мне не нужно два — я даже не могу понять, зачем мне будет два. Про это можем поговорить чуть позже. Я пользуюсь оконным менеджером, и в целом этого достаточно. Если кто видел, я на бэкстейдже покажу фотографию, как у меня расположен компьютер на столе, — довольно просто. Из интересного: MacBook поднят, а туда, где клавиатура, я кладу планшет, — например, когда смотрю туториалы, видосы, настройки Vim, я их там включаю, а у себя на компе применяю в реалтайме, чтобы не свитчить туда-обратно.

[07:23] Илья: Одну штуку не сказали. У меня монитор вообще стоит на подставке, потому что не все мониторы регулируются достаточно высоко. Это ещё и освобождает место на столе: подставка занимает только две точки, сам монитор висит на этой навесной штуке, и под него можно что-нибудь поставить — у меня там карта захвата, аудиокарта стоит. Так что если у вас монитор плохой в том смысле, что не поднимается достаточно высоко для глаз, — хороший лайфхак купить подставочку: сэкономите место и сделаете рабочее место эргономичнее.

[08:00] Александр: Я, кстати, недавно увидел, что у меня в качестве подставки — коробка из-под бокалов. А ещё я видел кронштейны, которые прикручиваются к столу, и монитор прям висит.

[08:17] Илья: Есть мониторы уже built-in с этими кронштейнами. Не буду рекламировать конкретную модель, их легко найти. У меня самый стандартный монитор — я его в офисе посмотрел, понравился, себе такой же взял и не парился. Но с мониторами, и с Mac в частности, есть небольшая проблемка: во-первых, мало мониторов в целом совместимы с макбуками по USB и клавиатурам; во-вторых, я лично замечаю разницу между внешним монитором — там LG, Lenovo — и экраном MacBook, это прямо чувствуется.

[08:58] Александр: Калибровка света как минимум. И цвет, и плавность картинки, скорость. У тебя, наверное, 60 или 120 FPS?

[09:08] Илья: У меня 60.

[09:08] Александр: 60 всё-таки можно заметить, если сильно придираться. Но в целом это классная тема, особенно когда монитор достаточно далеко и достаточно крупно — всё, мне кажется, норм. Ты поднял тему, что с Mac несовместимы многие мониторы. И говоришь, что явно видишь разницу маковского монитора и обычного. У меня тоже есть чувствительность — я вижу разницу между 60, 120 и 240 FPS, я очень чувствителен к FPS. Но работаю только за 60, потому что сижу в Vim, там вообще нет анимации, там просто переключение одним кадром.

[09:45] Илья: 120 FPS было бы прикольно — обогнать скорость света в печати.

[09:47] Александр: Что тогда делать? У меня очень простая ситуация. Есть небольшая утилита, вы сможете найти, она бесплатная, но есть и платная версия, называется Better Display. Она делает так, что любой монитор можно отмасштабировать в High DPI. В чём особенность маковского монитора? Там один пиксель — это на самом деле несколько пикселей. У тебя отображается картинка, условно 1920 на 1080, а само разрешение экрана выше, просто достигается это тем, что один пиксель делится на субпиксели. Я могу в деталях ошибаться, но примерно так. А у внешнего монитора этого разделения нет — один пиксель это один пиксель. Есть встроенные в Mac возможности сделать High DPI на обычном мониторе, но, скорее всего, буквы будут слишком большие, и вы такие: «что-то мне это не нравится», — и забьёте. А Better Display находит золотую середину: есть довольно высокие разрешения, и при этом с High DPI. По каким-то умным алгоритмам оно строит картинку — может, объединяет не 4 пикселя в 1, а поменьше, например 3. Короче, хитрая магия под капотом, и картинка получается красивой, более похожей на Mac. Понятно, что цвета всё равно придётся калибровать, если хочешь красить видосы или фотки, но с масштабированием проблем уже не будет.

[11:06] Александр: Круто, про мониторы поговорили. Думаю, по постановке монитора вопросов ни у кого не будет. И от монитора можно плавно перейти к клавиатуре, потому что, если я поднимаю MacBook выше, до его клавиатуры я уже тянуться не смогу — и у меня стоит отдельная клавиатура, обычная, почти обычная механическая клава. С какой клавиатуры ты начал взаимодействие в плане механики? Какая была первая?

[11:36] Илья: Мы сейчас поделимся общим опытом, потому что у меня первый опыт был Keychron K3 V2.

[11:39] Александр: Keychron, да.

[11:39] Илья: Я в эту тему с механическими клавиатурами заехал года два назад. Вначале купил себе просто отдельную клавиатуру, у меня была какая-то небольшая Logitech, мембранная, — я про неё в видосе про клавиатуры упоминаю, не буду подробнее. Потом перешёл на механику, Keychron K3 V2, и мне kind of понравилось. Я бы на ней до сих пор сидел, просто захотелось поэкспериментировать, и я перешёл на сплит-клавиатуры. В чём, мне кажется, плюс отдельных клавиатур: как ты правильно сказал, не надо тянуться куда-то далеко, можно поставить куда тебе удобно. И там есть разные — повыше, пониже, — в зависимости от того, что тебе надо. Если покупаешь повыше, надо ещё понимать, что под них, скорее всего, надо подкладочки под кисти, чтобы кисти не передавливались. Это тоже отдельная технология.

[12:31] Александр: Давай для слушателей, которые первый раз слышат, — что такое сплит-клавиатура, я думаю, такие есть. Вот есть обычная клавиатура, руки у меня на ней стоят так. Обратите внимание, что плечи уже как-то себя некомфортно начинают ощущать. Тут ещё стол немножко высокий — но, допустим, вот так я сижу, всё равно напряжение в плечах есть, и это неестественное положение рук. У нас руки так не должны быть: когда вы сидите за столом, вы либо на подлокотник ставите руки, либо на стол вот так кладёте. И вот сплит-клавиатура — почему сплит? Она разделена на две, и под каждой рукой одна половинка. Мы кладём руки на стол вот так — и смотрите: плечи внизу расслаблены, шея расслаблена, и я смотрю в монитор. Это совсем другое дело. Ещё это полезно тем, кто сидит на созвонах, потому что диафрагму можно открыть. Когда ты вот так держишь руки, у тебя, во-первых, горло зажато, говорить будет сложнее — ну, не сложнее, звук будет хуже, зажатая поза. Сложно что-то выдать, говорить на митинге, на митапе, выступать онлайн — будешь менее убедительным, чем мог бы. Даже я вот сейчас так сижу и чувствую себя увереннее.

[13:36] Илья: Да, когда расправлена диафрагма, можно говорить на опоре, связками хорошо работать, никаких проблем. Например, у меня был один менеджер, который всё время сидел за сплитом и говорил, что ему так удобнее говорить. Он ещё и стоя работал — я до стоя ещё не дошёл, может быть, когда-нибудь дойду, но пока меня устраивает работа сидя.

[13:57] Александр: А как ты вообще к механике пришёл? Удивительно, но моя первая механическая клавиатура была абсолютно такая же, как у тебя, — Keychron. Объясню. Механических клавиатур очень много, они разделяются на невозможное количество, но плюс-минус их можно разделить по классам. Есть плата, в неё вставляются свитчи — механизмы, которые отвечают за нажатие, — а поверх свитчей надеваются кейкапы, то, что трогают наши пальцы. Вот три основных компонента большинства механических клавиатур. И первая клавиатура — и у меня, и у Ильи — была такая, где эти свитчи маленькие, миниатюрные, чтобы она была плоская. Многие любят клавиатуры плоские, low-profile, потому что они почти как листочек бумаги лежат на столе и руки не задирают, это более естественное положение. У меня первая Keychron была с впаянными свитчами, их нельзя было менять, — хотя большинство механических клавиатур свитчи менять позволяют.

[15:01] Илья: У меня есть интересная история, как я всё-таки умудрился поменять свитч. Я впервые её видел — просто ножом отковырял припаянный свитч и поменял. Я мама-инженер: не хот-свап, но да. Работало всё супер. Свитчи разделяются на разные типы: тактильные — которые приятненько нажимать; линейные — которые просто быстро нажимать, для быстрой печати; и клики, синие, как-то так называются.

[15:30] Александр: А какие себе выбрал?

[15:31] Илья: Я себе выбрал первые — как раз клики, потому что посмотрел в интернете видос, там так классно звучит. Как будто на печатной машинке: ты прям нажимаешь реально как на печатной машинке. У меня в школе бабушка работала сторожем, я к ней вечерами приходил, и там была печатная машинка — видимо, бухгалтеры на ней что-то делали. Я прям помню эти металлические звуки, когда она бьёт. Минус таких клавиатур и таких свитчей в том, что они очень громкие, и людям вокруг это в целом не очень нравится. У меня есть друг, который в офисе принёс синие свитчи — его закэнселили.

[16:07] Александр: Закэнселили, попросили не использовать эту клавиатуру в офисе.

[16:16] Илья: Keychron у меня был как раз на таких свитчах, и я с ней быстро рассталась как раз из-за этого. Вторая клавиатура была Nuphy, тоже низкопрофильная, типа Air75, с теми же маленькими свитчами, но их уже можно менять. А сейчас у меня Nuphy 60 — она уже полнопрофильная, и свитчи мне очень нравятся, прям эстетическое удовольствие, и подставочка под неё есть, руки прям комфортно лежат на столе. Вот я сейчас на такой клавиатуре. А ты на какой?

[16:47] Александр: У меня после Keychron была сплит от Ergohaven. Это компания, если не ошибаюсь, откуда-то с юга России. Они собирают по опенсорсным схемам, которые сами проектируют и публикуют. У них есть и сплит-, и не-сплит-клавиатуры, но все позиционируются как эргономичные. У меня была одна из их — K02 называлась. Это высокопрофильная клавиатура на Choc-свитчах. Коричневые у меня были свитчи, то есть тактильные — я люблю чувствовать это нажатие, и, по-моему, это очень полезно, когда используешь home row: меньше мискликов, потому что ты явно должен нажать кнопку. Это золотая середина между синими, которые кликают как печатная машинка, и линейными, которые красненькие. А говоря про мою последнюю клавиатуру, которой я сейчас пользуюсь, — это Corne. Это самая базовая низкопрофильная сплит-клавиатура с очень маленьким количеством клавиш, если не ошибаюсь, у меня там только 48. И в ней у меня вначале были розовые свитчи. Их очень легко нажимать — буквально клал палец, и оно нажималось, надо было прям на дне держать. Я на ней очень быстро печатал, но так же много собирал мискликов. Особенно противные были первое время, когда я нажимал Enter и случайно отправлял сообщение, которое ещё не хотел отправлять. Это было противно.

[18:21] Илья: А сколько ты печатаешь, какая у тебя скорость сейчас?

[18:24] Александр: Я сотню выдаю на русском, а на английском, наверное, 90 — слов в минуту. Я не самый… Есть ребята в чатике моего канала, там вообще спортсмены, которые наваливают по 120, по 130, я не понимаю как. Но понимаю, что для такого результата надо инвестировать в это своё время, а я решил, что для меня 100 — с головой, и 90 на английском более чем достаточно, чтобы в работе чувствовать себя продуктивно и не отставать.

[18:56] Илья: Да. У тебя, конечно, сплит-клавиатура, ты так уже больше… А я на обычной механической: у меня там типа 60, и мне комфортно. Мискликов мало, поэтому я такой думаю-печатаю. Это, наверное, тоже индивидуально, но я хочу повысить хотя бы до 80–90, чтобы реально был толк. И раз мы заговорили про скорость печати от хардвера, от клавиатуры, — мы скоро, наверное, перейдём к слепой печати, я надеюсь.

[19:25] Александр: Soft skills. Есть ли ещё что-то из хард-вещей, которые нас окружают, что ты хотел бы про здоровье упомянуть, помимо монитора, посадки, клавиатуры?

[19:36] Илья: Наверное, самое важное скажу, потому что у меня очень сильно устают глаза во время работы за компом. Это какой-нибудь способ отвлекать себя от компьютера, чтобы раз в какое-то время поднимать свою задницу, походить, посмотреть в окошко, жизнь посмотреть. Как мне один человек сказал: «ты жизнь не видишь, в окно посмотри — и ты всё поймёшь». Я посмотрел в окно — и я всё понял. Реально очень полезно. Я для этого использую обычный кухонный таймер — техника «помодоро». Заводишь кухонный таймер на 30 минут: поработал — сделал перерывчик 10–15, 5 минут, кто как, у кого какая конфигурация. Я 30 минут работаю, 10 отдыхаю, и вот так чередую весь день, для меня это более чем достаточно. В эти 10 минут можно посмотреть в окошко, заварить кофеёк (я в гейзере варю), поприседать — что хочешь. Можно музыку послушать, потанцевать дома, если любите, — я иногда люблю, у меня настроение игривое бывает. Вот это, наверное, второе, что есть после монитора, — для глаз.

[20:46] Александр: Прикольно, что ты именно это в контексте глаз упоминаешь. У меня пока что вроде более-менее нормально с глазами, я вот эти перерывы и активность оправдывал больше как пользу для спины. Я сижу всё время, но даже в правильном положении иногда задница начинает уставать, спина упирается в спинку, поясница начинает как-то… Ну, в общем, да, я тоже встаю, пытаюсь посмотреть в окно. В этом плане мне нравится офис с большими панорамными окнами, чтобы был какой-то вид; у меня сейчас из квартиры классный вид, я прям залипаю. Но я бы ещё упомянул, что многим может зайти спорт — именно регулярный. Я как раз один из тех, кто каждый день ходит в зал, прям полюбил это дело. Если я понимаю, что компьютер не нужен, надо присутствовать просто в аудио, — я вставляю наушники и на дорожку, хожу, бегаю.

[21:56] Илья: Не, ну это ты, конечно, придумал, это прям лайфхак. Это очень круто. Я, наверное, возьму на вооружение, когда буду жить рядом со спортзалом. Я с другой стороны пошёл, тоже себе хобби придумал: люблю походить, пофоткать. Просто ходить гулять для меня полный тупизм, в этом никакого интереса не было. А потом подумал: я же снимал блог, у меня была камера — а что с ней ещё можно делать? Наверное, фотки. И просто начал ходить, всякие интересные моментики снимать. Это тоже помогло: иногда хочется просто выйти, пофоткать. Сейчас фоткаю на плёнку, но это как-нибудь отдельно расскажу. Ну, найдите себе хобби: ты нашёл спортзал, я нашёл плёночку, чтобы хотелось выйти, размяться.

[22:39] Александр: Да, у меня ещё было во времена студенчества — я, кстати, нигде на канале это не рассказывал. Я довольно активный был студент: со второго курса фулл-тайм работал программистом на Java. А математический факультет, где я учился, требует посещаемости — нельзя просто приходить раз в две недели на лекции. Я ходил почти на все лекции и на все практики, и очень много ходил: офис был минутах в 20–25 ходьбы, и у меня могло быть три-четыре ходки туда-обратно за день. И во время этой ходьбы я слушал подкасты. Когда ходишь и слушаешь подкаст или музыку — мне подкасты заходили просто супер. Именно поэтому с тех пор я задумал свой подкаст. Я тогда слушал всё, что возможно, про программирование: любой подкаст, который вы можете вспомнить пять лет назад, я весь прослушал. И это прикольно: ты ходишь, у тебя активность, мозг начинает более концентрированно информацию улавливать. Ну и аудиокниги ещё слушал.

[23:43] Илья: Классная тема. Почти все книги, которые я так или иначе могу сказать, что прочитал, на самом деле я их прослушал. Мне на слух намного лучше воспринимается, потому что когда я читаю книги, я просто засыпаю.

[23:54] Александр: Я тут добавлю коммент. Во-первых, про книги. Я тоже засыпал, когда читал, но нашёл лайфхак: начал читать вслух — и перестал засыпать. Вот это вот лайфхак, можешь попробовать. Зрители, если вы засыпаете во время книг, попробуйте почитать для себя вслух. А потом про аудиокниги и подкасты. У меня тоже был период, когда я ходил в офис, работал в компании, где было много студентов. Команды, где я прям конкретно работал в офисе над чем-то, у меня не было — приходил в основном пообщаться. И я тоже слушал подкасты, практически все джавовые, всё переваривал. Но недавно я такую вещь заметил — и потому скорее за хобби, как ты сказал, первый вариант: зал, бег, фотография, you name it. То, что отвлекает от мысленного процесса. Я читал книгу и за собой замечаю, что надо давать мозгу не думать. Книга называется «Думай медленно… решай быстро».

[25:01] Илья: Канеман, да-да-да.

[25:03] Александр: И всё вокруг неё, там довольно много литературы. И там как раз говорится: чтобы дать мозгу творчески подумать, надо ни о чём не думать. Надо какую-то информацию скушать и потом дать ей перевариться. Поэтому я бы слушал, если есть возможность, где-то в дороге подкасты, но иногда давал бы себе отдых, чтобы просто дать мозгам поварить. У меня такое бывает: иду в кофейню, беру с собой фотоаппарат — и хоба, идея какая-то пришла, я не знаю откуда. За кадром подтверждают, что ко мне иногда такие идеи приходят, когда я ни о чём не думаю. Какая-то дичь полная, но это реально работает: надо дать мозгам сделать своё дело.

[25:44] Илья: Да, это прикольно. По-моему, он там в контексте какого-то процесса, который где-то на фоне происходит, — подсознание.

[25:53] Александр: То есть что-то асинхронное. Индексы строятся, демон там.

[25:59] Илья: На самом деле, ты сейчас это проговорил, и я начал понимать, что часто себя на этой мысли ловлю, но не формулировал. Почему я это делаю? У меня очень много даже на работе — если не брать подкасты и блоги — в целом работа довольно творческая: я много пишу архитектуры, дизайны, решения. И там реально прям творчески нужно подумать крепко. И я иногда понимаю: вот я сейчас сяду и не напишу, не выдам из себя архитектурное решение — какие индексы, где что построить, какой процесс, в каком формате, какой протокол. Не идёт. Я сейчас пойду в зал схожу, в магазин, погуляю — и завтра ещё раз сяду со свежей головой. И у меня нет ощущения, что я прогуливаюсь и не работаю: я наоборот коплю энергию, коплю ману, и оно потом само выходит. На следующий день, даже через неделю.

[26:56] Александр: «Само выходит» — оп, сел ночью.

[27:00] Илья: Ночью нет, но на выходных частенько. Просто вдохновение — и выдаю за час то, что многие за неделю не могут. Просто потому, что в этом состоянии, не потока, а вот этого творческого наплыва, оно настолько быстро и качественно выходит, что даже ничего не надо делать: отдаёшь — и оно классно. Как говорят, хорошая мысля приходит опосля.

[27:24] Александр: Утро вечера мудренее.

[27:28] Илья: Утро вечера мудренее, да, из той же оперы.

[27:30] Александр: Ну давай тогда перейдём к более программистским вопросам. Я бы хотел перейти от клавиатур к софту, который будем обсуждать. Но есть кое-что необходимое, чтобы с помощью клавиатуры этим софтом пользоваться, — и это слепая печать, touch typing. Это когда вы печатаете и не смотрите на клавиатуру. Причём если вы печатаете не глядя, но вот этими тремя пальцами, — это не слепая печать, это печать, как её назвать…

[28:02] Илья: Доморощенная.

[28:05] Александр: Доморощенная, интуитивная печать — я бы так её назвал. А слепая печать — вполне понятный термин: у каждого пальца есть вполне определённые кнопки, и каждый палец на них нажимает. Пальцев 10, кнопок, очевидно, больше, и вы не только не смотрите на клавиатуру, но и пальцы нажимают на определённые кнопки. Например, на пробел очень часто нажимает левый и правый большой палец, а большинство тех, кто печатает интуитивно, жмут на пробел одним большим пальцем. Про слепую печать давай поговорим — у меня первый выпуск подкаста был про слепую печать, я тут ссылку ставлю, можете послушать, как оно было тогда. Что ты скажешь про слепую печать? Почему это, наверное, ты со мной согласишься, необходимый навык для программиста?

[28:49] Илья: У меня, на самом деле, есть видос, где я говорю, что это не самый важный навык для программиста. Для меня лично он очень важный, я считаю его необходимым. И начну с глаз. Я говорил про мониторы: что меня напрягает, когда два монитора, что надо на них перефокусироваться. У меня глаза быстро устают, я прям чувствую, что левый устал, правый устал. И с клавиатурой так же: когда ты смотришь на монитор, потом на клавиатуру, на монитор, на клавиатуру, каждый раз ты расфокусируешься. Это как челночный бег, потому что нормальное положение для глаз — смотреть вдаль, мы не созданы для того, чтобы смотреть на клавиатуру, читать, какие там буквы, искать. Это очень плохой способ. Когда у вас есть интуитивная печать, как ты её назвал, — это уже полбеды мы избежали. Но интуитивная печать всё равно заставляет смотреть на клавиатуру, потому что нет привычки держать пальцы на home row. У вас, наверное, на клавиатуре есть засечки — я не помню, на каких они буквах, по-моему, J и F.

[29:48] Александр: F, да. J и F.

[29:50] Илья: Скорее всего, там есть засечки. И если вы не пользуетесь слепой печатью, вы на них не обращаете внимания — может, знаете, что ими можно нащупать позицию, но не делаете этого. Я всё равно помню, как руки должны стоять, но иногда всё равно смотришь на клавиатуру, и это минус, потому что не фокусируешься. И вот этот челночный бег от монитора на клавиатуру на короткое расстояние — перефокусировка — это то, что прям напрягает глаза. Именно поэтому я обратно вернулся на слепую печать, потому что меня бесило елозить глазами. А с ними надо поаккуратнее.

[30:23] Александр: Получается, клавиатура, где руки, — это одно фокусное расстояние, одна поверхность, в которой глаза фокусируются. Монитор — уже другое фокусное расстояние, и оно меняется. Мышцы глаз одинаковым это не сделают, потому что они фокусируются в разных местах, на разном расстоянии, и им приходится корректировать фокус — это уже нагрузка. Если это происходит 8, 10, не знаю, я иногда 14 часов могу днём сидеть…

[30:56] Илья: Прайм-тайм.

[30:57] Александр: …и очевидно, что это уж точно не полезно, а скорее вредно. Поэтому даже с точки зрения глаз слепая печать — уже плюс. С какой ещё точки зрения плюс? Ну, можно быстрее коллегам наваливать текст.

[31:11] Илья: Да. Мне это очень нравится, потому что я вообще считаю, что общение не на встречах намного более продуктивно. Оно становится конструктивным, появляются ссылки, пруфы, это всё можно отследить и вынести в документацию. В этом плане я не люблю встречи, если никто их не суммирует. Сейчас, наверное, нейросети умеют суммировать встречи, но я этим не пользовался. Я люблю, когда составляются какие-то фоллоуапчики, а ещё лучше — когда мы обсуждаем что-то в треде, потому что история остаётся.

[31:40] Александр: Ну, иногда это всё равно происходит неконструктивно: любой тред, даже текстовый, можно свернуть в неконструктив, если нет желания вести его конструктивно.

[31:48] Илья: Это правда. Я тоже за собой начал замечать: когда уже начал бегло и на русском, и на английском печатать, не глядя на клавиатуру, — сам барьер для того, чтобы написать и выразить мысль понятно, уменьшается. И поэтому я чаще пишу более развёрнутые ответы, описания. Просто потому что вот я сейчас как говорю — так же у меня и текст льётся, никакой проблемы. А когда тебе нужно что-то долго печатать, ты на подсознании меньше отвечаешь, лишний раз писать не будешь: ну зачем, и так вроде всё понятно. И от этого страдает рабочая коммуникация.

[32:23] Александр: Мне кажется, это правда. И письменная коммуникация уж точно не хуже вербальной в плане обсуждения чего-то. Но, знаешь, иногда в письменной коммуникации участвуют как минимум два человека: ты-то можешь хорошо в ней быть, а другой человек может этого не уметь, и тогда она всё равно страдает. А вербальная — ну, говорить все умеют с детства, поэтому разговором иногда вещи решаются быстрее и эффективнее. Я замечаю: созвонились, и если реально нужно что-то решить, то решение по-любому быстрее будет.

[32:59] Илья: Ну, не факт, что оно будет оптимальнее.

[33:01] Александр: Не факт, что оптимальным. Но понимаешь…

[33:04] Илья: Не всегда нужно оптимальное решение. Иногда нужно просто решение, и побыстрее.

[33:09] Александр: Ещё вчера.

[33:12] Илья: Да-да-да. Так что я тут не адвокатирую за созвоны, но на практике так получается, что с людьми мне чаще быстрее скинуть ссылку на созвон, договориться, а потом, если понимаю задним умом, что мы важное обсудили, — запечатлеть это, задокументировать. Я уже в Readme, в devnotes, где-то в комментариях к коду описываю.

[33:37] Александр: Постфактум.

[33:37] Илья: Да, постфактум. Но печатать без проблем и быстро — это ещё один плюс.

[33:47] Александр: Следующий плюс могу сказать. Ты начинаешь понимать, где какие клавиши находятся, и начинаешь хотеть этим пользоваться. Например, ты знаешь, где у тебя буковка S, и палец её помнит. Но тебе надо нажимать Command-S, чтобы сохранить, надо придумывать новую комбинацию, которую ты будешь нажимать. Это не очень привычно, потому что на всяких тренажёрах мы не тренируем Command-S, Command-Shift-F5 и подобные штуки. И тут приходит желание какого-нибудь инструмента, который можно настроить так, чтобы ты нажимал на любую клавишу, а она делала то, как тебе удобно, — и желательно, чтобы это было заточено под слепую печать.

[34:33] Александр: Давай сейчас для тех, кто смотрит и не отключил видео, — им, думаю, интересно. Пока мы плавненько по ступенькам куда-то идём (в конце узнаете, куда придём): какие тренажёры ты считаешь полезными для изучения слепой печати? Вот я хочу сейчас изучить слепую печать — куда мне идти?

[35:03] Илья: Я изучал слепую печать в приложении KeyKey. Оно дорогое, 5000 рублей в App Store, — не надо его покупать, скорее всего. Ну, если хотите попечатать в красивом интерфейсе, в стиле Apple, то окей, можете. Я купил, потому что понимал: раз купил, мне будет жалко денег, и я буду сидеть и тренироваться. Это как дополнительная мотивация. Но я знаю, есть бесплатные сайты, их куча, — есть какой-то Delta клавотренажёр. Главное, чтобы на экранчике показывалось, где находятся клавиши, — это будет полезно первое время как тренажёр. А как практика, самый лучший вариант, по-моему, MonkeyType — это сейчас вне конкуренции. Он красивый, удобный, теги в нём есть — короче, в нём есть всё, чтобы оттачивать мастерство скоростного набора.

[35:49] Александр: Плюсую MonkeyType. Когда уже умеешь печатать, сидишь на митинге, такой: «есть пять минут, погружаться не хочется» — и за эти пять минут несколько сессий можно попечатать.

[36:01] Илья: Класс, и заодно скорость проверить. MonkeyType.

[36:03] Александр: Если бы я отвечал на собственный вопрос, какой сайт, — мне понравился Typing Club, ссылочки будут, и есть ещё парочку. В общем, это легко гуглится, можно найти под себя. Все они плюс-минус одинаковые и работают. Единственное — некоторые не делают акцент на изучении важных для программирования клавиш, таких как открывающая, закрывающая скобка. Как раз вот этот мизинец страдает, и у меня до сих пор он страдает. Как от этого избавиться, можем поговорить попозже. Давай теперь обсудим, что для тебя является не проблемой, а каким-то недостатком стандартной раскладки — например, в редакторе IntelliJ IDEA. Какие комбинации клавиш тебе кажутся неправильными?

[36:56] Илья: Если ты не владеешь слепой печатью, то ты не сможешь сесть за сплит, потому что сплит абсолютно ломает твоё взаимодействие: раскладка там, скорее всего, не будет как-то нарисована. Например, на мой сплит не помещаются все клавиши, и там всё равно надо запоминать. Поэтому без слепой печати в сплит, скорее всего, ничего не получится сделать — будешь как котёнок тыкаться и ничего не поймёшь. Это тоже пререквизит.

[37:21] Александр: Необходимое условие, да-да-да.

[37:24] Илья: А про среды разработки: мне не нравится, например, в IntelliJ IDEA, что там слишком много всего настроено за меня. Вот как мы обсуждали за кадром — что ты знал какую-то функциональность, но не знал, на какую она клавишу, как она называется вообще, не мог её найти, поэтому пришлось обращаться к человеку, который шарит. Так вот, мне это и не нравится: я знаю, что там есть шорткаты практически на всё, можно сделать шорткат на что угодно, но ты этого не знаешь, и нет, например, in-depth-туториалов, ты не знаешь, почему это работает. Когда я запускаю Gradle через какое-нибудь Command-Command, я не знаю, как это работает под капотом — Gradle может вызываться, может не вызываться. Ты не знаешь, как отрабатывает тот же рефакторинг — вытаскивание переменной, вытаскивание метода: у IntelliJ IDEA своя реализация, и она остаётся под капотом. Например, в одном из твоих подкастов про IntelliJ IDEA было, что им надо всю интеграцию с тем же Gradle перереализовать, там много дублирования функциональности Gradle, чтобы IDEA это поддерживала. И чтобы подсвечивать ошибки компиляции — вряд ли они переиспользуют компилятор, это моя гипотеза; скорее всего, делают свой компилятор Java, который проверяет валидность кода. То есть всё это дублирование работы компилятора. И, по-моему, было бы более явно, если бы я настроил себе только то, что мне нужно для работы. Если я сам это всё настраивал, я знаю, как это работает, что мой инструмент умеет, куда пойти посмотреть. И не будет вот этого перегруженного API, перегруженного клавишами — в IDEA какие-нибудь сочетания из пяти, из четырёх кнопок. В VS Code это делается иначе: например, Command-K, а потом какая-нибудь другая комбинация. Аккорды комбинаций — это вообще, по-моему, какой-то прикол.

[38:59] Александр: Знаешь, к чему я хотел подвести вопрос про комбинации — к тому, что они задействуют неочевидные пальцы. Когда мы говорим про правильное нажатие правильными пальцами правильных кнопок: Command — ещё куда ни шло, Command задействует большой палец. Большой палец самый подвижный, в нём мышца самая большая, и хорошо, что хотя бы он там задействован — Command, окей. А остальное задействует Control, Shift, Option — это всё безымянные пальцы и мизинец. Мизинец бедный, его лучше не трогать, а ему столько места, столько клавиш выделяется. И ладно бы их иногда нажимал, но когда это комбинация, которую ты постоянно жмёшь…

[40:08] Илья: Ты программист.

[40:09] Александр: Да, когда ты программист, когда тебе нужно быстро перезапускать тесты, что-то искать, Shift-Shift тот же нажимать, чтобы команду запустить, — мизинец такой: «ну зачем ты меня используешь?». Мне кажется, мало кто в целом об этом задумывается — что часто используются пальцы, которые эволюционно не предназначены для такой работы. И это, мне кажется, основная причина использовать что-то другое или переделывать маппинг клавиатуры. Потому что, ребят, если вы реально много программируете, много сидите за компьютером, печатаете, это начинает чувствоваться. Это не возраст, это ничто, это просто…

[40:53] Илья: Ну, справедливости ради, я думаю, есть кто-то, кто говорит: «мне и так нормально». Напишите в комментах, если вам и так нормально.

[40:59] Александр: Ну да, если вы сидите за компьютером по 8, 10, 12 часов пять дней в неделю, и у вас всё окей на протяжении пяти лет, — я вам завидую, честно.

[41:10] Илья: Титаны.

[41:11] Александр: А вот на протяжении 10 лет давайте перекличку в комментах встроим.

[41:14] Илья: А этих людей уже нет, они не смогут написать комментарий.

[41:16] Александр: Они не смогут напечатать.

[41:18] Илья: Они осилят.

[41:20] Александр: Да. Но про мизинец ещё прикольно, с этим Emacs’ом… Блин, я так перешёл — короче, про редакторы кода, наверное, можно уже начать говорить. Первый мой не-IntelliJ IDEA… Естественно, я познакомился и работал 7 лет в IntelliJ IDEA и думал, что это… Ну, сейчас я думаю, что это хороший инструмент для Java-разработки, а на какой-то момент в жизни это был лучший инструмент для меня — потому что я других не знал, скажем так. Я решил познакомиться с Emacs. Меня вдохновил на Emacs, если ты знаешь, такой подкаст — «Мысли и методы».

[41:57] Илья: Я слышал про такой, да.

[41:58] Александр: И там ведущий даже сделал отдельную веточку про Emacs на YouTube. Я это всё, конечно, послушал, и это меня вдохновило — всегда интересно, когда умный, эрудированный, увлечённый человек про это рассказывает: ты как-то загораешься и начинаешь тоже пробовать. Я поставил себе Emacs на Mac, настроил там что-то, и сразу увидел: там Control — это лидер-кей, постоянный Control, если вы понимаете. А Control — это вообще… Ладно, я его на Caps Lock перемапил, хоть что-то, но всё равно это типа мизинец. И я понажимал буквально два дня этот Control и просто офигел, насколько это неудобно, насколько криво. Есть даже всякие мемы — не знаю, найду ли я картинку с пользователем Emacs вот с таким мизинцем. Короче, естественно, это всё можно перемапить. Я себе перемапил на Vim-байндинги — называется Evil Mode в Emacs. Стало сильно лучше, я такой: «вау, насколько это удобнее». А потом думаю: а зачем мне тогда вообще Emacs, если я использую Vim-овские байндинги? Может, сразу на Vim посмотреть. Ещё, если вы не знаете, блогер The Primeagen отличный — постоянно про этот Vim говорит, — и я таки перешёл на него. Но про это я как-нибудь расскажу потом, про свой переход. А вот давай про тебя поговорим. Ты, я так понимаю, тоже в NeoVim программируешь?

[43:21] Илья: Да, да.

[43:21] Александр: Фулл-тайм?

[43:22] Илья: Да.

[43:22] Александр: Расскажи, как ты к нему перешёл, как был твой процесс, — потому что я думаю, ты вначале на IDEA программировал.

[43:29] Илья: Ну, смотри, я начну издалека, с универа. В универе моя любимая среда разработки на первом курсе — это был Qt Creator, потому что я любил C++ и Qt Framework, может, ты знаешь, что это. Я в нём писал, меня всё устраивало. Потом, когда перешёл в Java (это был третий курс, я пошёл на курсы, устроился), пробовал ту же IDEA и такой: «воу, можно было что ли? Так много всего уметь». Где-то там я ещё пробовал Vim, но это было на уровне: я знаю, что буду иногда заходить на сервер и менять конфиги. Nano — как-то позорно перед пацанами Nano запускать. Я такой: я буду Vim запускать. Почитал про это, зашёл, научился из него выходить, осознал себя в Vim.

[44:20] Александр: Пишите в комментариях, как вы выходите из Vim, сколько способов выхода из Vim вы знаете. Пишите, все пересчитаем. И тому, кто напишет больше всего способов, мы скинем ссылку — не знаю, как перейти на другую среду разработки, потому что так изучать Vim надо уметь. А пока мы не погрузились полностью, скажу, что я тоже был озабочен этой проблемой — что где-то на сервер нужно через SSH зайти и что-то поменять. Как я себя некомфортно, помню, чувствовал, когда захожу в Vim и такой… вот по одной там вниз. Сейчас сервак повалится, а я что-то сломаю, сейчас как-то rm -rf запущу. Сейчас надо сохранить. А если ещё откроешь файл, который другим процессом открыт, он тебе вопрос выдаёт про swap — ой-ой-ой, это синий экран смерти походу, закрываем терминал, перезаходим. И я тогда смотрел много YouTube, и там, по-моему, Виктор Гамов, ну какой-то из девелопер-адвокатов, говорил: есть такой редактор кода, терминальный, написан на Go, называется micro. И я такой: «вау, там можно мышкой тыкать» — условно VS Code в терминале, там нативные операционной системе хоткеи: Command-стрелочка, ты по словам прыгаешь, более-менее норм. И сразу подсветка синтаксиса из коробки. Вот я этот micro себе на все серваки поставил — ну, на два, какие были, — и у себя локально, и как-то этим пользовался. Потом думаю: что я на какие-то серваки micro ставлю, у него никакого конфига нет, как-то странно, — и перестал его использовать, старался вообще не трогать файлы на серваке. Дать это админам, они умеют пользоваться каким-то текстом. Ну, это до поры до времени, пока не начинаешь свои проекты делать, а там по-любому придётся зайти по SSH, докер запустить, что-то поменять, поэкспериментировать. По мне, так это необходимо с какого-то момента уж точно. Ну давай про тебя. Ты начал потихоньку изучать его, я так понимаю?

[45:15] Илья: Я буквально изучил: мог зайти на какие-нибудь серверы и что-то изменить, иногда мне это пригождалось — не скажу, что часто, но пригождалось. Особенно вот я с Raspberry Pi баловался, там приходилось заходить, было суперудобно. Потом я плотно сидел на IDEA, ничего не знал, пока не вышел Kotlin, и мне перестало нравиться то, куда идёт JetBrains, как они свои продукты позиционируют. Но это отдельный разговор. Я решил слезть на VS Code — это было года четыре назад, или три. Плотно попробовал слазить, но думал, что это шило на мыло: я сидел и как будто вообще ничего не меняю, мне надо к чему-то перепривыкать, а оно вроде даже и не лучше, то же самое, только на Electron. Короче, сомнения меня терзали.

[46:27] Александр: Да-да-да. Теорема Эскобара.

[46:29] Илья: Так что я решил сделать? Решил пойти в Vim. Думаю: наверное, в Vim что-то поменялось. Ты, если делаешь для VS Code LSP (если кто не знает, это серверы, которые поднимаются рядом с вашим текстовым редактором и добавляют функциональность всяких ренеймов, переходов к определениям, умную работу с кодом), — я подумал: ну не зря же Microsoft это заопенсорсил, дал людям. Наверное, теперь что-то такое есть и для Vim появилось. И реально для Vim появились расширения, а потом я узнал, что есть такая штука, как NeoVim, и начал во всё это погружаться. Я это где-то с год настраивал. Параллельно, если вы используете какую-нибудь среду разработки — IDEA или VS Code, — там есть режимы Vim, которые вы можете себе настроить, может, позже это обсудим. Я параллельно с настраиванием IDEA под себя через IdeaVim начал прокачивать NeoVim, собирать себе конфиг, потому что сразу понял, что пойду в NeoVim: он более коммунальный, общественный, там все могут контрибьютить, вокруг него крутое комьюнити. Мне понравился TJ, который снимает видосы, — он такой добряк, прям понравилось, как он там Telescope сделал. Меня зацепила эта открытость, и то, что Lua — это прям настоящий язык программирования. Потому что, например, в NeoVim вы пишете плагины на языке Lua, и вам для этого достаточно создать один файлик, не надо учиться писать плагины: буквально один файлик, открываешь доку в Vim — и можешь писать плагины за полчаса.

[49:01] Александр: А давай для тех, кто первый раз услышал такое словосочетание, как NeoVim, — как бы ты объяснил, что это такое?

[49:12] Илья: Ну, NeoVim в сравнении с Vim или в целом?

[49:16] Александр: Вообще.

[49:16] Илья: NeoVim — это терминальный текстовый редактор, модальный. Вот это важное добавление.

[49:24] Александр: Для меня это ключевой момент — что он модальный. В IDEA мы всегда в одном моде: печатаем текст и навигируемся. Чтобы куда-то перейти, мы либо стрелочками, либо умные ребята делают Command-стрелочки, Option-стрелочки, чтобы через слово перепрыгивать. Кто-то, наверное, использует IDEA-шные шорткаты, чтобы прыгнуть через метод, — я, честно, таких уже не помню, но наверное есть. В общем, кто как навигируется. Кто-то быстро ставит тачпад под клавиатуру, чтобы подвинуть и перейти. А Vim позволяет сделать иначе: ты навигируешься клавиатурой, ты всё делаешь клавиатурой, просто есть несколько режимов. В одном режиме я навигируюсь и ввожу команды, делаю какую-то мета-обработку, — так называемый Normal, Normal-мод. Есть мод Insert — это когда я просто ввожу текст, и там есть дополнительные нажатия, например Ctrl-W, удалить предыдущее слово, и так далее; они популярны даже в других текстовых редакторах. Есть мод поиска, есть мод команд, есть мод операторов — то есть там куча разных модов. И это всё позволяет работать только на клавиатуре, частенько настраивая её так, как тебе удобно. То есть это позволяет настроить среду разработки под себя, а не самому под неё подстраиваться. Вот это мне тоже не очень нравится в IDEA. И знаешь, про моды: я, кстати, до того, как начал это осмыслять — а давно знал, что такое Vim, что там есть моды, — думал: что это вообще, зачем? Normal — вы просто портите жизнь людям, пользовательский опыт, надо переключаться, что это такое? А вот когда есть базовое владение слепой печатью — вот эти рисочки, сосочки, которые постоянно трогают пальцы, лежащие на home row (среднее, где K, J, F, A), — вот аналогия. Чтобы напечатать, мы задействуем эти клавиши: тык-тык-тык-тык, всё удобно, руки никуда не двигаются. А чтобы навигироваться, эти клавиши уже не подходят, если у тебя нет модальности. Эти удобные клавиши предназначены только для введения текста. Для навигации, если хотите клавиатуру, — там Command, Control, стрелочки; представьте, вы за стрелочкой куда потянетесь — это уже искривление.

[51:49] Илья: Я стрелочками тоже не пользуюсь.

[51:51] Александр: То есть навигация и ввод — эти два основных режима не разделены, и поэтому приходится делать разделение на уровне клавиш. А так как всё основное удобное пространство отведено под печать, под навигацию остаётся неудобное. А в чём прикол модальности? В том, что и в том, и в другом моде эти удобные клавиши используются по делу. Ты печатал, печатал, потом перешёл в режим Normal — и эти же клавиши используются для навигации: K, J, H. Я их очень часто вижу у себя, когда путаю моды.

[52:29] Илья: Ну, то есть это… Ребят, потом всё расскажу — у меня будет целый плейлист про Vim, про NeoVim, как это всё работает; я сам учу и буду этим делиться. Так что если это не вырезано и вы это слушаете — значит, плейлист уже есть, переходите по ссылочке. В общем, да, в этом суть модов: задействуются самые удобные клавиши, на которых руки всегда лежат, и для навигации, и для поиска, и для всего-всего.

[52:55] Александр: Лучше и не скажешь. Ты прям выдал настоящую базу про то, что мы переиспользуем навык эффективности, который у нас есть. Это прям суперудобно. Я бы к этому ещё добавил, что Vim на самом деле продуман — если им пользуешься, он продуман до мелочей. В нём есть Unix-философия: он построен вокруг того, что мы можем какие-то блоки использовать, чтобы делать новые блоки. Например, пользуемся IDEA — и у нас будут разные диалоги, чтобы искать файлы, какой-нибудь structured search, это всё разные диалоги. А в Vim есть отдельный специальный диалог, который сделан для любого сохранения списка мест, — это quickfix list, ещё есть location list. Есть понятный UX, и он переиспользуется кучей плагинов: плагины не пытаются городить что-то своё, они переиспользуют существующий UX, который вмещается в философию home row, то есть одной только клавиатуры. Мне это очень нравится, потому что в IDEA и во всех UI-ных штуках ты как будто новое приложение заново учишь. А когда я ставлю какой-нибудь плагин, я знаю, что у него будет какая-нибудь команда, скорее всего какие-нибудь маппинги — это уже термины Vim. У него будут стандартные инструменты UX, которые есть у Vim, и это суперудобно: я сразу понимаю, как их переиспользовать, команду можно запайплайнить, можно перемапить. А в остальных средах разработки я могу получать только то, что мне уже подготовили разработчики, я не могу сам что-нибудь подхачить. И, если развивать тему, в Vim я сделал доморощенную штуку для заметок: сижу, делаю заметки в Vim, и это суперудобно, потому что я написал код — и мне надо что-то записать: нажимаю две клавиши, и я уже в заметках. Могу открыть их рядышком и писать заметки и код одновременно.

[54:45] Илья: Это классно. Ты сделал плагин для Obsidian, по-моему?

[54:47] Александр: Ну, я сделал плагин, который Obsidian-like — там похожая функциональность. Он под меня довольно сильно подогнан, поэтому вы можете попользоваться, но, скорее всего, чего-то вам будет не хватать. Недавно вот сказали про один баг, который я не заметил, потому что просто им так не пользовался. Он подогнан под меня, но показывает всю ту мощь, которую можно сделать. Я буквально сделал это, пока болел: ездил в поездку, заболел болезнью одной очень интересной, просто сел и за несколько дней навалял первый драфт. Пользовался им, наверное, несколько месяцев, только потом уже сел: «так, ладно, надо дореализовать». И это всё было возможно только потому, что у Vim есть какой-то уточнённый UX. У него есть quickfix-листы, которые я использовал, чтобы перечислять бэклинки; я использовал Telescope в Vim, который все используют, чтобы искать что-то. То есть есть общепринятые методы что-то делать, и я ими просто воспользовался, подсунув туда свои данные. Это было супербыстро, суперудобно, и всё это делалось на Lua. Короче, мне очень понравилось.

[55:52] Илья: Да, мне ещё знаешь, что понравилось? Что ты сравнил это с Unix-философией. Для тех, кто, возможно, не понимает, о чём речь: Unix-философия такая, что каждая команда — cat, less, grep, любая, которую вы вводите, — делает одну вещь и делает её хорошо. И суть в том, что для того, чтобы сделать какую-то сложную вещь, которой ещё нет (нет такой команды, которая делает эту вещь), — ты можешь эти команды спайпать, скомбинировать: аутпут одной команды передать в инпут другой, и так из кубиков собрать то, что тебе нужно. И так как они все друг друга понимают, они друг с другом соединяются. В Vim, в NeoVim суть такая же: плагины и философия в целом сделаны так, что один плагин может быть скомпонован с другим и с третьим, и это на уровне дизайна — там ничего специально под это делать не нужно. И для меня лично это ещё пример того, как надо писать софт, как его надо продумывать архитектурно, — когда софт становится чем-то большим, чем просто программа.

[57:08] Александр: Фреймворком.

[57:11] Илья: Я бы даже, знаешь, как назвал — ну не произведением искусства, но чем-то близким в инженерном плане. Какое-то законченное решение, которое само по себе уже хорошее.

[57:22] Александр: Но его можно сделать лучше своими переосмыслениями.

[57:25] Илья: Да, ты можешь его поменять, если хочешь, и тебе не нужно внутрь залезать. Это как раз архитектура, open-closed принцип — он не только на уровне классов, он и на уровне софта всего. И это отличный пример. И в целом, пользуясь такой вещью, мне кажется, сам твой код и продукты, которые ты пишешь, становятся более дематичными, более продуманными — там не будет лишних вещей. Мне кажется, в целом довольно полезно с такими инструментами быть хотя бы знакомым.

[57:54] Александр: Ну да, знакомым точно. Я не говорю, что всем будет полезно садиться на Vim и писать в Vim. Скорее всего, если вы просто работаете, для вас программирование — хорошее хобби зарабатывания денег, но вы не фанатеете от программирования (для вас это хобби на уровне «я люблю пообщаться с программистами и иногда что-нибудь пописать, но не считаю, что должен сидеть 12 часов дома за компом и вкалывать»), — если вы не такой человек, а цели у вас более прагматичные, то, скорее всего, вам не надо Vim, вам удобнее какой-то готовый инструмент. Разве что вы захотите прокачаться и для общего развития, для понимания Unix, поучить Vim. Потому что он, например, при комбинации команд в Unix, как ты сказал, умеет из коробки взаимодействовать с текстом, который у тебя редактируется, как с текстом, который можно передать другим командам. В Vim есть, я упоминал, командный мод, и там куча разных команд — по сортировке строк, по переходу к определениям функций и так далее. Команд, на самом деле, куча понаписана сторонних, зависит от того, какой у вас набор плагинов. Но суть в том, что команды могут взаимодействовать с текстом, который я выделил. Например, если я выделил текст и нажал Command-восклицательный знак…

[59:07] Александр: …то это будет значить, что я текст, который выделил, закину в башевскую команду, которую вызову. То есть я могу использовать, например, wc, чтобы считать строки, или у меня есть какой-нибудь скрипт, который считает цикломатическую сложность кода. И чтобы использовать его в Vim, я просто выделяю все эти строчки и вызываю команду с этим bash-скриптом — и оно передаст ему это на вход. Для этого не надо ставить никакие плагины, это прям built-in в Vim, его можно комбинировать с любыми утилитами, которые есть в баше. У меня, например, есть утилиты, которые считают количество строк кода, которые что-то удаляют, сканируют какие-то файлы. Опять же, у того же Primeagen, о котором ты упоминал, есть видос «почему я люблю Vim», где он берёт и просто комбинирует команды именно с башем. Я, честно, даже не вспомню — там такая магия, я никогда такого не делал, но ты можешь скомбинировать Vim и bash вместе, команды Vim с башем, и это будет работать без каких-либо плагинов, и это всё расширяемо.

[1:00:15] Илья: Расширяемо и командами, и самим Vim с помощью его плагинов, наверное, так. Ну и в Vim куча разных полезных вещей, которые в IDEA есть, но не так нативно смотрятся. Например, какие-нибудь операции к большой части файла — выделить что-то в функцию: в IDEA ты должен либо стрелочку куда-то ставить, стрелочками переходить, потом зажимать Shift, выделять текст и нажимать Command-Shift-M, чтобы выделить метод, какая-то такая комбинация. А в Vim ты просто нажимаешь Shift-V и нажимаешь, сколько строк тебе надо: цифру и букву — вверх это k, вниз j, — и команду, которая у тебя для выделения строк. То есть ты вообще не двигаешь мышкой, ты просто берёшь и используешь его, не отходя от кассы. Ещё можно, если ты на открывающей или закрывающей скобке, перейти сразу на парную скобку — в Vim это процент. Это встроено в Vim, а в NeoVim можно взять, настроить. Во-первых, есть плагин treesitter, он позволяет делать выделения автоматически: выделить функцию, выделить класс, выделить блок кода, выделить if, выделить else — там бесконечно можно себя настроить, это всё поддерживается синтаксическим парсером. Это суперудобно, и ты можешь настроить это под себя. И прикол в том, что тебе не надо будет смотреть какие-то видосы с лайфхаками, как что-то делать в IDEA — я не видел прям исчерпывающих учебников, курсов. А в Vim ты просто открываешь awesome-лист по плагинам, и каждый плагин делает конкретную вещь и делает её хорошо, как в Unix-философии. Открыв его, почитав документацию — она обычно небольшая, — ты узнаешь всё, что можешь сделать, например, с анализом синтаксиса, с treesitter, и настроишь только то, что тебе нужно. И это будет в твоих конфигах, ты всегда сможешь вернуться и узнать, что же там на самом деле настроено, чтобы это заново переиспользовать. Потому что у меня, например, есть проблема, что некоторые вещи использую редко: я редко прыгаю от метода к методу и иногда забываю маппинг, — обычно пользуюсь просто прыжками по количеству строчек. И я просто открываю конфиг своего treesitter и смотрю настройки. Мне не надо помнить, где там это в IDEA, в какой-то папочке находится: у меня всё соответствует моим ментальным моделям, полностью их отражает, поэтому я быстро нахожу и ориентируюсь.

[1:02:50] Александр: Да, и ещё знаешь, что прикольно, чего стандартные текстовые редакторы точно не могут предоставить, — это то, что свои конфиги, так называемые dotfiles, ну или в целом конфигурацию (просто набор файлов, как и любая другая программа), ты можешь закинуть в git, как большинство людей делают. То есть у тебя есть версионирование: ты такой «так, у меня неделю назад работало, а я потом поковырял, поменял, оно сломалось» — классическая история.

[1:03:21] Илья: Никогда не начал спрашивать человека: «а как у тебя сейчас, конфиг в порядке?» — «да нет, там вот это не работает, я в каком-то промежуточном состоянии». Мне понравилась аналогия, кстати, когда автор «Мыслей и методов» говорил, что это как иметь свой гараж: в нём постоянно что-то происходит, нет идеального состояния гаража, он всегда где-то там…

[1:03:39] Александр: Творческий беспорядок.

[1:03:41] Илья: Да, творческий беспорядок. И git позволяет хотя бы немножко в этом ориентироваться.

[1:03:45] Александр: И что более крутое — этот репозиторий можно на сервачок зайти по SSH, склонировать, и у тебя там твоя IDEA. Вот как она есть, твоя интегрированная среда разработки на сервере: всё, оно такое же, все те же маппинги, тот же терминал. Мне кажется, это настолько удобно и классно, что пока ты это не попробуешь, ты даже не можешь оценить.

[1:04:15] Илья: Это круто, но я это никогда не использовал, полный Vim на сервере не разворачивал.

[1:04:20] Александр: Полный — нет, но хотя бы байндинги, чтобы быстро прыгать и ориентироваться, маппинги можно туда закинуть, если это твой сервер. Я намного более продуктивен в Vim. Я даже в обычном Vim могу зайти и программировать в нём — без NeoVim, без всех моих наворотов, — потому что ориентируюсь; например, в Python могу написать скрипт, который делает базовую автоматизацию. Мне для этого не обязательно автокомплиты, ничего не надо. Я спокойно захожу на серверы, в голом Vim пишу код, и это работает, потому что ты знаешь, что в Vim есть встроенное автодополнение — для этого не надо плагинов, и понимаешь, как оно работает. И можно башевскую команду на крайняк запустить, удобно запустить тесты для этого скрипта, опять же через баш. Если ты умеешь работать в баше, для тебя Vim — как дом родной.

[1:05:13] Илья: Я, кстати, не очень хорошо умею работать в баше. Никак не ложится мне эта концепция и синтаксис. Надо, наверное, инвестировать в это время. Я не баш-гуру: я читал какие-то книги, но для меня баш-гуру — это человек, который может написать на баше умный скрипт. Я, честно, не помню, как if-ы пишутся в баше, я их гуглю.

[1:05:37] Александр: Но для меня вполне естественно понимать философию: что такое пайплайны, что такое stdin, stdout, stderr, как их перенаправить, что такое tee, как сделать цепочку из команд, и знать какие-то основные команды — find, ls, ripgrep, если вы используете, или ast-grep, мне очень нравится. То есть найти какие-то свои утилиты, которые вы используете, и применять их в рабочих буднях. Тот же git, чтобы понимать, как он работает, как его философия устроена, — это суперполезно.

[1:06:06] Илья: Да-да. Я бы тут вставил такой дисклеймер — хотя, наверное, его можно было бы в начале ставить, но удобно сейчас, когда мы уже много про Vim говорим. Почему-то у большинства людей, у программистов, когда ты начинаешь затрагивать тему Vim, байндингов, показывать, как это прикольно (ну и когда тебя, конечно, попросили — «хочешь я тебе немножко…»)…

[1:06:34] Александр: Это как-то «I use Arch, by the way».

[1:06:36] Илья: Нет, типа, что-то показываешь, человек спрашивает: «а как ты это сделал?» — «да я в Vim это делаю». И это часто вызывает какое-то отторжение у той стороны: «ну это вообще задротство какое-то лютое, красноглазик какой-то, это не для меня, я лучше в IDEA буду сидеть». И я пытался это осмыслить, почему. У меня, наверное, в начале карьеры что-то подобное возникало внутри: «что это вообще, зачем? Есть же IDEA». Наверное, защитная реакция психики, чтобы оправдать для себя, почему тебе это не нужно. Ты говоришь: «ну есть же более современные…».

[1:07:18] Александр: «Там умные люди всё продумали».

[1:07:20] Илья: Да, как будто, если более современное, то оно лучше. То есть здесь нет никакой причинно-следственной связи.

[1:07:26] Александр: Это просто другой софт.

[1:07:28] Илья: Вот. И как будто оправдываешь: есть IDEA, там всё можно настроить, есть VS Code, плагины. А Vim — это уже деды сидят.

[1:07:38] Александр: Которые не смогли выйти.

[1:07:39] Илья: Да. Я недавно у тебя на канале видел комментарий про Vim — там что-то чувак написал, что современный вот этот надо изучать, а эти деды сидят и не могут выйти. Блин, это настолько интересно, как одна и та же… как противоположные стороны могут одинаково друг другу теми же аргументами доказывать. Он говорил, что те, кто сидят в Vim, эти старички, не способны изучить что-то новое и не могут перейти на IDEA. Я такой: ладно. Они как-то изучили Vim — уже ресурсы исчерпаны, застряли и не могут выйти, а новички, которые на них смотрят, думают, что это круто, и начинают всем рассказывать, что это круто. Я помню такой коммент. А я такой: да ты вообще наоборот. Те, кто не хотят Vim изучить — ну, кто не делают этого, — мне кажется, им просто не хватает времени, потому что порог входа действительно высокий: это что-то новое, это нужно изучить, в это нужно инвестировать. Как раз наоборот. И почему я всё это начал говорить: люди это как-то слишком близко к сердцу берут. Вообще пофигу, на чём вы пишете: если вы используете IDEA, если вы используете Notepad, это сугубо ваше решение, никакого противопоставления нет. Так что, ребят, если вы это используете — пожалуйста; тем, кому интересно, кто досмотрел до этого момента, давайте про это поговорим. Я к тому, что если вы хотите написать комментарий «а в IDEA можно вот так» — ребят, я знаю. Я 7 лет на IDEA пишу, не надо это писать.

[1:09:21] Александр: Мне, кстати, в комментах тоже часто писали: «вот ты рассказываешь, что нажимаешь gd и переходишь, а в IDEA можно Command какой-то нажать». Я уже не писал, что я знаю. Я на IDEA долго сидел, я был тем челом, у которого IDEA была офигенно настроена: синхронизировались все настройки. Если я Vim настроил, вы можете представить, сколько я себе IDEA настраивал. Я настраивал Vim, потому что люблю что-то настраивать, и IDEA настраивал точно так же, я в ней эффективно работал. Просто я, как уже упоминал, не в восторге от позиции JetBrains по тому, как они свои продукты продают. И второй момент — я просто чувствую себя эффективнее в Vim. А самое главное, что дальше хочу сказать: Vim меня заставил познакомиться с инструментами, которые я использую. Я начал более эффективно работать в bash. Раньше я в терминале что-то как-то там: cd сделаю, найду файлик, а дальше IDEA открою, и было бы классно. А сейчас меня вообще ничего не пугает: там походил, файлики надо найти, синтаксис проверить, линтеры запустить, тесты позапускать, CI настроить — вообще без проблем, я bash могу написать спокойно. Надо только загуглить, как if писать.

[1:10:38] Илья: Да-да. Кейсы только проще, свитч-кейсы, все эти две скобочки. Часто ли ты ходил на джавовый проект, где форматирование проверяется божьим словом и ответственностью разработчиков?

[1:10:53] Александр: Стандартные. С форматированием вообще вопрос хороший, потому что оно как-то непонятно: вроде бы есть в IDEA стандартное форматирование. Оно стандартное? Ну, если из коробки берём, устанавливаем IDEA — там есть Command-Option-Shift-L.

[1:11:12] Илья: Command-Option-L, по-моему.

[1:11:14] Александр: Command-Option-L, наверное, без шифта, там что-то Shift дополнительный. Я так всегда пользовался. Но оно из коробки может, например, публичные статические методы двинуть наверх класса, и это выбешивает: ты поправил что-то чуть-чуть, сделал Command-Option-L, и оно улетело, у тебя весь файл перелопатило, ты отправляешь pull request, и он говорит, что ты натворил.

[1:11:36] Илья: А знаешь, с чем ещё прикол IDEA? Почему я, когда изучал Vim, начал лучше изучать свои тулзы? Потому что я понял, что у нас в Java-комьюнити — ну, я писал на Java — нет инструмента, который тупо форматирует код. Мы не можем из консольки просто взять и сказать «отформатируй код». Нету такого. Нету инструмента, который проверит форматирование кода. Мы обычно говорим: «смотри, у нас IDEA со стандартными настройками», а потом ты начинаешь свой код коммитить. А IDEA на самом деле, если ты нажимаешь Command-Option-L, — форматирование IDEA-евское, — она не просто форматирует код, это подгонка кода. А чтобы она прям форматировала, перегнала строчки как ей удобно, переносы изменила, надо два раза нажать форматирование. Тогда она спросит: «сейчас будет strict-формат кода, вы точно хотите?» — нажимаешь OK, и тогда она форматирует прям как считает нужным. Такая вот особенность.

[1:12:28] Александр: Я, кстати, постоянно задавался вопросом, почему она меня это спрашивает. Я просто хочу отформатировать код.

[1:12:32] Илья: «А ты хочешь?» — «Да, хочу». А по умолчанию она просто немножко приукрашивает код, и многие думают, что вот это и есть форматирование. А форматирование — если вы попишете в Go или в Python, там есть форматтер: в Go — gofmt, goimports, и это офигенно сделано с точки зрения баша, ты просто берёшь и используешь их с консоли, понимаешь, как они работают. А в Java, когда начинается вопрос… У меня часто это был вопрос: я приходил — я был на аутсорсе, летающий по проектам — и ты приходишь что-то законтрибьютить, а у тебя там неправильное выравнивание, вот это всё. И у меня всегда был вопрос: почему это? На самом деле в Java есть тулза Spotless, но тот, кто её написал, — это вообще герой, просто воплоти. Я как-то стикеров-мемов даже видел: «на коленях молю». Реально классная штука, она проверяет всё — соответствует ли форматирование кода настройкам в проекте или не соответствует, и это без IDEA. Поэтому ты можешь прям при сборке сделать проверку, не надо будет писать на камень комментарии в pull request. А во всех нормальных языках это built-in — в Rust, в Go, в JS даже, — какой-то форматтер, который запускается, всё понятно. А в Java как-то с этим нет. Я начал разбираться с тулзами, которые мы используем в Java, потому что начал настраивать Vim, — и понял, что укрепил так вообще. То, как в Java устроена работа с пакетами, — это IDEA делает вообще невероятную работу, как она всё это упрощает: мы просто добавили и особо не паримся. А когда понимаешь, как это под капотом… там должны быть разные скоупы — и тесты, и исходники, и скоуп для компиляции. Когда начинаешь в этих терминальных тулзах разбираться — а раз ты работаешь с ними, это надо делать, не прямо во всём, но чтобы понимать, как форматирование работает, как компилятор работает, — надо самому это настраивать, и ты с этим знакомишься. И потом приходишь на проект и можешь сказать: я из коробки знаю все утилиты для Java, которые проверяют что угодно, у меня всё локально сделано, мне вообще не надо ничего делать — просто аккуратненько свои настройки переношу. И это прям офигенно, классно: ты очень хорошо знакомишься со своими инструментами. Вот этим помог Vim, и я за это ему благодарен — если можно быть благодарным текстовому редактору. IDEA бы меня так с инструментами не познакомила, она наоборот тебя оберегает.

[1:15:10] Александр: Да, это просто другой подход — более юзер-френдли, наверное. Но понятно, почему это так происходит. Про CI, кстати, тоже хорошая тема: ты вроде локально себе это настраиваешь, тратишь время, что-то ковыряешь, но потом всё, что узнал, большинство скилов ты можешь трансформировать в то, что делаешь на работе. Написать CI, настроить сервак, быстренько Ansible накидать, раскинуть на все серверы. То есть оно у тебя начинает как будто «локально это всё делать».

[1:15:47] Илья: Да, я в принципе это каждый день делал. Такая вот реакция начинается: надо какой-нибудь небольшой скриптик написать — ну, я себе Vim-плагин пишу, это каждый раз небольшой скриптик, который что-то делает с текстиком, совсем небольшое. И ты вот такие маленькие простые задачки решаешь, свою думалку тренируешь, знакомство с инструментами тренируешь, из-за этого прокачиваешься. Вот это то, чего нет в IDEA. В IDEA плагин написать можно, но для этого надо какие-то видосы смотреть, а в Vim ты просто открываешь доку по плагинам, добавляешь файлик, строчку пишешь — и всё, у тебя подсосало, всё работает, это прям из коробки. Короче, я прям кайфую с этого.

[1:16:25] Александр: Да-да. Про NeoVim, наверное, про плагины можно чуть-чуть ещё рассказать, потому что мы немножко рассказали в целом: что это модальный редактор, что там эргономичное расположение, и это всё можно менять, кастомизировать. Про плагины я бы ещё тоже сказал, потому что когда первый раз с этим знакомишься, это немного взрывает голову в хорошем смысле — что можно настолько кастомную вещь сделать. Система плагинов в NeoVim работает так, что ты, как в Java-проекте dependency соединяешь, как в любом другом пакетном менеджере, — точно так же в конфигурационной части редактора можешь подтянуть несколько плагинов, с десяток: указал на GitHub ссылки, перезапустил — и всё, они у тебя выкачались. Ну, это зависит от пакетного менеджера — встроенным никто обычно не пользуется, все в NeoVim используют Lazy.

[1:17:24] Илья: Ну да, всё настолько просто, даже ещё проще. Не обязательно делать какую-то dependency — ты можешь создать себе новый файлик и в нём объявить dependency, поддерживается группировка на модули. Ты можешь классно всё это организовать у себя, файлик подключить, отключить, проверить, — да, строчку кода можешь одну убрать, где там ошибка. Например, ты что-то не так настроил: в IDEA есть люди, у которых что-то не работает, такой «блин, а как это проверять?» — а там оказывается, в PATH что-то не подкинул, куда-то ещё надо было добавить, чтобы заработало. А в NeoVim ты просто берёшь: наверное, в PATH чего-то не хватает — залогировал момент до настройки плагина, всё проверяешь. Это реально помогает.

[1:18:05] Александр: Да. Это вот что называется, по-моему, ещё в эту тему — у книжки «Программист-прагматик» был один из советов, «Know Your Tools», или как-то так.

[1:18:17] Илья: Да-да-да, это прям было. Они, по-моему, там тоже про Vim, про Emacs что-то писали.

[1:18:20] Александр: И с тех пор я начал серьёзно задумываться. Книжка «Программист-прагматик», всем советую, крутой цикл про неё есть.

[1:18:27] Илья: Я вот с него, с твоим подкастом, познакомился — скажу ребятам. Когда искал про TDD ролики — про них вообще мало на YouTube, и вообще везде мало про TDD, — один из твоих подкастов был. Я туда зашёл. И про «Программиста-прагматика» тоже послушал, потому что это одна из моих любимых книг. Она очень хорошая, мы её читали у нас в чатике, и я уверен, человек, который её со мной всю прочёл, тоже скажет, что суперклассная книга и очень помогает.

[1:18:53] Александр: Классная. Я причём оба издания читал.

[1:18:55] Илья: Первое я читал, когда в универе ещё учился.

[1:18:57] Александр: Да, когда я тоже в универе учился. Она прям, знаешь, такая из книг, которую хорошо в универе прочитать. Вот ты когда студент, смотришь вокруг на коллег, и они все кажутся суперумными и дофига знающими — потому что область того, что они знают, сильно больше твоей, и ты не можешь оценить глубину их знаний, не понимаешь, кому прислушаться, кого выбрать в качестве ментора или role model. Мне дико повезло: у меня случилось так, что я нашёл себе классного наставника на работе, он сам предложил. Тимофей, привет, если ты смотришь. Он направил меня в профессиональном плане в то, что нужно. Я, например, с его пинка волшебного писал диплом в LaTeX. Мне бы никто в жизни это не сказал — все в университете делали в Word, — а он такой: «оно тебе в будущем не понадобится, но напиши, оно классное». И я понял, что да, это действительно круто. Если бы я ещё тогда про Vim знал, я бы настолько кайфанул от процесса, а то писал в каком-то… там LaTeX-эдит есть какой-то. Ужас, короче, полный. Всё равно собирал я это всё через терминал, MikTeX какой-нибудь или что там, я даже не помню.

[1:20:16] Илья: То есть, знаешь, есть репозитории, если кому интересно, — у меня кто-то в чатике спрашивал. Есть ребята российские из JetBrains, они сделали репозиторий, dissertation template на LaTeX, что-то такое. Просто клонируешь, там инструкция есть, я по ней всё делал, там можно в докер даже поднять.

[1:20:36] Александр: Прикольно. Да, и возвращаясь к этим менторам, наставникам: ребята, авторы книги «Программист-прагматик» — это те самые менторы, которых можно выбрать себе, если у вас других нет и вы думаете, за кем пойти. Вот за ними, классные ребята. Я со всей ответственностью заявляю, что авторы крутые, и я полностью с ними во всём согласен. Так что если кому-то менторы нужны — можно себе выбрать такого. Книжный ментор.

[1:21:05] Илья: Книжный ментор, да.

[1:21:05] Александр: Ну, давай тогда перейдём к следующей теме про программирование, потому что тут всё про среды разработки, про правильную посадку, про здоровье. Уже, наверное, два часа говорим, а про программирование и языки даже не затронули. Давай про Java, наверное, и про TDD.

[1:21:23] Илья: Да, я не то чтобы адепт, не могу себя назвать адептом TDD, потому что иногда действительно…

[1:21:29] Александр: Что такое TDD для тех, кто первый раз это слышит?

[1:21:33] Илья: Test-Driven Development — когда тесты пишешь до основного кода, а потом имплементируешь код, чтобы он удовлетворял тестам, которые ты написал. Это всё зацикливается, там ещё есть промежуточный этап рефакторинга.

[1:21:47] Александр: Ну, в общем, ребят, кто хочет — ссылка на подкаст про TDD будет, ссылка на видос Ильи про TDD будет. Классная тема, особенно хорошо заходит, когда тестов на проекте мало и хочется ввести культуру тестирования в проект.

[1:22:04] Илья: Супер. И для индивидуальных проектов тоже я так пишу. Но есть такая проблема, и много людей про это говорят: все примеры, которые используются в TDD, во всех докладах — вот даже там Josh Long, spring-адвокат, кто там, он тоже постоянно в TDD пишет, — это всё-таки игрушечные проектики с нуля: взял, один REST endpoint поднял. А вот когда у тебя реальный жёсткий проект, где несколько серваков, в плане несколько сервисов, которые между собой как-то взаимодействуют, это всё надо поднять, — ну никогда ты не будешь тесты вперёд писать, говорят так многие. Что ты скажешь, почему ты всё-таки считаешь, что тесты писать можно вперёд даже в этом случае?

[1:22:46] Илья: Ну, я бы тут сослался, наверное, на книжку «Working Effectively with Legacy Code», мне она тоже нравится, хорошая, Майкла Физерса, тут наверное будет какая-то обложечка. О чём эта книга? Это книга о том, как работать с говнокодом. Как я вообще пришёл к TDD? Как раз-таки не от хорошей жизни. У меня был проект, в котором я вообще ничего не понимал — я понимал, что это конкретно легаси: открываю класс на 2000 строк, я такой «классно, наслаждаемся этим», и все классы такие. Ну, жил я с этим, жил, думаю, надо что-то менять. Зашёл, нашёл эту книжку по работе с легаси-кодом — это Martin Fowler Signature Series, поэтому мне пришлось долго гуглить, — и там про TDD как раз говорилось, что с таким кодом надо работать по TDD. Я такой: стоп, ребят, я вообще не могу с этим работать, я его тестом покрыть не могу, как мне это по TDD делать? И там как раз автор показывает способы, как изолировать ваши изменения, чтобы смочь написать на них тест. На любое практически изменение он показывает, как писать тест. Если вам кажется, что нельзя на него написать тест, скорее всего можно, просто не знаете как. Он даёт инструментики — не скажу, что они часто помогают, но они помогают изолировать именно изменения. Например, подсказывает, как сделать так, чтобы ваш новый код не пересекался со старым, а новый код вы всегда можете протестировать хотя бы постфактум. Примерно так я и пришёл к этому. Это первая книга, которую я прочёл, на этом легаси-коде иногда писал, можно сказать, по TDD: писал конкретно тесты, которые хочу. Например, мне пришёл баг, я знаю, что в этом сервисе, в этом классе, — я его воспроизвожу и потом начинаю делать фикс, и когда я завершил тест, значит, мой фикс готов. Это не прям TDD, но это первые мои зачаточные шаги, и мне это прям помогало: я был уверен, что я что-то сделал, — не факт, что не сломал, но уверен, что сделал. А потом я пришёл на новый проект, и там писал инструменты для разработчиков — то есть вещи, которые обычно даже не знают как тестировать. Взаимодействие с Gradle, сложные взаимодействия — это не просто в раз-сервис сходить, в ручку, которую можно молком замокать. Там надо было умело под это всё подсунуться, чтобы интеграционно протестировать: gRPC там было, обвязки в Gradle-плагинах надо было писать. И вот я сидел за этим всем, твёрдо решил, что буду писать только по TDD, — год чем-то писал и вообще не запнулся. У меня просто была задача написать вначале тест, и это мне помогало изучить инструмент. Я взаимодействую с gRPC — и понял, как gRPC поднять в процессе, как gRPC-сервис поднять, разобрался, что это такое. То есть написание тестов помогло познакомиться с инструментом, который я тестировал: я понял, как работают Gradle-плагины, как они подсовываются в classpath. Без TDD я вряд ли бы это узнал, вряд ли бы узнал, что Gradle-плагин тестируем, — типа проверил бы локально, работает, работает, и всё. А TDD меня подвигло. Ну вот так вот радикально — не попросил, скажем так.

[1:25:50] Александр: И ты сейчас, по сути, весь код так пишешь?

[1:25:50] Илья: Да-да. Ну, на Java точно весь код так писал, на всех проектах. Сейчас я немножко меняю своё направление, перехожу в Go, и бывают иногда моменты, когда я не могу написать тесты. Но тут ещё надо понимать: иногда — ну, это, наверное, не оправдание, чтобы не писать тесты, — у меня есть проблема, потому что в Java, даже когда не писал по TDD, я знал инструменты для тестирования некоторых вещей, я уже был хорошо знаком с экосистемой Java и знал, куда посмотреть. Здесь мне сложнее: если какие-то вещи в проекте не тестируются, мне сложно найти инструмент, чтобы это протестировать. В Java я офигенно знал рефлексию, знал, как практически любую штуку подхачить, мог всё что угодно сделать с этим языком, потому что очень хорошо в нём ориентировался, и мог писать тесты на разные штуки. Тут иногда я чувствую себя скованным: какую-нибудь инфраструктуру у меня не получается покрыть тестами, и я её пока — думаю, что пока — пишу без тестов. Вот такая ситуация.

[1:26:51] Александр: Ну, про Go, я думаю, можно будет поговорить чуть-чуть попозже. Я бы ещё отметил, что когда я только познакомился с этой техникой TDD, я прям ей сильно вдохновился и действительно следовал ей хрестоматийно, как по учебнику. Но потом в какое-то время немножко подотпустил эти строгости — ну, там нет особых строгостей, просто есть некоторая сильная…

[1:27:22] Илья: Система, правила, которым хоть и следовало бы следовать, но никто тебя за руку не дёргает, если что-то пропускаешь.

[1:27:27] Александр: И как правило, чтобы соптимизировать, побыстрее код написать, ты часто пропускаешь. Например, рефакторинг делаю не каждый раз, а через раз-через четыре.

[1:27:38] Илья: Ну, не каждый раз нужен рефакторинг.

[1:27:38] Александр: Да, но суть в том, что я начал замечать: это на уровне ощущений, что ли, или отношения к коду, который ты пишешь, — оно как-то меняется. Ты сначала думаешь: так, а что я хочу, чтобы оно как работало? Вот я пишу код или багу пишу — так, а в чём бага, что такое вот эта бага? Ты её формулируешь в виде кода, в виде теста. И пока ты это сделал — это огромная мыслительная работа, которая на самом деле всегда должна быть сделана, но она делается неосознанно, иногда кривовато, если ты сразу пытаешься багу пофиксить. Ты можешь иногда вообще не то фиксить. А тут ты её сформулировал в виде теста — и это уже, наверное, 80 процентов работы сделано. Потом остаётся дело за малым: просто сделать тест зелёным. И это сильно меняет подход к дизайну кода, к дизайну вообще продукта, программы: ты тоже думаешь, а как я её буду end-to-end-тестами тестировать, ты хочешь, чтобы она была тестируемой.

[1:28:40] Илья: Не надо упарываться, если видите, что тут прям сложно написать тест.

[1:28:46] Александр: Да, и чуть не упарываешься — берёшь и делаешь работу. Вот сейчас, как я делаю: есть возможность написать какую-нибудь новую REST-ручку. Я такой: напишу REST-тест, который дёргает несуществующую ручку, падает там с 404; потом иду, пишу контроллер, пишу в нём какую-то логику, тест работает; потом понимаю, что логика в контроллере не очень, надо её вынести — стадия рефакторинга; потом ещё этот сервис тестами обрастает. И вот так эволюционно, потихоньку оно приходит к тому, что получается встроенный нормальный, на мой взгляд, код, хорошие тесты, и я начинаю себя более уверенно чувствовать. Когда потом возвращаюсь к этой кодовой базе, я такой: так, ну я тут тесты писал, я вот прямо сейчас могу здесь всё сломать, что-то поменять — я знаю, что меня эти тесты спасут. Если бы их не было, я бы не так активно менял кодовую базу, как сейчас могу себе это позволить. Это тоже круто.

[1:29:43] Илья: Про эволюционность ты прямо в точку сказал, и я вспомнил пример из моего опыта, очень показательный. Была задача, которая очень долго откладывалась, — и откладывалась потому, что не были сформулированы требования: непонятно, что сделать, что она фиксит, что вообще решает. Было понятно, что баг, но никто не понимал, почему он происходит, как система на самом деле работает под капотом. Это всё проблема, непонятно, что с этим делать. И я пришёл — так как я адепт, можно сказать, — говорю: ребят, давайте я напишу приёмочный тест, вот точно знаем мы первый кейс, который должен работать. Мы написали приёмочный тест, он прошёл, и мы больше на нём не концентрируемся. Я говорю: так, есть ещё какие-нибудь у вас идеи, тесты, которые могут не пройти? И мы придумали ещё несколько. Потом я говорю: вот всё, я их пофиксил, теперь у нас есть четыре теста, старый продолжает работать — давайте ещё ваши идеи. И мы вместо того, чтобы пытаться сверху вниз идти, дедуктивно додумываться, как логика должна быть организована, строить схемы в голове, пытаться весь этот флоу организовать в башке (что очень сложно, потому что логика была реально сложная, её в одну голову было не уместить), — мы начали конкретно решать одну проблему за раз и вот так продвигаться. И это именно TDD, он про индукцию: вы берёте много экспериментов, ставите и после них обобщаете. У вас выстраивается — вы не сразу строите замок в голове, а потом пытаетесь нарисовать его. Это как прикол «как нарисовать сову»: кружочек, кружочек, третий кружочек — потом сова. Вот примерно так выглядит, когда ты строишь в голове схему, как должно что-то работать. А по TDD ты конкретно говоришь: вот это я нарисовал линию, потом нарисовал вторую линию, и при этом эта линия до сих пор сочетается с первой. Это всё позволяет делать TDD. И мы вот так итеративно, именно по TDD — хотя ребята, может быть, не осознавали, что это TDD, — мы именно так сделали эту задачу. И оказалось, что там мы кучу всего не учли, надо было вообще всё не так делать, как мы планировали. И это плюс TDD. Люди, может, даже не осознали, что мы использовали TDD и получили всю его пользу, но я это осознавал. И не обязательно даже, чтобы ребята это осознавали, потому что был человек, который понимает TDD. Поэтому вы можете быть человеком, который понимает TDD и умеет использовать тесты, чтобы руководить разработкой, — это бывает полезно. Потому что термины у аналитиков одни в голове, у разработчиков другие, у тестеров третьи. А тест — это тест: он зелёный или красный? Если зелёный — кайфуем, всё классно работает; если красный — что-то пошло не так. И это тот бейзлайн, от которого все могут отталкиваться и понимают друг друга.

[1:32:24] Александр: Да, то есть формулирование требований — есть даже такое понятие, как test specification: ты как бы специфицируешь фичу или багу в виде кода, и этот код проверяет, что другой код соответствует какому-то требованию. И в этом плане я бы ещё дополнил: я сейчас много кода ревьюю, и очень часто я сначала весь код пропускаю, открываю тесты, читаю их, такой: ага, вот этот код делает вот это. Потом смотрю в тикет в Jira: это ли нужно было сделать — чисто по тестам, я даже ничего не видел. Да, тесты тестируют то, что написано в Jira, и только потом иду смотреть сам код. Хотя чаще всего на этом этапе уже есть вопрос: почему это не протестировано, почему здесь так? То есть описание фичи иногда не соответствует тестам, которые я вижу, и я иногда могу написать: а давай вот здесь ещё один тест-кейс, а что будет вот тогда. Когда этот этап пройден, я уже иду смотреть сам код. И когда ты понимаешь, что он должен делать, код намного проще ревьюить. Ну и понятное дело, если он бажит, то этот баг должен был ещё на уровне тестов быть виден. То есть тот уровень ревью — просто ревью — уже покрыл большинство, и если баги в коде были, они должны быть видны на уровне теста.

[1:33:47] Илья: Да. Если тест супер, он проходит, то скорее всего с кодом тоже всё ок.

[1:33:52] Александр: Да, можно где-то красоту навести, но я в целом придерживаюсь того, что красота в глазах смотрящего, и нельзя всегда на ревью говорить всем: «давай сделай метод меньше». У меня есть интересная аналогия: вот код — если есть нормальные тесты, всё протестировано, работает как надо, то он уже хорош, good enough, не надо больше его ревьюить. Все чеки, все чек-стайлы если проходят — то всё.

[1:34:18] Илья: Так, кстати, ребята-разработчики ClickHouse такой же придерживаются стратегии: если код проходит зелёный пайплайн — а у них есть пайплайны перформанс-тестов, чек-стайл, формат, — если всё это ок, то доверяют зелёному пайплайну.

[1:34:32] Александр: Это круто. И так оно и должно работать. В этом плане я сравниваю сам код с почерком автора — это авторское сочинение, ты его написал. Есть мнение, что почерк у команды должен быть одинаковый. Я с ним не согласен, но такое мнение есть. Если есть форматтер или чекер, который этот почерк проверяет и говорит на уровне пайплайна, что здесь нужно писать по-другому, — окей. А если есть человек, который всё время приходит и говорит «а вот здесь у тебя комментарий должен точкой оканчиваться», — такой: блин, ну сколько можно? Я воспринимаю код как авторский: вот автор излагает мысль. Если я с мыслью согласен и в целом мне она понятна — это окей. Я не могу сказать человеку: «а вот давай пиши в стиле Толстого, потому что он мне нравится». Ну блин, это глупо. И в этом плане TDD, или наличие хороших тестов, как раз даёт мне спокойствие, что с кодом всё окей, потому что он проходит тесты. Если тестов достаточно и они написаны — даже, по-моему, авторы это говорят, — спать можно спокойно.

[1:35:40] Илья: Да.

[1:35:40] Александр: И в этом плане, да, если кто-то хочет познакомиться с TDD, что бы ты им посоветовал почитать, посмотреть?

[1:35:48] Илья: Ну, я бы посоветовал две книги, хрестоматийные. Это Кент Бек, «Экстремальное программирование. Разработка через тестирование» — так она называется. И про лондонскую школу разработки через тестирование — это, как её, «Growing Object-Oriented Software, Guided by Tests». Обе книги классные, вторая более душная, но тоже интересная. У меня к тебе был вопрос. Смотри, у меня есть такая штука: я был бы рад смотреть на ревью кода тестов, но иногда вижу тесты и просто считаю, что лучше бы их не было. Вот ты говоришь про почерк — я тоже считаю, что за почерк нельзя корить человека. Но часто, например, на тестах отключают линтеры: считают, что тесты — главное, чтобы тестировали, а какое в них качество, вообще нет смысла смотреть. Нет ли у тебя такой проблемы, что ребята пренебрегают тестами? Может, на твоём проекте такого нет, но сталкивался ли ты с тем, что тесты не хочется читать, потому что понимаешь, что они по остаточному принципу написаны, ребята их делают для покрытия?

[1:36:52] Александр: Да, у меня бывало такое в начале карьеры, когда я просто следовал практикам, установленным в команде, и не мог особо ничего поменять. Я решил эту проблему, сейчас расскажу как. Но вначале ещё раз сформулирую, в чём проблема, потому что, возможно, кто-то не понимает. Код, который написан в тестах в таких средненьких легаси-проектах, которые писали не гении, — он, мягко скажем, грязноват. Если откровенно — это прям говнокод, потому что, как правило, там используется куча наследования. Ну, да, рефлексия какая-нибудь.

[1:37:39] Илья: Рефлексия, кстати, довольно редко в тестах я видел, а вот наследование — это прям база. Базовый тест с кучей никак между собой не связанных методов, и ассерты там, и prepare, и close — это база, мы от неё наследуемся. И дальше вот эти франкенштейны наследовательские вырастают в реальных франкенштейнов, и оно как-то тестирует.

[1:38:06] Александр: А там ещё куча моков, потому что у тебя в сервис инжектится 15 штук: ты одну фичу в сервисе поменял, тебе нужен один метод протестить, а для этого нужно 15 объектов создать. Естественно, ты не будешь создавать, ты моков накидал — и вот есть тест, в котором 50 строчек это настройка моков, потом одна строчка вызова и ассерт в конце. Вот про это я говорю. Я такой: нет, — вначале думал, может, я чего не понимаю, потому что молодой, а потом понял, что нет, наверное, не во мне проблема. Как я с этим начал бороться в последующих проектах? Естественно, в том проекте, где я это видел, это уже не исправить — ну, или если исправить, то нужно нереальным желанием это сделать, а у меня такого не было. Как я делаю сейчас? Я пишу много тестов, пишу много кода сам и пишу инфраструктуру для тестов сам. Я стараюсь формировать такую инфраструктуру для тестов — JUnit Extension, DSL всякие, удобные методы, — которая настолько делает приятным и кайфовым написание тестов, как для меня, так и для других, что я потом вижу: люди просто используют этот код, и он примерно такой же аккуратный, как у меня. Я всё делаю интеграционно, тестирую. У меня есть несколько подходов к тому, чтобы настроить среду для интеграционного тестирования, она удобная — это может быть JUnit Extension с одной настройкой, и люди себе тоже это подключают и используют. И вот так красиво, складно получается. Моки — пару раз я, наверное, на ревью видел моки, закрыв глаза ставил, но вообще говоря, у нас очень мало моков сейчас в кодовой базе. Мне кажется, отчасти потому, что культура интеграционного тестирования, которую я сильно старался внести хотя бы в тех компонентах, за которые отвечаю, — она есть, просто она удобная. Сейчас вот, не знаю, может, как-нибудь про это расскажу — я прям новый фреймворк начал писать для интеграционного тестирования, потому что в интеграционных тестах какая проблема? Они медленные. Если ты всё это будешь поднимать каждый раз — будет медленно, и приходится изобретать: файловую систему, снапшот делать, на каждом тесте подкладывать. Но если есть возможность написать инфраструктуру для интеграционного тестирования, чтобы она немедленно, более-менее нормально работала, — это супер, это решает все подобные проблемы с моками.

[1:40:31] Илья: Мы могли бы похоливарить, потому что я люблю моки. Я как раз-таки чаще, наверное, пишу по Лондону. То есть если говорить, чикагская школа и лондонская, я часто по TDD… Ну, кто не понимает: лондонская школа, грубо говоря, это школа ребят, которые пишут приложения сверху вниз. Они пишут с контроллеров, но сервисы не сразу делают какими-то реализациями, заглушками, — они делают моками, и вначале формируют к сервису все требования на уровне контроллера, а потом уже начинают реализовывать сервис, когда сформировали все требования с помощью моков. То есть они используют моки, чтобы для себя в голове сформировать требования для сервисов. И я скорее вот так вот пишу. Я на самом деле покрываю всё, что связано с базой данных, тоже интеграционными тестами, но я люблю тесты с моками — именно для того, чтобы спроектировать. Для меня это как средство проектирования. Поэтому можно было бы это как-то в другой раз похоливарить.

[1:41:30] Александр: Ну, про моки я, наверное, так скажу: когда у тебя много внешних зависимостей, когда другие сервисы, которые не всегда можно поднять — они могут кривые-косые, локально не стартовать, конфигурация им нужна, — там действительно других вариантов ты не осуществишь: либо WireMock используешь, либо моки. Это плюс-минус одно и то же в плане архитектуры. И тогда, ну да, лучше уж такие тесты, чем никакие. Но когда я вижу, что мы мокаем собственные классы, которые вот здесь лежат рядом, — немного странно. Ну, я давно микросервисы не писал, я пишу всё-таки с нуля всё, и там просто нет места мокам, на самом деле.

[1:42:10] Илья: Ну, там, наверное, у вас нет фреймворка, у вас всё своё, поэтому проще всё поднять.

[1:42:13] Александр: Там в целом всё поднимаешь, и оно всё есть. Что тебе можно сделать? Ну да.

[1:42:19] Илья: А тогда да, ничего против моков внешних зависимостей я не имею.

[1:42:25] Александр: Тогда даже не получилось поспорить, ладно, окей. Да, но в целом на ревью я, правда, сильно спорю, но у меня есть аргумент, что это не внешняя зависимость, а он железный.

[1:42:36] Илья: Ну да, он железный, я бы с ним не спорил. Ну там тоже бывает иногда: а что будет этот класс создать? Там нужно ещё 10 других классов, мне впадлу, я лучше одним моком прикрою его, и будет всё устроено мирно. И, ну, не знаю, для меня это, конечно, не аргумент, и иногда у меня есть возможность вот так сказать: не будет мержа. Но чаще всего я — как бы не из таких людей — часть такую потом перепишу сам. Действительно так проще; не знаю, я просто могу спокойно на выходных сесть и попрограммировать для работы, потому что мне зудит, хочется это исправить.

[1:43:17] Александр: Лучше не переработать. Ну, это отдельная тема.

[1:43:19] Илья: Ну можем, кстати, на это похоливарить, потому что у меня есть чёткое мнение про переработки, про долгое сидение, work-life balance, вот это всё.

[1:43:27] Александр: Я пробовал по-разному. Я начал свою карьеру с того, что дохрениша работал и учился, 12–14 часов, вот прям только на сон оставалось. Потом коснулся немножко, наверное, чего-то подобного выгоранию, когда началась ковид, я дома сидел, и мне было сложно работать. Тогда прям почти апатия была. И вот потом я такой: наверное, делал work-life balance — что-то много работал, — и начал осознанно больше уделять времени отдыху. И понял, что во время отдыха я сильнее напрягаюсь, потому что моя натура не позволяет: я себя чувствую некомфортно, если что-то хочу делать и не делаю. Такое: а почему я это не делаю, надо отдыхать? Окей, я отдыхаю, но внутри напряжение всё равно есть. И я для себя так это сформулировал: если у тебя есть положительная отдача от того, что ты делаешь, ты самореализуешься — например, тем, что это запрограммировал, — то есть оно есть в исполнении, в балансе, тогда тебе, ну, мне отдыхать в классическом плане — не знаю, два дня прогулок, чтения книг, что вы любите, — как бы и не надо, потому что ты не напрягаешься эмоционально. Я для себя это так формулирую. И, например, был недавно момент, когда я всё воскресенье пропрогал вот этот фреймворк как раз для тестирования — я настолько был доволен по итогу. Никто из менеджмента время на это не выделит, а все разработчики вокруг будут этим довольны. И для меня это самореализация, поэтому я на неё трачу время и не вижу ничего зазорного, что там 12 часов в воскресенье, — ну, помимо того, что я не провёл время с женой, но остальных минусов вообще не вижу. А ты что думаешь на это сейчас?

[1:45:17] Илья: Я на самом деле считаю, что это… Ну, я буду оппонировать, хотя отчасти это понимаю, я тоже раньше любил что-нибудь в свободное время поделать. Но сейчас я, если хочу что-то поделать для работы, категорически все эти мысли откидываю: скорее пойду Vim настраивать дальше, что-нибудь новое искать, или просто потуплю во что-нибудь в YouTube, тоже надо потупить. Я стараюсь так делать, потому что для меня, как ты говоришь, менеджеры не выделят для этого времени. И, по-моему, вот такая вне-процессная активность — это соломка под места, которые на самом деле надо лечить. Это плохо, это как любая переработка. Переработка празднует, что вот мы, перерабатывая, сделали проект. Это неправильно: это значит, что вы решили не проблему, а её последствия, укрыли переработками свои процессные минусы. И тут то же самое. Вот ты сделал фреймворк — и это значит, что ваш менеджмент не готов уделять время улучшению… Вот если этот фреймворк ещё выстрелил, ребятам понравится, — это значит, менеджмент не готов выделять вам время на развитие технического инструментария. И это проблема, которую надо решать. И она решается не тем, что программировать по воскресеньям, а тем, что менеджмент может на этом примере — что ты в воскресенье сделал полезную вещь — начать прислушиваться и увидит, что все остальные скажут «это реально классная вещь, я начал писать больше интеграционных тестов». И тогда менеджмент скажет: окей, окей.

[1:46:46] Александр: Сомнительно, но…

[1:46:46] Илья: Да-да, мы будем больше времени вам давать, там пятница, вечер, можете делать свои инструменты, мы не будем это на бизнес требовать. Это может быть как разовая акция, чтобы показать бизнесу, что можно сделать такую штуку, если вы дадите нам время. Но я бы даже разовую акцию, по своему опыту, не делал. Для меня рабочий день — это 8 часов. Я могу потом отвечать в чатах, но, скорее всего, не сяду делать фичу. Если меня кто-то попросит помочь, я помогу, потому что я просто отниму время, которое потратил на помощь человеку. Я считаю, что надо работать столько времени, сколько отведено, потому что мы его планируем.

[1:47:25] Александр: Все твои мысли супер логичные, и у меня они были в своё время. Я сейчас не такой типа «как будто что-то понял в жизни» — нет, я просто выработал для себя, почему мне внутри комфортно так работать, жить. И долго я к этому шёл. Действительно, если что-то, что всем мешает, — как, например, отсутствие инфраструктуры для тестирования, — и ты постоянно пишешь тесты, и вокруг тебя люди пишут тесты, а менеджмент такой: «ну вы же пишете тесты, зачем вам на это две недели тратить, ты можешь фичу новую добавить». Это было всегда и, мне кажется, будет всегда. Как правило, менеджеры среднего звена и C-level не сильно хотят и не сильно шарят в том, в чём мы хороши как инженеры. Как правило. Даже если вы думаете, что вы хороши…

[1:48:18] Илья: Вы не хороши. Может быть, были хороши.

[1:48:21] Александр: Да, когда-то, но не сейчас.

[1:48:23] Илья: Это как совет деду, знаешь: когда-то ты был хорош.

[1:48:25] Александр: Дед, да. Я так примерно внутри представляю: ну пускай поговорит, а я сделаю всё равно как считаю нужным. И доказывать им правильность того, что это нужно сделать… Я просто часто пробовал это делать, и чаще всего оно увенчалось тем, что не давали, не понимали зачем. И это как личная гигиена, я воспринимаю это так. Вот я могу себе NeoVim настроить — я считаю, что для меня это самый оптимальный, удобный способ. Да, это не работа, но я же работаю в нём, эффективнее работаю. На это я не прошу мне часы выделить, очевидно. И вот то же самое — это собственный комфорт. Как и написание тестов: да, я хочу, чтобы делал это удобно. Это раз. Два — всё-таки IT-мир довольно маленький, закрытый, люди между собой часто пересекаются, вместе работают, зовут друг друга на работу. И вот те ребята, с которыми мы вместе в команде, которым я покажу этот фреймворк, скажут: блин, ну Саня вообще красава. И мы потом установим такие связи, которые в будущем помогут вместе что-то классное делать. А те, кто принимает решения сверху, — пускай дальше их принимают.

[1:49:43] Илья: Знаешь, как я это делал? Я тоже писал инструменты для тестирования. У меня был проект, куда пришёл — ребята вообще интеграционные тесты не писали, там была сложная ситуация. Я сделал инструмент, чтобы эти extension’ы всё поднимали, всё настраивали, ты просто подключаешь — и у тебя работает. И я просто сказал, что делаю бизнес-таску, и оценил её во время так, чтобы написать этот инструмент. Я менеджеру говорю: так и так, вот мне для задачи надо столько-то. Я заложил в оценку время на знакомство с кодом и тестовой инфраструктурой, потому что, как ты говоришь, менеджер думает, что он разбирается, но, скорее всего, уже не так разбирается. И ты можешь технически придумать себе причины, чтобы выделить время на написание этого фреймворка: сегодня мне небольшой шажочек надо подреализовать, чтобы в будущем классно работать. И реализуешь, потом несколько задач сделал — и сложилась цельная картина. Я когда пришёл на проект, у меня была задачка с SQL, я сделал extension для тестирования одной штуки — там SQL, нашей реляционной базы данных. И потом, в конце какого-то промежутка времени, я сделал несколько задач, и у нас вся инфраструктура — уже десяток extension’ов, абстрактное количество — в сумме решала проблему поднятия любого сервиса вообще в любой конфигурации. То есть я примерно так эту проблему решал: не работал в нерабочее время, а просто давал over-estimate. Ну и понятно, что лид мне в этом помогал, потому что без помощи лида может быть такая ситуация, что ребята с команды скажут «эта задача не стоит столько, ты не будешь прав, если будешь так делать». Но я сразу, когда прихожу в команду, предупреждаю ребят: если у меня будет выбор — не тестировать что-то и коммитить это в продакшн либо написать инструмент, хоть и небольшой, но который поможет мне это протестировать, — я в бизнес-задаче при реквизитах сделаю этот инструмент, потому что я пишу по TDD. То есть ребята готовы. Ну и меня в тот проект взяли, сказали, что там пишут по TDD, и им было важно, чтобы мы начали тестировать, — и вот я им заэнейблил эту тему. Теперь они могут тестировать любые сервисы, потому что там реально нетривиально было, по крайней мере с реляционными базами данных, всё это сделать.

[1:51:49] Александр: Заручиться поддержкой от ведущих разработчиков, которые утверждают оценки, и давать оценки с учётом того, чтобы написать инструмент для нужного тебе тестирования. Вообще закладывать время можно, но иногда менеджеры или те, кто принимает решение, хороша ли эта оценка, могут быть немножко технически подкованными и всё-таки сказать: слушай, ну реально там одну ручку в REST добавить — ты там 13 стори-поинтов, ты серьёзно? И это одно, и сложно с этим спорить, по факту. А другое то, что для них, как для внешних наблюдателей, сложно отличить тебя, энтузиаста, который реально потратит это во благо, и просто лентяя. Вот им как развести эти две — лентяй тоже будет переоценивать, просто чтобы меньше времени тратить.

[1:52:41] Илья: Но он же этого не узнает. Ну, тут скорее это для разработчиков: я буду выглядеть для других ребят как лентяй, которые оценивают, они видят какого-то чувака-лентяя, что он оценивает высоко задачи, — и они будут во мне видеть того, кто оценивает высоко. Но я буду оценивать высоко, потому что хочу больше времени проинвестировать, а чел — просто потому, что считает, что дольше делать. Я вижу, а менеджеру всё равно: он просто будет думать, что у них есть работяга, который всегда даёт низкие эстимейты, а на самом деле чел просто говно наваливает с низкими эстимейтами. А второй, допустим, кто-то — даже не я — даёт нормальные эстимейты, потому что он много знает, понимает. Но это типичная проблема эстимейтов, надо просто как-то их синхронизировать. Опять же, если в команде будет хорошо выстроен процесс, когда будет планинг-покер и часть команды не будет согласна с тем, чтобы я тратил это время на написание тестов, то тогда будет сложно эту штуку продвинуть. Но, как я говорю, если сложились звёзды и у вас планирование происходит так, что его в основном одобряет лид, то можно такую штуку продумать: чтобы около оценки лид понимал, что, например, в это входит, и одобрял то, что ты делаешь. Тогда мне всё равно, как я выгляжу перед бизнесом; я окей с тем, что бизнес думает, что я не топ-перформер. Мне главное, чтобы обо мне думали коллеги и видели, что я работаю. Такое вот у меня имхо.

[1:53:58] Александр: Ну да, какое-то такое признание тех, кто понимает, намного более ценно, чем признание тех, кто не понимает.

[1:54:04] Илья: Ну да.

[1:54:06] Александр: Я полностью согласен с этим. Я бы, наверное, добавил, что тоже зависит всё от компании, от команды, от того, что вы делаете. Разные процессы: где-то лиды есть, где-то в целом просто ребята офигачат. Поэтому ничего не стопроцентно кристально истинно, всегда есть разные ситуации, трейд-оффы. Но мне кажется, что мы вообще супер продуктивно поговорили. Во-первых, спасибо тебе, Илья, за то, что пропушил меня сделать оффлайн-запись. Оффлайн — это круто, это был интересный опыт, намного более, как мне кажется, близкий, уютный и интимный разговор получается, чем если бы это было…

[1:54:44] Илья: Не будет после подкаста. У нас тут есть бэкстейдж.

[1:54:50] Александр: На Бусти подписывайтесь.

[1:54:51] Илья: Да-да-да.

[1:54:54] Александр: Большое тебе спасибо.

[1:54:55] Илья: Спасибо большое студии Fabuma Records, которые позволили нам это записать.

[1:54:59] Александр: Ну и ставьте лайки, подписывайтесь, комментарии, всё такое. Как вам формат, кстати? Надо ли онлайн встречаться, или надо в Zoom встречаться, ну или на той штуке, о которой ты говорил. Может быть, вы захотите вторую серию.

[1:55:17] Илья: Ты бы приехал в Питер.

[1:55:19] Александр: Да, я бы мог приехать в любимый город. В общем, пишите, ребят. Всем спасибо большое. Пока.