Плохо, прям очень плохо. Надеюсь всё плюсы и положительные отзывы этому посту это по большей части аналог с али экспрессовским "товар получил, не открывал, ставлю 5 звёзд" и реакция на БЕСПЛАТНО. Даже просто открыв этот pdf можно увидеть на сколько автору было безразлично удобство чтения этого опуса. Микро формат страниц, который просто убивает форматирование кода, сразу бросается в глаза. Но в конце концов вёрстку можно исправить, если автору есть что добавить в довольно пропаханную тему базовых знаний по одному из достаточно старых ООП языков. Я как практикующий товарищ решил сразу посмотреть какой то более менее цельный и минимально содержательный фрагмент кода, так как разделяю мнение что хороший код является "само документируемым" и также может показать общий уровень книги. Первый такой фрагмент нашёлся на 119 странице и содержал очень плодотворную тему рефакторинга кода. Вообще, эта тема обсуждается начиная с банальных уроков программирования в школе, где вас просят хотя бы давать осмысленные имена переменным и проходит через весь опыт практического программирования, где является одним из ключевых элементов борьбы со сложностью. Самое сложное тут суметь уместить в маленьком примере какую то идею, чтобы читатель смог её увидеть, а не просто "поверить автору". И даже в сравнительно больших фрагментах программ с подробным разбором на протяжении всей книги (например "Чистый Код" Роберта Мартина) бывает сложно это реализовать и люди приходя на проект в 1 миллион строк сталкиваются с тем, что рефакторинг в рафинированных примерах и реальном проекте может значительно отличаться по сложности реализации. Это я увлёкся лирикой, перейдём к коду, у нас есть некоторый метод TryOpenDoor со следующей сигнатурой:
private static bool TryOpenDoor(); (посмотреть реализацию можно на странице 119)
и после ряда "улучшений" и вынесения методов получается следующий код:
Давай посмотрим что с ним не так? Пункты будут идти по моему субъективному убыванию критичности.
1) Это другое поведение ! Это прям вообще не нормальная вещь. И дело не в том что мы переименовали метод, это как раз допустимо. Мы изменили сигнатуру метода, ранее он возвращал булевское значение (правда\ложь) , теперь он ничего не возвращает. В случае реального рефакторинга IDE нам бы подсказала и такой проект просто не собрался бы. Почему так получилось ? Потому что по факту начальный код и конечный выполняет немного разные вещи, и оригинальный метод является частью InteractWithDoor() и он естественным образом разваливается на 2 метода, которые и хочется объединить под новым более общим методом.
2) Смешение уровней абстракции. Это может показаться не критичным на таком маленьком примере, но в реальности это огромная проблема и очень важно на начальном этапе дать правильное понимание базовых вещей в архитектуре кода. Так как когда вы перейдёте от 20 строчных примеров к проектам с 20 000 классов вы сможете намного ухудшить качество своего кода, но не улучшить его. У нас есть метод запроса\чтения возраста из консоли, если кто не знает это ReadInt, и первый вывод консоли логически относится к этому методу, тем более в нём уже есть интерактивность с пользователем. На том уровне где мы оперируем методом ReadInt aka GetAge как правильно не должно быть вывода в консоль, если он есть внутри ReadInt.
3) ReadInt() - это вызывает вопросы. Для начала сообщу что почти любая IDE выведет тип возвращаемого значения просто при наведение на метод. В старом коде на си, например, можно встретить обозначение типов в приватных переменных класса, но даже в таком случае оно дополняет название, а не заменяет его. Если бы метод хотя бы назывался GetAgeInt я бы не стал придираться, в конце концов есть принятые в командах стандарты и практики ,а также вкусовщина. Можно возразить "но этот же метод действительно просто получает Int32 из консоли", и с этим можно было бы согласиться, если бы это был какой то публичный метод для consol-и, но даже в таком случае ключевым тут было бы что это значение из консоли. То есть выглядеть должно было, либо так ConsoleEx.GetInt32(), либо GetInt32FromConsole(). Приватный метод, особенно с таким маленьким скоупом, должен иметь очень специфичное функции имя.
4) В книге автор заявляет что он добился успеха выделив "чистое правило" открытия двери в TryOpenDoor() , кстати это было названием оригинального метода. Но давайте посмотрим на этот метод, что в этой строке "age >= 18" есть о двери ??? У меня нейминг вызывает вопросы
И большая часть того что написано это не просто "придирки"? а реально очень критичные вещи. Не хочу сказать что сам могу написать идеальный код с точки зрения доступности для понимания и структуры, иногда, особенно в реальных проектах приходится идти на какой то трейд офф, бывает реально сложно подобрать нейминг и так хочется сделать метод с несколькими ответственностями или у классов появляется какое то неявное состояние и потом с ним реально очень сложно бороться. Но , во-первых, я не пишу книг, т.к. являюсь заурядным программистом, и на мой взгляд их должны писать те, кому действительно есть что сказать поверх формальной документации. Во-вторых, проблемы начинаются в действительно комплексных проектах, где есть причины для появления говнокогда. В третьих, для такого маленького учебного проекта тут слишком много косяков. Если бы я писал книгу то к любой строчки кода относился бы как минимум, как к коду, который я отправляю на код ревью, а в реальности бы это был код, который кто то уже заревьювил и заупрувил.
Многие в комментариях гонятся за какими то "актуальными знаниями", которые толи должны быть в книге, толи не могут быть в ней т.к. она устаревает. Но в реальности я легко могу сказать тимлиду, что не знаю что то требуемое из нового реквайремента или таски и мне нужно время на изучение документации\кода. Но я плохо себе представляю как бы я смог объяснить такое качество кода, при том что в нём самый базовый функционал, который будет работать и на версиях языка десятилетней давности, такой код плох даже для intern позиции.
Как мог бы выглядеть этот код с моей точки зрения. Если мы хотим реализовать InteractWithDoor, то исходный метод, конечно, недостаточен и он разбивается на 2 составляющие, получение возраста и его валидация, но далее нам требуется открытие\отказ в открытие двери, что в коде автора реализовано через сообщение "Дверь не для тебя!" с очередным нарушением уровня абстракции.
Пара комментариев по коду.
1) Конечно, метод EnableRussianSymbolsForConsole не относится к InteractWithDoor, но когда книжный пример при копирование в IDE на некоторых системах будет выдавать тебе вопросы вместо текста это не очень хорошо. И для примера добавить такой вызов допустимо, но лично я бы предпочёл просто использовать английский во всех запросах.
2) Длинный нейминг методов допустим и даже хорош для само документирования кода, в случае если это внутренние методы с малым скоупом видимости (в данном случае все методы кроме InteractWithDoor являются приватными).
3) Может показаться что методы ShowNotAllowedMessage и OpenDoor немного избыточны т.к. у них однострочная реализация, но лично моя практика показывает что такая разбивка оправдана.
4) Код получился длиннее и это нормально, особенно когда речь идёт про рефакторинг таких маленьких фрагментов. Главный показатель качества кода не его количество, а его читаемость и простота модификации. При рефакторинге больших объёмов кода часто бывает и обратный эффект из-за устранение дублирования и избыточной логики, вызванной кривой архитектурой.
Хороший код на верхнем уровне читается почти как осмысленный текст без матана и всяких сложных условий.
Взять возраст из консоли и используя его попробовать открыть дверь
Что же такое попробовать открыть дверь?
Если открытие двери разрешено для данного возраста, то открыть дверь, иначе показать сообщение, что открытие запрещено.
не идеально, согласен, но я на многое и не претендую, а теперь попробуйте прочитать оригинальную программу автора.
P.S. Если взглянуть на обе версии, может показаться что разница небольшая, но это проблема масштаба, все эти вещи становятся очень критичны когда кодовая база растёт вместе с числом разработчиков работающей над ней. И , конечно, у меня нет тех талантов, чтобы суметь это показать в таком маленьком фрагменте кода, в том числе и поэтому у меня никогда не было желания писать какие-либо материалы по программированию.
