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

Ну и какой язык у нас более объектно-ориентированный — тот, где объект можно создать литералом, забрать деструктуризаций и накинуть дефолтные параметры (решение в одну строчку) или тот, где для решения этой базовой задачи целый паттерн придумали, который без код комплишена руки устанут набирать? Синк эбаут ит

Для раскрашивания кода на слайдах пользуюсь консольной утилитой highlight. Классно, здорово, но иногда её нет под рукой. Ну и не хватает наглядности. А тут Семён Левенсон подсказал SlidesCodeHighlighter . Неплохо, неплохо.

Пользуйтесь и не вставляйте на слайды скриншоты из IDE. И портянки кода не вставляйте, никто в зале их читать не будет. Мой выбор — verdana 36pt отступ 1.5. Не только видно с последнего ряда, но и не даёт засунуть в слайд слишком много кода.

Глеб Михеев в докладе про contract first упомянул, что этот подход позволяет одновременно стартовать работу фронта и бэка, на что получил резонный комментарий из зала, что важней не начать, а закончить вместе. А чтобы закончить вместе, нужно:
а) точнее прогнозировать
б) устранить узкие места

Как уже ранее писал, одним из наиболее узких мест является тестирование, которое, как правило, начинается когда все компоненты системы готовы. И вот тут нам на помощь приходит статегия тестирования Shift-left. Идея простая — мы должны начасть тестировать как можно раньше. В идеально мире даже раньше разработки. Как это так? Ну так же как мы делаем TDD — разработка ещё не началась, а тесты написаны.

Так-то и TDD, и BDD, и линтеры, и статический анализ, и contract-first и автотесты — всё это вписывается в стратегию shift-left. Мы должны отловить максимум возможных проблем до того как код будет финализирован перед релизом.

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

Пока цены упали, обновил домашнюю машинку с M1 13” на MBP14 M1 Pro 10c 16gb 1Tb (вот такой вот набор цифр и букв). Бомба, конечно. Размер классный, экран запредельный, портов раздолье. Очень хотел 32gb, но их не днём с огнём не отыщешь, а те, что есть, стоят страшно. Благо и на этом летает всё, что нужно.

А зачем обновлял — ну, прежде всего, 2 type-c мне мало. 3 вот прямо на пределе, но уже можно жить. 14 дюймов, опять же, больше, чем 13”, но ещё не такой гроб, как 16”.

Есть у нас один важный эндпоинт, общий для фронт-бэк и для сервер-сервер взаимодействия. Вот только принимает он форму с файлами. Ну вы понимаете, да? Multipart/form-data и, что хуже, никаких контрактов. А уж как приятно тесты на это писать с парсилками текстовых строк в моках.
Разделяйте интерфейсы, господа и дамы, зря вам дядя Боб про ISP рассказывает что ли. Пойду фасады напилю что ли.

«Я не могу тратить много времени на ревью, потому что у меня есть своя работа, вообще-то».

Очень распространённое, очень популярное и в корне, как мне кажется, неверное мнение. Ревью чужого кода это точно такая же часть работы, как и написание собственного. Золотое правило Гитлаба, которым стоит руководствоваться (сам не проверял, но точно слышал от Ильи Климова, что оно существует) — сначала разблокируй других, потом занимайся своими делами.

Стараюсь раза три в день минимум заглядывать в колокольчик гитхаба и очищать инбокс. А лучше, конечно, почаще. Большой минус, что не выходит работать в режиме «сегодня встреч нет, днём погуляю, а вечером всё сделаю». Свою задачу сделаю, а чужие заблокирую. И QA не помогу. И команде на вопросы не отвечу.

Тимлидам совет — при оценке эффективности специалиста не забывайте проверять, насколько человек обращает внимание на что-то, кроме своих непосредственных задач.

На днях читал лекцию для библиотекарей про IT и айтишников. Кто мы такие, с чем нас едят и как нам помочь, когда мы ещё маленькие, но глаза уже горят. Пока готовился — нашёл уникальный артефакт из прошлого, выпуск журнала «Семья и школа» за 1989 год, который познакомил менял с понятием алгоритма.
Делюсь. Собственно, алгоритмические задачи для детей — https://disk.yandex.ru/i/nRbiqN_eBvTcHA

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

В далёком уже 2018 году я читал доклад «Как я полюбил и возненавидел React Native». TL;DR RN даёт потрясающие возможности делать вообще всё силами одной кроссфункциональной команды JS-разработчиков, но, к сожалению, печально сырой. Сырой настолько, что сложно было тогда думать о каком-то продакшене.

Иначе говоря, я влюбился в идею, но был опечален реализацией. Тут я слышу голос Глеба Михеева «да зачем это всё, заворачивайте сайты в webview». Да, можно, но я продолжаю фанатеть от хороших нативных интерфейсов в iOS. Понятное дело, в Android можно любую шляпу отгружать (я почти не шучу), но iOS мы любим за плавность и выверенность. И RN (в отличие от HTML-based и canvas-based) позволяет делать 100% нативные интерфейсы.

