Есть у нас один важный эндпоинт, общий для фронт-бэк и для сервер-сервер взаимодействия. Вот только принимает он форму с файлами. Ну вы понимаете, да? 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, Илья может достойно ответить кажется просто на любой вопрос. А я так, теории начитался, да в парочке больших проектов посидел.

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

Из утреннего чатика:

Андрей: Ссылка для отпускников и безработных https://teamlead.wrike.tech/

Олег: прикольно, только не понимаю, почему тимлид всегда ревьюит всех ? чот странно

Илья: Вчера аудиторы спрашивали, у вас типа какой то руководитель код смотрит перед мержем.
Я даже растерялся

Андрей: Еслинт Приттирович Сонаров смотрит

——
Только так. И точка.

Кстати, у Сонара есть плагин для eslint https://github.com/SonarSource/eslint-plugin-sonarjs

Статья для субботнего утра. Мощные аргументы Вильяма в защиту SPA.
https://williamkennedy.ninja/javanoscript/2022/05/03/in-defence-of-the-single-page-application/

Для меня архитектура — это как сделать сегодня так, чтобы не было мучительно больно завтра. Если про завтра не думать, то и архитектура не нужна. Например, по таким законам живут MVP и одноразовые промо-странички. https://news.1rj.ru/str/artalog/340

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

С моей точки зрения, каждый раз, когда я встречал API, позволяющий мне создавать элегантный код, он заканчивался кошмарной кодовой базой, полной неподдержимого спагетти-кода.»

—- в этой части автор ругает миддлвары. Пропустим очевидное —-

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

https://insertafter.com/en/blog/no_more_middlewares.html