(обычно если нет UI то ты делаешь либо SDK либо апишку)

в апишке может меняться бизнес логика

может, и тут приходят на помощь всякие branch by abstraction и конфигурации а уровне DI (это тоже фича тоглы по сути)

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

в случае бизнес-логики не должна

ну значит и тогл тебе не нужен)

опять же - branch by abstraction + DI конфиги это те же тоглы

речь шла о порядке выкладки кода в прод и миграциях

речь шла о порядке выкладки кода в прод и миграциях

- выполняем миграции с обратной совместимостью (то есть не удаляем колонки) - выкатываем новый код - выполняем миграции (обычно в следующий деплой) которые чистят старое

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

спасибо

но самый простой способ - делать деплои чаще (а для этого тоглы что бы разделить понятия "деплой" и "релиз"), тогда проще сохранять обратную совместимости схемы между деплоями. Если деплоишься раз в месяц будет больно

короч все те штуки котоые применяются когда у тебя continious integration (который не CI сервер а который идеология с ежедневными вливаниями изменений в мастер). И чем больше команда тем больше выхлопа от этих загонов. Но да это сложно особенно если до этого команда делала фича брэнчи которые висели по 3 недели

фича брэнчи по 3 недели потом выливаются в клёвые мержи =( Особенно если код плохо разделён

фича брэнчи по 3 недели потом выливаются в клёвые мержи =( Особенно если код плохо разделён

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

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

я те времена не застал, но боль от редких мержей почувствовал

ну а разделение кода - это извечная проблема... я в своей жизни не видел ни одного проекта где код был бы разделе грамотно.

ну а разделение кода - это извечная проблема... я в своей жизни не видел ни одного проекта где код был бы разделе грамотно.

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

я на предыдущем проекте вообще практиковал что все прямо в мастер херачат

а сколько была разница по времени обычно между мержами?

человек 12. Это нужно было что бы мы могли в контексте 2-х паралельных под проектов (типа вторая итерация на основе первой) делать дела и всегда быть вкурсе что поменялось + мы там жестко меняли структуру проекта паралельно

а сколько была разница по времени обычно между мержами?

все прям в мастер, нет мерджей) ну вот сча у нас с короткоживущими брэнчами (так как парное программирование как на том проекте вместо ревью PR-ов в распределенной команде я пока не умею) - есть негласное правило стараться вливать все в течении 2-х дней (в идеале сегодня отвел ветку и вечером вмерджил)

но за счет ревью приходится еще день давать

(ну и есть ветки которые иногда по тем или иным причинам висят неделю например, но это уже редкость к счастью)

хотя ревью можно делать и когда код уже в мастере) Я не считаю что ревью должно блочить мердж

а фичатоглы все же юзаете?

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

а фичатоглы все же юзаете?

да

все прям в мастер, нет мерджей) ну вот сча у нас с короткоживущими брэнчами (так как парное программирование как на том проекте вместо ревью PR-ов в распределенной команде я пока не умею) - есть негласное правило стараться вливать все в течении 2-х дней (в идеале сегодня отвел ветку и вечером вмерджил)

ну тут ещё от разделения кода зависит. У нас бывало, что дня 3 ветка не мержится, а проблем с мержами потом всё равно много. Имхо очень высокий coupling у нас да и с SRP всё_очень_плохо. Да вообще глобально всё плохо, чё уж там :D

это при том, что 3 разраба всего

ну тут ещё от разделения кода зависит. У нас бывало, что дня 3 ветка не мержится, а проблем с мержами потом всё равно много. Имхо очень высокий coupling у нас да и с SRP всё_очень_плохо. Да вообще глобально всё плохо, чё уж там :D

ну в таких штуках круто то что ты чувствуешь боль от этого. А чувствуешь боль + анализируешь источники боли и ищешь способы как боль убрать - это опыт. Это работает намного мощнее чем все книжки вместе взятые и просттанные обсуждения. Боль учит.

не все проекты позволяют деплоиться часто. например взять ставки на спорт или казино. остановка работы сайта даже на 1 мин болезненно воспримут пользователи которые крутят однорукого бандита

не все проекты позволяют деплоиться часто. например взять ставки на спорт или казино. остановка работы сайта даже на 1 мин болезненно воспримут пользователи которые крутят однорукого бандита

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

