Вот это инженерный подход. Хорошо что не на голом js стартанули, а взяли неплохие в общем инструменты. Если этим проектом на практике пользуются, то значит не зря старались
С Kubernetes можно создавать Pipeline’ы, то есть объединять весь процесс разработки в единую систему, когда разработчик пишет код, отправляет его в Git в основную ветку, администратор нажимает кнопку, и этот код автоматически отправляется на тестовый стенд
Кесарю кесарево. Работал я в местной фирме, где было 2 QA на условно 15 разрабов, 4-5 активных проектов и 0 авто тестов, QA гоняли тесты по сценарию использования от заказчика. Вряд ли они заранее знали о всех багах, вполне возможно, что кандидатов могли кинуть на тестовом. Другое дело, что не кидали, так как брали в основном местных зарекомендовавших себя студентов (и препов пытались вытащить), да и тестовых не давали. Видно, что модель бизнеса далека от идеалам, тем не менее такое имеет место быть
Сам факт наличия скриптов сборки и развертывания - огромный плюс. А версионирование их - логично, как и версионирование кода. Использование инструментария и машинерии, естественно, зависит от проекта. Где-то и пару строк на bash/powershell достаточно черкануть, и то в качестве документации потомкам, где-то разумно докер образы собирать и разворачивать. Где-то вообще достаточно rsync на боевой сервер (не сильно боевой, конечно, тем не менее бывает и такое). А где-то да, Jenkins агенты спавнятся в облачном кластере кубера, собирают пачки микро сервисов и раскатывают это дело по пачке датацентров. Так что дженкинс, шуршащий в докер контейнере, который крутится в кубера, - не шутка даже ни разу
Непонятно, какой кейс решает эта статья и зачем в такой конфигурации докер, но допустим. Насколько я помню, на хост папки монтируются под рутом, так что либо chmod надо ставить интересный (что,кстати, немедленно отразится в git), либо в ide работать от рута. Ну и дев сервер в докере гонять - уже совсем беда имхо. Для локальной разработки это всё лишние абстракции. Что касается фронта, то если у вас нет SSR, то лучше использовать multistage сборку, где сперва собрать статику, а потом запаковать её в образ с тем же nginx. Что касается сервисов на ноде, образ на основе alpine - не лучший выбор для пакетов с биндингами в нативный код. Могут выскочить лишние ненужные проблемы. Наконец, автор умалчивает о том, как запускать образы в разных конфигурациях окружений. Если с нодой всё довольно просто - можно переменные окружения использовать, то со статикой не всё так очевидно. Я часто сталкивался с тем, что многие вообще не понимают, как это можно реализовать. В общем, есть простор для более глубокого освещения темы
Подход, описанный в статье, делает состояние компонента неявным, в этом соль всей этой истории с передачей пропсов снизу вверх.
Что если components.ContentArea случайно изменится каким-нибудь другим компонентом?
Что если компонент более верхнего уровня будет размонтирован, а компоненты более низкого уровня — нет?
Кроме того, сложнее становится тестировать компоненты независимо, ведь кроме передачи пропсов нужно сформировать подходящий объект components с необходимыми заглушками, ценность этих тестов также падает.
Наконец, хранение ссылок на компоненты в глобальном объекте components, особенно массива ссылок (хоть автор и не рекомендует так делать), приведет к утечкам памяти, поэтому если уж и пользоваться таким подходом, то очень аккуратно, не забываю про очистку ссылок при размонтировании компонентов.
А вообще, в документации к react описано несколько подходов, позволяющих избегать сквозного проброса на несколько уровней вниз, включая использование контекста, рендер-пропсы и прочее, с описанием подводных камней и примерами.
Я думаю, что многие разработчики «морщатся» потому, что на интуитивном уровне понимают, что ваш подход противоречит принципам функционального программирования, в духе которого реакт и написан. И тут уже дискуссия перетекает на высокие материи =))
Почему не useLayoutEffect? Сложности с этим?
Можно просто QR-сканировать, без бар-кода, если я не ошибаюсь
Вот это инженерный подход. Хорошо что не на голом js стартанули, а взяли неплохие в общем инструменты. Если этим проектом на практике пользуются, то значит не зря старались
А также известный тестовый фреймворк Jenkins =)))
Ну и без Кубера тоже можно
Как будто достаточно использовать editorconfig
Кесарю кесарево. Работал я в местной фирме, где было 2 QA на условно 15 разрабов, 4-5 активных проектов и 0 авто тестов, QA гоняли тесты по сценарию использования от заказчика. Вряд ли они заранее знали о всех багах, вполне возможно, что кандидатов могли кинуть на тестовом. Другое дело, что не кидали, так как брали в основном местных зарекомендовавших себя студентов (и препов пытались вытащить), да и тестовых не давали. Видно, что модель бизнеса далека от идеалам, тем не менее такое имеет место быть
Сам факт наличия скриптов сборки и развертывания - огромный плюс. А версионирование их - логично, как и версионирование кода. Использование инструментария и машинерии, естественно, зависит от проекта. Где-то и пару строк на bash/powershell достаточно черкануть, и то в качестве документации потомкам, где-то разумно докер образы собирать и разворачивать. Где-то вообще достаточно rsync на боевой сервер (не сильно боевой, конечно, тем не менее бывает и такое). А где-то да, Jenkins агенты спавнятся в облачном кластере кубера, собирают пачки микро сервисов и раскатывают это дело по пачке датацентров. Так что дженкинс, шуршащий в докер контейнере, который крутится в кубера, - не шутка даже ни разу
Непонятно, какой кейс решает эта статья и зачем в такой конфигурации докер, но допустим. Насколько я помню, на хост папки монтируются под рутом, так что либо chmod надо ставить интересный (что,кстати, немедленно отразится в git), либо в ide работать от рута. Ну и дев сервер в докере гонять - уже совсем беда имхо. Для локальной разработки это всё лишние абстракции. Что касается фронта, то если у вас нет SSR, то лучше использовать multistage сборку, где сперва собрать статику, а потом запаковать её в образ с тем же nginx. Что касается сервисов на ноде, образ на основе alpine - не лучший выбор для пакетов с биндингами в нативный код. Могут выскочить лишние ненужные проблемы. Наконец, автор умалчивает о том, как запускать образы в разных конфигурациях окружений. Если с нодой всё довольно просто - можно переменные окружения использовать, то со статикой не всё так очевидно. Я часто сталкивался с тем, что многие вообще не понимают, как это можно реализовать. В общем, есть простор для более глубокого освещения темы
Что если components.ContentArea случайно изменится каким-нибудь другим компонентом?
Что если компонент более верхнего уровня будет размонтирован, а компоненты более низкого уровня — нет?
Кроме того, сложнее становится тестировать компоненты независимо, ведь кроме передачи пропсов нужно сформировать подходящий объект components с необходимыми заглушками, ценность этих тестов также падает.
Наконец, хранение ссылок на компоненты в глобальном объекте components, особенно массива ссылок (хоть автор и не рекомендует так делать), приведет к утечкам памяти, поэтому если уж и пользоваться таким подходом, то очень аккуратно, не забываю про очистку ссылок при размонтировании компонентов.
А вообще, в документации к react описано несколько подходов, позволяющих избегать сквозного проброса на несколько уровней вниз, включая использование контекста, рендер-пропсы и прочее, с описанием подводных камней и примерами.
Я думаю, что многие разработчики «морщатся» потому, что на интуитивном уровне понимают, что ваш подход противоречит принципам функционального программирования, в духе которого реакт и написан. И тут уже дискуссия перетекает на высокие материи =))