Pull to refresh
2
0.1
Send message

Тесты по TDD обычно пишутся теми же, кто пишет код. Если разработчик неправильно истолковал требования - то и тест, и тестируемый модуль будут содержать ошибку.

Вот если бы тесты писали постановщики задач перед тем как передавать задачу в разработку!.)

Чтобы наверняка узнать на фронте, что контракт поменялся, а вам об этом не сообщили, нужно использовать проверку runtime-типов.

Я плавно подводил к этому)

Как вы считаете, если учесть что:
- фронт и бек пишут разные команды, может даже распределённые географически и во времени
- фронт и бек это разные репозитории
- факт согласования контракта\апи присутствует в любом случае, между лидами фронта\бека или с участием аналитика - неважно
- необходимость шага - оповещения фронт-команды про обновление контракта
- как следствие, необходимость шага - фронту "поправить код" (в рамках отдельной задачи, или в попыхах неважно)

Верно ли следующие, что:

Проще и надёжнее фронтам описывать контракт в своей кодовой базе и валидировать его в рантайме (условный zod делает это в одно "приседание"), и не доверять апи-респонсам также, как и не доверять пользовательскому вводу, поскольку это пограничные слои приложения. Да, будет некое дублирование кода во фронт\бек командах. Зато не будет дополнительного "непонятного\мусорного" кода 50-100кб на фронте. Да, не будет удобной(?) странички сваггера со всеми эндпоинтами, которую бек должен не забывать обновлять. Зато у фронта будет свой, написанный собственноручно контракт со всеми "ручками", а своему коду доверия больше как-то)) И самое главное, что при смене контракта - количество телодвижений остаётся ровно столько же, т.е. два - оповестить фронт, и поправить код фронта. И инструменты вроде swagger-typescript-api никакой рекламируемой автоматизации особо не добавляют (учитывая список моментов выше).

Почему я затеял эту дискусию.. потому что у меня часто подгорает когда на проектах 2+ года всеми любимый сваггер не соответствует действительности.. потому что это завязано на дисциплину бекенд-разработчиков. А фронт страдает.. че не работает?.. а блин Петя забыл аннотацию поправить и вообще сказать что он поменял поля этого ответа чуть-чуть))

Спасибо за ответы.

И да, когда контракт обновляется нужно клиент генерировать заново.

Вот тут не совсем ясен флоу. Был контракт, что возвращается поле user_messages. Потом бекенд-команда переименовала его на userMessages (примем, что они не забыли поменять аннотации в коде, или отредактировать в сваггер-эдиторе).

Факт смены поля.. об этом как-то сообщается, и если да - то в какой момент времени?.. например в слак "парни, мы поменяли поля - все пересоздайте у себя клиенты и поправьте маппинг!"

Или же оно должно дойти до qa или pipeline, там упасть, и только потом вернуться на фронт команду с отдельной задачей - чтоб те пересоздали клиенты и поправили маппинг?

Парочка вопросов:

1. Как описыватеся или генерируется сам контракт.. руками? swagger-editor? комментрии в роутах?

2. Если фронт и бек пишут разные люди - как фронт-команда узнаёт что контракт изменился и нужно пересоздать "клиент"?

Для меня вишенкой на торте стало внезапное понимание старых любимых песен.. типа слушал всю жизнь металлику и слушал.. и тут бац, понимаешь о чём песня.. невероятный кайф)

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

Я как разработчик - постоянно только этим и занимаюсь почему-то)) Иногда мечтаю побыть просто кодером..)

  • Что будет, если 2 компонента вызовут fetch?

зачем в компонентах вызывать fetch? пусть себе компоненты (хоть сотня компонентов) рисуют данные, которые лежат в одном единственном месте.

Всё как обычно - нужно иметь чуйку, когда выделять из общего в частное, а когда обобщать частное в общее (не важно, функции, фронт, бек, инфраструктура, дизайн, бизнес, жизнь..). Также главное не забывать, что - Плоское лучше, чем вложенное.

Последние лет шесть использую mobx. При этом в паре проектов была долгоиграющая задача - буквально переписать с reduxa на mobx.

По ощущениям, mobx - это реально серебряная пуля для проектов любого уровня сложности. Особенно это ощущается на долгосроке, при кардинальных изменениях требований и сценариев.

Мобх также позволяет вообще забить и забыть про апи реакта, про все его useMemo, useCallbackи, useContextы и не следить за этим впринципе. Реакт - используется просто как шаблонизатор с предельно тупыми компонентами. Вся логика в сторах, в ооп-стиле, на обычном javascript, сверху вниз. Никакой функциональной вакханалии. На одном проекте, которому пару лет уже - до сих пор нет ни одного useState-а!!

И да, никаких проблем с дебагом, или проблем "скрытой магии" нет вприницпе.

И ещё плюс - бекенд разработчикам понятен код))

дочитайте, пожалуйста, до конца — вас ждет неожиданная развязка.

Думал, что облачный гейминг победит. GeForce Now, premium account - супер. Конечно, речь не про кибер-спорт.

По возможности нужно анимировать только определенные CSS-свойства: transform, opacity, filter, backdrop-filter.

