АГ
пока внятного прода нет. пилоты. дев, тест, уат пока есть более менее. уатом как продом в тестовом режиме ограниченно пользуются
Size: a a a
2020 August 11
АГ
если код работает, а псалм показывает 10к ошибок, явно не показатель того, что надо срочно исправлять код
срочно этим не занимаются) в свободное время)
DT
это только откладывание плюшек статанализа на потом, типа вот как исравлю, то заживем)
DT
срочно этим не занимаются) в свободное время)
ну тогда это вообще mission impossible)
АГ
это только откладывание плюшек статанализа на потом, типа вот как исравлю, то заживем)
да, надо будет заняться все-таки этим) посвящать хотя бы 2 часа в день.
DT
какой в этом смысл? конкретно - делаешь бейслайны - ошибок нет (как бы). Пилишь код - появляются ошибки, их и правишь. Тогда есть смысл. Сидеть исправлять прошлые ошибки, когда еще нового кода подъезжает пачками - это просто дрочерство какое-то на абсолютное фактическое отсутствие ошибок статанализа, бессмысленное и беспощадное
VS
да, надо будет заняться все-таки этим) посвящать хотя бы 2 часа в день.
Не в день - а один раз. Поставил - бейслайн - сi - забыл.
2020 August 12
АГ
Vlad Sobenko
Не в день - а один раз. Поставил - бейслайн - сi - забыл.
сделаем.
АГ
ну после этого другие ошибки то можно обозначить? или уже нет?
VS
ну после этого другие ошибки то можно обозначить? или уже нет?
Удаляешь baseline. Ошибки вернутся.
АГ
хорошо, всем спаибо) я думаю можно закрыть на этом тему эту)
k
А мне нравится идея из мира TS. Они используют jsonSchema. Для валидации используют. Оказалось очень удобно использовать одну и туже валидацию на фронте и на бэке с пхп. Данные проверяются до попадания в дто(или что другое). Ненадо никаких исключений. А бонусом ты имеем что у нас бэк и фронт используют одну и туже валидацию. Бонусом можно клиентам давать эти схемы. Для всех языков есть либы для jsonSchema. Тоже самое давно было с xml. Переизобретение велосипеда но все равно удобно.
а каким инструментарием ты пользуешься?
SB
а каким инструментарием ты пользуешься?
Мы этот используем https://docs.opis.io/json-schema/1.x/ . Но у нас пока только в одном месте SPA приложения для и мы по большей части для того чтобы валидацию переиспользовать на стороне бэка и фронта. Пока нравится.
VP
Привет ребята
Чисто теоретический вопрос по архитектуре приложения.
Есть несколько уровней сервисов, допустим 3.
1 уровень управляет общей бизнес логикой
2 уровень выполняет какие-то конкретные действия
3 уровень например какие то клиенты к стороннему апи и тд
Вопрос состоит в следующем, могут ли сервисы находящиеся на одном уровне вызываать друг друга или они должны работать только с более низкоуровневыми сервисами?
Чисто теоретический вопрос по архитектуре приложения.
Есть несколько уровней сервисов, допустим 3.
1 уровень управляет общей бизнес логикой
2 уровень выполняет какие-то конкретные действия
3 уровень например какие то клиенты к стороннему апи и тд
Вопрос состоит в следующем, могут ли сервисы находящиеся на одном уровне вызываать друг друга или они должны работать только с более низкоуровневыми сервисами?
VS
читай про правила зависимостей здесь: https://habr.com/ru/post/269589/
и про принцип DIP из SOLID-а
и про принцип DIP из SOLID-а
ЕР
Привет ребята
Чисто теоретический вопрос по архитектуре приложения.
Есть несколько уровней сервисов, допустим 3.
1 уровень управляет общей бизнес логикой
2 уровень выполняет какие-то конкретные действия
3 уровень например какие то клиенты к стороннему апи и тд
Вопрос состоит в следующем, могут ли сервисы находящиеся на одном уровне вызываать друг друга или они должны работать только с более низкоуровневыми сервисами?
Чисто теоретический вопрос по архитектуре приложения.
Есть несколько уровней сервисов, допустим 3.
1 уровень управляет общей бизнес логикой
2 уровень выполняет какие-то конкретные действия
3 уровень например какие то клиенты к стороннему апи и тд
Вопрос состоит в следующем, могут ли сервисы находящиеся на одном уровне вызываать друг друга или они должны работать только с более низкоуровневыми сервисами?
Не понятно почему первое это сервис а не сущность/агрегат, а третье вообще инфраструктуоа
VP
читай про правила зависимостей здесь: https://habr.com/ru/post/269589/
и про принцип DIP из SOLID-а
и про принцип DIP из SOLID-а
думаю вы говорили об этом
> Зависимости в исходном коде всегда указывают внутрь. По мере продвижения внутрь уровень абстракции возрастает. Внешний круг — уровень деталей. Внутренний круг является наиболее общим.
и об этом
> Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.
Но вопрос про модули на одном уровне
> Зависимости в исходном коде всегда указывают внутрь. По мере продвижения внутрь уровень абстракции возрастает. Внешний круг — уровень деталей. Внутренний круг является наиболее общим.
и об этом
> Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.
Но вопрос про модули на одном уровне
VP
Не понятно почему первое это сервис а не сущность/агрегат, а третье вообще инфраструктуоа
Может не совсем коректно привел примеры, но вопрос про сервисы которые находятся на одном уровне. могут ли они знать друг о друге?
ЕР
Может не совсем коректно привел примеры, но вопрос про сервисы которые находятся на одном уровне. могут ли они знать друг о друге?
It depends.
ЕР
Агрегаты друг от друга по хорошему не должны зависеть напрямую, юзкейсы тоже, инфраструктура может