Критика книги Боба Мартина «Профессиональный программист»

У меня со стариной Бобом складываются довольно сложные односторонние отношения. Когда-то, он был моим чуть ли не кумиром, но после внимательного прочтения его книги «Принципы, паттерны и методики гибкой разработки» мое мнение сильно изменилось. Теперь же любой его труд мне читать стало заметно сложнее, поскольку явно начал проявляться «баг» под названием «подтверждение предвзятости». Я стал находить все больше и больше непонятных мне моментов и все меньше полезных советов. Но поскольку большинство книг «дядюшки» Боба весьма известны и обладают высоким рейтингом, я не могу пройти мимо и не поделиться с вами своим впечатлением от прочтения очередного его творения.

Книга «Профессиональный программист» (Clean Coder: A Code of Conduct for Professional Programmers) относится к жанру, который я называю «философией программирования», по названию одноименного форума на rsdn.ru, где было принято обсуждать вопросы стиля, кодинга, гайдлайдов, технического флейма по поводу языков программирования и тому подобных вещей. Популяризаторами этого жанра были такие замечательные авторы как Хант с Томасом и своим «Программистом-прагматиком», Джоэл Спольски со своими записками о программировании и многие другие.

Я вижу две ключевые пользы от таких книг:

• Расширения кругозора
• Повышение мотивации

Например, читая книгу Энди Ханта и Дейва Томаса вы узнаете о «теории разбитых окон»; правиле Деметры; вы узнаете о пользе и сложностях общения в коллективе; поймете, что важно говорить «нет»; убедитесь, что сбор требований – дело сложное и пользователь сам не знает, чего он хочет; узнаете о трюке с резиновым утенком при отладке и будете с осторожностью заявлять о багах в компиляторе и операционной системе и станете больше уделять внимания своим собственным ошибкам. Вы познакомитесь с десятками разных концепций и пополните копилку книг для чтения в будущем.

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

Цель книги Боба Мартина “Clean Coder” аналогична. Но вот справляется ли она со своей задачей? Я в этом не уверен.

Проблема #1. Слишком много личных историй

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

По моему мнению, Боб Мартин явно перебрал с количеством, объемом и качеством личных историй. Нет, я все понимаю, поделиться собственным опытом, полученным в 70-х годах прошлого века очень полезно. Особенно когда дело касается столь актуальных сегодня вещей, как совместная работа с магнитными лентами или дебагинг коммуникационной тулы, которая работала на 300 бод. Давать такие истории книги вполне разумно, если из истории можно сделать полезный вывод или она готовит контекст будущего обсуждения.

ЦИТАТА
В 1964 году моя мама подарила мне на 12-летие маленький механический компьютер. Он назывался Digi-Comp I и состоял из трех пластиковых триггеров и шести пластиковых конъюнкторов.

Но если личные истории носят повествовательный характер и занимают 20% от объема книги, то это не круто. Я бы даже сказал, что это «не профессионально»J. Детальное описание механизма работы древней системы приятно читать на страницах книги вроде «Кодеры за работой», но это не столь уместно в книге, из которой читатель хочет почерпнуть максимум полезной для него информации.

К сожалению, из подавляющего большинства историй сложно сделать какие-то выводы, да и истории эти далеко не всегда служат базой для будущих обсуждений.

Проблема #2. Книга о идеальных программистах и тупых менеджерах

На протяжении четырех глав (главы 1, 2, 3, 10) идет борьба между мифическим менеджером и мифическим программистом. Первый пытается «прогнуть» второго на тему выпиливания сферического коня в вакууме тупым лобзиком за 3 дня, работая при этом 40 часов в сутки. При этом рассматриваются разные модели поведения «кодера», как он должен реагировать на происходящее: должен ли он попросить новый лобзик, должен ли он разбить свой лоб, но сделать в навязанные начальником сроки или как он должен объяснить менеджеру, что тот дурак, но сделать это максимально изысканно и тонко.

