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

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

Вообще, в нашей довольно сложной области любые абсолютные истины вызывают вопросики. Для меня слишком стронг опинион — признак инженера со слабыми софт-скиллами. Ну, может, я просто пусси ¯\_(ツ)_/¯

#softskills

​​В третьем выпуске подкаста, я позвал Сару Долган из Злых марсиан — компании с огромной Ruby-экспертизой.

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

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

PiterJS #46

Посмотрел уже довольно старый PiterJS и хочу посоветовать вам тоже.

Там три доклада:
1. про разработку UI компонентов — базовые принципы, которые помогают делать это быстро и получать поддерживаемый результат;
2. обзор способов повышения перформанса веб-приложений — освещены все варианты, начиная от веб-воркеров и заканчивая микро-оптимизациями;
3. прекрасный доклад про $mol — такие доклады всегда одинаково веселые, а в этом ещё и пара интересных решений относительно типизации CSS-in-JS библиотек.

https://youtu.be/FMNLN5YIE_M

#фронтенд

Люди работают с людьми

Недавно в чатике напомнили, что три года назад Женя Родионов делал просто восхитительные видосы про культуру работы и производство продуктов.

Посмотрите их, они классные — https://www.youtube.com/c/EvgenyRodionov/videos

#softskills #рост

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

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

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

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

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

Посмотрел доклад «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

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

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

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

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

#кейс