Заметки Андрея Романова

2022-02-28 20:27:14 За последние несколько дней:
1. Путин развязал кровавую войну в Украине, в которой гибнут мирные жители, украинские и российские солдаты.
2. Чиновники и пропагандисты перешли все мыслимые границы в наёбывании россиян: сперва говорили, что войны не будет; теперь это не «война», а «спецоперация»; собирались освобождать ЛДНР, а атакуют всю территорию Украины; якобы идут «освобождать» украинцев, хотя самим украинцам это не нужно.
3. Весь мир поддержал Украину и её независимость, Россия стала страной-изгоем, курс доллара перевалил за 100₽, соседские страны спешат вступить в НАТО, ипотеки подорожали в два раза, а и без того бедные россияне получили неиллюзорную перспективу стать ещё беднее.

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

• Петиция «Остановить войну с Украиной»

• Петиция «Инициировать импичмент президента Российской Федерации Владимира Владимировича Путина»

• Открытое письмо представителей российской ИТ-индустрии против войны в Украине

• Покажите родственникам и друзьям свидетельства военных преступлений и потерь нашей армии (например, их публикует nexta)

Украине — мир и независимость. России — люстрации. Путину и его пособникам — трибунал. Открыть/Комментировать

2022-02-20 20:43:05 Как упростить кодревью
Делюсь проверенными на личном опыте способами упростить ревью вашего кода и в целом повысить культуру кодревью в компании.

Размер пулреквестов — 80% успеха

Чем меньше пулреквесты — тем лучше. Большие PR демотивируют ревьюеров и снижают качество ревью, потому что сложно удерживать объём изменений в голове.

Если получается большой пулреквест, возможно вы смешали в нём правки в разных частях системы, требуемые для решения исходной задачи. Такие правки обычно можно разбить на отдельные PR: например, отделить новые UI-компоненты от реализации страницы с их использованием.

Ещё один случай больших PR — рефакторинги. Обычно их можно разделить на две части:
1. Содержательные изменения в какой-то части системы
2. Шаблонное обновление остального кода

Отделите первое от второго, и вы сэкономите время и силы ревьюеров, которым не очень важен бойлерплейт.

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

Описание изменений

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

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

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

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

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

Ревью собственных пулреквестов

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

Уведомления о ревью

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

Явное обозначение намерений в комментариях

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

Conventional Comments — хороший пример готовых соглашений для обозначения намерений. Открыть/Комментировать

2021-06-02 20:23:14 Список сделанных рабочих задач

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

Каждую неделю я завожу в списке отдельную секцию с временным диапазоном (например, «24–28 мая 2021») в заголовке и в течение недели записываю сделанные задачи.

Основная польза в том, что мне больше не нужно в разных ситуациях мучительно вспоминать, чем я занимался и что сделал. А такие ситуации в моём опыте возникают постоянно:
1. Ежедневные встречи с командой, на которых рассказываешь, чем занимался вчера.
2. Еженедельные отчёты о проделанной командой работе, для которых каждый член команды составляет список сделанных им задач.
3. Ретроспектива: понять, на что ушло время вместо важных запланированных задач.
4. Performance review: выделение основных достижений за последние полгода.
5. Подготовка к поиску работы: список освежает память при составлении резюме и рассказе о прошлом опыте.

В общем, горячо рекомендую завести себе такой список и снять с себя когнитивную нагрузку в описанных (и не только) случаях. Открыть/Комментировать

2021-01-12 20:21:11 ​Подход Fail Fast

В разработке есть довольно здравые и широко применимые подходы, о которых почему-то редко рассказывают в учебных курсах или книгах, и ты со временем либо интуитивно приходишь к ним сам (зачастую не в состоянии осознанно их сформулировать), либо узнаешь о них случайно. Для меня одним из таких подходов оказался Fail Fast. Давно о нём где-то поверхностно услышал и отложил в закладки, а сейчас добрался до исходной статьи Джима Шора Fail Fast (PDF, ~120 КБ).

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

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

Как раз недавно столкнулся на работе с проблемой, которую можно было бы предотвратить с помощью этого подхода. Моё приложение ожидает, что при запуске в переменных окружения будет задан определённый внешний URL, который открывается в iframe на одной из страниц приложения. При запуске нового экземпляра приложения эта переменная окружения ошибочно была задана с неправильным названием. Приложение успешно поднялось, а спустя некоторое время пользователи сообщили, что iframe перестал работать.

Джим приводит аналогичный пример про конфигурацию прямо в начале своей статьи: при отсутствии значения в конфигурации лучше вообще не запускать приложение и выводить сообщение о проблеме, чем использовать какое-то значение по умолчанию. В первом случае разработчик попробует запустить приложение и получит ошибку вида «Ключ ____ отсутствует в конфигурации», а во втором случае он уйдёт отдыхать и узнает о проблеме от недовольных пользователей, которые не могли решать свои задачи всё время его отсутствия.

Важно отметить, что этот подход не про полную остановку программы при обнаружении ошибки, а в первую очередь про то, чтобы сделать проблемы заметными. Джим приводит в пример пакетную обработку данных, при которой можно обойтись отправкой сообщения об ошибке разработчику (например, через Sentry) и ненавязчивым сообщением пользователю о том, что часть данных обработать не удалось. Основная идея в том, чтобы разработчик узнал о проблеме как можно раньше и чтобы сообщение о проблеме направило его как можно ближе к причине. Открыть/Комментировать

2020-11-28 23:33:22 Идеальный сервис для прослушивания музыки

На дворе 2020 год, а все сервисы для прослушивания музыки, которые я пробовал (Яндекс.Музыка, Spotify, Deezer, Google Play Music, Apple Music), работают отвратительно.