Происходит все примерно так:

ЦИТАТА
Мардж: «Питер, мне нужно четкое «да» или «нет». Система оценок вместе с документацией будет готова к пятнице?
Мардж задает абсолютно правильный вопрос. Ей нужно обеспечить соблюдение графика, и ей нужен однозначный ответ насчет пятницы. Как должен ответить Питер?

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

Самое странное, что о PERT-ах в книге говорится. Как говорится и о других механизмах планирования и оценках трудозатрат. Говорится в книге и о командной работе, и о нацеленности на результат, и о профессионализме, черт бы его побрал. Говорится и о том, что оценка носит вероятностный характер и именно так она должна представляться заказчику.

В книге есть парочка просто отличных идей, вот одна из них:

ЦИТАТА
Проблема в том, что оценки можно рассматривать по-разному. Бизнес любит рассматривать их как обязательства. Разработчики предпочитают рассматривать оценки как предположения. Между этими точками зрения существуют принципиальные различия.

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

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

Проблема #3. В книге о кодерах нет советов о кодинге

Чтобы понять, насколько все плохо, достаточно посмотреть содержание главы 4, озаглавленной «Написание кода»:

• Готовность
• Зона потока
• Творческий кризис
• Отладка
• Выбор темпа
• Отставание от графика
• Помощь

Да. В этой главе нет ни слова о кодинге. Нет ничего о пользе/вреде комментариев, о пользе программирования с использованием псевдокода, о пользе/вреде контрактов, о плюсах и минусах ООП, об ФП и неизменяемости, о важности понимания разных парадигм программирования и т.п. вещах.

Отсутствие в книге для кодеров ни слова о кодировании и лучших практиках выглядит довольно странно. И это достаточно странно, учитывая наличие у «дядюшки» Боба таких замечательных выступлений, как “The Failure of State”, которое было сделано еще за год до публикации этой книги, и в котором рассматриваются очень интересные технические вещи (эта же тема потом была раскрыта в его выступлении “Function Programming: What? Why? When?”).

Можно, конечно, сказать, что для кодера кодирование – это далеко не главное, но тогда зачем промывать мозги всякими TDD и прочими FitNess-ами, если эта тема не является ключевой темой книги?

Проблема #4. Я три раза не повторяю

При написании книги бывает сложно запомнить, о чем уже было сказано, а о чем – еще нет. Но в процессе вычитки материала эти проблемы находятся либо самим автором, либо рецензентом. В случае большого «букваря» иногда можно нарушить принцип DRY (Don’t Repeat Yourself) и напомнить читателю ключевые моменты, чтобы ему не пришлось перелистывать книгу несколько раз. В случае же небольшой книги или второстепенных подробностей, повторение режет глаз и выглядит … непрофессионально.

Старина Боб явно решил пропиарить свой проект FitNess, поэтому говорится о нем неоднократно. Что вполне нормально и я бы сделал тоже самое. Но вот описывал бы свой проект я бы лишь один раз, а не три:

ЦИТАТА (страница 25)
Я являюсь основным автором и исполнителем проекта с открытым кодом FitNesse. На момент написания книги размер FitNesse достиг 60K строк, 26 из которых содержатся в 2000+ модульных тестах. По данным Emma, покрытие этих 2000 тестов составляет около 90% кода. Почему не выше? Потому что Emma видит не все выполняемые строки! По моей оценке, степень покрытия намного выше. Составляет ли она 100%? Нет, 100% — асимптотический предел.

ЦИТАТА (страница 90)
Я являюсь основным автором и ответственным за сопровождение FitNesse — системы приемочного тестирования на базе Java. На момент написания книги код FitNesse состоял из 64 000 строк, из которых 28 000 содержались в 2200 отдельных модульных тестах. Эти тесты обеспечивают покрытие по меньшей мере 90% рабочего кода, а их выполнение занимает около 90 секунд.

