Раз уж такая пьянка, то вкину свои копейки. Кент в общем-то говорит простую вещь — хватит мокать всё подряд (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

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

Ах да, наконец-то скажем, кто и как победил в ctf.

В Barking store наткнулся на шапочку архитектора.

Одна из самых больших проблем в запоминании принципов SOLID (если вы зачем-то хотите их запомнить) — это буква L, (LSP, Liskov substitution principle, или принцип подстановки Барбары Лисков). Каноническое определение его скучно до зевоты: Пусть q(x) является свойством, верным относительно объектов x некоторого типа T. Тогда q(y) также должно быть верным для объектов y типа S, где S является подтипом типа T.

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

Наиболее простой способ понять этот принцип — это проблема квадрата и прямоугольника. Квадрат нельзя наследовать от прямоугольника, потому, что после этого мы теряем свойство родителя (независимое управление длинами сторон X и Y). У квадрата стороны равны, у прямоугольника нет. Сторонами прямоугольника можно управлять раздельно, и квадратом не заткнуть любую дырку, которую может занять прямоугольник.

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

Итого, если вы отнаследовались от какого-то класса и переписали его методы так, что ваш новый класс ведёт себя иначе и не может заменить родителя в коде — вы нарушили LSP.

https://news.1rj.ru/str/xufostation/772

Цитата с Хабра

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

После сегодняшнего обсуждения лямбда-боли:
——
думаю, что мы придём к тому, что будет одна лямбда для всего http и отдельным опциональным лямбдам там, где нужен s2s
——

Предложил сразу встроить фастифай и позже отправить это в кубер :troll_mode_activated:

Кстати, если среди читающих есть опытные пользователи лямбд — поделитесь в комментах: пакуете ли вы все HTTP-лямбды в одно приложение с внутренним роутингом, слушающее корневой роут в API Gateway, или разделяете на множество мелких «контроллеров», обслуживающих отдельные роуты?

Первый раз за несколько месяцев написал

let

. Но потом одумался и вынес код в функцию.

После того как команда Платформы разделила монорепу фронтенда (неудобно же работать в монорепе!) на полирепу с микрофронтами, каждая бизнесовая команда тихонько начала пилить свои маленькие монорепы (ну удобно же работать в монорепе!).

«Простота — это великая добродетель, но она требует напряженной работы, чтобы её достичь и образование, чтобы оценить. И к сожалению, сложность продается легче.» — Дейкстра.

—

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

Кажется, что раз решение сложное — то в него вложено больше труда и значит оно должно быть лучше.

Это, конечно, не так. Процитирую Паскаля: «если бы у меня было больше времени, я бы написал письмо покороче».

В программировании ровно то же самое: простые решения требуют гораздо больше интеллектуальных усилий, приходят с опытом.

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

—

Отличная статья об этом феномене на примере научных статьей в области машинного обучения. Спасибо Игорю за наводку.

Вот Виктор Хомяков на Субботнике подтверждает мнение, что JS не лучший выбор для FP с точки зрения перфоманса и лимитов памяти (ох уж эти цепочки map().filter().reduce() и прочие спреды). Да, Ramda может немного упростить жизнь но фундаментальные противоречия отсутствия оптимизации хвостовой рекурсии (кроме Сафари) и иммутабельных структур на уровне движка непреодолимы.

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

Вот правда, дизайн Server Push ставил в тупик с первого дня, однако дотащили же до прода. Зачем, кто это форсил — непонятно.

https://news.1rj.ru/str/daily_geek_news/197