Рубрика «Проектирование и рефакторинг» - 49

в 7:39, , рубрики: clojure, rest, routing, Проектирование и рефакторинг, Разработка веб-сайтов, функциональное программирование

Существуют библиотеки на различных языках, имеющие общие черты. Это compojure, sinatra, grape, express, koa и подобные.

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

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

Я расскажу, как улучшить поддерживаемость кода в экосистеме Clojure, и покажу, как:

  1. организовать url'ы
  2. структурировать код обработчиков
  3. использовать языковые конструкции для генерации url

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

в 12:56, , рубрики: web, Алгоритмы, атомарность, высокая производительность, Проектирование и рефакторинг, Разработка веб-сайтов, счетчик, счетчики, метки:
Как считать счётчики и не сбиться со счёта - 1

Число подписчиков блога. Число опубликованных постов пользователя. Число положительных и отрицательных голосов за комментарий. Число оплаченных заказов товара. Вам приходилось считать что-то подобное? Тогда, готов поспорить, что оно у вас периодически сбивалось. Да ладно, даже у вконтакта сбивалось:

Как считать счётчики и не сбиться со счёта - 2

Не знаю как у вас, но в моей жизни счётчики — едва ли не первая проблема после инвалидации кеша и нейминга. Не стану утверждать, что решил её окончательно. Просто хочу поделиться с сообществом подходом, к которому я пришёл в процессе работы над Хабром, Дару~даром, Дёрти, Трипстером и другими проектами. Надеюсь это поможет кому-то сэкономить время и нервные клетки.

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

в 8:49, , рубрики: adobe flash, flash, html, html5, Yahoo, видео, Медиа, Проектирование и рефакторинг, Промышленное программирование, стриминг

Как Yahoo перешла от Flash к HTML5 в видео - 1

Adobe Flash когда-то был стандартом де-факто в мире веб-медиа, но со временем индустрия отвернулась от него из соображений безопасности и производительности. Требовать у юзеров устанавливать плагин для воспроизведения видео — тоже плохая практика. В результате, мы переходим к HTML5 для видео.

Разработка в области воспроизведения видео на HTML5 все еще в зачаточном состоянии, и изначально браузеры поддерживали эти возможности в самом примитивном виде. Только в последнее время поддержка была расширена и стала включать адаптивный стриминг. Адаптивный стриминг имеет два главных преимущества:

  • Адаптивный битрейт (ABR): Алгоритм определяет пропускную способность канала пользователя, мощность процессора, размер плеера и т.д. в реальном времени и подстраивает параметры видео.
  • Изменяемый размер буфера: возможность, позволяющая нам управлять временем, которое нужно для запуска воспроизведения.

Эти возможности позволили индустрии стриминга видео перейти от Flash к HTML5 и JavaScript.

Наш видео-плеер в Yahoo использует HTML5 во всех современных браузерах. В этом посте мы опишем наш путь к реализации этих возможностей, расскажем о проблемах, с которыми столкнулись, и опишем возможности, которые мы видим.Читать полностью »

в 9:03, , рубрики: DRY, дублирование кода, практика программирования, Программирование, Проектирование и рефакторинг, Промышленное программирование

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

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

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

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

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

в 5:17, , рубрики: .net, bdd, C#, nunit, specflow, библиотеки, ооп, Программирование, Проектирование и рефакторинг, фреймворки

Тема автономного тестирования давняя, почтенная, разобранная до косточек. Кажется, что после отличной книги Роя Ошероува и сказать особо нечего. Но на мой взгляд есть некоторая несбалансированность доступных инструментов. С одной стороны монстры вроде SpecFlow, с огромным оверхедом ради возможности писать тесты-спецификации на квази-естественном языке, с другой — челябинская суровость фреймворков старой школы вроде NUnit. Чего не хватает? Инструмента для лаконичной, выразительной, легко читаемой записи тестов, по удобству и ортогональности аналогичного библиотекам для создания подделок, таких как FakeItEasy, или проверки утверждений вроде FluentAssertion.

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

в 7:48, , рубрики: contoso-express, express.js, full-stack apps, javascript, node.js, postgresql, React, sequelize, TypeScript, vue.js, Проектирование и рефакторинг
Строим свой full-stack на JavaScript: Клиент - 1