ЦИТАТА (страница 98)
Например, я веду проект FitNesse, написанный на Java и состоящий из 64 000 строк кода. Полная сборка со всеми модульными и интеграционными тестами занимает менее 4 минут. Если тесты проходят, то я публикую новую версию продукта. Таким образом, весь процесс контроля качества, от исходного кода до развертывания, занимает менее 4 минут. Время компиляции ничтожно мало. Тесты выполняются за считанные секунды. Выходит, цикл компиляции/тестирования может прокручиваться по 10 раз в минуту!

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

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

Отдельной категорией проблем являются сомнительные советы или странные/неполные объяснения некоторых вещей.

Сомнительный совет #1. 100% покрытие кода

ЦИТАТА
Скажете, я предлагаю 100% тестовое покрытие кода? Ничего подобного. Я не предлагаю, а требую. Каждая написанная вами строка кода должна быть протестирована. Точка.

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

Подход Боба сильно отличается от подходов тех же Кента Бека или Мартина Фаулера, которые никогда не выражаются столь категорично по поводу процессов или практик. Большинство опытных людей знают, что 100% покрытие недостижимо не потому, что это сложно, а потому что это вредно! Метрики – штука опасная, экстремальное увлечение метриками приведет к покрытию геттеров и сеттеров, конструкторов и других примитивных штук. В результате, мы получим массу тестов, которые ничего не тестируют и станем свидетелями карго-культа, с которым сложно бороться.

Сравните цитату Боба Мартина с высказыванием другого Мартина – Мартина Фаулера, чтобы понять, какая между этими ребятами разница:

From time to time I hear people asking what value of test coverage (also called code coverage) they should aim for, or stating their coverage levels with pride. Such statements miss the point. Test coverage is a useful tool for finding untested parts of a codebase. Test coverage is of little use as a numeric statement of how good your tests are.

Сомнительный совет #2. 20 часов обучения в неделю

Предыдущая статья – О трудозатратах на саморазвитие, была навеяна этой книгой и следующей цитатой Боба:

ЦИТАТА
Запланируйте 60 рабочих часов в неделю. Первые 40 вы работаете на своего работодателя, а остальные 20 на себя. В эти 20 часов вы читаете книги, практикуетесь, учитесь и иным образом развиваете свою карьеру.

И если вы думаете, что это много, то у старины Боба есть ответ:

Давайте немного посчитаем. В неделе 168 часов, 40 достается вашему работодателю, еще 20 – вашей карьере. Остается 108. 56 тратится на сон, на все остальное остается 52. Возможно, вы не хотите брать на себя подобные обязательства. И это вполне нормально, но тогда не считайте себя профессионалом. Профессионалы не жалеют времени на совершенствование в своей профессии.

Идея подобной книги в том, чтобы зажечь читателя. Проникнуть в его голову и изменить, хотя бы немного, его мировоззрение или, хотя бы, отношение к определенным вещам. Изменится ли ваше отношение к самообразованию, если вы поймете, что вас только что заклеймили «непрофессионалом», поскольку вы тратите каких-то жалких 10 часов в неделю на обучение?

Сомнительный совет #3. Вред состояния потока

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

ЦИТАТА
А теперь небольшой совет от того, кто неоднократно бывал в Зоне (так называется здесь состояние «потока») Избегайте Зоны. На самом деле это состояние не настолько уж эффективно, и безусловно, не непогрешимо. Это всего лишь умеренно-медитативное состояние, в котором мыслительные способности снижаются ради ощущения скорости.

…

Код быстрее пишется в Зоне, но вам придется чаще возвращаться к нему… Теперь когда я чувствую, что мое состояние постепенно входит в Зону, я на несколько минут отхожу от края. Я стараюсь прояснить свои мысли: отвечаю на электронную почту, просматриваю твиты. Если время идет к полудню – я делаю обеденный перерыв. Если я работаю в группе, то нахожу кого-нибудь для парного программирования.

