норм

нет проблем

копипаста лучше унифицируемого подо все случаи кода

++++++

там есть модули которые упрощают весь этот боилерплейт

копипаста еще пишется может ок, но читается потом херово

Недавно из-за этого кучу дерьма съел

норм читается

Код был универсальный для двух разных абсолютно кейсов

копипаста еще пишется может ок, но читается потом херово

есть же пакеты которые этот боилерплейт выкидывают

Но одно время алгоритм был одинаковый

И решили не запариваться

А потом наступил пиздец и алгоритмы стали прямо разными

Но первое время улучшали универсальный алгоритм под кейсы

Потом психанул и написал два новых класса

Ибо там уже жуть была

есть же пакеты которые этот боилерплейт выкидывают

например?

например?

честно скажу, сейчас уже не помню названий. Еще в 2015 у меня знакомый юзал готовые пакеты под типовые экшоны.

и там все вполне чистенько было.

Потом психанул и написал два новых класса

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

я в мелких нефункциональных компонентах для переключения состояния, не влияющего на другие компоненты, часто разрешают сетСтейт юзать )

я в мелких нефункциональных компонентах для переключения состояния, не влияющего на другие компоненты, часто разрешают сетСтейт юзать )

ну это насколько я помню нормальная практика для самых конечных не критичных компонент

а то стейт раздувается до неприличных размеров

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

еще мы мешаем классы и функциональные компоненты

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

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

Если сложная - имеет смысл подумать, а нельзя ли упростить? )

Это много куда относится

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

нельзя как раз в стейт пихать вообще все.

Часто любят пихать сервисы в обычные CRUD приложения

типо каждый экшен - сервис

я до сих пор хз зачем там абстракция на будущее

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

сложные приколы

усложнится - вынесешь, а пока всё просто я не сторонник писать абстракцию сервисов

я до сих пор хз зачем там абстракция на будущее

это как бы паттерн такой есть ) организация большой логики, вполне рабочая штука

это как бы паттерн такой есть ) организация большой логики, вполне рабочая штука

рабочая, но я недавно написал сервисы для каждого create и update

и пользы особой - ноль

проект был простой очень

и гораздо удобнее было без сервисов

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

и гораздо удобнее было без сервисов

а тестить как?!11адынадын

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

именно поэтому я написал про "большую логику" ) на простом такое делать это паттерны головного мозга

по старинке, Rails way, тестишь модели и контроллеры

это профитнее, чем вводить абстракцию, которая нужна

сервисы чаще нужны, чем нет

но даже их не надо бездумно пилить

онли интеграционные тесты на маленьких проектах - идеально

у рельс из коробки туча проблем просто

и они все начинаются где то месяцев через 6 кодинга

онли интеграционные тесты на маленьких проектах - идеально

да, как вариант

онли интеграционные тесты на маленьких проектах - идеально

TDD тебе не скажет спасибо

и они все начинаются где то месяцев через 6 кодинга

да, но последний проект был полностью написан за 2 месяца

))

онли интеграционные тесты на маленьких проектах - идеально

маленький проект всегда стремиться стать большим

если только не бросить его писать ?

TDD тебе не скажет спасибо

TDD это подход, который улучшает жизнь, а не религия ) я его просто не использую, если нет понимания реальной пользы )

TDD это подход, который улучшает жизнь, а не религия ) я его просто не использую, если нет понимания реальной пользы )

реальная польза в скорости написания кода

если только не бросить его писать ?

если у проекта есть конкретная цель, которая не будет расширятся - не будет ничего расти

я с TDD быстрее код пишу чем без него

есть такая категория проектов

ну как, у меня TDD+RDD

реальная польза в скорости написания кода

не писать тесты, вот это прирост скорости )

не писать тесты, вот это прирост скорости )

смешно если честно.

у меня на первой работе тимлид также думал.

смешно если честно.

если проект на 2 месяца - не смешно

а так и есть

давай на сложный сервис-объект каждый раз пересоздавать dev окружение

ERROR: S client not available

неудобно ну прям вообще ни разу.

но я их таки написал, в конце, чтобы не стыдно было

хз откуда вы выкапываете проекты которые потом никто не будет поддерживать

у меня на первой работе тимлид также думал.

я не пишу тесты на код, который "на выброс" и в 90% я прав ) бизнес-процессы иногда такие быстрые, что хорошо писать дорого и вредно

я что не видел, так даже php сайты и то поддерживать надо было

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

я не пишу тесты на код, который "на выброс" и в 90% я прав ) бизнес-процессы иногда такие быстрые, что хорошо писать дорого и вредно

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

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

выносишь логику из моделей и контроллеров.

хз откуда вы выкапываете проекты которые потом никто не будет поддерживать

можно их так писать, что потом невозможно будет поддерживать (c) think about it

я же сказал, рельсы из коробки

эм нет

забыли про form object и прочее.

с моделью с кучкой валидаций начинаются приколы.

особенно если она основа всего сервиса.

только если есть условные валидации

если просто много полей и валидаций - особо проблем нет же

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

тут не зависит от фреймворка и ЯП

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

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

как грят - нормально делай, нормально будет

как грят - нормально делай, нормально будет

дело не только в этом, а еще в используемом фреймворке.

у рельсы довольно хреновый подход из коробки.

Хорош для старта, но потом начинаются приколы.

у рельсы довольно хреновый подход из коробки.

Антон, мы тебя узнали, перелогинься

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

какие приколы то?

ржёт в консоль или шутки про мамок в логах?

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

опять тесты рассматриваются как maintainability

через тесты _удобно_ писать код.

в моем случае даже быстрее.

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