Pull to refresh

Comments 27

С точки зрения кода, мы стараемся использовать sync, чтобы избежать всех external weights, таких, как weights БД

В большинстве случаев лучшая стратегия для веб-сервера – это максимальная быстрота, не надо размазываться на разные ядра.

Если я правильно понял фразу, то запрос пользователя исполняется в sync-контексте? Понятное дело, где-то в глубине backend-а, работа с кэшем и БД идет в своих контекстах, но вот точка входа, контроллер используется без async? Или я неправильно понял фразу?
В случае использования библиотек или приложений в backend это имеет больше смысла, так как там меньше запросов и лучше использовать больше ядер на запрос. На самом деле именно для этого создавалась CUDA. Мы заметили, что увеличение количества потоков увеличило и производительность


«Увеличение количества потоков» — может, все-таки имелось ввиду async и это просто опечатка?
In terms of the actual code we use “async” to skip over all the external calls, like database calls, but I don’t know if we can call that multithreaded really.

Так в оригинале, да ошибка.
Понимаю, они крутые ребята, но тут прямо набор антипаттернов разработки.
Продакшн – вот наш бенчмарк. Мы просто релизим код и смотрим, работает он или нет.
Если вы напишете меньше кода, он будет работать быстрее. В одном и том же классе вы можете найти все от HTML, к сожалению, до SQL.
Дотошное следование паттернам и методологиям разработки совершенно не дает гарантии написания хорошего/производительного кода.
С этим не спорю, но.
Есть годами выработанные принципы, являющиеся не достаточным, но необходимым условием для написания производительного, но понятного и поддерживаемого кода. Они возникли не на пустом месте.
UFO just landed and posted this here
1. Тут все просто -> нет сайд эффектов и запрещено заменять навсегда, то без интерфейса, в противном случае по желанию.
2. Это вообще антипаттерн если есть EF.
3. Тут спорно: если вы не билдите вьюхи в том же MVC, то это очень спасает от случайных косяков. А еще если вы протащили энтити из EF — то вообще мастхэв для спокойного сна.
4. Если проект мелкий, то хоть в одной сборке все держите.
Большие проекты с top-down подходом к проектированию — совершенно другие требования.
За все время работы понял, что модульность заставляет писать нормально, думая головой что, где и на каком уровне надо делать. AspNet Core хороший пример, когда я могу взять только те компоненты, которые мне нужны.
5. А вы как, бинарниками шарите? То, что шарят модель — ну сами себе злобные буратины, которые верят в реюз моделей во всех слоях.
6. Независимость не единственный бонус. Например масштабирование определенных компонент, которые вынесены в отдельный сервис. Если неправильно готовить, то все будет какашкой :)
7. Поменяется. Как минимум internal сразу станет бесполезным, а цепкие ручонки полезут тыкать и вызывать все подряд.

Вам не свезло с проектами :) И задачи бизнеса это не только тяп ляп и в продакшен — это всю хрень еще поддерживать годами, следить за совместимостью на бинарном уровне и апи, развивать spi и учитывать, что неверное движение или лишний интерфейс в Nuget пакете — получите кучу головняков с велосипедами от клиентов.

redmanmale то же категоричен:

Даже большой проект != SO. Часть проблем встречается только при таких нагрузках и объемах, которые на тестовом стенде никогда не увидать. Например потестируйте коллизии гуидов.

Меньше кода — лучше локализация, меньше кол стэк и тд и тп. В определенных ситуациях это критично.
Иногда лучше цикл развернуть или по самому тупому закодить, но без лишних аллокаций и вызовов.
У нас есть код где каждый if критичен, например.
UFO just landed and posted this here
Надо сразу резать скоуп проекта ;) Так как сайт или например процессинг — слегка разные весовые категории ;)
Во всем надо искать золотую середину — не надо все упрощать до состояния стола и табуретки, но и абстрагировать все подряд то же не надо.
Еще один фактор: есть проекты «конечные» — написал, сдал, забыл, а есть продукты, которые из года в год развиваются. Тут разный подход, но народ все равно кидается какашками друг в друга, не понимая, что каждый по своему прав :)
А почему репозиторий с EF — анти-паттерн? Везде встречаю репозитории. Надо что, прямо с DbContext операции в сервисе производить? Такую сильную зависимость слоя логики от слоя доступа к данным сделать?
Да, прямо с DbContext в сервисе, если используете EF. Какую сильную зависимость? EF и есть абстракция со встроенным абстрактным репозиторием. Причем это очень текучая абстракция.
А встречается часто, так как начитались книжек про паттерны и пихают куда ни попадя. Абстракция от абстракции. А уж если еще и автомаппер пихнуть(ведь общие модели со слоем данных нини), то просто сказка, а не код. Самый шик — выставить IQueryable из репозитория.

С одной стороны, наличие доступного DbContext дает большую гибкость. С другой стороны, в репозитрии зачастую включает часто используемый код, чтобы не реализовывать его каждый раз в сервисах.
UFO just landed and posted this here
Если я правильно понимаю, то Rich Domain Model — это модель, которая содержит в себе какую-то бизнес-логику, что никак не связано с тем, как она маппится на таблицы. Вполне, мне кажется, можно иметь Rich Domain Model, которая маппится на таблицу 1-к-1 (или если используются свойства навигации — это уже нельзя считать 1-к-1?)

И различные методы репозитория, вроде Insert, Update мне кажется полезными. Хоть они и короткие, но все же не в одну строку. Мне тут видится дублирование кода.

P.S. Сам я просто хочу разобраться, потому что столько мнений, что голова кругом
UFO just landed and posted this here
Добавлю к сказанному sentyaev, что используя репозитори, зачастую, откидываются фичи EF. Например identity map на уровне контекста(либо это все шикарно утекает через всякие врапперы наверх).
Если это все не используется, то не проще использовать тот же Dapper или Linq.Net если уж так не хочется писать SQL запросы? Тут нет лишних абстракций — все, что надо, допиливаете сами и тут как раз паттерн репозиторий как раз в тему.
Мы просто релизим код и смотрим, работает он или нет.

Это как разработчики Galaxy Note,
— «Надо уменьшить толщину телефона, ведь так он более привлекателен для покупателя»
— «Но сэр, хрен его знает что будет с аккумулятором!»
— «Давайте просто зарелизим и посмотрим»
Неправильная аналогия, считаю. У самсунга не было 20ти кратного запаса прочности. Нельзя так просто взять и отозвать over 9000 устройств, а откатить на предыдущую версию код можно.
Значок очень редкий, и единственный способ получить его – встретиться с нами. Мы хотим их раздать в Хельсинки и Москве.

А почему именно в этих городах? Это города с наиболее крупным коммьюнити? (А где же Пекин, Нью-Йорк) Или наоборот, с наименее крупным, но наиболее перспективным?

UFO just landed and posted this here
Интервью проводилось в контексте конференций DotNext, поэтому Марко назвал два соответствующих города.

Конечно, значок можно получить в любом другом месте, встретившись с представителями команды SO.
А есть статья на английском? Хочу дать коллегам почитать, но по русски вообще не бум бум они
супер, спасибо огромное
– О, нет, у нас множество проблем с производительностью. Но вы знаете, оптимизация производительности – это не то, чем вы занимаетесь только тогда, когда уже все умирает и постоянная нагрузка на процессор не падает ниже 80% в течение дней. Именно потому, что мы постоянно оптимизируемся, именно благодаря этому у нас нагрузка 5%, оптимизация – это постоянный и длительный процесс
Sign up to leave a comment.