Is TDD Dead. Часть 5

В то время, как в Виларибо спорят жив ли TDD или мертв, в Вилабаджо думают, а стоит ли компилировать код перед коммитом.

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

Is TDD Dead. Part V on Youtube. В целом, получилось более затянуто чем обычно (ведь выступление длилось в двое дольше), но, как всегда, весьма любопытно.

Проблема обсуждения вопросов дизайна

Отвечая на первый вопрос аудитории, Дэвид затронул очень интересную проблему, с которой я лично сталкиваюсь довольно часто: проблему обсуждения подходов к дизайну приложений.

Обсуждение вопросов дизайна является довольно сложным вопросом и у этого есть как минимум несколько причин. Во-первых, дизайн любой системы постоянно развивается, при этом результат зависит не только от способностей членов команды, но и от исторического контекста (злосчастное, «исторически сложилось»). Это значит, что мы не можем судить о существующем дизайне в вакууме, нам нужно еще и понимать, как мы к нему пришли и какие проблемы считали наиболее приоритетными. Во-вторых, не существует достаточно объективной меры качества дизайна, которая бы четко доказывала, что одно решение действительно лучше другого. В-третьих, при обсуждении вопросов дизайна автор статьи или книги сталкивается с вопросом выбора размера и сложности примера. С одной стороны, нет смысла рассматривать продвинутые техники проектирования на примитивных примерах, ведь примитивные задачи можно решить любым способом. С другой стороны, автор не может давать слишком сложные примеры, поскольку 90% читателей просто не захотят тратить свое время и с ними разбираться.

Это я все к тому, что не стоит ждать идеальной книге о дизайне лично для вас, просто это не тот вопрос, на который вы сможете найти простой ответ. Большинство вопросов дизайна привязаны к контексту и именно поэтому, практически на любой вопрос, типа «А что лучше …?» большинство специалистов используют любимую фразу Кента Бека: “It Depends”.

Дизайн – это же поиск наиболее эффективного компромиссного решения, «эффективность» которого всецело зависит от контекста и ограничений, в которых находится человек (или группа людей), принимающая решение. Именно поэтому люди с разным опытом часто не могут найти общий язык в вопросах дизайна, и именно в этом и заключается причина возникновения обсуждения #IsTTDDead. Мы очень часто обобщаем наш опыт, доказывая, что «TDD не имеет смысла, ведь оно применимо лишь в одном случае из 10!». Но это мнение основано на нашем опыте, который может сильно отличаться от опыта нашего оппонента, который работал над задачами, использование TDD в которых было очень удобным.

Вторая причина столь разных точек зрения на использования инструментов заключается в «спирали обучения». Если у вас больше 5 лет опыта, то вы наверняка замечали, что кривая обучения на самом деле выглядит не совсем так, как обычно принято представлять, а несколько иначе. Я бы сказал, что кривая обучения – это скорее бесконечный процесс, который в лучшем случае будет «сходиться» к точке «идеального использования инструмента»:

Форма этой «спирали обучения» обусловлена нашей увлеченностью. Как только мы узнаем о новом инструменте мы начинаем его интенсивно использовать, нас «заносит» и мы начинаем его применять там, где нужно, и там, где без него было бы лучше обойтись. Со временем наша эйфория проходит и мы можем либо вообще отказаться от него («Все, паттерны проектирования не нужны!») или же перейти на новый уровень понимания и использовать инструмент более рационально.

Разные люди находятся на разных точках «спирали обучения», что также усложняет взаимопонимание. К тому же, у разных людей точка «правильного» понимания (линия «правильного понимания» на графике справа) находится на разном уровне, что проявляется в том, что кто-то полностью отказывается от инструмента («TDD не нужен!», или «IoC не нужен!», «или ОО не нужно» и т.п.), а кто-то продолжает упорно использовать инструмент не по назначению.

Как научиться использовать инструмент правильно?

Дэвид, Мартин и Кент затронули еще одну интересную тему, которая может помочь пролить свет на причины неэффективного использования любого инструмента, включая TDD.

По мнению этих трех уважаемых камрадов, неэффективное и зачастую неверное использование инструментов заключается в непонимании главных целей инструмента. Чтобы правильно использовать TDD нужно не только и не столько вызубрить предложенный Кентом цикл “Red, Green, Refactor”, но и понять, какую именно проблему этот цикл призван решать.

