О книге Боба Мартина «Чистый код»


    (Картинка без намека, просто уж очень хотелось котика в статью добавить! Ведь это основной залог популярности в интернетах, правда? :))

    У меня очень неоднозначное отношение к книгам Роберта Мартина… В них довольно много здравых и интересных мыслей, но иногда они выражаются столь категорично, что неокрепшим программерским мозгом они могут восприниматься неправильно. Если же мозг читателя достаточно окреп, чтобы воспринимать советы прагматично, то есть все шансы, что ничего нового из этих советов он (мозг или программист) не вынесет.


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

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

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

    Спорные и сомнительные моменты

    В «Чистом коде» есть несколько откровенно сомнительных моментов. Во-первых, в ней довольно много кода, читать который на страницах книги очень сложно. В 15-й главе рассматривается улучшение парсера командной строки на 60 страницах, 40 из которых – это сплошной код на Java. Главы 16-17 написаны в том же формате, но они короче, поэтому следовать рассуждениям автора проще.

    СОМНИТЕЛЬНЫЙ СОВЕТ
    Первое правило: функции должны быть компактными. Второе правило: функции должны быть еще компактнее. … Из сказанного выше следует, что блоки в командах if, else, while и т.д. должны состоять из одной строки, в которой обычно содержится вызов функции. Это не только делает вмещающую функцию более компактной, но и способствует документированию кода, поскольку вызываемой в блоке функции можно присвоить удобное содержательное имя.

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

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

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

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

    private String render(boolean isSuite) /*throws Exception*/
    {
        this.isSuite = isSuite; 
        if (isTestPage())
            includeSetupAndTeardownPages(); 
        return pageData.getHtml();
    } 
    
    private void includeSetupAndTeardownPages() throws Exception {
        includeSetupPages();
        includePageContent();
        includeTeardownPages();
        updatePageContent();
    }
    
    private void includeSetupPages() /*throws Exception*/
    {
        if (isSuite)
            includeSuiteSetupPage(); 
        includeSetupPage();
    }
    


    СОМНИТЕЛЬНЫЙ СОВЕТ
    Аргументы создают массу проблем с точки зрения тестирования. Только представьте, как трудно составить все тестовые сценарии, проверяющие правильность работы кода со всеми комбинациями аргументов.

    В чем разница с точки зрения тестирования между статическим методом с четырьмя аргументами и экземплярного метода объекта с четырьмя полями? Количество граничных условий в обоих случаях одно и тоже; просто в первом случае мы все входные данные протаскиваем явно, а во втором случае – неявно через this.

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

    СОМНИТЕЛЬНЫЙ СОВЕТ
    Стандарт кодирования определяет, где объявляются переменные экземпляров; как именуются классы, методы и переменные; как располагаются фигурные скобки и т.д. Документ с явных описанием этих правил не нужен – сам код служит примером оформления.

    Перевод

    Перевод, мягко говоря, не порадовал. Иногда он «радовал» настолько, что приходилось лезть в оригинал, чтобы понять, о чем идет речь:

    ЦИТАТА
    Когда у вас появился полный набор тестов, можно заняться чисткой кода и классов.
    Для этого код подвергается последовательной переработке (рефакторингу). Мы добавляем несколько строк кода, делаем паузу и анализируем новую архитектуру.


    WTF! Как добавление двух строк может повлиять на архитектуру?!?! Есть два варианта: либо мы имеем дело с очень длинными строками, или же авторы здесь говорят не об архитектуре, а о чем-то ином, например, о дизайне! Вся глава 12 (из которой взята эта цитата) полностью испорчена тем, что термин “design” переведен в ней как «архитектура», что делает многие советы автора спорными.

    Как обычно, переводчики не потрудились оставить оригинальные термины, так что приходилось догадываться, что же имеется ввиду под терминами «логическая привязка» или «многопоточность» (оказывается, что это high coupling и concurrency, соответственно).

    Поскольку содержимое книги относительно простое, то переводчикам удалось лишь «подпортить» впечатление, но не запороть ее полностью.

    Дельные советы

    На самом деле, все не настолько плохо и «дядюшка» Боб сотоварищи дают много хороших советов. Вот некоторые из них:

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

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

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

    О содержимом функций
    Все операторы в функции должны находиться на одном уровне абстракции, который должен быть на один уровень ниже операции, описываемой именем функции.

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

    Юнит-тесты в качестве инструмента изучения библиотек
    Изучение чужого кода – непростая задача. Интеграция чужого кода тоже сложна. Одновременное решение обоих задач создает двойственные сложности. А что, если пойти по другому пути? Вместо того, чтобы экспериментировать и опробовать новую библиотеку в коде продукта, можно написать тесты. Проверяющие наше понимание стороннего кода. Джим Ньюкирк (JimNewkirk) называет такие тесты «учебными тестами».

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

    Очень повеселил один совет. Давайте так: что вам говорит магическая константа 5280? Ничего? Странно, по словам автора, это одно из значений, которое можно спокойно «хардкодить»!

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

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

    Достоинства: приличное количество приличных советов

    Недостатки: часть советов весьма спорны; иногда советы непоследовательны; перевод хромает на обе ноги.

    Оценка: 4-
    Share post

    Similar posts

    Comments 59

      +3
      На мой скромный взгляд, «Чистый код» и другие шедевры(не сарказм) это всего лишь очередная ступенька в становлении программирования как технической науки. Каждая подобная книжка — это кирпичик в создание методик разработки, которых сейчас нет.
      Сейчас программирование на уровне алхимии. Люди вывели несколько правил и стараются следуя им создать философский камень. Поэтому к любой подобной книге нужно относится с высоким уровнем критики.
        +5
        О боже мой, они даже обложку вклали.

        image

        Прочел книгу в свое время. Понравилось. Действительно очень много спорных вопросов, но мне хочется думать, что автор уходил в крайности не просто так. Если бы он говорил делать функции в 10 строк, а не в 3, я бы делал в 20, а не в 10 — утрируя. Так же он сильно против наличия коментариев в коде и хорошо аргументирует свою точку зрения по этому поводу. Коментарии действительно зло, тк их никто не поддерживает up to date и код должен быть понятен и без коментариев в общем случае. Что думаете по этому поводу?

        У него есть еще книга The Clean Coder, в которой он описывает то, каким в его глазах должен быть программист сам.
          +3
          По поводу комментариев все-таки спорно.

          Во-первых, иногда переписывание кода таким образом, чтоб избавиться от комментариев, приводит к введению дополнительных сущностей, что только замусоривает текущий scope.
          Во-вторых, оптимизация часто приводит к малочитабельным кускам кода, в котором без комментариев никак.
          В-третьих, (это я уже со своей колокольни, как джаваскриптер) порядочные IDE показывают документацию к методу и его сигнатуре по нажатию хоткея и при наличии специально отформатированных комментариев улучшают интеллисенс (в JS по другому почти никак).
          В-четвертых, те же самые специально отформатированные комментарии позволяют генерить документацию в каком-нибудь красивом виде. Для клиентского кода, пожалуй, неактуально, а для библиотек важно.
            –3
            Различные *doc я вообще за комментарии не считаю :) Но и в других случаях комментарии могут быть полезны, если код «рвёт шаблоны». Скажем, не для всех будут понятны последствия объявления конструктора приватным или защищенным.
            • UFO just landed and posted this here
                –1
                Под «рвёт шаблоны» я не имел в виду что-то совсем непонятное, просто нюансы языка, библиотеки или фреймворка, которые в официальной документации описаны не внятно или даже вполне нормально, но редко используется и большинству разработчиков нужно провести мини-исследование, чтобы выявить нюансы. Из недавнего: все объекты в PHP5 приводятся к булеву типу как true и часто используется конструкция if ($obj) { }, но есть одно исключение — объекты расширения SimpleXML, оно документировано как
                When converting to boolean, the following values are considered FALSE:

                SimpleXML objects created from empty tags

                Многие ли это помнят? А из тех, кто помнит (скажем, готовился к собеседованию и знает, что любят спрашивать правила приведения к boolean) — понимают, что имеется в виду под «empty tags»? Что выведет код
                $xml = simplexml_load_string('<ROOT><LIST><ITEM></ITEM><ITEM>0</ITEM><ITEM>1</ITEM><ITEM><SUB_ITEM></SUB_ITEM></ITEM></LIST></ROOT>');
                foreach ($xml->LIST->ITEM as $item) {
                    var_dump((boolean)$item);
                }
                
                можете навскидку сказать?
                  0
                  Перформатировал код, но не успел отредактировать
                  $xml = simplexml_load_string(<<<EOT
                  <ROOT>
                    <LIST>
                      <ITEM></ITEM>
                      <ITEM>0</ITEM>
                      <ITEM>1</ITEM>
                      <ITEM>
                        <SUB_ITEM></SUB_ITEM>
                      </ITEM>
                    </LIST>
                  </ROOT>
                  EOT;
                  );
                  
                  foreach ($xml->LIST->ITEM as $item) {
                      var_dump((boolean)$item);
                  }
                  
                    +1
                    Потому и не нужно писать if ($obj) { } и комментарий, а if (some_passed_condition_name($obj)) { } тогда и коммент не нужен — он будет именем метода проверки.
                      0
                      А в этом методе return $obj? Пускай даже return (boolean)$obj? Ну и сложно в голове укладывается название метода, говорящее «возвращает true для объектов всех классов, кроме SimpleXML, которые возвращает true только если элемент содержит вложенные теги».
                        +1
                        Все зависит от того, какое условие проверяется. Например, насколько я вас понял, если нужно получить для всех oбъектов true:

                        return (bool) $obj || $obj instanceof SimpleXML;

                        Однако я не понимаю вообще смысла в if ($obj) { } когда есть is_object(...). Для чего используется if ($obj) { }?
                          0
                          Примерно в тех же целях, но используя (кроме одного исключения) правила неявного приведения типов.
                    • UFO just landed and posted this here
                      0
                      Очень хреновый совет.
                      Комментарии тоже должны быть правильными.
                      Просто большинство поступает тупо и комментит очевидные вещи. Отсюда и весь негатив к каментам.

                      Для себя определил, что надо писать не «Тут делим на два».
                      А что-то вроде «Тут очищаем список для корректной валидации. в ADF 11.1.1.6 бага».
                      Т.е. описывать надо не очевидные причины или действия.
                      И никакой красивый код не заменит таких подсказок.
                      • UFO just landed and posted this here
                          0
                          Надо смотреть в корень проблемы, а не в какие-то частности.
                          Да и указанная бага это всего лишь пример описания не действия а причины.
                          В таких местах часто видел камент «очистим список», т.е. бессмысленный и тупой камент.

                          >Система сложная, метод очень трудный, комментарий необходим. Правильно? Нет.
                          Это о чем вообще? Что такое «трудный метод»? Почему ему в друг необходим камент?
                          Ну и вообще, у вас не камент был не нужен, а дизайн был такой… хороший.
                          Что опять же мимо темы, ибо я говорил про каменты в не очевидных местах, а не в тупо спроектированных.
                          Но вы, как это характерно для многих, не дочитали до этого момента ставя минус…
                          Хотя опять же, при разборках в чужом коде, в таких местах как вы привели, часто ставлю каменты, что делает это кусок кода, ибо не всегда есть возможность переписывать чужой код.
                          • UFO just landed and posted this here
                              +2
                              каждый раз, печатая коммент, думали что это не правильно.

                              Вот в этом вся суть советов чуваков типа дяди Боба.
                              — Вы должны избегать комментариев, делая код настолько простым и прозрачным, чтобы его мог понять даже полуграмотный разработчик. Это принесет вам 100%-ную надежность, печеньки и порадует дядю Боба!
                              — Эээээ, но у меня все приложение состоит из неясных мест, воркэраундов, нетривиальных фокусов и заплаток.
                              — Ну, тогда, по крайней мере вы должны чувствовать себя очень виноватым.

                                0
                                В подобном случае, вместо того, что бы чувствовать себя очень виноватым, нужно брать ноги в руки и срочно рефакторить код.
                                  0
                                  Из чего сделан вывод, что такому коду нужен рефакторинг, да еще и срочный?
                                  Может нужно увеличение производительности? Может нужно добавление новых фич? Может нужно переписать заново? Может нужно переписать заново на эрланге? Может нужно нанять более компетентных разработчиков? Может нужно сесть и крепко подумать о жизни? Может не нужно ничего трогать вообще? Может не нужно ничего трогать прямо сейчас?
                                  Вот в этом-то и проблема, что дядя Боб дает несколько нормальных (и несколько сомнительных) советов по некоторым частным вопросам, но на вопрос «Как нам решать проблемы реального мира» эти советы не отвечают, вопреки тому, что говорит этот дядя.
                                    0
                                    Дело в том что не только дядя Боб не даст советов как решать реальные проблемы, но и вообще никто не даст. Ибо реальные проблемы зависят от слишком многих факторов, что бы можно было дать всеобъемлющую инструкцию того что делать в том или ином случае. Можно описать только некие абстрактные способы решения абстрактных проблем, а вот какие из них и в какой комбинации применять можно определить только имея некий опыт решения проблем.
                                      0
                                      Дело в том что не только дядя Боб не даст советов как решать реальные проблемы, но и вообще никто не даст.

                                      Гм, да отчего же. Вполне можно сформулировать набор утверждений в стиле:
                                      «Если пользователи говорят, что у вас все медленно, то примените такие-то и такие-то инструменты и сделайте побыстрее».
                                      «Если вы посчитали, что внедрение новой фичи приносит такую-то пользу, то ее надо реализовывать»
                                      «Для решения проблем со стабильностью, надо (предположим) тщательнее проверять возвращаемые значения функций»
                                      и конечно же
                                      «Предполагаемая польза перевешивает предполагаемые трудозатраты? Не делай этого».
                                      Формулируем значительное количество таких утверждений, ограничиваем область применимости и получаем вполне достойный сборник советов «Что делать, если у тебя проблема в IT», который принесет значительную пользу.
                                      От творений дяди Боба такой сборник выгодно отличается тем, что прямо и честно указывает, какие проблемы решаются, а не утверждает, что после внедрения этих советов наступит инженерный рай (в некотором нечетко определенном смысле).
                            0
                            Комментарий с указанием на ошибку в баг-трекере — довольно полезная вещь :-)
                    +1
                    Комментарии зло. До тех пор, пока это тривиальный CURD, а вот если в коде какой-нибудь сложный алгоритм с кучей оптимизаций и хаков, то там без комментариев будет очень плохо.
                      +2
                      Я думаю, никто не спорит с тем, что комментарий для не очевидного куска кода нужен. Но хорошо бы, чтобы таких кусков было как можно меньше.
                      • UFO just landed and posted this here
                        +5
                        Пришел я как-то работать в один большой энтерпрайз проект, который в течение лет трех разрабатывали исходя из этой идеологии, что если код правильно спроектирован, то комментарии не нужны.

                        Для того, кто оригинально этот код писал, комментарии были действительно не нужны.

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

                        Представьте себе, что библиотека Java или С++ начнет следовать такой идеологии и обходиться без комментариев…

                        Без комментариев можно обходиться в небольших проектах, которые один человек пишет.
                        • UFO just landed and posted this here
                            0
                            Что делать со стандартными функциями, которые имеют, скажем так, не очень очевидное поведение? Можно даже назвать авторов стандартной библиотеки быдлокодерами, но работать с ней все равно приходится.
                            • UFO just landed and posted this here
                              0
                              Да нет, авторы оригинального кода были очень профессиональными разработчиками с большим опытом проектирования — система в целом была очень грамотно разработана. У них не было злого умысла. Их подвело то, что эта идея о разработке без комментариев работает только до тех пор, пока поддержкой и развитием занимаются только оригинальные разработчики.

                              Самодокументируемым код типа

                              std::vector(Property) getPropertiesByMainType( int mainType )

                              или

                              void setTimeout( int timeout )

                              быть не может в принципе.
                            0
                            Я по поподу комментариев думаю вот что: О комментариях и О комментариях. Часть 2.
                              +1
                              Блин, да вы просто прочитали мои мысли)
                              0
                              “The Clean Coder” („Идеальный программист“) — гораздо интереснее, на мой взгляд. К тому, что описано в “Clean code” многие приходят и сами.
                              
                              
                              
                              
                              
                              this page intentionally left blank
                              
                              
                              
                              
                              
                              +8
                              На счёт 5280 — однозначно плохой совет. Мне когда-то казалось, что все вокруг знают, что такое 86400, пока меня коллега практически матом не попросил объяснить, что это число делает в коде. С тех пор всё — именованными константами.
                                +1
                                С 86400 у меня сложные отношения. Увидев в коде вспомню, а сам считаю на калькуляторе. Но, главное, в сутках может оказаться не 86400 секунд. Опять же, какие сутки и какие секунды- их вида три есть навскидку, не считая unix time. В подавляющем большинстве случаев, лучше работать с datetime, рассчитывая на актуальность tzdata.
                                  +10
                                  Я такие константы пишу как 24 * 60 * 60 — компилятор сам вычислит, а людям сразу понятно.

                                  Работа с datetime, конечно, правильней. Но для простых вещей часто проще задать константу.
                                  0
                                  Я только недавно узнал про 42 в коде, хотя смотрел фильм до этого.
                                  • UFO just landed and posted this here
                                    +1
                                    А мне кажется, что новичкам эта книга всё же полезна. Можно получить хотя бы какие-то рекомендации о том, как писать код. Ведь часто начинающий разработчик просто пишет код, который что-то делает (решает какую-то задачу). Но как только в этом коде нужны переработки или какие-нибудь исправления багов — время работы растет. А почему? Не потому что плохо знают язык / технологию, а потому что пишут «плохой» код. А вот прочитали бы книгу (ну и разумеется задумались бы о прочтенном) и код стал бы получше и поддерживать его было бы проще.
                                      +3
                                      Rapid software development — одна из лучших книг, что я читал в своей жизни.
                                      Автор, без сомнения, Гуру с большой буквы. Очень нравится его мышление, примеры, и принципы, изложенные им и коллегами и выведенные из опыта.
                                      И, самое главное, конкретные! С метриками! Не долбанные MVC/KISS и тд, которые каждый начинает понимать субъективно. А достаточно четкие SOLID, IoC и тд.

                                      Мнение на правах ИМХО, вы имеет право на собственное мнение!
                                      0
                                      (Прости Б-же мои прожженные aGoT мозги)
                                      Первая мысль при виде фамилии автора: «Половину основных классов удалят еще в первой главе».
                                      • UFO just landed and posted this here
                                          0
                                          ИМХО, смело и безрассудно критиковать алгоритмы в книгах Кнута, ОО подходы в книгах Мейера, фундаментальность трудов Хоара. Камрада Мартина я к этим товарищам в один список поставить никак не могу, поскольку его книги и статьи никогда не носили фундаментального характера. Что не плохо, нужно сказать, это его стиль, который я уважаю.

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

                                          Думайте, подвергайте сомнению, доказывайте и не принимайте советы о том, что такое хорошо, а что плохо, за чистую монету.
                                          • UFO just landed and posted this here
                                              0
                                              Но ведь «дядюшка» Боб — не единственный автор, который пишет о дизайне, архитектуре и кодинге.
                                              Есть, например, упомянутый выше Мейер. Его труд «Объектно-ориентированное конструирование программных систем» является признанной классикой в этой области и он не позволяет себе выражений типа «делайте так и будет все классно». Есть Мартин Фаулер, который пишет о Ынтырпрайз паттернах, это архитектура, но тоже без таких заявлений. Есть те же Фриманы с их Паттернами проектирования, но и они не делают вида, что нашли серебрянную пулю.

                                              Так что в этой книге напрягает категоричность, которой в нашей области просто не существует. У меня в команде есть джуниоры и при решении любых задач я стараюсь показать, что дизайн — это постоянный поиск компромиса и идеального решения нет по определению. Так и здесь, книга не идеальна и главный недостаток ее в том (ИМХО), что она не дает понять, когда приведенные правла можно и нужно нарушать. Вот и все.
                                          +2
                                          Читал книгу пару лет назад, насколько помню сумел почерпнуть для себя некоторые полезные идеи, но в основном — либо материал перекрывается с тем же совершенным кодом и подобными книгами, либо автор черезчур идеализирует и забивает на прагматизм. Поддерживаю мнение что читать следует продвинутым специалистам, в первую очередь чтобы расшевелить мозги и задуматься на определенные темы, а не для того чтобы жестко следовать всем советам из книги. Ну и еще там картинки есть смешные если не ошибаюсь.
                                            0
                                            Книга хорошая, но не дай вам бог просмотреть его видео лекции…
                                              0
                                              По поводу компактных функций:

                                              Сам не очень люблю дробить функционал на избыточно мелкие блоки (по аналогии с бритвой Оккама — «не вводи новые объекты без необходимости»).

                                              Опять же очень удобно читать код как книгу, то есть без блуждания по дереву вызовов, чреватого потерей фокуса.

                                              Но когда расширяешь объектно-ориентированную систему — правило маленьких функций очень помогает.

                                              С мелкими функциями достаточно переопределить один маленький метод, вместо того, чтобы переписывать большой блок, что очень удобно.
                                                +2
                                                Никакой clean code c помощью подобных книг писать не научиться. Clean code приходит с опытом работы в проектах, в постоянном сравнении и оптимизации того или иного кода, тех или иных практик. Поэтому, здесь я полностью согласен с автором статьи, что для программистов без опыта такие книги не предназначены.
                                                  +1
                                                  Есть у меня дома эта книга. Вначале читал с мыслью «да, верно пишет, хорошо бывает лишний раз об этом вспомнить», когда же для простых вещей пошел код просто дичайших размеров, стал плеваться. Как показывает лично моя практика, код, выполняющий конкретные вещи без особых возможностей к расширению зачастую намного проще поддерживать, чем дичайшую конструкцию на 100500 классов, в которой даже с документацией тяжело разобраться.
                                                    0
                                                    В электронном виде она тоже у нас имеется:
                                                    books.piter.com/product/chistyy-kod-sozdanie-analiz-i-refaktoring-biblioteka-programmista
                                                      0
                                                      Дядя Боб неоднократно говорил, что сегодня у молодых говнокодеров нет ментора. Он пытается предложить себя в качестве этого ментора. Тут писали, что джуниорам вредно читать Мартина, однако я вырос на его книгах и подкастах с cleancoders.com. Если джуниор не идиот, то он будет задоваться вопросами в любом случае, ибо Мартин не предлагает ответов на все случаи жизни. Причина кроется в том, что у него их нет. Он предлагает «базовый набор лучших практик».
                                                        0
                                                        Функции и методы действительно лучше делать компактными, разбивая по смыслу — это сильно упрощает потом и понимание и рефакторинг. Понятие интерфейса шире, чем просто ключевое слово и сигнатуры методов, изменение внутренних переменных необязательно может быть побочным эффектом, побочный эффект наступает тогда, когда документация или название метода не отражает эти нюансы. Скажем переписали метод toString(), который внутри еще дергает базу. Аргументы придется всегда таскать за собой, а что делать, если методов несколько? Или, например, вместо перегруженных функций использовать один метод, проверяя аргументы по типу или на null. Оформление сейчас можно прикрутить к ИДЕ без проблем, достаточно настроить один раз.
                                                        Лучше сосредоточится на выразительности названий, чем на их длинне.
                                                        Такие вот впечатления.
                                                          0
                                                          В чем разница с точки зрения тестирования между статическим методом с четырьмя аргументами и экземплярного метода объекта с четырьмя полями? Количество граничных условий в обоих случаях одно и тоже

                                                          Разница в том, что класс обычно подразумевает наличие инвариантов, которые должны соблюдаться состояниями объектов класса. Конструктор устанавливает эти инварианты, при вызове каждого метода на вход передаётся валидный объект, и метод оставляет объект в валидном состоянии. У свободных функции с набором параметров таких гарантий нет. Это позволяет, например, сократить кол-во проверок части параметров до одной — в конструкторе.
                                                          Кроме того, при увеличении возможных состояний не придётся переписывать кучу сигнатур.

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

                                                          Only users with full accounts can post comments. Log in, please.