В любом случае, выбор в Деньгах тогда был сделан в пользу отдельной команды мобильных разработчиков и мобильных QA. Которые худо бедно, но разгребают огромную очередь задач и пытаются успеть за вебом. А веб пилится и релизится с дикой скоростью. Схема плохая, но рабочая.

И вот на дворе 2021, я наконец-то попадаю в команду, где есть выделенные iOS и Android разработчики. Все фичи пилятся параллельно под 3 фронта, всё здорово. Но в какой-то момент мы теряем iOS-разработчика. Через пару месяцев находим нового и он начинает срочно догонять по фичам. А ещё через пару месяцев нам говорят, что все мобильщики уезжают в отдельную команду, которая будет пытаться разгребать огромную очередь задач и догонять веб. Потому что мобильщиков мало и они дорогие.

Да ёшкин крот.

В продолжение к предыдущему посту. Почему-то я ещё ни разу не встречал команды мобильных разработчиков, которые готовили бы себе BFF. Фронты вот всегда готовы залезть в бэк, только разреши ноду поставить. Нельзя ноду? Ну мы и в джаву готовы залезть. Да и в мобилку готовы, вы только пустите. А вот команды мобильщиков максимум разве что имели (в моём опыте) выделенного джависта, который им накручивал гетвей с mobile API.

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

Делитесь в комментах, как у вас устроено.

Очередная клёвая фича в Idea, появилась кажется совсем недавно. Позволяет в диффах красиво выравнивать код по вертикали.

А давайте расскажу как в Osome организован contract first. Мы держим все контракты в отдельном репозитории, описываем спецификации в формате tinyspec (да, местами сильно жмёт по ряду причин, есть планы с этим что-то делать). Из этой спеки генерируем openapi, а из него уже сваггер, json-schema ts-типы и удобный SDK (вот так вот openapi-ts-sdk).

В итоге получаем такую схему работы:
- PR в репозиторий контрактов с новым эндпоинтом / изменением существующего
- Прогон в CI статических проверок по всем проектам для проверки совместимости с внедряемыми изменениями (условно, не вызовет ли изменение типа поля userId на | undefined проблем)
- Аппрув от всех заинтересованных лиц
- Внедрение и начало работы над фронтом и бэком

Из минусов:
- SDK идёт вперёд реализации. Нет гарантии, что описанный в SDK контракт уже реализован. Т.е. Сваггер не отражает напрямую состояние микросервиса.
- Сваггер общий для всех микросервисов. Понять с какой версией работает конкретный микросервис невозможно (даже если микросервис начнёт отдавать версию установленной в зависимостях SDK это не гарантия, что сам эндпоинт уже реализован)
- Исходя из двух предыдущих пунктов — критические изменения на бэкенде должны выкатываться максимально быстро вслед за изменениями контрактов.
- Иногда нужна сложная цепочка PR (поменять работу с полем в микросервисе, изменить поле в контракте, снова поменять микросервис, снова поменять контракт). Зато ни в какой момент система не будет сломана.
- Мобилки живут на внутренних типах вместо внешних контрактов, проверить статически совместимость с ними (в нашем случае) невозможно

Есть противная проблема с AWS CloudFormation, которую пока не могу победить (не хватает знания). Смотрите, какая фигня получается:

CloudFormation позволяет описывать инфраструктуру как код. Всё хорошо, всё красиво.

Добавляем в приложение новый роут в API Gateway или создаём новую группу логов. Не важно что, важно, что это в коде. Деплоимся, CloudFormation создаёт новый ресурс.

Дальше откатываем на предыдущую версию (например, переключив ветку с нашей feature на main и задеплоив продовую версию.

Вливаем feature в main и деплоим новую версию. И тут получаем

An error occurred: BlaDashblaDashblaLogGroup - Resource handler returned message: "Resource of type 'AWS::Logs::LogGroup' with identifier '{"/properties/LogGroupName":"/aws/lambda/Bla-bla-bla”}’ already exists."

Ну а дальше идём и руками чистим ресурс созданный дев-веткой и катим снова.

Ерунда какая-то. Памагите.

Ко вчерашнему посту.

Немного поясню, почему окружение шатается так сильно, ведь казалось бы, ну как часто у нас меняется конфигурация системы? На самом деле очень часто, если речь идёт о лямбдах. Каждая лямбда это один контроллер, облуживающий 1 роут. Т.е. на лямбду нужно создать и хранилище в S3 и роут в API Gateway и группу в логах. В итоге крупный микросервис стремительно летит к лимиту AWS на количество ресурсов и невозможно просто заводить ресурсы с префиксом feature-ветки — они мгновенно выжрут лимит.

Вообще я часто думаю, насколько было бы проще завернуть всё приложение в одну большую лямбду и роутить уже внутри неё. Тут тебе и все логи в одном месте, и одна запись в API gateway и быстрый деплой и постоянно прогретая лямбда. Да, скейлить уже нужно будет по-старому, всем приложением.

