Рубрика «DRY»

image
Доброго времени суток, читатель! Хочу поделиться небольшой статье посвященной самым известным принципам разработки программного обеспечения. Статья будет полезна скорее для начинающих разработчиков, потому что опытные вряд ли найдут здесь что-то новое. Но и новичкам тоже нужно что-то читать.
Читать полностью »

Введение

Есть несколько статей об антипаттернах разработки ПО. Но большинство из них говорят о деталях на уровне кода и фокусируются на конкретной технологии или языке программирования.

В этой статье я хочу сделать шаг назад и перечислить высокоуровневые антипаттерны тестирования, общие для всех. Надеюсь, вы узнаете некоторые из них независимо от языка программирования.

Терминология

К сожалению, в тестировании пока не выработали общую терминологию. Если спросить сотню разработчиков, в чём разница между интеграционным, сквозным и компонентным тестом, то получите сто разных ответов. Для этой статьи ограничимся такой пирамидой тестирования:

Антипаттерны тестирования ПО - 1

Если не видели пирамиду тестирования, настоятельно рекомендую ознакомиться с ней. Вот некоторые хорошие статьи для начала:

Читать полностью »

Говорят, что не нужно изобретать велосипед. На первый взгляд это кажется очевидным. Если вы потратили время на разработку, то зачем делать это снова, можно ведь повторно использовать старое решение? Казалось бы, со всех сторон хороший вариант. Но не всё так просто. Как старый «седой» программист, я видел, как организации снова и снова становятся жертвами этого заблуждения, вкладываясь в предварительный дизайн и разработку, но никогда не достигая обещанного массивного ROI благодаря повторному использованию. На самом деле я считаю, что наша чрезмерно оптимистичная оценка пользы и простоты повторного использования — одна из самых распространённых и опасных ловушек в разработке ПО.

Я считаю корнем проблемы то, что Даниел Канеман сформулировал как правило «Что видишь, то и есть». Оно в двух словах объясняет жёсткие ограничения человека на быстрое принятие решений, используя только имеющиеся данные и некоторые базовые эвристики. Замедление мышления требует времени и дисциплины — так что вместо этого мы пытаемся заменить сложные проблемы, которые не полностью понимаем, простыми.
Читать полностью »

От всех моих предыдущих реализаций сетевого слоя осталось впечатление, что есть еще куда расти. Данная публикация ставит целью привести один из вариантов архитектурного решения по построению сетевого слоя приложения. Речь пойдет не об очередном способе использования очередного сетевого фреймворка.

Часть 1. Взгляд на существующие подходы

Для начала из публикации 21 Amazing Open Source iOS Apps Written in Swift взято приложение Artsy. В нем используется популярный фреймворк Moya, на базе которого и построен весь сетевой слой. Отмечу ряд основных недостатков, которые встретил в данном проекте и часто встречаю в других приложениях и публикациях.

Читать полностью »

Программирование — достаточно молодая область знаний, однако, в ней уже существуют базовые принципы «хорошего кода», рассматриваемые большинством разработчиков как аксиомы. Все слышали о SOLID, KISS, YAGNI и других трех- или четырех- буквенных аббревиатурах, делающих ваш код чище. Эти принципы влияют на архитектуру вашего приложения, но помимо них существуют архитектурные стили, методологии, фреймворки и много чего еще.

Разбираясь со всем этим по отдельности, меня заинтересовал вопрос — как они взаимосвязаны? Пытаясь выстроить иерархию и вдохновившись небезызвестной пирамидой Маслоу, я построил свою пирамиду «архитектуры приложения».

О том, что из этого вышло — читайте под катом.
Читать полностью »

При разработке любого, даже простого веб-приложения возникает необходимость повторного использования кода. В разных местах сайта рано или поздно обнаруживаются схожие участки разметки и логики, которые совсем не хочется дублировать. Однако, в решении этой задачи очень легко наступить на грабли и сделать все очень плохо.

Эта статья во многом вдохновлена докладом Павла Силина на РИТ 2017, однако здесь много моего собственного опыта и размышлений. Примеры будут на React + TypeScript, однако подход не привязан к какой-либо технологии.

Заменяй и властвуй — подход SOLID для разработки повторно используемых компонентов в вебе - 1Читать полностью »

25 марта университет интернет-профессий «Нетология» совместно с сообществом ruby-разработчиков Moscow.rb провел митап на тему альтернативных решений в мире Ruby. Выясняем, есть ли нетривиальный Ruby и что-то кроме «рельсы», а также за что любить этот язык программирования.

image

Читать полностью »

DRY и цена неправильных абстракций - 1

Эта статья давно висела у меня в списке задач. Но кажется, только сегодня у меня появились силы и время, чтобы материализовать её. Совпадение или нет, но я в том же кафе, где опубликовал недавно свою первую статью. Наверное, в напитки, которые тут подают, что-то подмешивают...

Так что? Бородатый, хороший совет — следовать лучшим практикам? Мы постоянно слышим о них. Мы даже дали им краткие прозвища, типа DRY или KISS, и используем на автомате в технических разговорах. Мы фанатично следуем концепции, и если кто-то случайно захочет или просто по незнанию не станет их соблюдать, мы выливаем на них вёдра грязной критики. Мы пленники этих убеждений и отказываемся отвернуться от них в нужный момент.

Конечно, я не намекаю, что такие принципы, как DRY — плохие. Это определенно не так. Просто я считаю, что всё зависит от ситуации. Сильно. Что касается именно DRY, это ведёт к логическому выводу: «На самом деле я тот, кто иногда склоняет других к дублированию, а не абстракции».

Да, вы правильно прочитали. Дублированный код (он же копипаст) может быть полезной практикой. Особенно когда абстракция, которая заменяет повторяющиеся части кода, причиняет боль при попытках разобраться в ней.Читать полностью »

Когда я только начинал задумываться о том, чтобы приобщиться к миру веб-разработки, и выбирал язык, с которого начну, одна из википедий мне напела, что в основе философии Rails лежат 2 принципа: Convention over configuration (CoC) и Don’t Repeat Yourself (DRY). Что касается первого — я тогда вобще не понял о чём речь, а вот второй понял, принял и ожидал, что в недрах этого замечательного фреймворка, я отыщу нативный инструмент, позволяющий мне один раз написать правила валидации для атрибутов модели, и потом использовать эти правила как для front, так и для back проверок.
Читать полностью »

imageЗа годы присутствия на хабре я прочитал немало статей на тему того, как должен выглядеть идеальный код. И поменьше статьей о том, как конкретно достигать этого идеала. Также стоит отметить, что весьма значительная часть всех этих материалов была переводом западных источников, что, вероятно, является следствием более зрелой отрасли IT «за рубежом», со всеми вытекающими вопросами и проблемами.

К сожалению, во многих случаях авторы либо забираются в недосягаемые выси многослойных архитектур, что требуется в лучшем случае для 1% проектов, либо ограничиваются общими фразами вроде «код должен быть понятен» или «используйте ООП и паттерны», не опускаясь до подробных объяснений, в чем например измеряется «понятность» кода.

В этой статье я хочу попытаться систематизировать те критерии оценки качества кода, и те практики его написания, которые мне удавалось применять в реальных проектах практически независимо от их размеров и специфики, используемого языка программирования и других факторов.
Читать полностью »