JavaScript на клиенте быстро меняется: библиотеки, фреймворки, упаковщики быстро появляютcя и сменяют один другой. Но несмотря на это, многие ключевые операции одинаковы для любого клиентского приложения. А в современных фронт-энд фреймворках, при всем их разнообразии, есть много общего.Читать полностью »

в 23:04, , рубрики: Анализ и проектирование систем, визуализация данных, менеджмент проектов, Проектирование и рефакторинг, проектирование по, системы контроля версий
image

От переводчика:

На этого интересного автора, Адама Торнхила, я набрел при поиске видео с конференции GOTO. Кому данная статья покажется интересной, советую посмотреть его выступление. Я немного заморочился с переводом (благодарен Тане за помощь!), потому что тематика показалась очень своеобразной, не встречал ранее аналогичные работы (буду рад ссылкам в комментариях!). Статья свежая, августа 2016, в оригинале называется Software ®Evolution — Part 1. В тексте идет повествования от первого лица, но имеется в виду автор оригинальной статьи.

Как эволюция кода позволяет понимать большие кодовые базы

Обычно плохой код – это надолго. Он не просто остаётся в конкретном файле, но ещё остаётся там на года, переживая своих создателей (внутри организации) и вызывая недовольство следующего поколения программистов, ответственных за поддержку. Изменения в таком коде являются рискованной деятельностью. Учитывая масштаб нынешних кодовых баз, мы нуждаемся в более эффективных инструментах для выявления подобных частей системы, так чтобы мы могли сделать коррекцию, приложить дополнительные усилия в тестировании или выполнить ревью кода. В этой статье мы используем данные по предыдущему поведению в сфере разработки для того, чтобы получить руководство к указанным решениям.

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

в 16:15, , рубрики: Erlang/OTP, highload, RabbitMQ, Анализ и проектирование систем, Блог компании Конференции Олега Бунина (Онтико), высокая производительность, павел филонов, Проектирование и рефакторинг

Павел Филонов (Positive Technologies)

Павел Филонов

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

Сначала немного в качестве пролога. Это приятная часть.

101 способ приготовления RabbitMQ и немного о pipeline архитектуре - 2

Сценка, разворачивающаяся в будний день в офисе, наводит нас на очень приятное размышление. Перед нами встает шикарная задача, новая система. Мало что так сильно будоражит ум инженера, как просьба разработать новую систему. Не починить что-то старое, не адаптировать что-то старое, а именно что-то создать, в каком-то смысле практически с нуля.

Вместе с такой задачей приходит и целая серия проблем.
Читать полностью »

в 9:24, , рубрики: качество, Программирование, Проектирование и рефакторинг, Промышленное программирование, Совершенный код, чистый код

Главные характеристики качественного кода - 1

Как часто вы поражаетесь, читая чужой код, и думаете «господи, ну и каша...». Скорее всего, достаточно часто. И можете ли вы быть уверенным, что никто не думал также когда читал ваш код? Другими словами, насколько вы уверены в чистоте своего кода? Можно быть уверенным только если полностью понимаешь, что значит чистый код.

Сложно дать точное определение чистому коду, и, скорее всего, сколько программистов — столько определений. Однако, некоторые принципы достаточно универсальны. Я собрал девять самых релевантных и описал ниже.

1.Плохой код делает слишком много, чистый код сфокусирован

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

Но я бы не ограничивал определение классами. В свой последней статье Ральф Вестфал (Ralf Westphal) представил более широкое определение принципа единственной обязанности:

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

в 1:12, , рубрики: .net, C#, антипаттерны, объектно-ориентированный дизайн, ооп, паттерны проектирования, Программирование, Проектирование и рефакторинг, метки:

Ключевое противоречие ООП

Как известно, классическое ООП покоится на трех китах

  1. Инкапсуляция
  2. Наследование
  3. Полиморфизм

Классическая же реализация по умолчанию:

  1. Инкапсуляция — публичные и приватные члены класса
  2. Наследование — реализация функционала за счет расширения одного класса-предка, защищенные члены класса.
  3. Полиморфизм — виртуальные методы класса-предка.

Но еще в 1986 году была обозначена серьезнейшая проблема, кратко формулируемая так:

Наследование ломает инкапсуляцию

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

1...1020...484950...6070...76
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js