Это из книг берётся. В стародавние времена читал что-то типа "Unit-тест в .NET" и один из первых примеров - тестирование метода класса с двумя зависимостыми. Сам метод из двух строк - берёт по Id данные из одной зависимости и вызывает метод другой зависимости с полученными данными. И листинги моков на целый разворот, чтобы это проверить. Становится непонятно, что тут тестируется - поведение классов или правильность написания моков.
Хуже всего, что и в продуктовой разработке с этим подходом регулярно приходится сталкиваться.
P.S. Вообще, у Владимира Хорикова в книге "Принципы юнит-тестирования" эти моменты про устойчивость тестов к рефакторингу очень хорошо освещены.
Я для себя давно вывел простое правило: юнит-тесты нужны там, где есть сложная логика. Если есть больше одного места, где можно допустить ошибку на единицу, сложные RegExp'ы - там нужны юнит-тесты.
Для того, чтобы всё это не превратилось в ад хрупких тестов "мок на моке сидит и моками погоняет" мы стараемся выносить эту сложную логику в функциональное ядро. И то, что мы пишем не на функциональном языке (C#) не мешает нам это функциональное ядро находить и выделять.
Тут важно вывести из требований относительно стабильный контракт и его тестировать. Может оказаться, что логика сценария для этого контракта сложна, кейсов проверки слишком много, тогда приходится спускаться на уровень ниже, но в целом, как показала практика, найденное ядро остаётся стабильным и не мешает рефакторингу.
В результате у нас много статических функций (проклятых ООП-евангилистами), данные на входе, данные на выходе, как правило, никаких моков, и тесты - простые как палки.
record'ы не обязательно иммутабельные, но любую структуру (а структура может быть объявлена как record, так и нет) можно объявить readonly и тогда компилятору действительно станут доступны многие оптимизации при передаче структуры как параметра.
Плюс на каждый ссылочный объект накладывается свой overhead по памяти из-за заголовка объекта и выравнивания (padding), что делает "плотность" структур ещё выше.
Так полетело или не полетело? По разным бенчмаркам всё не так однозначно получается и многое зависит от размера и типа словаря. Плюс за косвенное обращение к абстрактному методу какими-то тиками процессора приходится заплатить.
Да сколько угодно такого, но такое отношение как раз и не защищает от аналитического скама. Если б мы жили в идеальном мире, где по цепочке бизнес-продукт-аналитик до разработки доходят только выверенные решения, то и проблем бы не было. Бери табличку из спецификации и переводи её в SQL. Но в том то и дело, что эта цепочка никогда не работает даже близко к идеальному варианту. И если ещё и разработка пофигисты (мы так сделали, потому что нам так сказали), то это будет комбо.
"Не хотят вникать" - это человеческий фактор. Он может встретиться на всех уровнях. Но у разработки есть сдерживающий фактор, которого нет у других - им всё это самим делать. Вот я недавно отбрил прилетевшую сверху идею интеграции двух систем на основе парсинга писем, доставляемых пользователю. В 2025 году. Тебе же только в копию адрес системы поставить, а парсить другой отдел будет. Не разработчики такое придумали, к разработчикам овнеры с этим пришли, а аналитики промолчали.
Плюс много. От быдлокодера в любом случае мало толку. И часто разоработка понимает больше, потому что _вынуждена_ понимать. Это выше по стеку могут сказать: я дал вам стратегию, тактику сами выбирайте. А разработчик всегда тот Вася, которому лопатой махать.
Человек, который не попилил рестухи в кровавом энтерпрайзе пяток лет бесполезен для проектирования API и других подобных интерфейсов. Он может книжку какую-то найти и почитать, но сам по этим граблям не ходил, для него вся эта "идемпотентность" с "транзакционностью" - закрытая книга. Он не понимает почему и где это важно. Если аналитик взялся проектировать БД, то дай бог он not null правильно в колонках расставит. Ограничения уникальности, check constraint, понимания, что какие-то данные можно засунуть в jsonb - этого нет почти ни у кого. И таких людей без подходящего технического бэкграунда среди аналитиков большинство. Редко из разработки уходят в аналитику.
Идеальный мир описан, а в реальном мире "БА с помощью СА" регулярно рожают галиматью, а "откровенный бред" отсеивает тимлид, если ему ещё не стало всё тут фиолетово. Если и тимлид решил переселиться в "идеальный мир", то бред аналитиков будет обрушиваться прямо на головы разработчиков и команда из релиза в релиз будет заниматься откапыванием и закапыванием стюардессы. Доска полна багами, зато разработчики не "простаивают", команда превозмогает и все при деле - радостная картина, которую не трудно продать менеджменту.
>90% всех аналитиков пишут не особо понятные "требования" за продуктами или другими бизнесологами, или "проектируют" api и таблички в БД, которые разработчики потом переделывают
Ну, это если продукт им попадётся толковый, а то тоже протиратели штанов бывают. А так то многое верно: и в части ясности и чёткости требований регулярный булшит, и таблички в БД зачем то "проектируют". При этом польза от аналитиков в наших краях всё-таки есть: легаси могут хорошо расковырять, требования с горем пополам доводятся до уровня, что по ним тестировщики могут написать test-case'ы... Ну продуктовую постановку вместо продукта сделать.
Интересная тут собралась коллекция комментариев. Автор прямо и честно пишет, что предлагает субъективный дартаньявоский взгляд, но куча народа напихивает ему за "субъективизм", пишет, что надо выслушать обе стороны, и тут же, не отходя от кассы, додумывает, как оно всё было на самом деле.
Мне особенно понравились претензии, что автор "не умеет делегировать", и что "бизнесу нужны фичи, а не чистый код". Но каждый, кто в своей жизни сталкивался с корпоративным булшитом, знает одну простую вещь: бизнес просто не знает, какие фичи ему нужны. Таков закон жизни и это не из-за того, что там все дураки или какие-то плохие люди, просто на это есть ряд объективных причин. И DDD Эванса в лучшей своей части посвящена вопросу изучения бизнес-процессов разработкой совместно с бизнесом и дистилляции понимания этих процессов в явно определённых моделях, правилах и ограничениях. Т.е. это работа продукт-овнера, продукт-менеджера, аналитика и тим-лида понять действительную потребность бизнеса и найти кратчайший путь к её решению. Отсюда и возникает то самое "нет" тимлида, если это хороший тимлид, потому что бизнес часто приходит с хотелками вида "хочу кнопку в табличке на форме", а реальную потребность бизнеса можно закрыть иначе, лучше и дешевле, но для этого на каком-то этапе должен найтись человек со словом "нет".
А вопрос, кто станет этим "мистером нет" напрямую связан с "искусством делегирования". Потому что говорить это "нет" и предлагать более лучшие решения в первую очередь должен продукт-овнер, продукт-менеджер, бизнес-аналитики и только потом тим-лид. Но чем выше позиция к "начальству", тем сильнее у людей развита гибкость позвоночника и все эти важные для успеха продукта люди превращаются в обыкновенных "передастов". Бизнес хочет кнопку - Вася, сделай кнопку. Вот оно - искусство делегирования. Манагер "делегируя" задачу разработке и свою харизму перед бизнесом не портит и себе мыслями голову не нагружает. О сложных вещах пусть разработка думает, обязанность думать и разбираться в сложных вещах менеджер "делегировал" вниз по стеку.
И тут вопрос, кто окажется тем "Васей", на котором остановится эта цепочка делегирования. Часто таким человеком становится тимлид, который знает, что "копать" всё равно ему, поэтому он не поленится "думать" прежде чем взяться за лопату. Такой тимлид прослывёт токсичным душнилой, зато его команда не будет из спринта в спринт закапывать и откапывать стюардессу. Впрочем, не редка ситуация, когда тимлид сам овладел "искусством делегирования". Тогда он встроится в линейку начальников, с которыми бизнесу приятно общаться, а тащить работу будет пара сеньоров. Такое тоже случается сплошь и рядом, люди быстро учатся искусству пофигизма.
Есть места, где, чтобы выжить, надо быть... пофигистом. Сам недавно с такого ушёл - софт-скиллов не хватило спокойно наблюдать всё то безобразие, которое не можешь изменить. И, да, ваша хорошая работа никому не нужна, потому что пока вы тянете лямку, то хорошо получается "само", когда без вас что-то начинает сыпаться, то оказывается, что "и так сойдёт", зато нет этого токсичного душнилы.
На счёт смены роли на архитектора, как решение всех проблем... Не поверю. Думаю, что вам просто повезло со следующей компанией.
У меня сейчас похожая ситуация, в которой надо разложить имеющуюся legacy-систему на "кирпичики". Там только процедур на SQL сотни, некоторые из которых по 10 тысяч строк. Описания и экспертов, готовых поделиться своими глубокими знаниями о системе, разумеется нет. Что же мешает разложить такую систему "на кирпичики"?
Какие преимущества у применения CROSS APPLY в демонстрируемом случае перед обычным подзапросом?
SELECTa.AuthorID, a.AuthorName, p.PostIDFROM Authors AS a CROSS APPLY( SELECT MAX(PostID) AS PostID FROM Posts WHERE AuthorID = a.AuthorID ) AS p;
Вот с подзапросом. SELECT a.AuthorID, a.AuthorName, ( SELECT MAX(PostID) AS PostID FROM Posts WHERE AuthorID = a.AuthorID ) as PostID FROM Authors AS a
>Недостаток 2. Ничего не тестируют
Это из книг берётся. В стародавние времена читал что-то типа "Unit-тест в .NET" и один из первых примеров - тестирование метода класса с двумя зависимостыми. Сам метод из двух строк - берёт по Id данные из одной зависимости и вызывает метод другой зависимости с полученными данными. И листинги моков на целый разворот, чтобы это проверить. Становится непонятно, что тут тестируется - поведение классов или правильность написания моков.
Хуже всего, что и в продуктовой разработке с этим подходом регулярно приходится сталкиваться.
P.S. Вообще, у Владимира Хорикова в книге "Принципы юнит-тестирования" эти моменты про устойчивость тестов к рефакторингу очень хорошо освещены.
Я для себя давно вывел простое правило: юнит-тесты нужны там, где есть сложная логика. Если есть больше одного места, где можно допустить ошибку на единицу, сложные RegExp'ы - там нужны юнит-тесты.
Для того, чтобы всё это не превратилось в ад хрупких тестов "мок на моке сидит и моками погоняет" мы стараемся выносить эту сложную логику в функциональное ядро. И то, что мы пишем не на функциональном языке (C#) не мешает нам это функциональное ядро находить и выделять.
Тут важно вывести из требований относительно стабильный контракт и его тестировать. Может оказаться, что логика сценария для этого контракта сложна, кейсов проверки слишком много, тогда приходится спускаться на уровень ниже, но в целом, как показала практика, найденное ядро остаётся стабильным и не мешает рефакторингу.
В результате у нас много статических функций (проклятых ООП-евангилистами), данные на входе, данные на выходе, как правило, никаких моков, и тесты - простые как палки.
Для "развенчания мифа" вам нужно было разобрать влияние размера структуры на "чтение", передачу в параметрах метода прежде всего.
Там многое должно зависеть от наличия модификатора readonly, модификаторов передачи параметра (in, ref...). Вот это была бы интересная серия тестов.
record'ы не обязательно иммутабельные, но любую структуру (а структура может быть объявлена как record, так и нет) можно объявить readonly и тогда компилятору действительно станут доступны многие оптимизации при передаче структуры как параметра.
Чтобы record (который может быть и классом и структурой) стал иммутабельным, достаточно к его объявлению прибавить модификатор `readonly`.
Плюс на каждый ссылочный объект накладывается свой overhead по памяти из-за заголовка объекта и выравнивания (padding), что делает "плотность" структур ещё выше.
Так полетело или не полетело? По разным бенчмаркам всё не так однозначно получается и многое зависит от размера и типа словаря. Плюс за косвенное обращение к абстрактному методу какими-то тиками процессора приходится заплатить.
Да сколько угодно такого, но такое отношение как раз и не защищает от аналитического скама. Если б мы жили в идеальном мире, где по цепочке бизнес-продукт-аналитик до разработки доходят только выверенные решения, то и проблем бы не было. Бери табличку из спецификации и переводи её в SQL. Но в том то и дело, что эта цепочка никогда не работает даже близко к идеальному варианту. И если ещё и разработка пофигисты (мы так сделали, потому что нам так сказали), то это будет комбо.
"Не хотят вникать" - это человеческий фактор. Он может встретиться на всех уровнях. Но у разработки есть сдерживающий фактор, которого нет у других - им всё это самим делать. Вот я недавно отбрил прилетевшую сверху идею интеграции двух систем на основе парсинга писем, доставляемых пользователю. В 2025 году. Тебе же только в копию адрес системы поставить, а парсить другой отдел будет. Не разработчики такое придумали, к разработчикам овнеры с этим пришли, а аналитики промолчали.
Плюс много. От быдлокодера в любом случае мало толку. И часто разоработка понимает больше, потому что _вынуждена_ понимать. Это выше по стеку могут сказать: я дал вам стратегию, тактику сами выбирайте. А разработчик всегда тот Вася, которому лопатой махать.
Человек, который не попилил рестухи в кровавом энтерпрайзе пяток лет бесполезен для проектирования API и других подобных интерфейсов. Он может книжку какую-то найти и почитать, но сам по этим граблям не ходил, для него вся эта "идемпотентность" с "транзакционностью" - закрытая книга. Он не понимает почему и где это важно. Если аналитик взялся проектировать БД, то дай бог он not null правильно в колонках расставит. Ограничения уникальности, check constraint, понимания, что какие-то данные можно засунуть в jsonb - этого нет почти ни у кого. И таких людей без подходящего технического бэкграунда среди аналитиков большинство. Редко из разработки уходят в аналитику.
Идеальный мир описан, а в реальном мире "БА с помощью СА" регулярно рожают галиматью, а "откровенный бред" отсеивает тимлид, если ему ещё не стало всё тут фиолетово. Если и тимлид решил переселиться в "идеальный мир", то бред аналитиков будет обрушиваться прямо на головы разработчиков и команда из релиза в релиз будет заниматься откапыванием и закапыванием стюардессы. Доска полна багами, зато разработчики не "простаивают", команда превозмогает и все при деле - радостная картина, которую не трудно продать менеджменту.
>90% всех аналитиков пишут не особо понятные "требования" за продуктами или другими бизнесологами, или "проектируют" api и таблички в БД, которые разработчики потом переделывают
Ну, это если продукт им попадётся толковый, а то тоже протиратели штанов бывают.
А так то многое верно: и в части ясности и чёткости требований регулярный булшит, и таблички в БД зачем то "проектируют". При этом польза от аналитиков в наших краях всё-таки есть: легаси могут хорошо расковырять, требования с горем пополам доводятся до уровня, что по ним тестировщики могут написать test-case'ы... Ну продуктовую постановку вместо продукта сделать.
Интересная тут собралась коллекция комментариев. Автор прямо и честно пишет, что предлагает субъективный дартаньявоский взгляд, но куча народа напихивает ему за "субъективизм", пишет, что надо выслушать обе стороны, и тут же, не отходя от кассы, додумывает, как оно всё было на самом деле.
Мне особенно понравились претензии, что автор "не умеет делегировать", и что "бизнесу нужны фичи, а не чистый код". Но каждый, кто в своей жизни сталкивался с корпоративным булшитом, знает одну простую вещь: бизнес просто не знает, какие фичи ему нужны. Таков закон жизни и это не из-за того, что там все дураки или какие-то плохие люди, просто на это есть ряд объективных причин. И DDD Эванса в лучшей своей части посвящена вопросу изучения бизнес-процессов разработкой совместно с бизнесом и дистилляции понимания этих процессов в явно определённых моделях, правилах и ограничениях. Т.е. это работа продукт-овнера, продукт-менеджера, аналитика и тим-лида понять действительную потребность бизнеса и найти кратчайший путь к её решению. Отсюда и возникает то самое "нет" тимлида, если это хороший тимлид, потому что бизнес часто приходит с хотелками вида "хочу кнопку в табличке на форме", а реальную потребность бизнеса можно закрыть иначе, лучше и дешевле, но для этого на каком-то этапе должен найтись человек со словом "нет".
А вопрос, кто станет этим "мистером нет" напрямую связан с "искусством делегирования". Потому что говорить это "нет" и предлагать более лучшие решения в первую очередь должен продукт-овнер, продукт-менеджер, бизнес-аналитики и только потом тим-лид. Но чем выше позиция к "начальству", тем сильнее у людей развита гибкость позвоночника и все эти важные для успеха продукта люди превращаются в обыкновенных "передастов". Бизнес хочет кнопку - Вася, сделай кнопку. Вот оно - искусство делегирования. Манагер "делегируя" задачу разработке и свою харизму перед бизнесом не портит и себе мыслями голову не нагружает. О сложных вещах пусть разработка думает, обязанность думать и разбираться в сложных вещах менеджер "делегировал" вниз по стеку.
И тут вопрос, кто окажется тем "Васей", на котором остановится эта цепочка делегирования. Часто таким человеком становится тимлид, который знает, что "копать" всё равно ему, поэтому он не поленится "думать" прежде чем взяться за лопату. Такой тимлид прослывёт токсичным душнилой, зато его команда не будет из спринта в спринт закапывать и откапывать стюардессу. Впрочем, не редка ситуация, когда тимлид сам овладел "искусством делегирования". Тогда он встроится в линейку начальников, с которыми бизнесу приятно общаться, а тащить работу будет пара сеньоров. Такое тоже случается сплошь и рядом, люди быстро учатся искусству пофигизма.
Читаю и удивляюсь: какие вы тут все проницательные!
P.S. Ситуация, когда мои бывшие тимлиды отмалчивались на дейликах, меня тоже вымораживала. Вот баре.
Есть места, где, чтобы выжить, надо быть... пофигистом. Сам недавно с такого ушёл - софт-скиллов не хватило спокойно наблюдать всё то безобразие, которое не можешь изменить. И, да, ваша хорошая работа никому не нужна, потому что пока вы тянете лямку, то хорошо получается "само", когда без вас что-то начинает сыпаться, то оказывается, что "и так сойдёт", зато нет этого токсичного душнилы.
На счёт смены роли на архитектора, как решение всех проблем... Не поверю. Думаю, что вам просто повезло со следующей компанией.
У меня сейчас похожая ситуация, в которой надо разложить имеющуюся legacy-систему на "кирпичики". Там только процедур на SQL сотни, некоторые из которых по 10 тысяч строк. Описания и экспертов, готовых поделиться своими глубокими знаниями о системе, разумеется нет. Что же мешает разложить такую систему "на кирпичики"?
>Когда нужно вытащить 2+ поля он удобен
Да. Вот и хотелось бы в статье таких примеров, которые показывают в чём действительное удобство этих операторов.
Какие преимущества у применения CROSS APPLY в демонстрируемом случае перед обычным подзапросом?
SELECTa.AuthorID, a.AuthorName, p.PostIDFROMAuthorsASaCROSS APPLY(SELECTMAX(PostID)ASPostIDFROMPostsWHEREAuthorID = a.AuthorID)ASp;Вот с подзапросом.
SELECT a.AuthorID, a.AuthorName, (SELECT MAX(PostID) AS PostID
FROM Posts
WHERE AuthorID = a.AuthorID
) as PostID
FROM Authors AS a