Дизайн-ревью

Я очень люблю код-ревью, свежий взгляд на написанный код — это отлично. Шаринг знаний, все такое.

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

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

#проектирование

Посмотрел доклад «42» Вадима Макишвили. Он совсем не про программирование, а про работу головы. Почему опен-спейсы — это отстой, как правильно отдыхать и вот это все.

#softskills

Надёжность

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

#dia

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

#dia

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

#dia

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

#dia

Ой, как-то спамно получилось, простите.

React Renderer

Я вообще часто ругаю React 🤷‍♂️ но сегодня не буду. Эта библиотека внутри очень красива, там прямо супер-элегатный код местами. И это выливается в такие же (местами) элегантные API. Например, простота, с которой можно написать собственный рендерер (вместо react-dom) поражает.

На днях посмотрел доклад про интеграцию React и Figma. Поразительно!

#фронтенд

На выходных спросил в Твиттере, каким VPN-сервисом стоит попробовать пользоваться, из всех ответов, что я получил, процентов 80 были — подними свой VPN, будет секьюрно, дёшево, кайф.

И это вообще какая-то деформация программистов. Многие разработчики правда пользуются таким вариантом, несмотря на убогий UX, сомнительную надежность и стоимость поддержки (время стоит ведь денег). Многие разработчики тратят кучу времени на настройку идеального окружения разработки, на собирание своего особенного таск-трекера на основе Emacs и вот это все.

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

И посоветуйте, пожалуйста, хороший VPN — чтобы можно было входить из разных стран, приложения были классные и на iOS и на MacOS и чтобы компания была солидная 😇

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

Будете брать? 🤔

Акторы

В Aviasales очень много бекендов написано на Elixir, в этом языке принято писать приложения основанные на акторной модели. Чтобы лучше понимать о чем говорят коллеги, я решил разобраться в ней получше.

Делаю пет-проект, намеренно переусложняя архитектуру акторами, читатю статьи, смотрю доклады. Вот парочка прямо хороших:

+ Моя жизнь с актерами
+ Написание масштабируемых и временами распределённых систем

#проектирование

«Ты сделал говно»

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

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

Представьте, если первоклассник принёс учителю решение, что 2 x 2 = 3, а учитель в ответ выражает просто мягкое неодобрение, но не говорит, что правильно будет 4? Математика никогда не откроется ребёнку как точная наука, скорее ощущение будет «ну, я что-то делаю, что-то, наверное, получается».

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

Важно — именно «ты сделал говно», а не «ты — мудак». Критиковать можно только работу, но не личность.

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

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

Мы сели и усиленно подумали 🤣 результатом стали некоторые глобальные цели команды, и небольшие «проекты» которые соответствуют этим целям.

На этой неделе расскажу подробнее 😌

Цели мы сформулировали в формате «мы верим, что так должно быть».

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

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

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

#кейс

Случилось удивительное — я завел англоязычный твиттер

https://twitter.com/kamyshev_dev

Вдруг вам очень хочется читать мои твиты на английском 💁‍♂️

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

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

С другой стороны, мы движемся к этой задаче со стороны процессов. Раз в две недели собираем всех фронтендров на часовой синк, где рассказываем о новостях и решениях. Примерно раз в пару месяцев собираемся на внутренний фронтендовый митап.

#кейс

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

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

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

#кейс

​​Ноябрьский выпуск подкаста!

Полина Гавра — самая главная по HR в лучшей компании на свете. Я никогда не встречал такой крутой HR-команды, как в Aviasales и очень хотел узнать как это работает. Мы поговорили про зарплаты, бенефиты, найм, увольнения, внутреннее устройство HR-департамента и как заставить высокомерных разработчиков тебя уважать.

Слушайте, пишите фидбеки 💙

О, там к посту кнопка комментов не приложилась, вот тут будет👇

Пишите фидбеки 💙

Астрологи объявили неделю подкастов 🤣

Сходил поговрить истории про собеседования 👇