Так в примере выше, rsync и говорил про high-coupling. Якобы метод который и меняет бизнес-состояние и сам себя в базу пишет (вполне конкретную) — это хороший дизайн.
То есть это не просто Active-Record, а ещё и прибитая гвоздями к конкретной схеме конкретной базе конкретного драйвера.
А в чём проблема смены пароля при многофакторной авторизации? В консистенции смены на всех провайдерах? В рассылке уведомлений всем провайдерам об инвалидации? В том что будет многофазный процесс?
Вроде всё это выглядит решаемо. Я не очень знаком с этой конкретной предметной областью, но в своём опыте не припомню задач, где SRP был бы прямо явным антипаттерном.
Телеметрия и используется для улучшения продукта. Это может для кого-то открытие, но лучший способ улучшить продукт — надо просто понаблюдать что делает пользователь
Можно заказать исследования, где будут приглашать людей за деньги потыкать в разные элементы интерфейса, а затем выявлять где же они тупили. Цена этого исследования будет, естественно, включена в стоимость продукта.
А можно расставить таймеры и трекалки, которые соберут с каждого пользователя немного статистики — на каких элементах управления чаше всего тупят. Или в какие поля ввода водят неправильные данные.
Как тестировать фичу, когда ответственности смешаны?
DataAccess layer размазан по куче классов, как вы их будете тестировать? Базу в докере запускать?
Кстати, а почему вы уверены, что смена пароля профиля не приведет к увеличению налога? У вас нет теста на это!
Если код не соответствует общепринятым базовым паттернам, то это и не шашечки и не ехать. Это велосипед на костылях и замыкание процессов на себя. Потом проще выкинуть, чем внести изменения.
получается фигня, которая не держит нагрузку, с трудом удерживается DBA в рамках
А откуда гарантия, что ваши кривые SQL-запросы не уложат базу? Неумение пользоваться инструментом — не оправдание. При грамотном использовании оверхед на орм — на уровне статистической погрешности. А сколько оверхед на дублирование одного и того же кода?
можно смело раскладывать в продакшен в пятницы, перед праздниками
Если нет надёжной процедуры отката, у вас проблемы посерьёзнее скорости разработки или обеспечения качества фич
с типами в разы дороже и качество хуже или результат вовсе не достигнут
С типами обычно быстрее и проще. Свежий пример — я делаю библиотеку, которую пользователь (разработчик конечного приложения) должен проинициализировать довольно сложной вложенной структурой данных.
Как гарантировать, что пользователь библиотеки проинициализировал её правильно, заполнив все необходимые поля?
Тесты на код пользователя писать? Заставить его самого писать себе тесты по документации?
Можно конечно в рантайме проверять и бросать ошибки в рантайме вида: "Возраст должен быть числом", "Не знаю поля Nme, возможно вы имели ввиду Name?" Отладка может быть долгой.
А можно просто сделать типизированный конфиг, который просто не позволит собрать билд с неправильными параметрами или опечататься в значении поля.
ТДД и тестировшики не связаны и тем более не взаимозаменяемы, потому что тесты, которые пишут разработчик и QA — разные и предназначены для разных целей.
Ну будет лапша, которая не соответствует SOLID, тормозит разработку (билд занимает часы) и протестирована на единственной версии постгрис.
"а не отправили ли в постгрис ошибочный SQL"
Попробуйте ORM. Даже легковесные ORM предоставляют гарантии на уровне типов, что будет сгенерирован корректный SQL который вызывается на подходящей схеме БД. Остальные редкие случаи поймает приёмочное тестирование
Если упали тесты, которые тестируют код, то билд не мог состоятся, т.к. прогон этих тестов (которые написаны разработчиком) — часть процесса билда.
Если же билд состоялся, то регрессия упала на стороне QA и QA должен завести баг.
И всё это не имеет отношения к ТДД. ТДД — это не про тесты, ТДД — это про процесс написания кода
когда бизнес уже "что-то кому-то продал" и сидят довольные, празднуя с шампанским удачную сделку, но вот теперь IT должен сделать из говна конфетку ровно к сроку Х (который определили даже не проконсультировавшись с IT) или внедрить новую фичу опять же к сроку Х, которую уже продали, чтобы бизнес не выглядели жуликами.
Скрам существует с середины 80х и позволяет с цифрами в руках наглядно показать какое количество функционала может быть готово к определенному сроку. Или наоборот — когда будут готовы все требования.
Если есть риски, их надо озвучить. То что бизнес продал звездолёт без оценки исполнителей и обещает поставить его через неделю — исключительно проблемы бизнес-стороны и ИТ касаться не должны. Статистика — вещь упрямая. Начнёшь подгонять — так ещё и кадры растеряешь
Нафиг тогда в такой вселенной нужен тогда QA вообще?
В реальном мире QA не верит разработчику и покрывает требования (а не код) независимо.
Так в примере выше, rsync и говорил про high-coupling. Якобы метод который и меняет бизнес-состояние и сам себя в базу пишет (вполне конкретную) — это хороший дизайн.
То есть это не просто Active-Record, а ещё и прибитая гвоздями к конкретной схеме конкретной базе конкретного драйвера.
Если там в цикле перебирается все строки таблицы вместо запроса с группировкой и/или аггрегацией, то DBA не спасёт.
А в чём проблема смены пароля при многофакторной авторизации? В консистенции смены на всех провайдерах? В рассылке уведомлений всем провайдерам об инвалидации? В том что будет многофазный процесс?
Вроде всё это выглядит решаемо. Я не очень знаком с этой конкретной предметной областью, но в своём опыте не припомню задач, где SRP был бы прямо явным антипаттерном.
Это в какой вселенной QA доверяет разработчику?
Мне тоже матчат 100% но с первого года.
Положить я могу максимум половину федерального годового лимита $19000 / 2 = $9500 для 2019 года
На самом деле $9000, потому что первые $500 они зачисляют за первый отложенный туда доллар
Телеметрия и используется для улучшения продукта. Это может для кого-то открытие, но лучший способ улучшить продукт — надо просто понаблюдать что делает пользователь
Можно заказать исследования, где будут приглашать людей за деньги потыкать в разные элементы интерфейса, а затем выявлять где же они тупили. Цена этого исследования будет, естественно, включена в стоимость продукта.
А можно расставить таймеры и трекалки, которые соберут с каждого пользователя немного статистики — на каких элементах управления чаше всего тупят. Или в какие поля ввода водят неправильные данные.
В цикле TDD рефакторят ДО того, как фича попадёт к QA
Не могли бы Вы раскрыть свою мысль?
О каких более базовых принципах идёт речь с которыми можно пренебречь принципом единой ответственности например?
А лего, значит, вы собираете с помощью паяльника?
Как тестировать фичу, когда ответственности смешаны?
DataAccess layer размазан по куче классов, как вы их будете тестировать? Базу в докере запускать?
Кстати, а почему вы уверены, что смена пароля профиля не приведет к увеличению налога? У вас нет теста на это!
Это только по букве "S" вопросы.
ну вот опять — некомпетентность бизнеса привела к нарушениям процессов в угоду скорости и отсюда повылезали все проблемы.
Не удивлюсь, что в итоге разработчики и оказались виноваты во всех факапах, вызванных нехваткой времени.
Моя позиция — я следую процессам и деливерю с предсказуемым качеством. На иных условиях я не работаю, потому что не могу отвечать за продукт.
"Горе-бизнесмены", пообещавшие звездолёт за неделю сдаются сразу в топ-менеджмент (было 1 раз всего)
Будет ошибка десериализации очевидно, а не стектрейс в случайном месте.
И сколько же раз надо запустить программу, чтобы понять что конфиг корректный?
Ошибка в рантайме обходится гораздо дороже чем в компайл-тайме. Потому что может быть причиной отката релиза.
Если код не соответствует общепринятым базовым паттернам, то это и не шашечки и не ехать. Это велосипед на костылях и замыкание процессов на себя. Потом проще выкинуть, чем внести изменения.
А откуда гарантия, что ваши кривые SQL-запросы не уложат базу? Неумение пользоваться инструментом — не оправдание. При грамотном использовании оверхед на орм — на уровне статистической погрешности. А сколько оверхед на дублирование одного и того же кода?
Возможность легко понять что делает код, возможность его модифицировать и легко локализовать ошибку — довольно ценные в разработке, не так ли?
Для того, чтобы достичь этого, существуют определенные практики. Самые базовые — это SOLID.
Несомненно, даже используя лучшие практики при определенном старании можно сделать дерьмо. Но когда им не следуешь, то даже стараться не надо.
Если нет надёжной процедуры отката, у вас проблемы посерьёзнее скорости разработки или обеспечения качества фич
С типами обычно быстрее и проще. Свежий пример — я делаю библиотеку, которую пользователь (разработчик конечного приложения) должен проинициализировать довольно сложной вложенной структурой данных.
Как гарантировать, что пользователь библиотеки проинициализировал её правильно, заполнив все необходимые поля?
Тесты на код пользователя писать? Заставить его самого писать себе тесты по документации?
Можно конечно в рантайме проверять и бросать ошибки в рантайме вида: "Возраст должен быть числом", "Не знаю поля Nme, возможно вы имели ввиду Name?" Отладка может быть долгой.
А можно просто сделать типизированный конфиг, который просто не позволит собрать билд с неправильными параметрами или опечататься в значении поля.
Еще раз. ТДД — это способ написания кода
Когда код уже написан, нет никакого тдд.
ТДД и тестировшики не связаны и тем более не взаимозаменяемы, потому что тесты, которые пишут разработчик и QA — разные и предназначены для разных целей.
Ну будет лапша, которая не соответствует SOLID, тормозит разработку (билд занимает часы) и протестирована на единственной версии постгрис.
Это называется регрессионный тест.
Если упали тесты, которые тестируют код, то билд не мог состоятся, т.к. прогон этих тестов (которые написаны разработчиком) — часть процесса билда.
Если же билд состоялся, то регрессия упала на стороне QA и QA должен завести баг.
И всё это не имеет отношения к ТДД. ТДД — это не про тесты, ТДД — это про процесс написания кода
Скрам существует с середины 80х и позволяет с цифрами в руках наглядно показать какое количество функционала может быть готово к определенному сроку. Или наоборот — когда будут готовы все требования.
Если есть риски, их надо озвучить. То что бизнес продал звездолёт без оценки исполнителей и обещает поставить его через неделю — исключительно проблемы бизнес-стороны и ИТ касаться не должны. Статистика — вещь упрямая. Начнёшь подгонять — так ещё и кадры растеряешь