Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 59
На мой скромный взгляд, «Чистый код» и другие шедевры(не сарказм) это всего лишь очередная ступенька в становлении программирования как технической науки. Каждая подобная книжка — это кирпичик в создание методик разработки, которых сейчас нет.
Сейчас программирование на уровне алхимии. Люди вывели несколько правил и стараются следуя им создать философский камень. Поэтому к любой подобной книге нужно относится с высоким уровнем критики.
Сейчас программирование на уровне алхимии. Люди вывели несколько правил и стараются следуя им создать философский камень. Поэтому к любой подобной книге нужно относится с высоким уровнем критики.
О боже мой, они даже обложку вклали.
Прочел книгу в свое время. Понравилось. Действительно очень много спорных вопросов, но мне хочется думать, что автор уходил в крайности не просто так. Если бы он говорил делать функции в 10 строк, а не в 3, я бы делал в 20, а не в 10 — утрируя. Так же он сильно против наличия коментариев в коде и хорошо аргументирует свою точку зрения по этому поводу. Коментарии действительно зло, тк их никто не поддерживает up to date и код должен быть понятен и без коментариев в общем случае. Что думаете по этому поводу?
У него есть еще книга The Clean Coder, в которой он описывает то, каким в его глазах должен быть программист сам.
Прочел книгу в свое время. Понравилось. Действительно очень много спорных вопросов, но мне хочется думать, что автор уходил в крайности не просто так. Если бы он говорил делать функции в 10 строк, а не в 3, я бы делал в 20, а не в 10 — утрируя. Так же он сильно против наличия коментариев в коде и хорошо аргументирует свою точку зрения по этому поводу. Коментарии действительно зло, тк их никто не поддерживает up to date и код должен быть понятен и без коментариев в общем случае. Что думаете по этому поводу?
У него есть еще книга The Clean Coder, в которой он описывает то, каким в его глазах должен быть программист сам.
По поводу комментариев все-таки спорно.
Во-первых, иногда переписывание кода таким образом, чтоб избавиться от комментариев, приводит к введению дополнительных сущностей, что только замусоривает текущий scope.
Во-вторых, оптимизация часто приводит к малочитабельным кускам кода, в котором без комментариев никак.
В-третьих, (это я уже со своей колокольни, как джаваскриптер) порядочные IDE показывают документацию к методу и его сигнатуре по нажатию хоткея и при наличии специально отформатированных комментариев улучшают интеллисенс (в JS по другому почти никак).
В-четвертых, те же самые специально отформатированные комментарии позволяют генерить документацию в каком-нибудь красивом виде. Для клиентского кода, пожалуй, неактуально, а для библиотек важно.
Во-первых, иногда переписывание кода таким образом, чтоб избавиться от комментариев, приводит к введению дополнительных сущностей, что только замусоривает текущий scope.
Во-вторых, оптимизация часто приводит к малочитабельным кускам кода, в котором без комментариев никак.
В-третьих, (это я уже со своей колокольни, как джаваскриптер) порядочные IDE показывают документацию к методу и его сигнатуре по нажатию хоткея и при наличии специально отформатированных комментариев улучшают интеллисенс (в JS по другому почти никак).
В-четвертых, те же самые специально отформатированные комментарии позволяют генерить документацию в каком-нибудь красивом виде. Для клиентского кода, пожалуй, неактуально, а для библиотек важно.
Различные *doc я вообще за комментарии не считаю :) Но и в других случаях комментарии могут быть полезны, если код «рвёт шаблоны». Скажем, не для всех будут понятны последствия объявления конструктора приватным или защищенным.
Под «рвёт шаблоны» я не имел в виду что-то совсем непонятное, просто нюансы языка, библиотеки или фреймворка, которые в официальной документации описаны не внятно или даже вполне нормально, но редко используется и большинству разработчиков нужно провести мини-исследование, чтобы выявить нюансы. Из недавнего: все объекты в PHP5 приводятся к булеву типу как true и часто используется конструкция
Многие ли это помнят? А из тех, кто помнит (скажем, готовился к собеседованию и знает, что любят спрашивать правила приведения к boolean) — понимают, что имеется в виду под «empty tags»? Что выведет код
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);
}
Перформатировал код, но не успел отредактировать
$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);
}
Потому и не нужно писать if ($obj) { } и комментарий, а if (some_passed_condition_name($obj)) { } тогда и коммент не нужен — он будет именем метода проверки.
А в этом методе
return $obj? Пускай даже return (boolean)$obj? Ну и сложно в голове укладывается название метода, говорящее «возвращает true для объектов всех классов, кроме SimpleXML, которые возвращает true только если элемент содержит вложенные теги».
Очень хреновый совет.
Комментарии тоже должны быть правильными.
Просто большинство поступает тупо и комментит очевидные вещи. Отсюда и весь негатив к каментам.
Для себя определил, что надо писать не «Тут делим на два».
А что-то вроде «Тут очищаем список для корректной валидации. в ADF 11.1.1.6 бага».
Т.е. описывать надо не очевидные причины или действия.
И никакой красивый код не заменит таких подсказок.
Комментарии тоже должны быть правильными.
Просто большинство поступает тупо и комментит очевидные вещи. Отсюда и весь негатив к каментам.
Для себя определил, что надо писать не «Тут делим на два».
А что-то вроде «Тут очищаем список для корректной валидации. в ADF 11.1.1.6 бага».
Т.е. описывать надо не очевидные причины или действия.
И никакой красивый код не заменит таких подсказок.
Надо смотреть в корень проблемы, а не в какие-то частности.
Да и указанная бага это всего лишь пример описания не действия а причины.
В таких местах часто видел камент «очистим список», т.е. бессмысленный и тупой камент.
>Система сложная, метод очень трудный, комментарий необходим. Правильно? Нет.
Это о чем вообще? Что такое «трудный метод»? Почему ему в друг необходим камент?
Ну и вообще, у вас не камент был не нужен, а дизайн был такой…хороший.
Что опять же мимо темы, ибо я говорил про каменты в не очевидных местах, а не в тупо спроектированных.
Но вы, как это характерно для многих, не дочитали до этого момента ставя минус…
Хотя опять же, при разборках в чужом коде, в таких местах как вы привели, часто ставлю каменты, что делает это кусок кода, ибо не всегда есть возможность переписывать чужой код.
Да и указанная бага это всего лишь пример описания не действия а причины.
В таких местах часто видел камент «очистим список», т.е. бессмысленный и тупой камент.
>Система сложная, метод очень трудный, комментарий необходим. Правильно? Нет.
Это о чем вообще? Что такое «трудный метод»? Почему ему в друг необходим камент?
Ну и вообще, у вас не камент был не нужен, а дизайн был такой…
Что опять же мимо темы, ибо я говорил про каменты в не очевидных местах, а не в тупо спроектированных.
Но вы, как это характерно для многих, не дочитали до этого момента ставя минус…
Хотя опять же, при разборках в чужом коде, в таких местах как вы привели, часто ставлю каменты, что делает это кусок кода, ибо не всегда есть возможность переписывать чужой код.
каждый раз, печатая коммент, думали что это не правильно.
Вот в этом вся суть советов чуваков типа дяди Боба.
— Вы должны избегать комментариев, делая код настолько простым и прозрачным, чтобы его мог понять даже полуграмотный разработчик. Это принесет вам 100%-ную надежность, печеньки и порадует дядю Боба!
— Эээээ, но у меня все приложение состоит из неясных мест, воркэраундов, нетривиальных фокусов и заплаток.
— Ну, тогда, по крайней мере вы должны чувствовать себя очень виноватым.
В подобном случае, вместо того, что бы чувствовать себя очень виноватым, нужно брать ноги в руки и срочно рефакторить код.
Из чего сделан вывод, что такому коду нужен рефакторинг, да еще и срочный?
Может нужно увеличение производительности? Может нужно добавление новых фич? Может нужно переписать заново? Может нужно переписать заново на эрланге? Может нужно нанять более компетентных разработчиков? Может нужно сесть и крепко подумать о жизни? Может не нужно ничего трогать вообще? Может не нужно ничего трогать прямо сейчас?
Вот в этом-то и проблема, что дядя Боб дает несколько нормальных (и несколько сомнительных) советов по некоторым частным вопросам, но на вопрос «Как нам решать проблемы реального мира» эти советы не отвечают, вопреки тому, что говорит этот дядя.
Может нужно увеличение производительности? Может нужно добавление новых фич? Может нужно переписать заново? Может нужно переписать заново на эрланге? Может нужно нанять более компетентных разработчиков? Может нужно сесть и крепко подумать о жизни? Может не нужно ничего трогать вообще? Может не нужно ничего трогать прямо сейчас?
Вот в этом-то и проблема, что дядя Боб дает несколько нормальных (и несколько сомнительных) советов по некоторым частным вопросам, но на вопрос «Как нам решать проблемы реального мира» эти советы не отвечают, вопреки тому, что говорит этот дядя.
Дело в том что не только дядя Боб не даст советов как решать реальные проблемы, но и вообще никто не даст. Ибо реальные проблемы зависят от слишком многих факторов, что бы можно было дать всеобъемлющую инструкцию того что делать в том или ином случае. Можно описать только некие абстрактные способы решения абстрактных проблем, а вот какие из них и в какой комбинации применять можно определить только имея некий опыт решения проблем.
Дело в том что не только дядя Боб не даст советов как решать реальные проблемы, но и вообще никто не даст.
Гм, да отчего же. Вполне можно сформулировать набор утверждений в стиле:
«Если пользователи говорят, что у вас все медленно, то примените такие-то и такие-то инструменты и сделайте побыстрее».
«Если вы посчитали, что внедрение новой фичи приносит такую-то пользу, то ее надо реализовывать»
«Для решения проблем со стабильностью, надо (предположим) тщательнее проверять возвращаемые значения функций»
и конечно же
«Предполагаемая польза перевешивает предполагаемые трудозатраты? Не делай этого».
Формулируем значительное количество таких утверждений, ограничиваем область применимости и получаем вполне достойный сборник советов «Что делать, если у тебя проблема в IT», который принесет значительную пользу.
От творений дяди Боба такой сборник выгодно отличается тем, что прямо и честно указывает, какие проблемы решаются, а не утверждает, что после внедрения этих советов наступит инженерный рай (в некотором нечетко определенном смысле).
Комментарий с указанием на ошибку в баг-трекере — довольно полезная вещь :-)
Комментарии зло. До тех пор, пока это тривиальный CURD, а вот если в коде какой-нибудь сложный алгоритм с кучей оптимизаций и хаков, то там без комментариев будет очень плохо.
Пришел я как-то работать в один большой энтерпрайз проект, который в течение лет трех разрабатывали исходя из этой идеологии, что если код правильно спроектирован, то комментарии не нужны.
Для того, кто оригинально этот код писал, комментарии были действительно не нужны.
А все новички, коих было много (не важно с десятью годами опыта или с двумя) жутко плевались и страдали от того, что им приходилось переловачивать горы кода и изучать реализацию, чтобы понять, какие параметры допустимы, как функции реагируют на ошибки, и т.п.
Представьте себе, что библиотека Java или С++ начнет следовать такой идеологии и обходиться без комментариев…
Без комментариев можно обходиться в небольших проектах, которые один человек пишет.
Для того, кто оригинально этот код писал, комментарии были действительно не нужны.
А все новички, коих было много (не важно с десятью годами опыта или с двумя) жутко плевались и страдали от того, что им приходилось переловачивать горы кода и изучать реализацию, чтобы понять, какие параметры допустимы, как функции реагируют на ошибки, и т.п.
Представьте себе, что библиотека Java или С++ начнет следовать такой идеологии и обходиться без комментариев…
Без комментариев можно обходиться в небольших проектах, которые один человек пишет.
Что делать со стандартными функциями, которые имеют, скажем так, не очень очевидное поведение? Можно даже назвать авторов стандартной библиотеки быдлокодерами, но работать с ней все равно приходится.
Да нет, авторы оригинального кода были очень профессиональными разработчиками с большим опытом проектирования — система в целом была очень грамотно разработана. У них не было злого умысла. Их подвело то, что эта идея о разработке без комментариев работает только до тех пор, пока поддержкой и развитием занимаются только оригинальные разработчики.
Самодокументируемым код типа
std::vector(Property) getPropertiesByMainType( int mainType )
или
void setTimeout( int timeout )
быть не может в принципе.
Самодокументируемым код типа
std::vector(Property) getPropertiesByMainType( int mainType )
или
void setTimeout( int timeout )
быть не может в принципе.
Я по поподу комментариев думаю вот что: О комментариях и О комментариях. Часть 2.
“The Clean Coder” („Идеальный программист“) — гораздо интереснее, на мой взгляд. К тому, что описано в “Clean code” многие приходят и сами.
this page intentionally left blank
На счёт 5280 — однозначно плохой совет. Мне когда-то казалось, что все вокруг знают, что такое 86400, пока меня коллега практически матом не попросил объяснить, что это число делает в коде. С тех пор всё — именованными константами.
С 86400 у меня сложные отношения. Увидев в коде вспомню, а сам считаю на калькуляторе. Но, главное, в сутках может оказаться не 86400 секунд. Опять же, какие сутки и какие секунды- их вида три есть навскидку, не считая unix time. В подавляющем большинстве случаев, лучше работать с datetime, рассчитывая на актуальность tzdata.
Я только недавно узнал про 42 в коде, хотя смотрел фильм до этого.
А мне кажется, что новичкам эта книга всё же полезна. Можно получить хотя бы какие-то рекомендации о том, как писать код. Ведь часто начинающий разработчик просто пишет код, который что-то делает (решает какую-то задачу). Но как только в этом коде нужны переработки или какие-нибудь исправления багов — время работы растет. А почему? Не потому что плохо знают язык / технологию, а потому что пишут «плохой» код. А вот прочитали бы книгу (ну и разумеется задумались бы о прочтенном) и код стал бы получше и поддерживать его было бы проще.
Rapid software development — одна из лучших книг, что я читал в своей жизни.
Автор, без сомнения, Гуру с большой буквы. Очень нравится его мышление, примеры, и принципы, изложенные им и коллегами и выведенные из опыта.
И, самое главное, конкретные! С метриками! Не долбанные MVC/KISS и тд, которые каждый начинает понимать субъективно. А достаточно четкие SOLID, IoC и тд.
Мнение на правах ИМХО, вы имеет право на собственное мнение!
Автор, без сомнения, Гуру с большой буквы. Очень нравится его мышление, примеры, и принципы, изложенные им и коллегами и выведенные из опыта.
И, самое главное, конкретные! С метриками! Не долбанные MVC/KISS и тд, которые каждый начинает понимать субъективно. А достаточно четкие SOLID, IoC и тд.
Мнение на правах ИМХО, вы имеет право на собственное мнение!
Эта книга именно так называется? Что-то не могу отыскать. Можете написать автора или дать ссылку?
Думаю имеется ввиду это: www.amazon.com/books/dp/0131857258
Быстрая разработка ПО
(Прости Б-же мои прожженные aGoT мозги)
Первая мысль при виде фамилии автора: «Половину основных классов удалят еще в первой главе».
Первая мысль при виде фамилии автора: «Половину основных классов удалят еще в первой главе».
ИМХО, смело и безрассудно критиковать алгоритмы в книгах Кнута, ОО подходы в книгах Мейера, фундаментальность трудов Хоара. Камрада Мартина я к этим товарищам в один список поставить никак не могу, поскольку его книги и статьи никогда не носили фундаментального характера. Что не плохо, нужно сказать, это его стиль, который я уважаю.
Цель таких рецензий в том, чтобы при чтении книг у разработчиков не возникало карго культа, а было прагматичное и взвешенное отношение, как к решениям, принимаемым за клавиатурой, и такое же отношение было и при чтении авторитетных книг или статей.
Думайте, подвергайте сомнению, доказывайте и не принимайте советы о том, что такое хорошо, а что плохо, за чистую монету.
Цель таких рецензий в том, чтобы при чтении книг у разработчиков не возникало карго культа, а было прагматичное и взвешенное отношение, как к решениям, принимаемым за клавиатурой, и такое же отношение было и при чтении авторитетных книг или статей.
Думайте, подвергайте сомнению, доказывайте и не принимайте советы о том, что такое хорошо, а что плохо, за чистую монету.
Но ведь «дядюшка» Боб — не единственный автор, который пишет о дизайне, архитектуре и кодинге.
Есть, например, упомянутый выше Мейер. Его труд «Объектно-ориентированное конструирование программных систем» является признанной классикой в этой области и он не позволяет себе выражений типа «делайте так и будет все классно». Есть Мартин Фаулер, который пишет о Ынтырпрайз паттернах, это архитектура, но тоже без таких заявлений. Есть те же Фриманы с их Паттернами проектирования, но и они не делают вида, что нашли серебрянную пулю.
Так что в этой книге напрягает категоричность, которой в нашей области просто не существует. У меня в команде есть джуниоры и при решении любых задач я стараюсь показать, что дизайн — это постоянный поиск компромиса и идеального решения нет по определению. Так и здесь, книга не идеальна и главный недостаток ее в том (ИМХО), что она не дает понять, когда приведенные правла можно и нужно нарушать. Вот и все.
Есть, например, упомянутый выше Мейер. Его труд «Объектно-ориентированное конструирование программных систем» является признанной классикой в этой области и он не позволяет себе выражений типа «делайте так и будет все классно». Есть Мартин Фаулер, который пишет о Ынтырпрайз паттернах, это архитектура, но тоже без таких заявлений. Есть те же Фриманы с их Паттернами проектирования, но и они не делают вида, что нашли серебрянную пулю.
Так что в этой книге напрягает категоричность, которой в нашей области просто не существует. У меня в команде есть джуниоры и при решении любых задач я стараюсь показать, что дизайн — это постоянный поиск компромиса и идеального решения нет по определению. Так и здесь, книга не идеальна и главный недостаток ее в том (ИМХО), что она не дает понять, когда приведенные правла можно и нужно нарушать. Вот и все.
Читал книгу пару лет назад, насколько помню сумел почерпнуть для себя некоторые полезные идеи, но в основном — либо материал перекрывается с тем же совершенным кодом и подобными книгами, либо автор черезчур идеализирует и забивает на прагматизм. Поддерживаю мнение что читать следует продвинутым специалистам, в первую очередь чтобы расшевелить мозги и задуматься на определенные темы, а не для того чтобы жестко следовать всем советам из книги. Ну и еще там картинки есть смешные если не ошибаюсь.
Книга хорошая, но не дай вам бог просмотреть его видео лекции…
По поводу компактных функций:
Сам не очень люблю дробить функционал на избыточно мелкие блоки (по аналогии с бритвой Оккама — «не вводи новые объекты без необходимости»).
Опять же очень удобно читать код как книгу, то есть без блуждания по дереву вызовов, чреватого потерей фокуса.
Но когда расширяешь объектно-ориентированную систему — правило маленьких функций очень помогает.
С мелкими функциями достаточно переопределить один маленький метод, вместо того, чтобы переписывать большой блок, что очень удобно.
Сам не очень люблю дробить функционал на избыточно мелкие блоки (по аналогии с бритвой Оккама — «не вводи новые объекты без необходимости»).
Опять же очень удобно читать код как книгу, то есть без блуждания по дереву вызовов, чреватого потерей фокуса.
Но когда расширяешь объектно-ориентированную систему — правило маленьких функций очень помогает.
С мелкими функциями достаточно переопределить один маленький метод, вместо того, чтобы переписывать большой блок, что очень удобно.
Никакой clean code c помощью подобных книг писать не научиться. Clean code приходит с опытом работы в проектах, в постоянном сравнении и оптимизации того или иного кода, тех или иных практик. Поэтому, здесь я полностью согласен с автором статьи, что для программистов без опыта такие книги не предназначены.
Есть у меня дома эта книга. Вначале читал с мыслью «да, верно пишет, хорошо бывает лишний раз об этом вспомнить», когда же для простых вещей пошел код просто дичайших размеров, стал плеваться. Как показывает лично моя практика, код, выполняющий конкретные вещи без особых возможностей к расширению зачастую намного проще поддерживать, чем дичайшую конструкцию на 100500 классов, в которой даже с документацией тяжело разобраться.
В электронном виде она тоже у нас имеется:
books.piter.com/product/chistyy-kod-sozdanie-analiz-i-refaktoring-biblioteka-programmista
books.piter.com/product/chistyy-kod-sozdanie-analiz-i-refaktoring-biblioteka-programmista
Дядя Боб неоднократно говорил, что сегодня у молодых говнокодеров нет ментора. Он пытается предложить себя в качестве этого ментора. Тут писали, что джуниорам вредно читать Мартина, однако я вырос на его книгах и подкастах с cleancoders.com. Если джуниор не идиот, то он будет задоваться вопросами в любом случае, ибо Мартин не предлагает ответов на все случаи жизни. Причина кроется в том, что у него их нет. Он предлагает «базовый набор лучших практик».
Функции и методы действительно лучше делать компактными, разбивая по смыслу — это сильно упрощает потом и понимание и рефакторинг. Понятие интерфейса шире, чем просто ключевое слово и сигнатуры методов, изменение внутренних переменных необязательно может быть побочным эффектом, побочный эффект наступает тогда, когда документация или название метода не отражает эти нюансы. Скажем переписали метод toString(), который внутри еще дергает базу. Аргументы придется всегда таскать за собой, а что делать, если методов несколько? Или, например, вместо перегруженных функций использовать один метод, проверяя аргументы по типу или на null. Оформление сейчас можно прикрутить к ИДЕ без проблем, достаточно настроить один раз.
Лучше сосредоточится на выразительности названий, чем на их длинне.
Такие вот впечатления.
Лучше сосредоточится на выразительности названий, чем на их длинне.
Такие вот впечатления.
В чем разница с точки зрения тестирования между статическим методом с четырьмя аргументами и экземплярного метода объекта с четырьмя полями? Количество граничных условий в обоих случаях одно и тоже
Разница в том, что класс обычно подразумевает наличие инвариантов, которые должны соблюдаться состояниями объектов класса. Конструктор устанавливает эти инварианты, при вызове каждого метода на вход передаётся валидный объект, и метод оставляет объект в валидном состоянии. У свободных функции с набором параметров таких гарантий нет. Это позволяет, например, сократить кол-во проверок части параметров до одной — в конструкторе.
Кроме того, при увеличении возможных состояний не придётся переписывать кучу сигнатур.
Книгу читал уже довольно давно. Не шедевр, но несколько идей плотно запали в мозг. Например, про уровни абстракции в рамках одной функции. Макконнелл произвёл бОльшее впечатление.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О книге Боба Мартина «Чистый код»