Понятно что корреляция есть (вы точно не только постоянно отбираете людей, но и затем работаете с ними?) — если уж я запарился почитать про какие-то тонкости или тем более логически до них дошёл, то я как минимум понимаю, в какие ещё стороны можно копать в используемой мною технологии. И практически ничего не говорит о том, как глубоко я туда копнул.
Но всё же из-за моего упрямства и агрессивных нападок, мало кто сможет переубедить в том, что тесты на собеседовании — хорошо. Они очень сильно облегчают жизнь собеседующему, но очень легко (но не всегда) могут быть совершенно оторваны от реальности тем, что будут сконцентрированы на никому не нужном бреде (кроме ЭГО автора).
Одно дело — тест с выбором единственно правильного ответа, другое «а как вы думаете, ....?»
Знание правильного ответа и попытка, пусть и в неверном направлении, до него добраться — разные вещи. Поэтому мой вопрос остался тем же: «с чего вы решили, что прохождение теста помогает ....»
Один я не понял, почему в первой задаче, где требование сформулировано как «Нужно получить единую таблицу со всеми словами и соответствующими им ссылками.», правильным ответом являются две результирующие таблицы? На что также намекает комментарий «для одних и тех же слов ссылки в разных таблицах могут быть разные, т.к. словари были загружены из разных мест». И при этом первый вопрос к собеседующему будет «вы хотите увидеть дубли слова, когда в разных таблицах оно имеет разные ссылки?».
И каким образом вам знание отличия в скорости a+b от for(...) помогают делать правильные оценки, следовать стандартам разработки, учавствовать в совещаниях, писать юнит-тесты и генерировать высокопроизводительный код в сжатые сроки? Ну правда?
Кстати, буквально на днях видел за 5К (или 10К) рублей очки в оптике в Санкт-Петербурге, на ценнике было написано что они умеют снимать и показывать видео и т.д. :)
Господа, вы меня убедили. Вы оба (возьмём именно этот глагол, но возможны варианты) забыли что такое bounded context. Эванс всё прекрасно расписал. Про применимость DDD, исключения, уход от него и прочее.
Требования DDD нас заставляют :) Репозитории только для агрегатов, всё остальное — уже через них (агрегаты). Полезете напрямую — gandjustas назовёт это «выкинуть DDD» :)
Поясню предыдущего оратора. Про неоптимальные запросы из-за DDD — это вопрос к тому, что мы в теории должны грузить связанные сущности из агрегатов. А агрегат — из репозитория. И сам агрегат не очень должен иметь доступа к репозиторию, чтобы качественно нам что-то отфильтровать\отсортировать. Он может только вернуть ссылку на полную неотсортированную коллекцию, а вы там дальше развлекайтесь как хотите, даже если вам нужно просто count(*)… where… по данной ассоциации.
На самом деле списки — это одно. Но если нужно именно в рамках бизнес-логики пройтись по ассоциациям, причём выбрать только удовлетворяющие условию связанные объекты и что-то над ними зашаманить — ещё один кандидат на N+1 или мегабайты данных из БД на каждый чих, т.к. нет прямого доступа к ORM и указанию стратегий загрузки, а есть только ссылка на агрегат.
В целом да, проблема с LL и ассоциациями имеет место быть. Даже если ты не пытаешься сделать DDD, а просто «в лоб» пользуешься ORM… Как её решать в терминах DDD лично мне пока не совсем понятно :-(
Но всё же из-за моего упрямства и агрессивных нападок, мало кто сможет переубедить в том, что тесты на собеседовании — хорошо. Они очень сильно облегчают жизнь собеседующему, но очень легко (но не всегда) могут быть совершенно оторваны от реальности тем, что будут сконцентрированы на никому не нужном бреде (кроме ЭГО автора).
Знание правильного ответа и попытка, пусть и в неверном направлении, до него добраться — разные вещи. Поэтому мой вопрос остался тем же: «с чего вы решили, что прохождение теста помогает ....»
не менее понятен, нежели
и т.д.