zero downtime организовать тоже проще когда у тебя деплои частые)

но а если один бэкенд

один бэкэнд может быть класстером из сотни серверов

это не важно. важна обратная совместимость между деплоями

что бы старый и новый код не конфликтовали

и тогда все изи бризи (потому что первое это пиздец сложно))

один энджинкс, один пхп, две версии кода… вполне себе перегоняются, хоть сине-зеленый делай

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

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

главное помимо "часто деплоить" еще грамотно мониторинг организовать)

Да

@anton_serdyuk как ты рассказывал собственно когда-то)

А еще один бэкенд рисково в плане а что если сервер тютю

Ночью

В субботу

у нас как-то один из продакшенов любил в 2-3 часа ночи приуныть

у нас как-то один из продакшенов любил в 2-3 часа ночи приуныть

"время тоски"

лечилось ребутом сервака) какая-то трабла на aws была с конкретным инстансом

благо у меня хоть и хэлскер но метрика "умерло пациентов" пока не нужна

а "умерло серверов"?)

пока тоже... мало серваков.

по 3 сервака + RDS в трех регионах

вот будет по 20 серваков в разных регионах - тогда можно вводить такие метрики)

(точнее как, метрика есть - просто пока алертика не срабатывает по ней чаще чем раз в год)

Всем привет. Народ подскажите можно ли как-то проверить реализует ли объект определенный интерфейс еще до момента инициализации этого объекта? Что-то типа if (OrderRepository::class instanceOf SearchableRepository)

$class = new ReflectionClass('Foo'); if ($class->isInstance('Interface')) { echo "Yes"; }

нет не то

interface Apple { function taste(); } class Fruit implements Apple { public function taste() { } } $obj = new ReflectionClass('Fruit'); var_dump($obj->implementsInterface('Apple'));

http://php.net/manual/ru/function.class-implements.php

Всем привет. Народ подскажите можно ли как-то проверить реализует ли объект определенный интерфейс еще до момента инициализации этого объекта? Что-то типа if (OrderRepository::class instanceOf SearchableRepository)

http://php.net/manual/ru/function.class-implements.php

опередили

http://php.net/manual/en/function.is-subclass-of.php

$class = new ReflectionClass('Foo'); if ($class->isInstance('Interface')) { echo "Yes"; }

это проверка на то можно ли создать объект (не абстрактный ли он и не трейт не интерфейс и тд)

ERROR: S client not available

я уже понял(

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

нашел class_parents, спасибо всем

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

После теста на iq)

После теста на iq)

Ну типа того. Что-то очень элементарное из области php

Привет

https://toster.ru/q/552902 Может кто-то знает ответ?

https://toster.ru/q/552902 Может кто-то знает ответ?

Чем вам ответ не нравится?

Похоже на нарушение LSP

Логически

ну в таких штуках круто то что ты чувствуешь боль от этого. А чувствуешь боль + анализируешь источники боли и ищешь способы как боль убрать - это опыт. Это работает намного мощнее чем все книжки вместе взятые и просттанные обсуждения. Боль учит.

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

Нельзя сужать диапазон входных параметров

Похоже на нарушение LSP

так и есть

А вот как в PHP это реализовано и почему я не знаю

Но вообще, так нельзя код писать, если бы язык позволял это делать даже

PHP это боль

контрвариантность + в последней вроде версии ввели возможность убирать тайпхинт назначенный в интерфейсе ?‍♂️

Не уверен, что контрвариантность применима в этом контексте

контрвариантность + в последней вроде версии ввели возможность убирать тайпхинт назначенный в интерфейсе ?‍♂️

про убирать тайпхинт звучит как сказки какие-то =\

Это про метатипы

Про дженерики

Не уверен, что контрвариантность применима в этом контексте

ну то что он хочет это ковариантный тип

просто он не в курсе что object это про другое

а есть еще stdClass

Ты мне кажется неправильно применяешь ковариантность/котравариантность

Оно не про типы, а про метатипы

Оно не про типы, а про метатипы

что ты подразумеваешь под метатипом

ну у тебя есть List<Object>

Например

метатип я имею ввиду это List<template T>