Ну давайте делать вотерфолл... когда лет через 5 будет готова спецификация, вдруг окажется что оно уже и не актуально... или же конкуренты вышли на рынок раньше. Это бизнес в конце концов.
Мы должны смириться с тем что увы, никто не знает как писать код или создавать бизнес с нуля правильно, без багов, и что бы подходил всем. Это так не работает. Слишком много unknowns.
Бизнес это управление рисками и с одной лишь целью - заработать денег. Поэтому если бизнесу выгодно что-то, ему как бы все равно нравится ли это программисту/отдельному клиенту или нет.
И в этом примере, если бизнесу выгоднее что-бы какой-то условный индус с суппорта потратил час чтобы исправить вручную какую-то конкретную проблема конкретного человека чем тратить час работы программиста на баг, который приходит раз в год - то со стороны бизнеса это правильное решение.
Я не знаю в каких компаниях вы работали, но так работает бизнес. Там другие метрики, риски и т.д.
Компания физически не может вот взять и все починить. Я не знаю если вы программист, но по вашей логике, глядя на бэклог багов MySQL, все должны тут-же плюнуть и отказаться от нее... а то глючная штука.
Еще раз. Если компания может позволить потерять вас из-за этих багов, то все нормально. Это бизнес и ничего более. Скорее всего есть баги из-за которых компания рискует потерять больше, и они в приоритете.
У вас всегда есть выбор перейти к другой компании где все программисты пишут продукт без багов...
Для начала нужно не создавать эти проблемы. Идея иметь общий код/модели/схемы вотевер чтобы сэкономить что-то там в конце концов обернется выстрелом в ногу или в голову.
И да, я не против BFF. Бизнес логика на клиенте это почти всегда катастрофа. Да и тут вроде понятно в чем минусы-плюсы.
Я против Shared types... нахавались... но опять же, это немного холиварная тема. Мы страдали потому что много разработчиков, продуктов, апишек, клиентов, требований, версийб багов...
Да нет. Как минимум в микро-сервисной архитектуре. В идеале не должно быть общих зависимостей. Ни моделей данных базы, ни dto, ни чего либо еще. Все должно быть по максимуму независимым.
Создание зависимостей, как вы их не назовите - останутся зависимостями и может выйти боком. Версионирование, разный цикл разработки и релизов различных сервисов в конце упрется в эти зависимости.
Хотя возможно для каких-то проектов это и будет работать.
Вот убейте меня, но я все никак не пойму. Бэкендисты столько страдали, чтобы прийти к таким паттернам архитектуры как микросервисы, разделения всего и вся - от базы до моделей и обратно. И все равно придет кто-то да и посоветует делать shared dependencies.
И как бы сексуально это не выглядело, по моему личному опыту shared stuff это всегда проблемы. Это всегда зависимость от чего-то или кого-то еще.
Я тоже жаловался раньше. Все дураки. Подумаешь там формочку исправить. Это ж минутное дело. А теперь сам работают в сравнительно большом стартапе. У нас этих маленьких проблем в бэклоге - лет на 10 хватит. Поэтому прекрасно понимаю почему где-то есть глюки и их не исправляют.
В конце концов это все приорити и естимейшены, и вы с вашим опытом должны то это понимать.
По мне так влияние количество правок на направление зависимостей выглядит странно. ИМХО контекст намного важнее. А то по вашей логике, если у меня есть http клиент который инжектится но изменяется часто, я должен инжектить бизнес логику в него?
В любом нормально языке Circular Dependency решается 2мя способами.
1. Объединение 2ух файлов/классов вотевер в одине файл/класс/пекедж 2. Интерфейсами
Потому что есть легаси. Потому что фреймворки меняются. Есть фреймворки без встроенной магии DI контейнеров. Если нужно либу написать/подправить и т.д. Забери фреймворк, и человек беспомощен.
Не все же простенькие крад ендпоинты пишут. Есть вещи чуть посложнее, и хотелось бы чтобы человек понимал принципы. Фреймворк должен быть лишь инструментом.
Понимая принципы мне например все равно на каком фреймворке писать. Я их даже не "учу". Для меня это такая же "либа" с документацией.
А вот когда человек не понимает принципов, он реально "учит" фреймворк...
На бэкенде JS тоже самое. Приходит человек который работал с фреймворком X. Начинаешь спрашивать че да как там. Ну вот например вроде человек и знает что есть такая штука как dependency injection, а для чего он в принципе нужен объяснить не может. Вот он умеет им пользоваться во фреймворке, и все. Забери фреймворк - и начнутся обычные require() везде и вся... потому что человек учил фреймворк а не общие принципы и практики.
Мне кажется что в больших компаниях процессы в принципе настолько медленные что ожидание билда от нескольких часов до нескольких дней это норма.
А вот в небольших компаниях и стартапах где надо очень быстро делать деливери, очень чувствуется когда ты на задачу потратил 5 минут и потом пол дня деплоишь это чудо.
Понятно что с микро-репозиториями свои проблемы и сложности. Но там они возникают в конкретных случая и как бы выше на уровне шеред стафф и интерфейсов взаимодействия.
Да, если возможно в монорепо сделать так что реально тестируется только код который изменился и только сервисы использующие эти тесты то по идее нужно будет только ждать тесты при создании пиара (при условии что другие команды реально коммитят только в свои файлики и они не затронут тебя и не затриггерят твои тесты). Тогда придется ждать только мерж который в принципе быстрый. Вот только это сложно сделать в монорепо с монолитом + отдельные сервисы + shared dependencies и т.д. Ну и nodejs в придачу =))
Рально не знаешь где выстрелит. Поэтому приходится прогонять все тесты и билдить все и вся внутри :/
Решили что отдельные репы будет быстрее организовать. Хотя да, не очень удобно для разработчика. Когда все стянул с одного репо и у тебя все в одной папочке, удобнее. Но вроде привыкли уже. Но самое главное что боль уходит и теперь свои фичеры можно задеплоить за 5 минут.
Еще отдельная боль как результат того что билдится все и вся в монорепо - со временем появились тесты которые падают рендомно и никто не знает как их чинить. А те кто их писал уже не работают тут. Бывает задеплоить одну строчку кода берет пол дня потому что оно падает а ответственного за этот код хрен найдешь.
з.ы.
Возможно это только я замечаю, но мне кажется что отдельные репо тоже могут стать боттлнеком который в конце концо перевесит боттлнеки монорепо. Возможно при 200+ репо лучше подождать монорепо. Поэтому сейчас мы не делаем репо пер сервис а что-то вроде репо пер домейн где в своем домене можно шерить код, и там находятся свои воркеры, скедулеры и хттп сервисы. Но мы не ентерпрайз, еще стартап. Что будет лет через 5? Кто знает... Просто не первый раз читаю статьи о возвращении к монорепо но вот четкие метрики по которым можно принять решение не вижу.
У нас раз в 1000 меньше кода, разработчиков и пул реквестов. Но мы деплоим в веб. И мы ушли от монорепо. Еще не до конца, ибо распиливаем. Но новые сервисы в новых рипо по доменам. Не суть.
Одна из главных причин ухода от монорепо это ожидание своей очереди мержа в мастер и последующего деплоя.
То есть:
Ты создал пиар
Запустились тесты и если все хороше можешь мержить
Но пока твои билды бежали кто то уже замержил свой бранч в мастер, и там соответственно опять пробегаются тесты, билд и т.д.
Делаешь апдейт мастера в свой бранч и ждешь опять пока все тесты пробегут
Пытаешь опять замержить в мастер - а там опять кто то успел свой бранч запихнуть.
Надоело... Почему я должен ждать всех если изменения у меня в моем небольшом сервисе?
Понятно что можно автоматизировать. Но все равно придется ждать всех. А мы стартап. И так много проблем а тут еще и деплой ждать чтобы потом проверить все ли там норм.
С отдельными репо, небольшими, ты не зависишь от других команд и разработчиков.
Сколько у вас разработчик ждет от нажатия кнопки "деплой" (не уверен что это слово подходит в вашем случае) до нотификации - готово?
Я так понимаю в ваших масштабах билды как в интеле могут бежать от нескольких часов до суток и ожидание каких-то пару часов мержа вообще не проблема?
Возьмите любой стартап до 4 лет. Да и старше, если стартап все еще не выстрелил и нет денег на переписывание. Там будет все это и еще больше. Вот вам навскидку:
Логи? Нахрен надо. Х...к х..к и в продакшен. Кому нужны эти логи?
Тернарный оператор - чем длиннее строка тем лучше. А еще если там функция вызывает функцию с параметром где тоже тернарный оператор и вызывается другая функция - это будет вишенкой на торте.
Прочитал про функциональное программирование? Давай засовывай замыкание и каррирование где надо и где не надо. А, мутации... точно, делай клон всему и вся, память то бесконечная. А еще ко всему этому прицепи какую нибудь либу типа рамды и стримов, чтобы никто не смог продебажить это творение.
Используй везде и только примитивы и булианы. Ведь если функция которая что-то проверяет возвращает false, вряд ли завтра или даже сегодня ты захочешь знать почему она вернула false. А передавать 10+ параметров в функцию однозначно лучше упаковки их в объект... объекты они страшные. А деньги можно и в переменно price передавать. И рядом отдельную переменную currency. Зачем еще один лишний объект в системе.
Возвращай разные объекты из функций. Это круто когда ты можешь получить массив когда результатов много, и один объект когда результат один.
Так же у тебя есть возможно назвать параметр функции listingId, и в функции проверять если там массив то делай одно, а если нет - другое. Ведь нет вероятности того что следующая функция будет понимать только стринг а не массив, и что кто-то просто туда предаст это переменную.
Проходясь по легаси коду стартапов где главное - быстро в продакшен все пихнуть, можно книгу написать...
Как рассказал Singh в беседе с Stat News, отчасти проблема в том, как разрабатывался алгоритм Epic. Он диагностирует сепсис, исходя из момента выставления врачом счета на лечение, что необязательно совпадает с моментом, когда пациент впервые ощутил симптомы.
За эту бизнес идею наверное кто-то еще и бонус получил...
А вообще, глядя на то как разработчики относятся к алертам, особенно к ложным срабатываниям, я уже представляю врачей которые игнорят сообщения о потенциальной проблеме у пациента... но надеюсь я неправ и врачи ответственнее нас.
Возьму на заметку. Как раз у нас в компании поняли что написание и поддержка документации это тоже работа. Но, мы уже год не можем выбрать единственную платформу которая подходила бы для
1. Написания сухой документации аля отправьте это — получите то
2. Описания юз кейсов и различных флоу
3. Публикацию бест практис в виде статей
4. Хороший поиск
5. Вставка и форматирование кода
6. Можно было бы разделять внутреннюю документации дл] инженеров от публичной которую мы даем партнерам.
Сейчас у нас документация разбросана по гиту (wiki), wix и собственный статический сайт где нужно коммитить изменения в репо и деплоить.
Спасиб. Ща глянул, он вроде как даже умеет с консулом дружить, где у нас регистрируются сервисы. Надо будет поиграться. Retries, rate limit, circuit breaker. Вкусная штука. Будем обсуждать с девопсами =)
Как будто это что-то плохое.
Ну давайте делать вотерфолл... когда лет через 5 будет готова спецификация, вдруг окажется что оно уже и не актуально... или же конкуренты вышли на рынок раньше. Это бизнес в конце концов.
Мы должны смириться с тем что увы, никто не знает как писать код или создавать бизнес с нуля правильно, без багов, и что бы подходил всем. Это так не работает. Слишком много unknowns.
Бизнес это управление рисками и с одной лишь целью - заработать денег. Поэтому если бизнесу выгодно что-то, ему как бы все равно нравится ли это программисту/отдельному клиенту или нет.
И в этом примере, если бизнесу выгоднее что-бы какой-то условный индус с суппорта потратил час чтобы исправить вручную какую-то конкретную проблема конкретного человека чем тратить час работы программиста на баг, который приходит раз в год - то со стороны бизнеса это правильное решение.
Я не знаю в каких компаниях вы работали, но так работает бизнес. Там другие метрики, риски и т.д.
Компания физически не может вот взять и все починить. Я не знаю если вы программист, но по вашей логике, глядя на бэклог багов MySQL, все должны тут-же плюнуть и отказаться от нее... а то глючная штука.
https://bugs.mysql.com/search.php?search_for=&status=Open&severity=all&limit=All&order_by=&cmd=display&direction=ASC&os=0&phpver=&bug_age=0
Жизнь она немного сложнее. Сделать можно все. Это лишь вопрос времени и денег.
Еще раз. Если компания может позволить потерять вас из-за этих багов, то все нормально. Это бизнес и ничего более. Скорее всего есть баги из-за которых компания рискует потерять больше, и они в приоритете.
У вас всегда есть выбор перейти к другой компании где все программисты пишут продукт без багов...
Именно. Как показывает практика - не лучше. На эту тему много в интернете написано. Кажется контр-интуитивно. Как это!? А как же DRY?
По факту, это то что дает независимость. Естественно не бесплатно. Поэтому у ваш должно быть достаточно тестов чтобы предотвращать всякие инциденты.
У вас в сервисе ордер будут свои DTOошки, свои модели данных базы и т.д. Даже если сегодня они выглядят одинаково (так же как и в сервисе users).
Для начала нужно не создавать эти проблемы. Идея иметь общий код/модели/схемы вотевер чтобы сэкономить что-то там в конце концов обернется выстрелом в ногу или в голову.
И да, я не против BFF. Бизнес логика на клиенте это почти всегда катастрофа. Да и тут вроде понятно в чем минусы-плюсы.
Я против Shared types... нахавались... но опять же, это немного холиварная тема. Мы страдали потому что много разработчиков, продуктов, апишек, клиентов, требований, версийб багов...
Да нет. Как минимум в микро-сервисной архитектуре. В идеале не должно быть общих зависимостей. Ни моделей данных базы, ни dto, ни чего либо еще. Все должно быть по максимуму независимым.
Создание зависимостей, как вы их не назовите - останутся зависимостями и может выйти боком. Версионирование, разный цикл разработки и релизов различных сервисов в конце упрется в эти зависимости.
Хотя возможно для каких-то проектов это и будет работать.
Вот убейте меня, но я все никак не пойму. Бэкендисты столько страдали, чтобы прийти к таким паттернам архитектуры как микросервисы, разделения всего и вся - от базы до моделей и обратно. И все равно придет кто-то да и посоветует делать shared dependencies.
И как бы сексуально это не выглядело, по моему личному опыту shared stuff это всегда проблемы. Это всегда зависимость от чего-то или кого-то еще.
Переубедите меня Ж)
Я тоже жаловался раньше. Все дураки. Подумаешь там формочку исправить. Это ж минутное дело. А теперь сам работают в сравнительно большом стартапе. У нас этих маленьких проблем в бэклоге - лет на 10 хватит. Поэтому прекрасно понимаю почему где-то есть глюки и их не исправляют.
В конце концов это все приорити и естимейшены, и вы с вашим опытом должны то это понимать.
По мне так влияние количество правок на направление зависимостей выглядит странно. ИМХО контекст намного важнее. А то по вашей логике, если у меня есть http клиент который инжектится но изменяется часто, я должен инжектить бизнес логику в него?
В любом нормально языке Circular Dependency решается 2мя способами.
1. Объединение 2ух файлов/классов вотевер в одине файл/класс/пекедж
2. Интерфейсами
Потому что есть легаси. Потому что фреймворки меняются. Есть фреймворки без встроенной магии DI контейнеров. Если нужно либу написать/подправить и т.д. Забери фреймворк, и человек беспомощен.
Не все же простенькие крад ендпоинты пишут. Есть вещи чуть посложнее, и хотелось бы чтобы человек понимал принципы. Фреймворк должен быть лишь инструментом.
Понимая принципы мне например все равно на каком фреймворке писать. Я их даже не "учу". Для меня это такая же "либа" с документацией.
А вот когда человек не понимает принципов, он реально "учит" фреймворк...
ИМХО
На бэкенде JS тоже самое. Приходит человек который работал с фреймворком X. Начинаешь спрашивать че да как там. Ну вот например вроде человек и знает что есть такая штука как dependency injection, а для чего он в принципе нужен объяснить не может. Вот он умеет им пользоваться во фреймворке, и все. Забери фреймворк - и начнутся обычные require() везде и вся... потому что человек учил фреймворк а не общие принципы и практики.
Pegasus производства израильской компании
NGOмогли оказаться телефонные номера Макрона и 14 других глав государств.NSO
Мне кажется что в больших компаниях процессы в принципе настолько медленные что ожидание билда от нескольких часов до нескольких дней это норма.
А вот в небольших компаниях и стартапах где надо очень быстро делать деливери, очень чувствуется когда ты на задачу потратил 5 минут и потом пол дня деплоишь это чудо.
Понятно что с микро-репозиториями свои проблемы и сложности. Но там они возникают в конкретных случая и как бы выше на уровне шеред стафф и интерфейсов взаимодействия.
Да, если возможно в монорепо сделать так что реально тестируется только код который изменился и только сервисы использующие эти тесты то по идее нужно будет только ждать тесты при создании пиара (при условии что другие команды реально коммитят только в свои файлики и они не затронут тебя и не затриггерят твои тесты). Тогда придется ждать только мерж который в принципе быстрый. Вот только это сложно сделать в монорепо с монолитом + отдельные сервисы + shared dependencies и т.д. Ну и nodejs в придачу =))
Рально не знаешь где выстрелит. Поэтому приходится прогонять все тесты и билдить все и вся внутри :/
Решили что отдельные репы будет быстрее организовать. Хотя да, не очень удобно для разработчика. Когда все стянул с одного репо и у тебя все в одной папочке, удобнее. Но вроде привыкли уже. Но самое главное что боль уходит и теперь свои фичеры можно задеплоить за 5 минут.
Еще отдельная боль как результат того что билдится все и вся в монорепо - со временем появились тесты которые падают рендомно и никто не знает как их чинить. А те кто их писал уже не работают тут. Бывает задеплоить одну строчку кода берет пол дня потому что оно падает а ответственного за этот код хрен найдешь.
з.ы.
Возможно это только я замечаю, но мне кажется что отдельные репо тоже могут стать боттлнеком который в конце концо перевесит боттлнеки монорепо. Возможно при 200+ репо лучше подождать монорепо. Поэтому сейчас мы не делаем репо пер сервис а что-то вроде репо пер домейн где в своем домене можно шерить код, и там находятся свои воркеры, скедулеры и хттп сервисы. Но мы не ентерпрайз, еще стартап. Что будет лет через 5? Кто знает... Просто не первый раз читаю статьи о возвращении к монорепо но вот четкие метрики по которым можно принять решение не вижу.
Вы же бинарники компилируете? Не веб-сервисы?
У нас раз в 1000 меньше кода, разработчиков и пул реквестов. Но мы деплоим в веб. И мы ушли от монорепо. Еще не до конца, ибо распиливаем. Но новые сервисы в новых рипо по доменам. Не суть.
Одна из главных причин ухода от монорепо это ожидание своей очереди мержа в мастер и последующего деплоя.
То есть:
Ты создал пиар
Запустились тесты и если все хороше можешь мержить
Но пока твои билды бежали кто то уже замержил свой бранч в мастер, и там соответственно опять пробегаются тесты, билд и т.д.
Делаешь апдейт мастера в свой бранч и ждешь опять пока все тесты пробегут
Пытаешь опять замержить в мастер - а там опять кто то успел свой бранч запихнуть.
Надоело... Почему я должен ждать всех если изменения у меня в моем небольшом сервисе?
Понятно что можно автоматизировать. Но все равно придется ждать всех. А мы стартап. И так много проблем а тут еще и деплой ждать чтобы потом проверить все ли там норм.
С отдельными репо, небольшими, ты не зависишь от других команд и разработчиков.
Сколько у вас разработчик ждет от нажатия кнопки "деплой" (не уверен что это слово подходит в вашем случае) до нотификации - готово?
Я так понимаю в ваших масштабах билды как в интеле могут бежать от нескольких часов до суток и ожидание каких-то пару часов мержа вообще не проблема?
Возьмите любой стартап до 4 лет. Да и старше, если стартап все еще не выстрелил и нет денег на переписывание. Там будет все это и еще больше. Вот вам навскидку:
Логи? Нахрен надо. Х...к х..к и в продакшен. Кому нужны эти логи?
Тернарный оператор - чем длиннее строка тем лучше. А еще если там функция вызывает функцию с параметром где тоже тернарный оператор и вызывается другая функция - это будет вишенкой на торте.
Прочитал про функциональное программирование? Давай засовывай замыкание и каррирование где надо и где не надо. А, мутации... точно, делай клон всему и вся, память то бесконечная. А еще ко всему этому прицепи какую нибудь либу типа рамды и стримов, чтобы никто не смог продебажить это творение.
Используй везде и только примитивы и булианы. Ведь если функция которая что-то проверяет возвращает false, вряд ли завтра или даже сегодня ты захочешь знать почему она вернула false. А передавать 10+ параметров в функцию однозначно лучше упаковки их в объект... объекты они страшные. А деньги можно и в переменно price передавать. И рядом отдельную переменную currency. Зачем еще один лишний объект в системе.
Возвращай разные объекты из функций. Это круто когда ты можешь получить массив когда результатов много, и один объект когда результат один.
Так же у тебя есть возможно назвать параметр функции listingId, и в функции проверять если там массив то делай одно, а если нет - другое. Ведь нет вероятности того что следующая функция будет понимать только стринг а не массив, и что кто-то просто туда предаст это переменную.
Проходясь по легаси коду стартапов где главное - быстро в продакшен все пихнуть, можно книгу написать...
Да не очень то и нормально. У дефолтного клиента таймаут бесконечный. Может быть сюрпризом.
За эту бизнес идею наверное кто-то еще и бонус получил...
А вообще, глядя на то как разработчики относятся к алертам, особенно к ложным срабатываниям, я уже представляю врачей которые игнорят сообщения о потенциальной проблеме у пациента... но надеюсь я неправ и врачи ответственнее нас.
1. Написания сухой документации аля отправьте это — получите то
2. Описания юз кейсов и различных флоу
3. Публикацию бест практис в виде статей
4. Хороший поиск
5. Вставка и форматирование кода
6. Можно было бы разделять внутреннюю документации дл] инженеров от публичной которую мы даем партнерам.
Сейчас у нас документация разбросана по гиту (wiki), wix и собственный статический сайт где нужно коммитить изменения в репо и деплоить.
Может кто посоветует чего?