Comments 36
Если честно, складывается ощущение, что статья ни о чем.
Если добавить хотя бы по одному примеру на каждый пункт: как не надо и как надо, то будет уже гораздо лучше.
+26
Правила-то хорошие, но не нужно им слепо следовать, надо применять с умом. Например, пункт номер 7. Методология «нам нужно больше классов» не везде шикарно подходит. Я видел случаи, когда особенно фанатичные ребята разбивали один и без того короткий класс на два, потому что «эта функциональность совершенно отдельная, ее нужно выделить в свой отдельный класс». В итоге код терял в читаемости. Так что классы по несколько строк – это уже слишком, имхо.
В общем, каждый подход нужно применять с головой.
В общем, каждый подход нужно применять с головой.
+1
Согласен. Лично у меня стек абстракций ограничен, где-то на 10-м уровне вложенности классов происходит его переполнение и я вообще перестаю понимать что этот код делает и зачем я сюда пришёл. Со всякими «крутыми штуками» вроде мета-программирования, функциональщины, абстрактных интерфейсов и шаблонов проектирования это происходит ещё быстрее.
Впрочем, у меня недостаточно «математическое» мышление, подозреваю что люди, размышляющие о непредставимых фигурах в n-мерных пространствах могут в большее количество уровней абстракции. Вот только их очень-очень мало.
Впрочем, у меня недостаточно «математическое» мышление, подозреваю что люди, размышляющие о непредставимых фигурах в n-мерных пространствах могут в большее количество уровней абстракции. Вот только их очень-очень мало.
+1
0. Код должен решать проблему. Желательно быстро и эффективно Если код не решает то ради чего он написан, то не имеет значения насколько он читабельный, минимальный и приятный.
В последнее время я очень часто наблюдаю как разработка тормозится потому, что команда разработчиков решает философские проблемы выразительности и оптимизации проекта на стадии Proof of Concept.
В последнее время я очень часто наблюдаю как разработка тормозится потому, что команда разработчиков решает философские проблемы выразительности и оптимизации проекта на стадии Proof of Concept.
+10
Тот же дядька Боб заявлял, что выполнять свою работу для кода — это второстепенное качество.
Первостепенное качество, и с этим я согласен — это быть гибким достаточно, чтобы с лёгкостью покрыть будущие нужды.
Имею обратную практику работы с кодом, который работает сегодня, но совершенно не поддаётся изменениям. Требования эволюционируют, код должен эволюционировать тоже.
Код, который не развивается — мертвый код.
Первостепенное качество, и с этим я согласен — это быть гибким достаточно, чтобы с лёгкостью покрыть будущие нужды.
Имею обратную практику работы с кодом, который работает сегодня, но совершенно не поддаётся изменениям. Требования эволюционируют, код должен эволюционировать тоже.
Код, который не развивается — мертвый код.
+3
Дядька Боб деньги зарабатывает консультациями и продажей своих книг о чистом коде. Конечно он будет писать о том что код должен быть гибким и красивым, это же его хлеб с маслом. Его приоритеты отличаются от приоритетов стартапа, который закроется если приложение не будет написано или будет написано с опозданием на год.
А что такое «будущие нужды» и как их определить?
Если работает, то зачем его изменять?
А если уже совсем мешает работе приложения, так можно уделить время и переписать его целиком когда в этом возникнет необходимость.
Первостепенное качество, и с этим я согласен — это быть гибким достаточно, чтобы с лёгкостью покрыть будущие нужды.
А что такое «будущие нужды» и как их определить?
Имею обратную практику работы с кодом, который работает сегодня, но совершенно не поддаётся изменениям. Требования эволюционируют, код должен эволюционировать тоже.
Если работает, то зачем его изменять?
А если уже совсем мешает работе приложения, так можно уделить время и переписать его целиком когда в этом возникнет необходимость.
+4
Так Боб говорит о коде, а для стартапов важнее бизнес-процессы. Или, более точно, для стартапов чистота кода не является бизнес-требованием.
0
Совершенно верно. Но в стартапы приходят программисты(хорошие программисты, отличные умные ребята, без иронии), которые очень хорошо знают о чистоте кода, антипаттернах и лучших практиках. Поскольку обычно их не интересуют бизнес-процессы и схемы по которым деньги зарабатываются, то вместо выпуска продукта они начинают улучшать мир за счет инвесторов. Ну и результат становится легко предсказуемым.
0
Бизнес == говнокод?
0
Я этого не говорил. Я говорю, что чистый код это такой Haskell — о нем разговаривают с придыханием и мечтательной поволокой в глазах, но в продакшене встречается крайне редко.
Вообще, так уж получилось, но на моей практике, количество заработанных денег было обратно пропорционально чистоте кода.
Вообще, так уж получилось, но на моей практике, количество заработанных денег было обратно пропорционально чистоте кода.
0
А что такое «будущие нужды» и как их определить?
Для того и должен быть гибким, чтобы их не надо было определять — прогнём под любые нужды, когда они появятся.
если приложение не будет написано или будет написано с опозданием на год
С большой вероятностью так и произойдёт, если в каждый момент разработчики будут озабочены исключительно тем, как присобачить к существующему коду кусок для решения очередной насущной проблемы. В последнее время не очень, а раньше приходилось наблюдать, как разработка вообще останавливается, потому что это здание из говна и палок разваливается под собственной тяжестью.
0
Тот же дядька Боб заявлял, что выполнять свою работу для кода — это второстепенное качество.
Если чистый код выполняется неприемлемо долго (например, красивый SQL запрос выполняется часами, вместо пары минут), то в пекло такой код!
0
Где-то в статье о геймдеве я прочитал хороший совет: «Писать прототипы, не обращая внимания на чистоту кода нормально, если после появляения убеждённости в том, что концепция работает, прототит будет выброшен. Вне зависимости от того, насколько он удовлетворяет заказчика».
Абсолютно согласен с данным отношением к proof of concept: доказано — перепиши начисто.
Абсолютно согласен с данным отношением к proof of concept: доказано — перепиши начисто.
+3
Совет хороший но больше является крайностью и из теории.
На практике все получается несколько иначе.
После написания прототипа будет два пути:
1. Если прототип не устраивает в плане архитектуры (степень производительности и\или возможности расширения) то начинаем сначала: пишем прототип.
2. Если все устраивает. то прототип проходит процедуру рефакторинга. Устраняются все FIXME, TODO (которые вы должны были оставлять по мере написания прототипа). В общем код доводится до продакшен состояния.
На практике все получается несколько иначе.
После написания прототипа будет два пути:
1. Если прототип не устраивает в плане архитектуры (степень производительности и\или возможности расширения) то начинаем сначала: пишем прототип.
2. Если все устраивает. то прототип проходит процедуру рефакторинга. Устраняются все FIXME, TODO (которые вы должны были оставлять по мере написания прототипа). В общем код доводится до продакшен состояния.
+1
Ваша статья одним словом: S.O.L.I.D.
+2
На мужике с ножницами на картинке к статье женские туфли на каблуках? Или это женщина мужиковатого телосложения?
0
Лагерфельд собственной персоной ;)
0
За что СТОЛЬКО минусов в Карму за столь нейтральный вопрос? Я же не сказал, что «носить женские туфли для мужчины неприемлемо», с чего все минусующие решили, что я не толерантен к кросс-дрессерам?
(кросс-дрессер — не обязательно гей: он может быть и «лесбиян» сексующийся с девушками надев женское платье;
а гей — не обязательно кросс-дрессер, он может быть и огромным бородатым волосатым мужиком с большими бицепсами любящего других мужчин)
PS с обвинениями в провокации — тоже не ко мне, а к автору статьи!
Не я эту картинку сюда поместил!
(кросс-дрессер — не обязательно гей: он может быть и «лесбиян» сексующийся с девушками надев женское платье;
а гей — не обязательно кросс-дрессер, он может быть и огромным бородатым волосатым мужиком с большими бицепсами любящего других мужчин)
PS с обвинениями в провокации — тоже не ко мне, а к автору статьи!
Не я эту картинку сюда поместил!
0
Если вы про жёлтую вертикальную полоску сзади:
То это он просто привстал на цыпочки, а из-за ноги виден край лежащего обрезка макаронины. А на ногах у него что-то типа мокасинов.
То это он просто привстал на цыпочки, а из-за ноги виден край лежащего обрезка макаронины. А на ногах у него что-то типа мокасинов.
0
Без наличия общей формализованной модели понятий (онтологии) для всех участников индустрии подобные статьи это просто трата байтов. Сродни Библии или Корану, просто слегка знакомые всем вокруг слова, выстроенные в предложения таким образом, чтобы создавать иллюзию глубокой осмысленности. Аспекты, простота, чистота. Аминь.
+4
freetonik подписан на вас очень нравятся статьи и переводы, но вот эта статья она кому адресована? если джуниорам то им без примеров тяжело рассуждать о высоких таких материях, а тем у кого опыта побольше уже и сами пришли к этим выводам
0
Мне гораздо больше понравилось вот это: «Пишите код, который легко удалять, а не дополнять» — https://habrahabr.ru/company/payonline/blog/277629/
В отличие от абстрактных обще-интуитивно понятных пожеланий, которые вы перечислили, «удалять а не дополнять» — это краеугольный базис, который определяет все остальное.
Тоесть… хммм… выстраивайте иерархию правил по уровню критичности, а не пытайтесь согласовать кашу с разных уровней абстракции.
«Пристрели того парня, который пытается 5 яиц разложить в 3 корзины» (с) Black Lagoon
В отличие от абстрактных обще-интуитивно понятных пожеланий, которые вы перечислили, «удалять а не дополнять» — это краеугольный базис, который определяет все остальное.
Тоесть… хммм… выстраивайте иерархию правил по уровню критичности, а не пытайтесь согласовать кашу с разных уровней абстракции.
«Пристрели того парня, который пытается 5 яиц разложить в 3 корзины» (с) Black Lagoon
0
Это все хорошие принципы, но никогда не стоит возводить их в абсолют, нужно всегда умело жонглировать ими.
К примеру, «3. Не нужно избыточности» и «6. Нужно минимизировать зависимости» противоречат друг другу.
Первый гласит про DRY принцип, возводя его в абсолют мы получаем множество маленьких кусочков кода, тем самым увеличиваем количество зависимостей. Тот же модуль isArray в npm, с одной стороны хорошо мы не дублируем код, с другой стороны у нас появляется новая зависимость.
К примеру, «3. Не нужно избыточности» и «6. Нужно минимизировать зависимости» противоречат друг другу.
Первый гласит про DRY принцип, возводя его в абсолют мы получаем множество маленьких кусочков кода, тем самым увеличиваем количество зависимостей. Тот же модуль isArray в npm, с одной стороны хорошо мы не дублируем код, с другой стороны у нас появляется новая зависимость.
0
Использование фреймворков и ООП шаблонов нарушает многие пункты :)
0
Тут дело не в шаблонах, скорее язык выбран не правильно; см. «2. Язык, на котором вы написали код, должен выглядеть как будто его создали для решения этой проблемы.»
Решаете функциональную задачу — берите ФП с его паттернами, если же вам нужно решить задачу с изменением глобального состояния — берите ООП с присущими ему паттернами. В противном случае код будет всегда смотреться плохо и излишне усложненным.
Решаете функциональную задачу — берите ФП с его паттернами, если же вам нужно решить задачу с изменением глобального состояния — берите ООП с присущими ему паттернами. В противном случае код будет всегда смотреться плохо и излишне усложненным.
0
Мне нужно нарисовать кнопку, которая при нажатии открывает новое окно. Это функциональная задача или ООП?
0
Идеальный ответ: «Depends on...», — ведь может быть очень много дополнительных условий. К примеру на html это описывается одним тегом без какого-либо кода.
Открытие окна это побочный эффект. ФП говорит, что побочные эффекты — это очень плохо и функции должны быть чистыми. И тут мы становимся перед выбором использовать ФП и нарушать его концепции или использовать ООП.
Открытие окна это побочный эффект. ФП говорит, что побочные эффекты — это очень плохо и функции должны быть чистыми. И тут мы становимся перед выбором использовать ФП и нарушать его концепции или использовать ООП.
0
Макконнел и Мартин написали более объемно, но и более полезно.
0
Большинство статей подобного рода ссылаются на сложность топика, и потому не приводят реальных примеров. А жаль. Топик крайне нетривиальный. Сам дядюшка Боб уже давно запутался в том, что такое принцип единственной ответственности. Более широкого, ни к чему не обязывающего определения, придумать сложно. А очень хотелось бы увидеть настоящие примеры из реальной жизни, а не объяснение столь абстрактных концептов на уже набивших оскомину калькуляторах, шейпах или работниках.
0
Когда пишете про DRY, надо всегда упоминать KISS и KISS впереди DRY
А то иногда такого можно понаворотить, чтоб если что можно было одну строчку править, вместо двух.
А то иногда такого можно понаворотить, чтоб если что можно было одну строчку править, вместо двух.
0
Sign up to leave a comment.
Главные характеристики качественного кода