Эта статья давно висела у меня в списке задач. Но кажется, только сегодня у меня появились силы и время, чтобы материализовать её. Совпадение или нет, но я в том же кафе, где опубликовал недавно свою первую статью. Наверное, в напитки, которые тут подают, что-то подмешивают...
Так что? Бородатый, хороший совет — следовать лучшим практикам? Мы постоянно слышим о них. Мы даже дали им краткие прозвища, типа DRY или KISS, и используем на автомате в технических разговорах. Мы фанатично следуем концепции, и если кто-то случайно захочет или просто по незнанию не станет их соблюдать, мы выливаем на них вёдра грязной критики. Мы пленники этих убеждений и отказываемся отвернуться от них в нужный момент.
Конечно, я не намекаю, что такие принципы, как DRY — плохие. Это определенно не так. Просто я считаю, что всё зависит от ситуации. Сильно. Что касается именно DRY, это ведёт к логическому выводу: «На самом деле я тот, кто иногда склоняет других к дублированию, а не абстракции».
Да, вы правильно прочитали. Дублированный код (он же копипаст) может быть полезной практикой. Особенно когда абстракция, которая заменяет повторяющиеся части кода, причиняет боль при попытках разобраться в ней.Читать полностью »
Когда я только начинал задумываться о том, чтобы приобщиться к миру веб-разработки, и выбирал язык, с которого начну, одна из википедий мне напела, что в основе философии Rails лежат 2 принципа: Convention over configuration (CoC) и Don’t Repeat Yourself (DRY). Что касается первого — я тогда вобще не понял о чём речь, а вот второй понял, принял и ожидал, что в недрах этого замечательного фреймворка, я отыщу нативный инструмент, позволяющий мне один раз написать правила валидации для атрибутов модели, и потом использовать эти правила как для front, так и для back проверок.
Читать полностью »
За годы присутствия на хабре я прочитал немало статей на тему того, как должен выглядеть идеальный код. И поменьше статьей о том, как конкретно достигать этого идеала. Также стоит отметить, что весьма значительная часть всех этих материалов была переводом западных источников, что, вероятно, является следствием более зрелой отрасли IT «за рубежом», со всеми вытекающими вопросами и проблемами.
К сожалению, во многих случаях авторы либо забираются в недосягаемые выси многослойных архитектур, что требуется в лучшем случае для 1% проектов, либо ограничиваются общими фразами вроде «код должен быть понятен» или «используйте ООП и паттерны», не опускаясь до подробных объяснений, в чем например измеряется «понятность» кода.
В этой статье я хочу попытаться систематизировать те критерии оценки качества кода, и те практики его написания, которые мне удавалось применять в реальных проектах практически независимо от их размеров и специфики, используемого языка программирования и других факторов.
Читать полностью »
Фреймворк Ruby on Rails меня просто очаровывает, но недавнего времени некоторую сложность представляла из себя генерация CRUD контроллеров.
Почти всегда мне было необходимо реализовывать списки с сортировкой, фильтрацией и пагинацией, а стандартного способа этого достичь в рельсах я не обнаружил. Перепробовал несколько вариантов и ни один меня не удовлетворил:
Долгое время не удавалось найти ничего похожего на полюбившийся мне виджет CGridView из Yii framework. Уже почти смирился с необходимостью писать свой велосипед, но наткнулся на DRY CRUD и хочу поделится опытом его использования. Может кому-то он окажется полезным, а может кто-то подскажет еще более подходящий инструмент.
Читать полностью »
Статья о простом, но не очевидном способе как сделать код чище и избавиться от копипасты.
Условно проблема выглядит вот так:
###
My awesome class
###
class Awesome
doFoo : (arg, cb) ->
unless arg is 42
return cb Error """
only The Answer may be an argument, but got:
|arg| = |#{arg}|
"""
cb null, "#{arg} is The Answer"
doBar : (arg, cb) ->
# hm... arg must be The Answer too
У нас есть кусок кода (тот, что с проверкой), который во-первых похоже потребуется повторить в новом методе, да и вообще отвлекает от основного действа в методе.
Разработчику программных продуктов тяжело быть идеалистом — оптимизация кода никогда не прекращается. Всегда, чуть позже, находятся более элегантные решения, что приводит к постоянному рефакторингу кода. Если проект имеет ограниченные сроки, то это хоть как-то останавливает процесс постоянного улучшения, но в случае личных разработок, программист ограничен лишь своими знаниями, которые, в свою очередь, тоже постоянно растут, что превращается в замкнутый круг.
Но, отойдем немного от философии к практике. Разрабатывая приложения, я всегда стремился к идеалу, стремился следовать актуальным концепциям. По ходу разработки я всегда старался следовать принципу DRY. Некоторое время назад я начал заниматься разработкой под Windows Phone. В результате появились «обертки» для операций, которые используются чаще всего. Некоторыми из них хочу поделиться.
Читать полностью »
Я бы хотел, чтобы статья была интересна, а главное, понятна всем, кто занимается версткой. Однако, моя проблема заключается в том, что она лежит на рубеже знаний серверных и клиентских разработчиков. И если первые хоть изредка, но верстают, то вторые, как правило, «на сервер» не заглядывают вообще — в кавычках, потому-что речь не о железе или ОС — нам понадобится кое-какой серверный софт. В общем, я постараюсь подойти к сути вопроса постепенно, чтобы не повторить комикс с рисованием совы. Особо нетерпеливым я просто скажу здесь: я верстаю с помощью Flask. Тех же, кого интересуют детали — прошу под кат.
Читать полностью »
DRY(Don’t Repeat Yourself) — один из краеугольных принципов современной разработки, а особенно в среде ruby-программистов. Но если при написании обычного кода повторяющиеся фрагменты обычно легко можно сгруппировать в методы или отдельные модули, то при написании тестов, где повторяющегося кода порой еще больше, это сделать не всегда просто. В данной статье содержится небольшой обзор средств решения подобных проблем при использовании BDD-фреймворка RSpec.
Читать полностью »
От переводчика:
Немало копий сломано в спорах о том, когда уместнее KISS, а когда DRY, когда лучше как можно быстрее и проще решить задачу любыми средствами, а когда стоит создавать красивые и универсальные абстракции. Натан Марц, автор популярного фреймворка Storm, используемого в Твиттере, предлагает свой вариант. Чтобы не создавать тонны бесполезного кода ради абстрактной универсальности и в то же время не позволять системе превращаться в кашу из костылей, он использует «разработку через страдание» (suffering oriented programming).
Однажды меня спросили: «Как ты решился пойти на такой страшный риск — писать Storm одновременно с запуском стартапа?» (Storm — фреймворк для распределённых вычислений в реальном времени). Да, пожалуй, со стороны создание такого крупного проекта для стартапа кажется крайне рискованным. Тем не менее, с моей точки зрения это вообще не было рискованным делом. Трудным, но не рискованным.
Я использую стиль разработки, который сильно уменьшает степень риска таких больших проектов, как Storm. Я называю этот стиль «разработкой через страдание». В двух словах: не занимайтесь реализацией технологий, от отсутствия которых вы не испытываете страданий. Этот совет применим как к большим, архитектурным решениям, так и к маленьким повседневным задачам. Разработка через страдание существенно уменьшает риск, гарантируя, что вы всегда работаете над чем-то важным, и что вы хорошо разобрались в предметной области, прежде чем вложить в решение много сил.
Я придумал такую мантру разработки: «Сначала сделай, чтобы было. Затем — чтобы было красиво. Затем — чтобы было быстро».
Читать полностью »