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