Не проблема, но рано или поздно сервис все равно будет раздут до кучи методов и тысячи строк. Вот сколько раз не пытались так организовать код лучше чем с медиатором так и не получалось :) А вот проблема, с навигацией и подсветкой от компилятора неиспользуемых классов, да, очень бесит. Проблему с навигацией можно решить размещением класса-хендлера внутри класса-комманды, но этот подход прямо скажем на любителя.
Цель исследования — определить, какой из фреймворков лучше всего справляется со стилизацией по умолчанию, т.е. без добавления специальных (предусмотренных фреймворком) классов.
Нужно быть внимательнее, автор ставил другую цель.
На каждое слово из этой цепочки тебе может пригодиться минимум по циклу. Итого, в твоём примере будет семь циклов.
Ну почему же сразу 7? К примеру, первые три оператора: Where, Select и GroupBy (В зависимости от контекста), можно будет к примеру объединить в один цикл, осуществляющий одновременно фильтрацию, маппинг в объект и сохранение в какой-нибудь словарь. И скорее всего, если бы появились проблемы с производительностью, данная замена сказалась бы на ней положительно.
просит тестировщика перепроверить другие части приложения
А вот мы и пришли к тому, что вы согласились с автором.
— Как найти эти части приложения?
— Провести анализ, что, собственно, и было описано в пункте, который вы так рьяно хотели спихнуть на тестировщика)
Я прочитал остальные части текста, однако не счел правильным их комментировать. По моему мнению, все вещи, которые вы описали выше блока, который я процитировал имеют место быть только в шаблоне компании, в которой каждый сотрудник находится в черном ящике и область его деятельности — получить задачу от предыдущего звена цепочки обработать и выплюнуть статус-код. Это прекрасный пример как должна функционировать крупная компания и то, что вы привыкли к этому хорошо, но к сожалению, не весь бизнес работает так, как вы думаете. Если бы мне хотелось, я бы раскрыл эту тему, но проще просто процитировать первый комментарий:
Хорошо, когда есть тестировщик.
Что касается вашего замечания по поводу тестов и ide, тут получается все еще более небрежно, в плане аргументации. IDE даст вам возможность проследить где битый код вызывается, однако данные, которые этот битый код обрабатывает могут пройти еще миллионы итераций кода, положиться в базу или отправиться на обработку в какой-то сторонний сервис или пройти через какую-нибудь BPM и грохнуть чей-нибудь процесс…
Что касается тестов… Задайте вопрос, что делать если тестов не будет? Как в таком случае поступает бизнес? Тратит 40$/ч на написание тестов под древнюю систему?
Опять боязнь тестировщика, зачем его нанимали в компанию?
Я поражен вашей уверенностью.
После исправления ошибки в (? чужом) коде вы никогда не сомневались в правильности своего решения и его совместимости с остальными элементами? Не задумывались, по какой причине эта ошибка была совершена? Такая уверенность в собственной непогрешимости, а так же в непогрешимости остального кода, который скорее всего был написан теми же людьми, чьи ошибки и завели этот баг может сыграть плохую шутку.
Кроме этого, никто не гарантирует, что тестировщик, который будет тестировать ваше решение, проверит связанные с этим багом элементы, а не просто по тест-кейсу увидит совпадение с ожидаемым результатом и с радостью отправит свежий код в продакшен. Когда новая ошибка всплывет кто будет больше виноват, тестировщик работающий по тест-кейсу или программист, который в процессе починки одного модуля сломал другой?
Еще встает вопрос гордости. Хорошо, что у вас дружеские отношения с тестировщиками внутри компании, но что если вы работаете в аутсорс-компании, а тестирование происходит уже у заказчика или у посредника? Я уверен, что на каком-нибудь созвоне довольный тестировщик, расскажет как дал по рукам нерадивому погромисту и спас модуль от коллапса. Не скажу, что это большая проблема, но и приятного ничего нет.
Понятно, что такие баги встречаются не каждый день, но все же встречаются. Не то, чтобы я подписался под каждым пунктом автора, но и так категорично к ним бы не относился.
Не могли бы вы дать ссылку на пример подобной реализации, либо самому написать статью) После вашего комментария открылись глаза, прошерстил большую часть примеров «Правильной реализации веб-приложений на asp.net», и везде сервисы лишь являются переносом кода из контроллера в отдельную библиотеку, в которой используется вся доступная логика приложения.
Не проблема, но рано или поздно сервис все равно будет раздут до кучи методов и тысячи строк. Вот сколько раз не пытались так организовать код лучше чем с медиатором так и не получалось :)
А вот проблема, с навигацией и подсветкой от компилятора неиспользуемых классов, да, очень бесит. Проблему с навигацией можно решить размещением класса-хендлера внутри класса-комманды, но этот подход прямо скажем на любителя.
Исходя из контекста собеседование проходило онлайн, так что уж точно не лист бумаги.
А каким образом, в таком случае, разрешаются коллизии?
Любой из примеров можно интерпретировать как 12 августа в зависимости от перестановки...
Писали несколько крупных приложений с 0 на тс — все было отлично. Переводить, правда, не пробовали…
Нужно быть внимательнее, автор ставил другую цель.
Ну почему же сразу 7? К примеру, первые три оператора: Where, Select и GroupBy (В зависимости от контекста), можно будет к примеру объединить в один цикл, осуществляющий одновременно фильтрацию, маппинг в объект и сохранение в какой-нибудь словарь. И скорее всего, если бы появились проблемы с производительностью, данная замена сказалась бы на ней положительно.
А вот мы и пришли к тому, что вы согласились с автором.
— Как найти эти части приложения?
— Провести анализ, что, собственно, и было описано в пункте, который вы так рьяно хотели спихнуть на тестировщика)
Что касается вашего замечания по поводу тестов и ide, тут получается все еще более небрежно, в плане аргументации. IDE даст вам возможность проследить где битый код вызывается, однако данные, которые этот битый код обрабатывает могут пройти еще миллионы итераций кода, положиться в базу или отправиться на обработку в какой-то сторонний сервис или пройти через какую-нибудь BPM и грохнуть чей-нибудь процесс…
Что касается тестов… Задайте вопрос, что делать если тестов не будет? Как в таком случае поступает бизнес? Тратит 40$/ч на написание тестов под древнюю систему?
Я поражен вашей уверенностью.
После исправления ошибки в (? чужом) коде вы никогда не сомневались в правильности своего решения и его совместимости с остальными элементами? Не задумывались, по какой причине эта ошибка была совершена? Такая уверенность в собственной непогрешимости, а так же в непогрешимости остального кода, который скорее всего был написан теми же людьми, чьи ошибки и завели этот баг может сыграть плохую шутку.
Кроме этого, никто не гарантирует, что тестировщик, который будет тестировать ваше решение, проверит связанные с этим багом элементы, а не просто по тест-кейсу увидит совпадение с ожидаемым результатом и с радостью отправит свежий код в продакшен. Когда новая ошибка всплывет кто будет больше виноват, тестировщик работающий по тест-кейсу или программист, который в процессе починки одного модуля сломал другой?
Еще встает вопрос гордости. Хорошо, что у вас дружеские отношения с тестировщиками внутри компании, но что если вы работаете в аутсорс-компании, а тестирование происходит уже у заказчика или у посредника? Я уверен, что на каком-нибудь созвоне довольный тестировщик, расскажет как дал по рукам нерадивому погромисту и спас модуль от коллапса. Не скажу, что это большая проблема, но и приятного ничего нет.
Понятно, что такие баги встречаются не каждый день, но все же встречаются. Не то, чтобы я подписался под каждым пунктом автора, но и так категорично к ним бы не относился.