В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Software Design/Architecture/Zen

1840 membersпожаловаться на группу
2020 October 31

SP

Sergey Protko in Software Design/Architecture/Zen
Nikita Fedorov
> взял идеи кучи крутых челов, сделал вид что это вброс, ничего не объяснил нормально, словил хейта = Егор
у него есть еще забавная наивная статья с набором про то что SOLID это плохо, по посту было видно что человек вообще в теме не разбирается и использует популярные заблуждения как основные тезисы
источник
14:46пожаловаться#1

SP

Sergey Protko in Software Design/Architecture/Zen
вот скажем... можно погуглить статью "Dependency elimination principle" где автор объясняет "почему мол я больше не преподаю SOLID" - потому что научить людей избавляться от зависимостей солид не учит (наоборот чаще) и без этого скила все это не оч полезно
источник
14:47пожаловаться#2

SP

Sergey Protko in Software Design/Architecture/Zen
а у Егора можно просто брать заголовки (текст часто бесполезен) и за кружечкой пива с друзьями холиварить)
источник
14:48пожаловаться#3

NF

Nikita Fedorov in Software Design/Architecture/Zen
Sergey Protko
у него есть еще забавная наивная статья с набором про то что SOLID это плохо, по посту было видно что человек вообще в теме не разбирается и использует популярные заблуждения как основные тезисы
ну он усвоил урок о том что в современной жизни необоснованные набросы популярны, не думаю что он правда не понимает что пишет дичь, он же даже говорил что делает это осознанно, потому что так проще обратить внимание
источник
14:49пожаловаться#4

NF

Nikita Fedorov in Software Design/Architecture/Zen
Sergey Protko
вот скажем... можно погуглить статью "Dependency elimination principle" где автор объясняет "почему мол я больше не преподаю SOLID" - потому что научить людей избавляться от зависимостей солид не учит (наоборот чаще) и без этого скила все это не оч полезно
Brian Geihsler: Dependency elimination principle?
источник
14:52пожаловаться#5

SP

Sergey Protko in Software Design/Architecture/Zen
да оно
источник
14:52пожаловаться#6

NF

Nikita Fedorov in Software Design/Architecture/Zen
Sergey Protko
да оно
Ну я не понял когда мы начали говорить о Brian'е Geihsler'е, но мне кажется его притензии обоснованны
источник
15:02пожаловаться#7

SP

Sergey Protko in Software Design/Architecture/Zen
Nikita Fedorov
Ну я не понял когда мы начали говорить о Brian'е Geihsler'е, но мне кажется его притензии обоснованны
я про людей которые обосновывают свою точку зрения)
источник
15:03пожаловаться#8

NF

Nikita Fedorov in Software Design/Architecture/Zen
если не писать тестов, и не следить за зависимостями а просто клепать интерфейсы, то будет оч хуево
источник
15:03пожаловаться#9

NF

Nikita Fedorov in Software Design/Architecture/Zen
у меня даже бывало так что становилось сложнее из-за этого, это короче проблема стабильности абстракций
источник
15:04пожаловаться#10

SP

Sergey Protko in Software Design/Architecture/Zen
мне его статья эта в свое время было сродни откровения ибо у меня на тот момент было оч много каши в голове с конфликтующими идеями (don't create your aggregate roots от Уди, open/close из solid, DDD эванса, integration tests are scam j.b. reinsberger). мол было непонятно где и как стыковать эти все штуки.
источник
15:05пожаловаться#11

SP

Sergey Protko in Software Design/Architecture/Zen
мол я потом только нашел вот эти набросы про dependency elimination principles и в комментах в обсуждениях других статей тот же j.b. rainsberger намекал (помойму в дискуссиях с Нетом Прайсом) мол что да что бы его идеи работали нужно больше следить за зависимостями и убирать их, whole value и вот это все... оттуда было проще слинковать open/close и остальное
источник
15:07пожаловаться#12

SP

Sergey Protko in Software Design/Architecture/Zen
ну и с DDD и агрегатами - идеи контекстов и того что агрегаты по инвариантам дробить а не по сущностям тоже помогали
источник
15:08пожаловаться#13

SP

Sergey Protko in Software Design/Architecture/Zen
по инвариантам -> меньше зона ответственности и меньше нужды в зависимостях
источник
15:08пожаловаться#14

SP

Sergey Protko in Software Design/Architecture/Zen
еще скажем честно одна идея которая была не столь очевидна - разные кейсы требуют разных решений. Мол если у тебя есть кусок где хорошо ложится event sourcing то это не значит что в другом месте где тебе нужна версионизация данных имеет смысл этот самый сурсинг тащить. Концепция колаборативного домена про который Уди вещает вот уже совсем все на свои места расставила
источник
15:10пожаловаться#15

SP

Sergey Protko in Software Design/Architecture/Zen
дальше жду других конфликтов идей)
источник
15:10пожаловаться#16

NF

Nikita Fedorov in Software Design/Architecture/Zen
все это так прекрасно, но каждый раз открывая опенсорс проект на js/ts я вижу процедурный код, в котором об устранении зависимостей никто не думал, как и о солид
источник
15:21пожаловаться#17

NF

Nikita Fedorov in Software Design/Architecture/Zen
и каждый раз когда где-то кто-то говорит шо шобы стать крутым прогером и развиваться "надо читать код опенсорс проектов" это вызывает у меня легкую ухмылку
источник
15:22пожаловаться#18

NF

Nikita Fedorov in Software Design/Architecture/Zen
даже если взять тот-же спринг или асп нет они нифига не идеально написаны
источник
15:23пожаловаться#19

NF

Nikita Fedorov in Software Design/Architecture/Zen
хотя лучше среднего
источник
15:24пожаловаться#20