О сомнительных советах об эффективности

Давать советы об эффективности тех или иных языковых конструкций довольно сложно, поскольку мало в каком языке есть конструкции с заведомо плохой эффективностью. Обычно разные языковые конструкции предназначены для решения хоть и похожих, но несколько разных задач. Например, цикл for в C# работает только с индексируемыми коллекциями, поэтому сравнивать его с циклом foreach в общем случае некорректно.

Но самая главная проблема появляется тогда, когда в совете об эффективности той или иной фичи не объясняется ситуация, в которой этот совет является применимым. Вроде бы, цитату Кнута/Хоара о преждевременной оптимизации знают все, но продолжают давать советы об эффективности в ультимативной форме.

Вот и сегодня мне встретился такой совет, который ретвитнули несколько человек в моей ленте. Совет с самой мудростью, доступной лишь посвященным, но якобы полезной любому .NET разработчику:

Great high-performance tips for .NET developers pic.twitter.com/EepLub5cl9

— Morten Nielsen (@dotMorten) May 29, 2016

О рецензировании кода

Вот хочется немного поговорить о такой практике, как рецензирование кода, в простонародии – код ревью.С одной стороны, практика известная, во всяких аджайлах она обязательна и повсеместна. Но хотелось бы разобраться, насколько она полезна, и как сделать так, чтобы она ею стала.

Есть несколько стадий развития команды, в каждой из которых может применяться та или иная форма рецензирования кода. Некоторые команды о таком чуде только в мудрых книгах читали, а в некоторых просветленных командах, рецензирование кода является обязательной процедурой, без которой чекинить код низзя, и без него придет большой бородатый артихектор и отархитекторит нерадивому кодеру все, что можно.

Но если эта практика и применяется, то совсем не факт, что она приносит столько пользы, сколько об этом твердят в мудрых книгах адепты гибкости. Итак, в чем же может быть проблема?

TDD: Test-Driven vs. Type-Driven development

Боб «не люблю статическую типизацию» Мартин произвел отменный вброс в своем недавнем посте “Type Wars”, в котором он выразил мысль, что наличие TDD и 100%-е покрытие тестами вполне заменяет статическую типизацию:

“You don't need static type checking if you have 100% unit test coverage. And, as we have repeatedly seen, unit test coverage close to 100% can, and is, being achieved. What's more, the benefits of that achievement are enormous.”

После чего поднялась небольшая волна в этих ваших тырнетах, в результате даже Марк “Я-то точно знаю TDD” Сииман был обвинен в ереси и непонимании принципов, заложенных в TDD.

“TDD replaces a type checker in a dynamically typed language in the same way that a bottle of whisky replaces your daily problems“

— Matt Gumbley (@mattgumbley) May 2, 2016

Параметризованные юнит-тесты в xUnit

В прошлый раз я рассказывал о том, что мне не нравится в xUnit, но поскольку мне все равно с ним приходится иметь дело, то есть смысл поковыряться в нем чуть более основательно, ну и заодно, несколько смягчить, хотя бы рамках рунета, проблему документации и вменяемых примеров использования.

Если вы не в курсе, что такое параметризованные юнит-тесты, и для чего они нужны, то рекомендую почитать мой пост Параметризованные юнит тесты.

Если же вы не в курсе, но лезть в другой пост вам лень, то вот краткое объяснение: параметризованный тест – это специальная фича тестового фреймворка, которая позволяет «сгенерировать» несколько разных тест-кейсов из одного метода, путем передачи ему разных входных данных. Таким образом, тело тесто используется повторно, а с помощью атрибутов или фабричных методов задаются входные параметры тестируемого класса и ожидаемые результаты. А поскольку довольно большое число тестов как раз и используют один и тот же алгоритм проверки, а отличаются лишь «входом» и «выходом», то параметризованные тесты здорово помогают поднять покрытие кода, да еще и за счет улучшения читабельности тестов.