Понимание целей методологии или практики позволит не только использовать ее когда нужно, но, что самое главное, даст понять, когда эти практики можно игнорировать. Вот несколько примеров: главная цель коротких итераций TDD заключается в борьбе со сложностью. Значительно проще «есть слона по частям», решая техническую задачу мелкими шагами. При этом никто не говорит, что для каждого человека для каждой задачи «шаг решения» должен быть одинаковым. Для кого-то полезно лучше идти очень мелкими шагами, добавляя один тест для каждого аспекта отдельного метода, а для другого удобнее идти более крупными шагами, решая сразу же задачу уровня модуля.

Кент предложил этот цикл, поскольку ему лично очень комфортно работать в таком режиме, но какой режим максимально полезен вам – ни я, ни Кент Бек, ни Мартин Фаулер сказать не могут. Тоже самое касается и влияния тестов на дизайн: обдумывание дизайна класса через призму тестов и его открытого интерфейса очень хороший способ прийти к чистому дизайну и простому в использовании API, но никто не говорит, что это единственный способ добиться этого результата, или что этот результат вообще гарантирован!

Именно поэтому меня напрягают некоторые книги, которые не раскрывают контекста, а описывают лишь «что нужно делать», а не «почему нам это нужно делать, и когда». Почему считается, что для новичков именно такой подход является наиболее предпочтительным я не знаю, и тоже самое мнение выразил и Дэвид, говоря о вреде “tweet-size tips”. Мне кажется, что начиная обучение новому инструменту и методологии нужно сразу же давать их фундаментальные идеи и контекст использования, а не сосредотачиваться на частностях. Поскольку советы новичку из «Используй TDD всегда и будет счастье» или «TDD – это бред, никогда этого не делай» легко могут развить культ-карго или отбить охоту от инструмента навсегда.

Martin Fowler: “I don’t like dogmatic statements”

Мартин выразился еще более интересно: каждый раз при описании новой возможности, принципа или метода, у тебя должно быть четкое понимание, когда этим инструментом пользоваться не нужно. Если ты сам не можешь выступить адвокатом дьявола, то ты либо не объективен (“biased”), или сам не до конца разобрался в этой теме.

Semantic Diffusion

Чем шире распространяется технология или методология, тем более разнообразным становятся мнения по поводу того, чем же она является. Достаточно посмотреть на ailge, scrum, TDD, DDD и многое другое. (Это ведь даже к языкам программирования относится: Страуструп ведь явно не предполагал, что шаблоны в С++ могут применяться таким разнообразным образом). Если взять исходные труды по этим темам и сравнить с их «популярными современными» описаниями, то можно найти очень много различий.

Такое разнообразие мнений обусловлено эволюцией, что, в свою очередь приводит к понятию, которое Мартин Фаулер называет «размыванием смысла» (semantic diffusion). Такая «эволюция понятия» затрудняет процесс обучения, а также усложняет и без того не простой процесс оценки результата. Со временем становится чрезвычайно сложным понять, в чем причина успеха/провала использования инструмента на проекте: связан ли провал с непониманием или неверным пониманием того, что такое TDD или же TDD просто не применим в данном контексте?

Есть несколько причин, почему полезно знакомиться именно с оригинальными трудами. Во-первых, как правильно заметил Мейер в своей книге, исходные авторы обычно более адекватны:

The zealots of an idea are often more extreme than its creators - the phase "more royalist than the King" captures that phenomenon - and you will find that foundational agile texts, such as those by Beck, Larman or Cockburn, occupy a higher plane of discourse; in particular they avoid below-the-belt hits at other approaches.

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

Выводы

Is TDD Dead, оказалась замечательной серией выступлений. Она показала, что автор TDD (Кент Бек) очень прагматичный человек, который не считает TDD абсолютно полезным инструментом во всех случаях. Кент неоднократно пытался показать, как он подходит к процессу решения задачи и почему и когда TDD ему помогает, при этом он не отрицает, что есть случаи и люди, для которых этот подход будет далеко не таким эффективным.

Эти выступления показали, что инструменты не нужно мерять по шкале «использовать/не использовать»; нужно понимать, зачем оно тебе нужно и чего ты хочешь добиться, и прекращать пользоваться ими, если они перестают тебе помогать и начинает мешать.

Дополнительные ссылки

• О дизайне
• Об автоматизированном тестировании
• Что значат для вас юнит-тесты?
• Критика книги Боба Мартина "Принципы, паттерны и методики гибкой разработки на языке C#"
• Is TDD Dead. Part I
• Is TDD Dead. Part II
• Is TDD Dead. Part III
• Is TDD Dead. Part IV

З.Ы. Понравился пост? Поделись с друзьями! Вам не сложно, а мне приятно;)