вторник, 21 июня 2016 г.

Должен ли менеджер кодить?

DISCLAIMER: данные размышления в значительной степени относятся к менеджерам продуктовых компаний и, как мне кажется, менее применимы к миру аутсорса.

clip_image002

Я уже не раз встречаю мнение о том, что не зависимо от уровня, менеджер в софтверной компании должен оставаться hands on и продолжать кодить (*). Мысль эта несколько необычна, поскольку первое, чему приходится научиться любому начинающему менеджеру в области софтостроения – это как раз-таки, отказаться от этого самого кодирования.

(*) Об этом не раз писал Joe Duffy в постах и твитах, а также Michael Lopp в своей книге “Managing Humans”.

Как и в многих других вещах, ответ на вопрос «Кодить или нет?» несколько сложнее, чем может показаться и не подразумевает бинарной логики в ответе – «да» или «нет».

понедельник, 30 мая 2016 г.

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

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

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

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

среда, 18 мая 2016 г.

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

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

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

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

clip_image002

понедельник, 9 мая 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.

среда, 4 мая 2016 г.

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

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

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

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

вторник, 26 апреля 2016 г.

Что мне не нравится в Xunit

xUnit - это самый популярный нынче тестовый фреймворк, который сейчас активно используется во многих open source проектах типа Roslyn, CoreFx и сотнях проектах поменьше. Я всю свою сознательную жизнь использовал NUnit, но сейчас, иногда по работе, иногда просто при работе с чужеродными кодовыми базами, мне приходится иметь дело с xUnit.

Поскольку тестовый фреймворк – это не особый рокет сайенс, то столкнуться со сложностями при его использовании вообще довольно сложно. Конечно, если это не MSTest, который вызывает состояние недоумения с завидным постоянством.

Но несмотря на зрелость и всеобщую популярность, иногда таки посещают мысли вида WAT при работе с xUnit. Есть два конкретных момента, которые вгоняют меня в легкий ступор. Возможно, ступор этот обусловлен небольшим опытом работы с этим чудом, или неумением его готовить, но все же.

Итак, начнем.

понедельник, 18 апреля 2016 г.

Размышления о TDD

В наших с вами тырнетах снова образовался всплеск активности по поводу TDD, о его здоровье и жизненных показателях. Началось все с поста Ian Sommerville “Giving up on test-first development”, а продолжилось постом Боба «я все знаю о дизайне» Мартине “Giving up on TDD” и еще несколькими постами.

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

Результат vs. Процесс

Когда речь заходит о TDD (Test-Driven Development), то возникает впечатление, что речь идет о каком-то тайном знании. «Знающие» индивидуумы рассказывают о своих успехах с хитрым выражением лица и некоторым снисхождением к тем, кто еще не осознал всей прелести этой аббревиатуры. При этом, когда их просят рассказать о выгодах сего процесса, они начинают бормотать о пользе тестов, важности хорошего дизайна, легкости рефакторинга и гибкости получаемых систем. Иногда, в качестве аргументом могут встречаться фразы о самодокументируемом коде, наличиях «встроенной» в тесты спецификации и высоком покрытии, как о важном артефакте любой вменяемой кодовой базы. А если вы начнете детально обсуждать модульные тесты, то вас перебьют и скажут, что TDD – это вообще-то про дизайн (т.е. про проектирование), а не про тестирование.

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