Я не являюсь экспертом в этой теме, но я не смог найти ни одной критической статьи по этому поводу. Но есть много книг/статей, в которых это состояние считается весьма полезным. На замечательном вики-портале c2.com есть статья (http://c2.com/cgi/wiki?MentalStateCalledFlow) с мыслями многих известных людей из мира разработки ПО и ни один из них не выразил опасения по поводу «потока».

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

Сомнительные доводы #1: TDD

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

ЦИТАТА
Да, за прошедшие годы о TDD было написано много противоречивых статей и блогов. На первых порах встречалась серьезная критика и сомнения, но в наши дни все дискуссии завершены. Кто бы что ни говорил, TDD работает.
Я знаю, что это утверждение кажется слишком жестким и односторонним, но в конце концов, хирургам уже не нужно доказывать полезность мытья рук. И я не думаю, что программистам нужно защищать TDD.

Последний легендарный срач по поводу TDD прошел чуть больше года назад, что говорит о том, что дискуссии далеко не завершены (называлась та дискуссия Is TDD Dead, и я о нем писал в пяти частях: часть 1, часть 2, часть 3, часть 4, часть 5).

ЦИТАТА
При таком количестве доводов в пользу TDD отказ от неиспользования этой методологии можно считать проявлением непрофессионализма.
…
«Но я могу написать тесты позднее», скажете вы. Нет, не можете. Конечно, некоторые тесты можно написать позднее. Можно даже обеспечить высокое покрытие, если вы проследите за его измерением. Однако тесты, написанные позднее, лишь защищают от ошибок — тогда как тесты, написанные с опережением, их активно атакуют. Тесты, написанные позднее, пишутся разработчиком, который уже сформировал код и знает, как решалась задача. Такие тесты никак не сравнятся по полноте и актуальности с тестами, написанными заранее.

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

ПРИМЕЧАНИЕ
Если очень интересна TDD, то может быть будет интересным баттл дядюшки Боба и Джима Коплиена: Jim Complien and Bob Martin: Debate TDD. Спойлеры – старина Боб выглядел менее убедительным;)

Сомнительные доводы #2: Парное программирование

Парное программирование – это известная, но не слишком общепринятая практика из экстремального программирования. Вот что пишет о ней Боб Мартин:

ЦИТАТА
Я не собираюсь цитировать научные исследования, хотя у меня в запасе найдется немало подходящих цитат. Я не буду рассказывать «случаи из жизни», хотя и их у меня тоже предостаточно. Я даже не собираюсь указывать, какую часть времени следует проводить за парным программированием. Скажу одно — профессионалы работают в парах. Почему? Потому что по крайней мере для некоторых задач эта методология наиболее эффективна. Впрочем, это не единственная причина.
…
В одних ситуациях работа в одиночку — именно то, что нужно. Иногда вам просто нужно долго и напряженно думать над задачей. В других случаях задача настолько тривиальна, что привлекать к работе другого человека было бы попросту расточительно. Но в общем случае лучше выделять значительную часть времени на работу в тесном контакте с другими и парное программирование.

Интересно в этом плане вспомнить оценку идеи парного программирования, сделанную Бертаном Мейером в его “Agile!: The Good, The Hype and The Ugly”: “Applied judiciously, pair programming can unguestionably be useful. Many developers enjoy the opportunity to program jointly with a peer, particularly to deal with a thorny part of an assignment. ... What is puzzling is the insistence of XP advocates that this technique is the only way to develop software and has to be applied at all times. Such insistence makes no sense...”.

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

Заключение

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

Меня пугает рейтинг и популярность книг старины Боба. 4.3 рейтинг на goodreads и 4.5 – на amazon.com. Возможно, я придираюсь, возможно, обращаю внимание на ненужные подробности. Но я правда считаю, что на рынке есть книги, которые значительно превосходят данную книгу в качестве подачи материала.

Моя оценка: 2/5