Одержимость тестированием

Ниже речь пойдет только о веб-приложениях, которые легко и безболезненно деплоить.

В Самокате у нас был примерно такой флоу релиза:
+ планируем версию, накидываем таски, которые в неё попадут;
+ каждая таска проходит через QA;
+ когда все таски сделаны, собираем контейнер версии, которую собираемся релизить;
+ QA делают регрессионное тестирование;
+ катим в продакшн;
+ QA делают смоук-тест.

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

В Aviasales все устроено совсем иначе. Разработчик делает таску, другой разработчик ее тестирует и заодно смотрит код, после — катим таску на продакшн, потом ещё 10 минут смотрим за фоном ошибок и метриками.

В такой парадигме код доставляется клиентам сильно быстрее. А самое удивительное, что и багов больше не стало. Мне подход «смелых релизов» нравится больше.

#кейс #тестирование

Мы там в чатике обсуждали последний пост и я понял, что он получился не полным. Продолжение 👇

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

Просто 95% задач не такие и с ними можно обращаться проще.

Современный бэкенд для фронтенда на Node.js

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

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

Нот май бизнес

Некоторые разработчики панически бояться трогать соседние области. Например, я не раз встречал фронтендеров, которые категорически отказывались писать Node.js скрипты.

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

Например, если в компании много кода на Go, даже фронтендерам стоит научиться читать его. Если фронтенед сделан на React, продактам лучше представлять себе, что такое компонентный подход.

В первую очередь, это упрощает коммуникацию. А коммуникация — самое важное в командной работе.

#softskills

Начал читать новую книгу — Высоко-нагруженные приложения.

Она в основном о приложениях, нагруженных данными — data-intensive applications. Это когда основная проблема в приложении — качество данных, их сложность или скорость обновления. Главные качества DIA — надёжность, масштабируемость и удобство сопровождения.

Как обычно, буду публиковать сюда конспекты (не часто, читаю очень неспешно).

#dia

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

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

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

#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 там представила новые макбуки и рассказывает, что они идеальны для кодинга. Меня, конечно, терзают сомнения — не уверен, что все будет гладко работать на новых процессорах.

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