Помимо исследования рынка, один из ключевых моментов как минимум в том, что десятки бирж «играют не по правилам», и возможно это исследование привлечёт внимание контролирующих органов
Да, в какой-то момент скотч отвалится и Вася будет придумывать что-то еще или более крепкий скотч…
Мне кажется далеко не каждый бизнес может смириться со стабильными сбоями в системе и давать одному Васе время их разбирать. Ну и если это обходится дешевле чем обзавестись программистами поопытнее… Видимо основной продукт бизнеса вовсе не ПО.
Со временем Вася расскажет Пете про все виды костылей и все.
Опять же, какие размеры у проекта, что чтобы его понять хватит «рассказать про виды костылей и всё»?
Нет, это ужасно. Но бизнес остановится без Васи в любом случае, даже если бы он писал идеальный код, т.к. знание предметной области никто не отменял.
Есть два отличия:
— Если Вася оставит костыли и уволится, они не будут понятны никому. Предметную область же скорее всего знает кто-то кроме Васи.
— Можно посадить Петю до того как Вася уволится, и он тоже сможет вникнуть в предметную область
я все это не оправдываю, просто к сожалению, часто такое встречал.
Ну… Если бы я этого не встречал, не появилось бы этой статьи )
Мой посыл как раз в том что так делать не нужно.
То есть… Треугольник Стоимость-Время-Качество никто не отменял, но об этом нужно задумываться, оценивать риски и находить грамотные компромиссы, а не лепить как попало пока проблемы не начнутся
Мне не совсем понятна ваша терминология. Разве тот факт того что в код можно легко и быстро вносить изменения не ломая всё остальное не есть качественный код? Что тогда значит сделать «по нормальному»?
И если все же код состоит из костылей — что будет если бизнес захочет рядом с Васей посадить ещё Петю, будет ему так же легко вносить изменения в код? Что будет когда Васю попросят поменять что-то спустя пол года как он сделал какую-то фичу, он так же сможет разобраться со всем что он нагородил до этого?
P.S.
Если все работает на костылях и программист Вася умеет строить новые костыли поверх старых, то и отлично
То есть тот факт что бизнес остановится в развитии как только Вася заболеет/уволится это отлично?
Задача программиста — формализовать задачу и все возможные варианты и исходы, и решить её за минимально возможное время оставляя точки для расширения в зависимости от предполагаемых будущих требований )
Дядя Боб в книжке «Идеальный программист» рассказывал, почему всякие популярные ошибочные предположения 20-летней давности типа избавиться от кода и предоставлять решение задачи на более высоком уровне абстракции — например в виде диаграмм понятных любому человеку(Model-driven architecture), не избавит нас от необходимости найма программистов.
«Unfortunately, this grand dream has one tiny little flaw. MDA assumes that the
problem is code. But code is not the problem. It has never been the problem.
The problem is detail.»
Да и как бы (зачастую внешне) трепетно один программист не относился к своему коду, всё равно потом придёт другой и скажет «тут всё неправильно, надо переписывать».
Ну… Литература по архитектуре приложений. Уже сказали про SRP и bounded context, читать про SOA и связанные темы, всё те же Фаулер, Дядя Боб, Уди Дахан. Вобщем, тут важнее бэкграунд в принципе по дизайну приложений.
Мой посыл в том что высокий coupling в монолите это плохо, но разделить проект на микросервисы оставив coupling это ещё в разы больнее. В идеале каждый сервис это отдельное приложение с отдельной базой данных, и данные из него не растекаются по другим сервисам.
В докладе по ссылке на Ютуб что я выше кинул комментарием выше как раз рассматриваются примеры таких проблем когда ну вот прям кажется, что задачи бизнеса требуют сосредоточения данных из различных контекстов в одном сервисе, и как этого не допустить.
И ещё раз — Микросервисы это штука которая позволяет в проекте(монолите) который уже разбит на контексты и функциональные части ещё эффективнее разделить команды, и ускорить доставку фич на прод путем устранения блокировок между командами, расплачиваясь за это как раз таки возрастающей сложностью проекта в целом и оверхедом на поддержку инфраструктуры.
Вобщем, всё сводится к вопросу — «Кто будет чинить если эта фигня на проде упадёт?», если это достаточно серьёзный/важный/крупный кусок системы чтобы быть уверенным что на проекте будут люди для его поддержки — никаких проблем
Проблема в том что люди которые не читают первоисточники, и о новых технологиях судят по хайповым статьям на Хабре(и других ресурсах) не интересуются ни тем, какие проблемы решает новая технология, ни тем, какие у неё недостатки.
Микросервисы это отличная штука чтобы как можно быстрее доставлять фичи на прод в условиях когда много команд работают над различными функциональными частями продукта. Но для этого нужно чтобы на проекте были грамотные люди которые умеют разделять проект на разные функциональные части. У них высока стоимость ошибок декомпозиции и это сложнее чем монолит.
В современном мире же нередка ситуация когда команда программистов не смогла грамотно спроектировать монолит, наделав кучу архитектурных ошибок и подняв до небес стоимость поддержки этого проекта, и, путая причино-следственную связь, думая что микросервисы помогут им произвести грамотную декомпозицию системы убеждают бизнес выделить деньги на переписывание проекта на микросервисы.
А когда и это к успеху не приведет, получится по заветам Уди:
— Микросервисы не решили проблему декомпозиции, для декомпозиции нужны Экторы! Будем писать на Эрланге.
— …
— Экторы тоже не помогли декомпозировать систему. Нужно писать на F#
— Почему F#? Нуу… F# я ещё не пробовал, а это неплохая ачивка для резюме (с) ютуб
Разве проблема версионирования всякого инфрастуктурного софта(БД, веб сервер etc.) не решается Докером?
А вобще, вопрос по прежнему весьма холиварный, и даже никаких причин слезать с Дебиана пока не вижу. Я в поисках самого удобного дистрибутива остановился на Manjaro. Пол года сидел с KDE, уже пару месяцев с XFCE(Так и не решил какой DE выбрать, Cinnamon из Минта кстати тоже классная вещь).
Путь был Debian => Kubuntu => Mint => Manjaro, с параллельной пробой elementaryOS. В принципе проблемы(шрифты, драйвера) возникали только в Debian, у всех остальных дистрибутивов с этим всё сразу было отлично. Manjaro выбрал за Rolling Release(и ещё возможность юзать систему во время установки: ))
Если в команде разработчиков каждый сам за себя, у команды явно проблемы с атмосферой и отношениям между коллегами.
По поводу парного программирования, свежих взглядов, переработок, сопернической атмосферы в коллективе — все уже было описано в книге Роберта Мартина, «Идеальный Программист». И истории, кстати, очень похожие в книге представлены
Проблема «сервисов» в том, что само их определение достаточно размытое и каждый может вкладывать в этот термин свой смысл. Интерактор (или же «операция») — по факту и есть максимально узко специализированный «класс-сервис», отвечающий за конкретную операцию бизнес-процесса.
Я не вижу никаких проблем в обычных классах-сервисах которые аггрегируют внутри себя вызовы других сервисов, определяя какой-то сценарий. С Интеракторами у нас получается тоже самое, но с исковерканным не понятно для чего интерфейсом.
Ну то есть да, если бы я такое увидел у меня точно рука не поднялась добавлять в эту странную штуку какие-то свои методы, помимо call(), но такие вещи должны отсекаться на уровне code review, а от добавления в Интеракторы какой-нибудь не подходщей для них логики неопытным программистом всё-равно никто нас не застрахует.
Для пущего спокойствия можно инжектить обычные сервисы через единый интерфейс с каким-нибудь одним публичным методом типа call();
Пока что не совсем понятны преимущества такого подхода даже перед самым простым решением в лоб — запилить какой-то класс сервис, который будет заниматься созданием Книги, и дерганьем других сервисов, типа Email-sender`а если его нужно отправить Email при создании книги.
У такого сервиса будет хотя бы явно-определенный интерфейс с типизацией.
Зона ответственности класса так же весьма размыта. Судя по коду из базового трейта Интерактора автор уже как минимум предлагает прикручивать к реализации валидацию входящего запроса.
Код
<?php
namespace Lib\Interactor;
trait Interactor
{
abstract function call();
public function __invoke()
{
$arguments = func_get_args();
$payload = [];
if (method_exists($this, 'validate') && !$this->validate(...$arguments))
{
return new InteractorResult($payload, false);
}
static::call(...$arguments);
foreach ((static::$expose ?? []) as $expose) {
$payload[$expose] = $this->{$expose};
}
return new InteractorResult($payload, true);
}
}
Думаю, чтобы пустить такое решение в продакшен должны быть действительно веские аргументы. Я не представляю как понять что он делает не запустив его, или не покопавшись в документации по магическим методам.
> Правила валидации скорее относятся к формам
Вообще, я бы сказал тогда уж что к Реквесту, а не к форме. И да, валидировать данные без модельки было бы возможно удобно, но это спорно. В текущей ситуации я просто отдельную модельку создаю для реквеста, и валидирую через неё.
Всякими штучками для фронта(grid view, active forms), я не пользуюсь и пользоваться собственно не желаю, ибо не вижу смысла. Когда поверх этих виджетов для кодогенерации запиливаешь кучу кастомного кода, разбираться в этом новичку(да и не новичку) весьма и весьма нетривиальная задача, так что очень хотелось бы иметь удобную возможность из своего приложения их повыпиливать.
По поводу инкапсуляции — будет ли возможность сделать private поля в модели/AR без возможности доступа к ним через всякую магию?
Печально на счёт ORM. Правильно ли я понимаю что в Yii3 текущая версия AR будет отдельным компонентом и его можно будет легко выпилить/не устанавливать в свое приложение?
Будут ли какие-то изменения в Моделях, чтобы они не превращались в свалку из rules/attributeLabels/AR/Данных без инкапсуляции, чтобы они были хоть как-то пригодны для проектов у которых срок жизни более одного месяца?
> Конечно не на порядок, но в разы — два, три — это как пить дать.
Вы меня не поняли. Повышение трат на жильё в два раза не равно «Повышение общей суммы расходов в два раза».
> В Москве это все стоит денег и боюсь совсем не «30 тыр в месяц».
С повышенным уровнем зарплаты окупается. Хотя это уже от ваших потребностей. Если у меня в родном городе двушка в центре стоит 20т.р./мес не значит что я не поеду в Мск пока не смогу позволить себе двушку в центре.
> Для «молодых программистов» с моей (SIC!) точки зрения есть лишь один путь: учиться учиться и ещё раз учиться
У меня ощущение что вы вообще не дочитали моё сообщение. Я ясно сказал что в Ижевске учиться практически нечему. Начинающим программистам в таких местах обычно в веб-студию верстальщиком попасть уже за счастье.
> Пригласили в Яндекс (условно) полы мыть за миску супа? Без раздумий туда!
Где вы там офисы Яндекса нашли?
> Москва лучше. Там сильно больше выбор мест для учебы.
Наконец то дочитали.
> Но не ЗП! Не смотрите на ЗП. Её нет. Не существует. Первые 10ть лет.
На первом месте для меня конечно же проект и сильная команда, но з/п не маловажный фактор, и имхо глупо говорить что новички должны пахать за миску супа только ради того чтобы обучиться чему-то.
Вы наверняка и без меня прекрасно понимаете что жильё, еда, одежда, хорошее проведение досуга стоят денег, и являются немаловажным фактором в том числе и в развитии человека, влияя на качество жизни. Хотя опять же, всё индивидуально.
Мне кажется далеко не каждый бизнес может смириться со стабильными сбоями в системе и давать одному Васе время их разбирать. Ну и если это обходится дешевле чем обзавестись программистами поопытнее… Видимо основной продукт бизнеса вовсе не ПО.
Опять же, какие размеры у проекта, что чтобы его понять хватит «рассказать про виды костылей и всё»?
Есть два отличия:
— Если Вася оставит костыли и уволится, они не будут понятны никому. Предметную область же скорее всего знает кто-то кроме Васи.
— Можно посадить Петю до того как Вася уволится, и он тоже сможет вникнуть в предметную область
Ну… Если бы я этого не встречал, не появилось бы этой статьи )
Мой посыл как раз в том что так делать не нужно.
То есть… Треугольник Стоимость-Время-Качество никто не отменял, но об этом нужно задумываться, оценивать риски и находить грамотные компромиссы, а не лепить как попало пока проблемы не начнутся
И если все же код состоит из костылей — что будет если бизнес захочет рядом с Васей посадить ещё Петю, будет ему так же легко вносить изменения в код? Что будет когда Васю попросят поменять что-то спустя пол года как он сделал какую-то фичу, он так же сможет разобраться со всем что он нагородил до этого?
P.S.
То есть тот факт что бизнес остановится в развитии как только Вася заболеет/уволится это отлично?
Дядя Боб в книжке «Идеальный программист» рассказывал, почему всякие популярные ошибочные предположения 20-летней давности типа избавиться от кода и предоставлять решение задачи на более высоком уровне абстракции — например в виде диаграмм понятных любому человеку(Model-driven architecture), не избавит нас от необходимости найма программистов.
Ну и, такие вещи всё же нужно чем-то обосновывать
Мой посыл в том что высокий coupling в монолите это плохо, но разделить проект на микросервисы оставив coupling это ещё в разы больнее. В идеале каждый сервис это отдельное приложение с отдельной базой данных, и данные из него не растекаются по другим сервисам.
В докладе по ссылке на Ютуб что я выше кинул комментарием выше как раз рассматриваются примеры таких проблем когда ну вот прям кажется, что задачи бизнеса требуют сосредоточения данных из различных контекстов в одном сервисе, и как этого не допустить.
И ещё раз — Микросервисы это штука которая позволяет в проекте(монолите) который уже разбит на контексты и функциональные части ещё эффективнее разделить команды, и ускорить доставку фич на прод путем устранения блокировок между командами, расплачиваясь за это как раз таки возрастающей сложностью проекта в целом и оверхедом на поддержку инфраструктуры.
Вот ещё классный доклад про контексты — www.youtube.com/watch?v=ez9GWESKG4I
Микросервисы это отличная штука чтобы как можно быстрее доставлять фичи на прод в условиях когда много команд работают над различными функциональными частями продукта. Но для этого нужно чтобы на проекте были грамотные люди которые умеют разделять проект на разные функциональные части. У них высока стоимость ошибок декомпозиции и это сложнее чем монолит.
В современном мире же нередка ситуация когда команда программистов не смогла грамотно спроектировать монолит, наделав кучу архитектурных ошибок и подняв до небес стоимость поддержки этого проекта, и, путая причино-следственную связь, думая что микросервисы помогут им произвести грамотную декомпозицию системы убеждают бизнес выделить деньги на переписывание проекта на микросервисы.
А когда и это к успеху не приведет, получится по заветам Уди:
— Микросервисы не решили проблему декомпозиции, для декомпозиции нужны Экторы! Будем писать на Эрланге.
— …
— Экторы тоже не помогли декомпозировать систему. Нужно писать на F#
— Почему F#? Нуу… F# я ещё не пробовал, а это неплохая ачивка для резюме (с) ютуб
А вобще, вопрос по прежнему весьма холиварный, и даже никаких причин слезать с Дебиана пока не вижу. Я в поисках самого удобного дистрибутива остановился на Manjaro. Пол года сидел с KDE, уже пару месяцев с XFCE(Так и не решил какой DE выбрать, Cinnamon из Минта кстати тоже классная вещь).
Путь был Debian => Kubuntu => Mint => Manjaro, с параллельной пробой elementaryOS. В принципе проблемы(шрифты, драйвера) возникали только в Debian, у всех остальных дистрибутивов с этим всё сразу было отлично. Manjaro выбрал за Rolling Release(и ещё возможность юзать систему во время установки: ))
По поводу парного программирования, свежих взглядов, переработок, сопернической атмосферы в коллективе — все уже было описано в книге Роберта Мартина, «Идеальный Программист». И истории, кстати, очень похожие в книге представлены
Я не вижу никаких проблем в обычных классах-сервисах которые аггрегируют внутри себя вызовы других сервисов, определяя какой-то сценарий. С Интеракторами у нас получается тоже самое, но с исковерканным не понятно для чего интерфейсом.
Ну то есть да, если бы я такое увидел у меня точно рука не поднялась добавлять в эту странную штуку какие-то свои методы, помимо call(), но такие вещи должны отсекаться на уровне code review, а от добавления в Интеракторы какой-нибудь не подходщей для них логики неопытным программистом всё-равно никто нас не застрахует.
Для пущего спокойствия можно инжектить обычные сервисы через единый интерфейс с каким-нибудь одним публичным методом типа call();
У такого сервиса будет хотя бы явно-определенный интерфейс с типизацией.
Зона ответственности класса так же весьма размыта. Судя по коду из базового трейта Интерактора автор уже как минимум предлагает прикручивать к реализации валидацию входящего запроса.
Думаю, чтобы пустить такое решение в продакшен должны быть действительно веские аргументы. Я не представляю как понять что он делает не запустив его, или не покопавшись в документации по магическим методам.
Вообще, я бы сказал тогда уж что к Реквесту, а не к форме. И да, валидировать данные без модельки было бы возможно удобно, но это спорно. В текущей ситуации я просто отдельную модельку создаю для реквеста, и валидирую через неё.
Всякими штучками для фронта(grid view, active forms), я не пользуюсь и пользоваться собственно не желаю, ибо не вижу смысла. Когда поверх этих виджетов для кодогенерации запиливаешь кучу кастомного кода, разбираться в этом новичку(да и не новичку) весьма и весьма нетривиальная задача, так что очень хотелось бы иметь удобную возможность из своего приложения их повыпиливать.
Печально на счёт ORM. Правильно ли я понимаю что в Yii3 текущая версия AR будет отдельным компонентом и его можно будет легко выпилить/не устанавливать в свое приложение?
Вы меня не поняли. Повышение трат на жильё в два раза не равно «Повышение общей суммы расходов в два раза».
> В Москве это все стоит денег и боюсь совсем не «30 тыр в месяц».
С повышенным уровнем зарплаты окупается. Хотя это уже от ваших потребностей. Если у меня в родном городе двушка в центре стоит 20т.р./мес не значит что я не поеду в Мск пока не смогу позволить себе двушку в центре.
> Для «молодых программистов» с моей (SIC!) точки зрения есть лишь один путь: учиться учиться и ещё раз учиться
У меня ощущение что вы вообще не дочитали моё сообщение. Я ясно сказал что в Ижевске учиться практически нечему. Начинающим программистам в таких местах обычно в веб-студию верстальщиком попасть уже за счастье.
> Пригласили в Яндекс (условно) полы мыть за миску супа? Без раздумий туда!
Где вы там офисы Яндекса нашли?
> Москва лучше. Там сильно больше выбор мест для учебы.
Наконец то дочитали.
> Но не ЗП! Не смотрите на ЗП. Её нет. Не существует. Первые 10ть лет.
На первом месте для меня конечно же проект и сильная команда, но з/п не маловажный фактор, и имхо глупо говорить что новички должны пахать за миску супа только ради того чтобы обучиться чему-то.
Вы наверняка и без меня прекрасно понимаете что жильё, еда, одежда, хорошее проведение досуга стоят денег, и являются немаловажным фактором в том числе и в развитии человека, влияя на качество жизни. Хотя опять же, всё индивидуально.