Pull to refresh
0
0
Константин Чудин @Veterinar

Пользователь

Send message

С каменным лицом писать статью о том как вы юзкейсы прямо в entity пихаете это конечно сильно. Как только вам потребуется второй, третий, четвертый метод withdraw, который должен работать чуть иначе, весь ваш дизайн превращается в мусор.

Что значит кто мне сказал? Вы в методе своего класса используете неявную зависимость от черт пойми чего, какие конфиги, какие мидлвэры? Почитайте про solid, почитайте про явное определение зависимостей. Ваш класс должен иметь возможность быть созданным через new InstanceName() и явно давать понять что ему нужно для корректной работы. Без конфигов, без контейнеров. Вы же предполагаете наличие какого-то глобального объекта, который вернет какую-то зависимость, это нарушение инкапсуляции. В Ларке это допускается только потому, что по словам самого её создателя она нужна чтобы крудов быстро накидать. В нормальном приложении вы от этой лапши с ума сойдете, полностью потеряв границы ответственности программных модулей.

Использование сервис локатора в методах класса - плохая практика, нарушающая инкапсуляцию. В таком виде сервис локатор является антипаттерном, скрывающим предусловия для корректного использования объекта. Это плохая архитектура и куча проблем на серьезном проекте, выходящего за рамки "накидать крудов".

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

Поделитесь пожалуйста шикарным пакетом DTO для laravel, спасибо.
Мне в конце концов удалось найти как выкручиваются люди, использующие JSON API с кастомными действиями над сущностью: en.wikipedia.org/wiki/HATEOAS

В примере по ссылке предлагается указывать дополнительные действия в объекте «links». Думаю, идеальный REST такого все-таки не прощает и по канонам требовался бы специальный тип запроса на каждое действие, но ничего лучше, судя по всему, нет и не будет.
В статье (как и в большинстве статей о REST) приводятся примеры правильного REST-сервиса как набор из пяти конкретных действий и эти действия четко определены типом запроса. Слишком наивно для приложения, выходящего за рамки CRUD.

JSON API — это лишь схема описания ресурса и подобного вопроса она конечно же не рассматривает, то, что она не накладывает никаких ограничений на endpoint логично, но ведь концепции REST, описанные в статье — накладывают, ибо путь /articles/1/arhive уже попадает под «Здесь все неправильно относительно всех принципов REST». Ни в одной статье, попадавшейся мне на глаза, об этом не было ни слова, к сожалению.
Ох уж этот сказочный удивительный мир, где над ресурсами существует всего 4 операции.
Мы используем Sentry на своём инстансе (Saas-версия подтормаживает) и не знаем горя.
Вы не поверите, но на одном из первых семинаров-сборов free-lance.ru, Антон Мажирин об этом говорил, так и есть. Может быть его с того времени переписали, не владею информацией.
Может быть у него просто форма отправки атрофировалась из-за неиспользования? Ну, эволюционная теория Ламарка наоборот.
Комментарии на хабре часто ценнее самого поста или, по крайней мере, равны ему по ценности. Человек описывает проблему и свой способ решения с помощью какой-то технологии, а в комментариях люди описывают ещё сто тысяч своих способов, появляется возможность выбора. Комментаторы задают важные вопросы, которые автор не посчитал нужным раскрыть (и добавляет после этого в статью), иногда комментарий полностью опровергает статью. А написано так, как будто комментарии никакой ценности не имеют совершенно.
Йована не слышно совсем.
Совсем скоро в каждой квартире
image
Если не вписывать, сроки кажутся совершенно неадекватными по сравнению с другими предложениями на рынке.
Я вообще не с кем не спорю, только описываю проблемы с которыми мне лично пришлось столкнуться при реализации такого подхода к разработке, о котором написано в посте. И эти проблемы на самом деле очень трудно решить на практике, вроде бы поднятие цен за услуги — очевидный ответ, но это риск остаться без заказов, а зарплату платить всё равно нужно. Сам то я полностью этот подход поддерживаю, но стоит понимать, что выстроить такой процесс очень непросто.
Хочет, но тут вы показываете ему смету. И он видит, что тестирование и рефакторинг занимает 50% времени и бюджета. И просит ошибку на выходные вместо этого.
Так-то оно так, да не так. На практике большинство моих клиентов согласны на 500 ошибку все выходные, чем так сильно увеличивать бюджет и сроки проекта, притом, что это не даст 100% гарантии, что даже при идеальном процессе разработки, эта ошибка всё равно не будет висеть все выходные. Я не знаю с кем работают те, кому удается внедрить всё, о чем сказано в топике, на российском рынке это очень тяжело. Так что я всё же склоняюсь, что большинство здесь теоретизируют, но сами это всё внедрять не пробовали.
Это всё так, но невероятно сильно увеличивает временные рамки. Если проект не слишком сложный, а так обычно и есть во всяком случае у многих, то клиенту выгодней сделать систему даже с ошибками, но исправить их в процессе работы, чем умножать сроки в два раза и получить систему без этих некритичных ошибок. Да, если продукт работает с финансами, где ошибка может стоить миллионы, это не подходит, но это исключение, можно подумать тут все каждый день ПО для банков делают.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity