понедельник, 28 декабря 2015 г.

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

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

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

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

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

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

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

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

clip_image002[8]

Проблема #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

34 комментария:

  1. >> «не профессионально»J.

    Скорее всего, опечатка.

    ОтветитьУдалить
    Ответы
    1. При копировании "смайла" он вставляется в виде буквы J. Вот есть неплохая статья с описанием истории: https://blogs.msdn.microsoft.com/oldnewthing/20060523-10/?p=31103

      Удалить
  2. еще по поводу 100% покрытия тестами: http://blog.ploeh.dk/2015/11/16/code-coverage-is-a-useless-target-measure/

    ОтветитьУдалить
  3. - Проблема #1. Слишком много личных историй
    Как раз то что нужно при работе с менеджерами и постредственными програмистами. Им становиться интересно почитать\послушать.
    - Проблема #2. Книга о идеальных программистах и тупых менеджерах
    Не все работают в Микрософте, но большенство менеджеров действительно тупые в разработке.
    - Проблема #3. В книге о кодерах нет советов о кодинге.
    Так и книга не о коде, а о том как быть професионалом, как следует себя вести и общяться с людми.
    - Сомнительный совет #1. 100% покрытие кода
    Автоматическое тестирование и TDD не одно и тоже. Если следовать ТDD весь код действительно будет покрыт на 100%. А то что не покрыто было создано без использования TDD.
    - Сомнительный совет #2. 20 часов обучения в неделю
    В полне реально, смотря как различать активность. На пример, стоит задача использовать Entity Framework model first. А я дай и разобрался в code first и выполнил задачу. Как считать? это время потратил на работу или на обучение....

    ОтветитьУдалить
    Ответы
    1. > - Проблема #1. Слишком много личных историй
      > Как раз то что нужно при работе с менеджерами и постредственными програмистами. Им становиться интересно почитать\послушать.

      Сергей, мне несовсем ясно, как истории об отладке штуки 40 летней давности помогут чем-то при работе с менеджерами и посредственными программистами;)

      > - Проблема #2. Книга о идеальных программистах и тупых менеджерах
      > Не все работают в Микрософте, но большенство менеджеров действительно тупые в разработке.

      Сергей, чтобы судить о менеджерах в Майкрософте, нужно поработать в Майкрософте. Большинство менеджеров тут пришли из девелоперов, что СУЩЕСТВЕННО усложняет общение с ними, поскольку зачастую разговор переходит на тему реализации.
      Менеджеры в аутсорсе, например, совсем не занимаются техническими вещами, но обладают более развитыми скиллами в области проджект/программ-менеджмента.

      Мне не понравилось то, что "тупой" менеджер был на протяжении многих глав. Я бы, например, в этом случае дал бы один совет: научи менеджера планировать. И все. После этого, взаимоотношения "кодер" - "менеджер" стали бы на порядок более конструктивными.

      Не кодер должен знать о PERT-е, а менеджер. У кодера, даже очень и очень хорошего, хватает других дел.

      > - Проблема #3. В книге о кодерах нет советов о кодинге.
      > Так и книга не о коде, а о том как быть професионалом, как следует себя вести и общяться с людми.
      Сергей, а почему тогда тут есть о TDD? Зачем давать одну практику, которая влияет на код и дизайн, но не давать практики чисто кодерские?
      Я ведь не зря сравнивал эту книгу с "Программистом-прагматиком". Они обе из одной ниши и покрывают одни и те же темы, но "прагматики" покрыли и дизайн, и кодинг, и философию, при этом оставшись в соизмеримом объеме.

      > - Сомнительный совет #1. 100% покрытие кода
      > Автоматическое тестирование и TDD не одно и тоже. Если следовать ТDD весь код действительно будет покрыт на 100%. А то что не покрыто было создано без использования TDD.

      Я прекрасно понимаю разницу между TDD и автомтаизированным тестированием. Проблема в том, что TDD - практика не одназначная, лишь артефакты TDD признаны однозначно полезными.

      Я рекомендую пересмотреть Is TDD Dead, чтобы освежить, что вумные мужи думают по этому поводу.

      > - Сомнительный совет #2. 20 часов обучения в неделю
      > В полне реально, смотря как различать активность. На пример, стоит задача использовать Entity Framework model first. А я дай и разобрался в code first и выполнил задачу. Как считать? это время потратил на работу или на обучение....
      Считать просто: если это "плюс" к рабочему времени, то входят, если это во время работы - то не входят;) Из комментариев к предыдущей статьи и опросу, нашелся лишь один человек, который столько времени тратит на обучение. Статистика, конечно, небольшая, но и среди моих знакомых никто даже и близко не тратит 20 часов на обучение/сторонние проекты. Это просто слишком много.
      Ну и посмотрите на приведенную у меня в цитатах арифметику с оставшимися 52 часами в день, арифметика ведь не корректна.

      Удалить
    2. Сергей, я вижу, что вам книга понравилась (судя по тому, что с моими замечаниями вы не согласны). Я вам предлагаю вот что: попробуйте сформировать наиболее ценные вещи, которые вы вынесли из книги. Я почти уверен, что некоторые полезные вещи прошли мимо меня, либо потому что я их знал, либо потому что я их пропустил.

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

      Мме правда это интересно.

      Удалить
    3. Первое что мне в этой книге помогло было объяснение как менеджерам так и разработчикам разницы между Estimate и Commitment. Различия между "я думаю это займет 3 недели" и "Я обещаю что закочу это за 3 недели".
      Я вполне понимаю твоё недовольство книгой. Но у меня сложилось впечатление что твои ожидания от книги не оправдались что повлияло на восприятие. Вот например ты упоминаеш что автор живёт в идеальном мире. Хотя упоминаеш о мудрых менеджерах, что являеться для меня действительно нереальным явлением. Я думаю что кника не расчитана на сформировавшегося специалиста, а больше на простых разработчиков и даёт им рекомендации как организовать работу. В маём личном опыте, я всё время подозревал что менеджеры тупые но не мог в это поверить. После прочтения книги появляеться понимание что это так и есть, и вот рецепт что с этим делать. Например если на моём текущем проекте текущий менеджер перейдет на работу в другую индустрию, он будет то чно таким же менеджером, так как он ничего (от слова сосем) не понимает в разработке.

      П. С. Дядя Боб произвёл небывалое влияние на меня как разработчика, так что может быть что я ещё не готов к тому что бы кретически отнестись к его книгам. Когда он говорит "поверте мне", я склонен ему верить.

      Удалить
    4. Сергей, спасибо за развернутый комментарий!

      Есть несколько моментов, на которые стоит обратить внимание:
      1. Если ты в книге видишь категоричные заявления по поводу чего угодно, то стоит серьезно насторожиться. Дело в том, что любое правило должно применяться в определенном контексте и большинство авторов стараются либо дать контекст, либо высказываться осторожно. Я уже упоминал Is TDD Dead. Просто сравни фразы Кента Бека (автора TDD) и Боба Мартина. Кент очень осторожен в высказываниях, он всегда дает понять, что нет серебряных пуль и простых ответов на сложные вопросы.

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

      Ну и в заключении: если книга лично тебе помогла, то это просто прекрасно! Нет, я серьезно! Я просто считаю, что есть более качественные и более профессионально написанные книги (тот же "Программист-прагматик", которого я просто люто рекомендую тебе почитать) и с меньшим количеством безапелляционных заявлений, которые могут неправильно повлиять на читателя.

      Удалить
  4. Этот комментарий был удален автором.

    ОтветитьУдалить
  5. Когда читал твой предыдущий пост о затратах на самообучение, то сразу же вспомнил про эту книгу и про загиб Мартина насчёт 20 часов в неделю. Для меня Мартин тоже всегда был авторитетом (и является по-прежнему, он не категоричен и это понимаешь, когда относишься ко всему, что он говорит со спокойствием и читаешь ни одну его книгу, а практически весь материал, который он производит). Этот совет я воспринял буквально и записал на свой счёт. Стал замерять в течении месяца чистый расход времени на самообразование. У меня получилось максимум 14-16 часов в неделю. И такой график я могу выдержать максимум 2 недели, после этого просто глаза с орбит начинают вылазить :)

    ОтветитьУдалить
    Ответы
    1. Я также прочитал практически все его книги и из всех его трудов, лишь Чистый код мне понравился. Там есть ряд весьма сомнительных советов (типа, что самая лучшая функция - это функция, которая ничего не принимает и ничего не возвращает), но книга весьма хороша.

      Возможно, я правда воспринимаю его советы слышком буквально, что мне сильно не нравится. Но я не знаю, как воспринимать мысли, которые я тут запостил в качестве цитат: по поводу покрытия, по поводу TDD, парного программирования и прочее. Ведь там явно говорится, что это истинна в последней инстанции и автор не старается дать контекст применимости своих советов.. Что, ИМХО, довольно плохо...

      Удалить
    2. Наиболее адекватен он в своей серии скринкастов clean code episodes. Я там навскидку не вспомню дикого самодурства. Почему у него такие книги получаются - даже не знаю. Если, опять же, смотреть интервью с ним, то он тоже особо не грешит максимализмом. Иногда такие люди, возможно, начинают по дефолту ощущать себя менторами и пытаться загонять серебряные пули. Этого у Марка Симана тоже в избытке, кстати. Иногда он любит правила возводить до догматов.

      Удалить
  6. Ошибка наверное в предложении: Отсутствие в книге для кодеров ни слова о кодировании и лучших практиках выглядит довольно странно.

    ОтветитьУдалить
    Ответы
    1. Да, фраза мутная. Нужно бы переделать. Спасибо!

      Удалить
  7. По поводу потока.
    Мне кажется, Боб Мартин грешит преждевременным обобщением и пытается возвести свой личный опыт в абсолют (как и многие другие свои наблюдения).

    Есть мнение, что состояние потока (или, как еще его называют психологи, – оптимальное переживание) составляет основу человеческого счастья. Без него работать было бы далеко не так интересно.

    Можно почитать на эту тему "Flow: The Psychology of Optimal Experience" от Mihaly Csikszentmihalyi.

    ОтветитьУдалить
    Ответы
    1. Я даже скажу более - многие программисты (я, в том числе) наиболее плодотворно работают именно в состоянии потока. Хотя бы уже потому, что он позволяет держать в голове гораздо большее количество связанной информации, чем в обычном состоянии. И наверное самое ужасное, что может случиться во время кодинга - это когда тебя вырывают из потока и ты теряешь сразу кучу мыслей и полезной информации.

      Удалить
    2. Александр, небольшая правка: в голове мы можем держать всегда одинаковый объем информации, просто в состоянии потока там нет ничего лишнего))

      Удалить
    3. вот тут скажу в защиту: возможно вы обсуждаете разные "потоки". Мне показалось, что я понимаю о чем автор пишет. Часто бывает ухожу в код, непрестанно кодирую. Но эффективность не всегда высокая. И через пару часов появляется ощущение что сложно оторваться, чаю попить даже - тянет обратно, дальше дальше. Но как научил меня в начале карьеры опытный коллега: работать нужно конечно, но иногда нужно и думать. А в этом "потоке" думаю меньше, больше скорее играюсь.

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

      Удалить
    4. @Unknown (сори, не знаю, как по имени): идея потока в том, что мыслительные процессы протекают максимально эффективно за счет того, что кратковременная память (коей крайне мало) освобождена от других насущных проблем типа почты, твитера с фейсбучиком. Я пока что не слышал, чтобы кто-то работал в этом состоянии хуже. Т.е. если вы в состоянии потока не думаете, то это не состояние потока. По определению;)

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

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

      Я же боюсь одного: что читатель не включит свою голову при чтении и будет считать, что специально отвлекаться на почту и твиттер во время работы это не просто не очень, это очень даже нормально, поскольку авторитетный дядька по имени Боб Мартин об этом советует в своей книге. Еще раз: Боб Мартин рекомендует отвлекаться от работы на почту!!! Это противоречит не только опыту большинства программистов, но и принципам изложенным в таком замечательном курсе как Learning How To Learn;)

      Удалить
    5. >>идея потока в том, что мыслительные процессы протекают максимально эффективно ... Т.е. если вы в состоянии потока не думаете, то это не состояние потока.
      в этом и загвоздка - одно дело просто быстро соображать, а другое дело подумать над задачей. Из определения выше вы просто получаете больше ресурсов (пустую кратковременную память), но это увы автоматически не означает что глубый в обыденности человек становиться на порядки умнее в состоянии потока.

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

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

      >> из статьи: я не смог найти ни одной критической статьи по этому поводу
      >> Боб Мартин рекомендует отвлекаться от работы на почту!!!
      тут просматривается ошибка подтверждения: есть полная уверенность о непогрешимости этого состояния и не удивительно что "отвечаю на электронную почту, просматриваю твиты" сразу выхватывается из контекста. Меня заинтересовала как раз начало этой фразы "Я стараюсь прояснить свои мысли". Что вполне корректно отражает мысль автора выше и необходимость отвлекаться для прояснения мыслей. Не всегда первая идея - лучшая идея.

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

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

      >> недоумение по поводу его этой фразы, то он бы разъяснил свою точку зрения лучше и книга была бы лучше.
      Здесь я согласен, что написано не лучшим стилем для понимания: одно автор думал, другое выразил, третьее пероводчик перевёл и 4ое понял читающий. Поэтому я бы с удовольствием обсудил бы разбор книги, но с попыткой воспроизвести начальную идею автора и разъяснением в более понятном ключе.




      Удалить
    6. > Т.е. если вы в состоянии потока не думаете, то это не состояние потока.
      Ну, давайте возьмем определение:
      In flow, the emotions are not just contained and channeled, but positive, energized, and aligned with the task at hand. The hallmark of flow is a feeling of spontaneous joy, even rapture, while performing a task,[2] although flow is also described (below) as a deep focus on nothing but the activity – not even oneself or one's emotions.

      Таким образом, состояние потока может быть бездумным или глубоко мыслительным в зависимости от выполняемой задачи. Например, в состоянии потока можно копать огород и в этом случае мыслей будет ноль. Только лопата и земля перед глазами. Если же говорить о программировании, то мыслительная деятельность тут является важным и неотъемлемым атрибутом, а значит в состоянии потока она должна присутствовать. Безусловно, можно в состоянии потока и говнокодить, когда процесс включает лишь бездумное нажимание на кнопки, но мы же говорим о работе программиста, а не машинистки;)

      > Поэтому по подходу (в понятных терминах): не стоит критиковать реализацию, если абстракция верна. Можно предложить свои варианты отвлечения (сходить на обед мой любимый кстати, или попить чайку), но я не вижу оснований на корню обвинять автора в некомпетентности.

      Тут все очень тонко и сложно, ИМХО. Я не считаю, что абстракция верна или она настолько завуалирована, что ее исходный и правильный посыл полностью скрыт. Отвлечение отвлечению - рознь, и пройти прогуляться - это совсем не одно и тоже, что почту посмотреть. Да и посыл разный. Вспомните технику помидора: вы работаете 25 минут сосредоточено (поток?), после чего переключаете сознание на 5 минут. Автор же предлагает следить за собой и не входить в состояние потока. Я не могу сказать, что первый и второй варианты эквивалентны. Совсем.

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

      Вы критикуете мою критику, но я не вижу, чтобы вы следовали своему собственному совету;)

      > Здесь я согласен, что написано не лучшим стилем для понимания: одно автор думал, другое выразил, третьее пероводчик перевёл и 4ое понял читающий. Поэтому я бы с удовольствием обсудил бы разбор книги, но с попыткой воспроизвести начальную идею автора и разъяснением в более понятном ключе.
      Общение в интернетах - вообще дело сложное. Я, например, уже вообще не понимаю, в каком контексте дан вот этот комментарий:(

      Тут уже писали как-то, что польза от подобных книг есть как минимум в том, что они заставляют задуматься. Суть моей статьи в том, чтобы ВЫ задумались над определенными моментами, которые поднял автор в своей книге. Это тоже посмотреть на нечто с другой стороны не поддаваясь авторитетам автора. Если вы это сделали или собираетесь сделать, то вы прочитали мой пост не зря.

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

      Удалить
  8. Этот комментарий был удален автором.

    ОтветитьУдалить
  9. А мне понравилась книга. Какая разница насколько категоричны заявления автора и насколько они спорны? По мне так никакой. Все равно ни одного автора не стоит воспринимать как истину в последней инстанции. Самое главное, на мой взгляд, читая такие книги мы можем взглянуть на точку зрения автора и задуматься для себя над тем - с чем согласны, с чем не согласны, что применимо, что неприменимо, что кажется полезным, что бесполезным. И можем задуматься, если вдруг мы не согласны с автором, почему именно? Другими словами, читая о разных точках зрения существующих у разных людей, можем сами стать более взвешенными. Отмечу особенно - не более укрепившимися в своем мнении, а более взвешенными.

    ОтветитьУдалить
    Ответы
    1. Александр, полностью со всем согласен. Цель ревью и этой критики - дать понять, что на рынке есть книги, которые я бы люто рекомендовал, поскольку они выполняют всю работу, отвеченную вами, но делают это более взвешенно и качественно.

      У чтения книг есть одна интересная особенность: степень их восприятия сильно зависит от текущего уровня читателя, его текущих задач и ментального состояния. Некоторые книги будет оказывать сильное влияние сегодня и через 10 лет, а другие - только сегодня или даже вчера.

      Если книга Боба Мартина вам понравилась и дала почву для размышлений, то это просто замечательно. Но мне правда интересно, с каким количеством вещей вы лично были в ней согласны, а на какие обратили внимание лишь после моего ревью?

      Удалить
  10. Не люблю Боба Мартина, но согласен с ним про состояние потока - опасно и возможно вредно.
    Оно для меня описывается анекдотом, "что тут думать, трясти надо".
    Поток обращен больше на процесс, чем на результат. Борьбе с потоком очень помогает парное программирование и вопросы второго человека зачем и почему. Помогают построить связи между информацией в краткосрочной памяти.
    Тоже не люблю личные примеры, но есть такое чувство, что научные исследования пропали из программтстских книг и всё больше опора на очевидные факты или опыт.(и дядя Боб один из основных авторов этого направления).

    ОтветитьУдалить
    Ответы
    1. А откуда взяты сведения о том, куда именно обращен "поток"? Я чего-то не смог найти нигде ничего подобного:( Мне просто кажется, что цитата "думать поздно - делать нужно" ну никак не подходит к состоянию потока.

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

      Если это не так, то поправьте меня плз.

      Мне просто кажется, что тут приписывается этому состоянию несвойственные ему аспекты за которые оно потом критикуется.

      Удалить
  11. Еще хотел сказать, что книга "Совершенный код" была намного полезней для меня и научила быть лучшим программистом.
    Я думал, что "Чистый код" будет также полезен, но закрыл книгу через двадцать минут.

    ОтветитьУдалить
  12. Спасибо за обзор и за ссылки! За ссылки - спасибо особенно!

    Что касается темы поста — на мой взгляд, категоричность суждений всегда должна вызывать подозрение. Особенно категоричность, не подвтержденная аргументами. Особенно — в устах известного и влиятельного (в смысле - на умы) человека.

    А про состояние потока, мне кажется что тут путаница между именно "потоком" в смысле Михая Чиксендмихая и состоянием упоротого заруба в кодирование. В первом — ты видишь проблему, пути решения и следствия принятых решений. Это как "расширение сознания" (в хорошем смысле).

    Во втором — ты видишь только один путь решения, и не понимаешь последствий. Это как "сужение сознания".

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

    ОтветитьУдалить
  13. Да, книга весьма и весьма забавная, причем там есть перлы похлеще, чем догматизация TDD или пропаганда против потока.
    Например, шикарный тезис о неограниченной финансовой ответственности разработчика, который изумительно гармонирует с личным эпизодом: эпик фейл в роли начальника отдела разработки и уход от ответственности в качестве удачного личного решения.
    Параллельно читал Рэя Ошероува про автономное тестирование: мнения о качестве FitNesse у уважаемых авторов почему-то разошлись радикально.
    С программистом-прагматиком книгу Мартина сравнивать нельзя - совершенно разный уровень и формы, и содержания, и воздействия на читателя - джуниору лично я это рекомендовать не буду.

    ОтветитьУдалить
    Ответы
    1. Leo, спасибо за развернутое мнение. Кстати, интересный момент: если эта книга джуниору не подходит, то какая же у нее аудитория?;) ведь опытному разработчику она тоже не пригодится, ввиду отсутствия новой и полезной информаци...

      Удалить
    2. Мне кое в чем пригодилась. Например, рассмотрение TDD как REPL в OOP, личный опыт придает рельеф многим, казалось бы, банальным вещам. Но в целом, будь книга побольше объемом и подороже, то пожалел бы потраченных денег и времени, а так в качестве "еще одного сборника историй от профи" пойдет. Но для философии это слишком жидко, да еще и с вредными добавками в составе.

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

    Посмотрел “Function Programming: What? Why? When?”, получил скорее негативные впечатления. То есть да, в приницпе все проблемы он обозначает правильно. Но почему у него такие унылые примеры ("ну тут конечно есть стейт, но давайте прищуримся, как будто его нет, и тогда — глядите, у нас нет стейта!") и почему выступление строится в основном на эмоциях? Почему он не показывает обратную сторону — чем приходится платить за якобы отсутствие стейта?

    К сожалению вообще не увидел технических вещей в этом выступлении. Может есть возможность посмотреть оригинальный “The Failure of State”?

    ОтветитьУдалить
    Ответы
    1. Я не смог найти оригинальный "The Failure of State", но почти уверен, что выступление будет очень похожим в плане эмоционального накала.
      Мой главный поинт в том, что у него есть технические знания, которыми можно было бы поделиться с коллегами-кодерами, но в книге для кодеров он решил этого не делать:)

      Удалить