Хмм, а у меня отпечаталось в памяти что всё-что связано не с позицией и не с размерами - анимировать дорого, т.е. всякие прозрачности, тени, фильтры, заливки, градиенты.

Я обычно представляю чуть наоборот.. Event loop - это как раз один бедолага работник, у которого куча менеджеров со своими задачами.)

Перешёл на другую - лучше перезагрузить.

+1! Что говорит о том, что хождение между страницами - и есть нормальный, равномерный во времени, природный механизм инвалидации кеша. И сам юзер это подсознательно понимает - когда хочет увидеть самые свежие данные.

что такое type и что такое interface. В чем между ними основная разница и что предпочтительнее использовать. К сожалению, последнее мало кто понимает.

Расскажите вашу версию, что предпочтительнее использовать - type или interface (чтоб знать что отвечать на собеседованиях). А то, судя по всему, это просто вопрос принятых соглашений на проекте.

формировались новые команды, но мы не всегда могли аккуратно разграничить зоны ответственности 

Очень интересно, что именно не получалось? Не слушались?))

если у вас несколько команд и большое приложение, микрофронтенды – крутое решение

Неужели настолько "круче", чем обычный административный способ. Собрать лидов команд - сказать "Вася, ты со своими ребятами пилите шапку. А ты Петя со своими - будете делать сайдбар. Ваня, ты со своими джунами - полите ui-kit. А мы будем главную. Каждая команда работает в своей ветке. Если будут пересекающиеся вопросы\фичи - организовываем созвон и обсуждаем".

Удобная локальная разработка: работаешь в рамках одного микрофронтенда

И также для локальной разработки очень часто нужно не рамки одного микрофронтенда, а весь контекст проекта целиком. Иначе ж получится - "ничего не знаю - у меня всё работает")

Не совсем понял про менеджеров и карточки)

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

Также не совсем понял почему именно и что свалится в процессе CI. Вы ш уже административно поделили бизнес на команды. Они ж не просто так названы - команды. Это отдельные единицы со своим внутренним миром, со своими тараканами. Что-то обобщать - верный путь к переопределениям, иф-ам и т.д.

Тут надо посчитать, что дешевле

Именно. Уже ш подсчитали в умных книжках. Если процесс частый и регулярный - делаем автоматизацию. Если раз в пятилетку - нет (копи-паст выгоднее). На самом деле ноги ростут из подсознательного желания чтоб всё и вся соответствовало принципу DRY, и подсознательного желания программиста всё упорядочить и усложнить, даже в жизни..)

 многократное редактирование всех проектов может быть трудозатратным и неэффективным.

Почему многократное? Один раз сообщить всем - "парни, с понедельника у нас новое правило. Обновите свои конфиги, плзз". Разве это "трудозатратно и неэффективно" по сравнению с

и его последующая публикация в репозитории пакетов

и эти изменения автоматически применятся ко всем проектам

Точно автоматически? Или всё-же нужно будет совершить три действия - обновить общий конфиг; сообщить всем что конфиг обновился; и потом командам подтянуть этот конфиг.

Вместо того чтобы править конфигурации в каждом проекте, вы вносите изменения только в Shareable config и публикуете его. Это экономит время и уменьшает затраты на обслуживание.

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

и вы сделаете дополнительную автоматизацию

Вы сделаете high cohesion. Автоматизировать нужно не всё подряд, а то, что регулярно и часто повторяется.

Кнопкам без текста, с свг-шкой внутри добавляю только атрибут title. aria-label обязателен в таком случае?

В очередной раз подтвердил свои наблюдения - что делать общие библиотеки ui-компонентов - зло, и надеятся что оно там что-то кому-то когда-то облегчит жизнь - себя обманывать и оправдывать прожигание ресурсов. Усложнит жизнь - очень вероятно, но врятли облегчит. Это самое последнее про что нужно думать, только если уже совсем "делать нечего" и нужно освоить бюджет и время бизнеса.

каждый дубль элемента — модальное окно, кнопку, инпут — приходилось поддерживать отдельно, на это тратились ресурсы.

Неужели много "ресурсов" тратилось?. Дизайнер решил поменять бордер-радиус у кнопки на 4рх. Создал таску, оповестил всех в общем чате, етс - каждая команда взяла и сделала это у себя в проекте. Это просто, быстро, независимо, понятно и прогнозируемо. Ответственность не размывается. Нет high cohesion. Потом, опа, дизайнер решил в одном проекте чтоб кнопки были красные, а в другом синие.. команды реализовали это отдельно по проектам, не будет мук совести при добавлении if-а в общую библиотеку. Также такой подход легко переживает период смены главных дизайнеров (как правило раз в пару лет) и очередных глобальных редизайнов.

Мой поинт в том, что копи-пастить ui между проектами можно, это меньшее зло, если зло вообще.

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

Из минусов лично для меня выделил следующие:

Дополню. Разработчик там один китаец, которого может збить автобус. И насколько помню - он основной разработчик vue.. соответственно приоритет при решении проблем будет отдавать больше vue чем реакту, чтобы продвигать свою библиотеку.

Information

Rating
2,672-nd
Location
Blégny, Ličge, Бельгия
Registered
Activity