Вот только следующий вопрос сразу возникает — а нафига вообще заворачивать в лямбду, может просто поставить в EC2 нормальное приложение? =)

После выхода WebStorm 2022.2 можно новый UI ставить уже не на EAP и плагин не нужен. Здорово

По идее можно врубить через registry, проверено на idea ultimate 2022.2 :

Open Find Action (Ctrl/Cmd+Shift+A on Win&Linux/Mac respectively).
Type Registry...
Enable the ide.experimental.ui key.
Restart IDE.

Раз уж такая пьянка, то вкину свои копейки. Кент в общем-то говорит простую вещь — хватит мокать всё подряд (stop mocking so much stuff). Чем больше у вас моков в юнитах, тем меньше они отражают реальность в какой-то момент. В Osome мы полностью отказались от юнитов на бэке и пишем только интеграционные (кидаем данные на вход хэндлера и смотрим, что получили на выходе). Сетевые связи с другими микросервисами закрыты через nock.

Заодно сам собой снялся вечный вопрос про тестирование приватных методов. Нет доступа — нет тестов.

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

https://news.1rj.ru/str/msosnovfeed/383

Сегодня и Сергей Сова на бизнес-логику в хуках ругался и в патреоновом чатике JavaScript.Ninja вспомнили прекрасное — useEffect в React 18 срабатывает дважды, если вы в Strict Mode. Вот такая мотивация:

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

* React mounts the component.
* Layout effects are created.
* Effects are created.
* React simulates unmounting the component.
* Layout effects are destroyed.
* Effects are destroyed.
* React simulates mounting the component with the previous state.
* Layout effects are created.
* Effects are created.

[линк]

Вот-вот, помните, вы не управляете хуками. Хуками управляет движок реакта.

В общем-то есть очевидное ишью [Bug: v18 - How to deal with useEffect being called twice in Strict Mode?] где Дэн предлагает не забывать делать cleanup и отменять свои фетчи. Или вообще вообще использовать что-то для дедупликации и кеша запросов.

На худой конец, говорит, отключайте Strict Mode, если вам мешает, мол React 18 важнее, чем сидеть на старой версии.

Ну что значит «отключайте». Отключайте, правьте код, и снова включайте, чтобы быть готовыми к светлому будущему.

Тут в комментах Владимир процитировал Фаулера, а я заметил в цитате старую проблему с пониманием S из SOLID. Забавно, как долго Мартин пытается объяснить, что имел ввиду совсем другое, и как столь же долго практически вся индустрия отказывается принять изначальную трактовку и идёт по более простому пути. Обратимся к Мартину:

===============
«Из всех принципов SOLID наиболее трудно понимаемым является принцип единственной ответственности (Single Responsibility Principle, SRP). Это, вероятно, обусловлено выбором названия, недостаточно точно соответствующего сути. Услышав это название, многие программисты решают: оно означает, что каждый модуль должен отвечать за что-то одно.

Самое интересное, что такой принцип действительно существует. Он гласит: функция должна делать что-то одно и только одно. Этот принцип мы используем, когда делим большие функции на меньшие, то есть на более низком уровне. Но он не является одним из принципов SOLID — это не принцип единственной ответственности.

Традиционно принцип единственной ответственности описывался так:

Модуль должен иметь одну и только одну причину для изменения.
…
Фактически принцип можно перефразировать так:

Модуль должен отвечать за одного и только за одного пользователя или заинтересованное лицо.
…
Окончательная версия принципа единственной ответственности выглядит так:

Модуль должен отвечать за одного и только за одного актора»

Чистая архитектура. Искусство разработки программного обеспечения
Мартин Р.
===============

Почему так случилось и почему изначальная трактовка важна? Для меня весь SOLID это прежде всего архитектурные принципы. Мы задаём границы, описываем правила их пересечения, направление движения данных и контракты. На этом уровне восприятия нас не волнует размер и сложность функций и классов, мы проектируем систему. И в контексте архитектуры системы S (в изначальном понимании Мартина) — очень важно.

Полезная штука:

Если в package.json прописать

"engines": {
"node": ">=16"
"npm": "8"
}

и в .npmrc

engine-strict=true

то npm i на старой node.js выплюнет ошибку Unsupported engine

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

Что-то зачастили предложения консалтинга. А я вот ни капли не чуствую в себе уверенности для того, чтобы давать консультации. В консультациях решает широта опыта, потому что в глубине каждый новый сложный кейс уникален, и требует копания и ещё раз копания. В глубину копать люблю, а на широту внерабочего времени не остаётся. В рабочее же раскачиваться в ширину могут наверное только аутсорсеры, вот эти ребята действительно нюхнули пороху и посмотрели в продакшене на удивительные решения. В этом плане всегда удивляли AMA-сессии от @xanf_dev, Илья может достойно ответить кажется просто на любой вопрос. А я так, теории начитался, да в парочке больших проектов посидел.

Чем больше я знаю, тем больше я понимаю, что ничего не знаю, как говорил Сократ (или не говорил, кто же знает). А за ничего и деньги брать стыдно.