Мой субъективный гигиенический минимум для таких сервисов:
1. Кроссплатформенность и синхронизация фонотеки между девайсами. Здесь нечего добавить.
2. Простой и понятный интерфейс, который в первую очередь показывает твою фонотеку (исполнители, альбомы, треки, жанры), а не рекомендации и подкасты.
3. Стабильность фонотеки. Привет Яндекс.Музыке, в которой я постоянно обнаруживаю то дубли альбомов, то отсутствие добавленных ранее песен.
4. Переключение треков без задержек. Отсутствие этого особенно бесит, когда слушаешь что-то вроде Pink Floyd, где на протяжении всего альбома один трек плавно переходит в другой.
5. Возможность скачивания музыки на девайс. Как целыми альбомами, так и отдельными треками (привет, Spotify, в котором отдельный трек нельзя скачать без диких ухищрений вроде его добавления в специально созданный плейлист для скачивания).
6. Предсказуемая и стабильная работа в офлайне (например, в самолётах). Снова привет Яндекс.Музыке, у которой в офлайне половина песен пропадает, остальные перемешиваются (в прямом смысле, в альбом заходишь, а там песни в неправильном порядке), а у большинства песен не отображаются обложки альбомов.

Не такие важные для меня, но приятные возможности:
1. Просмотр текстов песен. Оценил эту возможность в Яндекс.Музыке.
2. Встроенный поиск треков по записи (аля Shazam). Тоже удобно, чтобы не держать отдельное приложение.
3. Экспорт и импорт метаданных фонотеки. Невозможно запомнить все треки, которые когда-то понравились, хотелось бы владеть данными фонотеки и иметь возможность их выгрузить и импортировать в любом сервисе (заодно это бы облегчило переход между сервисами).

Если знаете сервис, который удовлетворяет всем критериям — делитесь в чате! Открыть/Комментировать

2020-08-26 20:15:56 ​О личной эффективности

Марина Сафонова в 2016 году рассказала о своих принципах личной эффективности, а через два года очень хорошо над ними порефлексировала:

Спустя два года перечитываю тот пост и вижу между строк идею «как бы мне еще себя помучить».

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

2020-08-20 20:52:44 Публичные CDN и кеширование

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

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

Проблему слежки решает разделение кеша (cache partitioning): каждый сайт должен иметь собственный кеш для подключаемых на нём ресурсов. Если facebook.com и vk.com подключают с cdnjs.cloudflare.com jQuery одинаковой версии, пользователь при заходе на них скачает jQuery дважды.

Оказывается, в Safari кеш разделён аж с 2013 года. В Chrome с 77 версии тоже ведётся работа по разделению кеша. Инженеры Mozilla активно помогают в стандартизации этого поведения. Открыть/Комментировать

2020-03-25 00:46:44 Не просите время у бизнеса

Рефакторинг, доступность, быстродействие, тесты: эти вещи объединяет фраза «бизнес не выделит на это время».

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

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

Откуда вообще возникают такие просьбы? По моему опыту, так случается, когда задачи выполняются как можно скорее, жертвуя тестами, качеством кода и чем угодно ещё. Такой подход даёт выгоду только в краткосрочной перспективе, в долгосрочной техдолг копится, замедляет и усложняет разработку. Когда становится совсем невмоготу, разработчики осознают, что маленьким локальным рефакторингом не обойтись, и идут просить у бизнеса время на борьбу с техдолгом.

Более здоровый подход, работающий в долгосрочной перспективе — когда рефакторинг, тесты, документация и прочие технические работы становятся частью любой продуктовой задачи. Не нужно считать рефакторинг или написание тестов отдельными видами работ, которые нельзя сделать в рамках какого-то улучшения продукта и на которые нужно выделять отдельное время. Заложите эти работы в оценку продуктовой задачи и просто сделайте их вместе с задачей. Тогда, как говорится, и волки будут сыты, и овцы целы. Открыть/Комментировать

2020-03-09 21:38:58 Один удалённо — все удалённо

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

Подсмотрел у команды Miro принцип, помогающий справиться со сложностями: «один удалённо — все удалённо». Если хоть один участник совещания не может присутствовать лично, все остальные тоже подключаются удалённо. Это обеспечивает равные условия и комфорт: все говорят в собственные микрофоны, все видят друг друга (если камеры включены), никто не чувствует себя отчуждённым. Открыть/Комментировать

2020-01-30 23:12:56 Говорить в мире собеседника

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

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

Объясню на примере. Представьте, что человеку нужно сделать сайт, а он в этом ничего не понимает. Он нанимает специалиста и в какой-то момент интересуется, как продвигается работа. Ему отвечают:

> У меня возникли проблемы с модулем кеширования страниц в WordPress, почитал StackOverflow, там рекомендуют обновиться до PHP 7, тем более в нём появились декларации типов, которые очень полезны в разработке. Я обновил PHP, но из-за этого пришлось решать проблемы с новым механизмом обработки ошибок. К счастью, как раз сегодня закончил с этим разбираться и доделал главную страницу, двигаюсь дальше!

Что из этого понятно заказчику:

> доделал главную страницу, двигаюсь дальше!

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

Чтобы не совершать этих ошибок, можно пользоваться двумя приёмами:

1. Отвечать на вопросы максимально коротко, не погружаясь в детали. Собеседник при необходимости переспросит или уточнит важные ему детали.
2. В разговоре ставить себя на место собеседника и стараться оценить, будете ли вы ему понятны.

Это сильно упростит жизнь вам и всем, с кем вы будете разговаривать. Открыть/Комментировать