Контракты — это ещё один способ увеличить надежность программы. Это и валидация, и парсинг, и проверка типов. Класс! Но мне всегда казалось, что в JS-мире это неудобно и костыльно.

Сегодня посмотрел доклад Контрактное программирование как средство, а не цель, который меня переубедил.

#фронтенд

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

https://www.notion.so/kamyshev/4ab00ab272e144a69a10242e826dad72?v=6f679602f9ad41f0913dc638bcfc1aab

Стоит ли тут рассказывать о новых заметках в этом документе?
anonymous poll

Да 🤓 – 149
👍👍👍👍👍👍👍 96%

Нет 🤫 – 7
▫️ 4%

👥 156 people voted so far.

Сегодня утром посмотрел крутой доклад про архитектуру — Быстрорастворимое проектирование.

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

В докладе весь код приводится на C#, но подходы применимы к любому языку (с небольшими правками, конечно)

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

На прошлой неделе писал про мои заметки с быстрыми решениями, добавил туда новую напоминалку — про JS-функцию, которая типографирует русские тексты.

https://www.notion.so/kamyshev/036b55da6eb44540b941d66c07e0857b

#js

Массово выкидываем старый код

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

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

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

#кейс #рефакторинг

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

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

В Самокате у нас был примерно такой флоу релиза:
+ планируем версию, накидываем таски, которые в неё попадут;
+ каждая таска проходит через 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