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