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

в 19:25, , рубрики: баланс, Проектирование и рефакторинг, хабрахабр, метки: , ,

В одном из вчерашних комментариев был вопрос о том, что если всё плохо, то
— Как же будет хорошо?
— Сделать лучше.

 Я попробую показать, что можно изменить в карма логике хабра в лучшую сторону и в конце провести небольшие параллели с жизнью.
Можно сказать это объектное моделирование, в котором в большей степени важна логика, а предметом-моделью будет карма, как результат взаимоотношений между пользователями.
Я не знаю полного механизма начисления кармы и рейтинга и на хабре, поэтому опишу как это может работать с моей точки зрения (тз)

Всё решает баланс.
 Чем тоньше баланс между пользователями и производимым ими контентом, тем выше статус самой системы.
Сейчас модель уже работает и можно для начала усовершенствовать пару правил и посмотреть как пойдёт, как это повлияет на появление новых статей, присоединение пользователей, комментирование и прочее. Понятно что уже и так всё хорошо или можно сделать лучше?
К примеру плохо то, что имея небольшой ботнет («друзей-товарищей») можно задавить любого начинающего автора или комментатора, причём объективности можно не ждать, это может быть просто другой взгляд, не такой, как у других.
Читать полностью »

в 15:56, , рубрики: active record, rails, ruby on rails, переводы, Проектирование и рефакторинг, рефакторинг, метки: , ,

От переводчика: предлагаю вашему вниманию вольный перевод статьи из блога Code Climate под названием 7 Patterns to Refactor Fat ActiveRecord Models.
Code Climate — мощное средство анализа качества кода и безопасности Ruby on Rails — приложений.

Введение

Когда разработчики начинают использовать Code Climate для улучшения качества их Rails-кода, им приходится избегать «распухания» кода их моделей, так как модели с большим количеством кода создают проблемы при сопровождении больших приложений. Инкапсуляция логики предметной области в моделях лучше, чем помещение этой логики в контроллеры, однако такие модели обычно нарушают Принцип единственной обязанности (Single Responsibility Principle). К примеру, если поместить в класс User все что относится к пользователю — это далеко не единственная обязанность.
Читать полностью »

в 22:53, , рубрики: Программирование, проектирование, Проектирование и рефакторинг, рефакторинг, метки: , ,

imageПредлагаю перейти на сторону зла, на темную сторону программирования. Ситхи сильнее джедаев. И печенек хватит на всех. Предупреждаю, прежде чем начнете читать далее. Характер при переходе на темную сторону портится.
Прошу под кат
Читать полностью »

в 19:08, , рубрики: архитектура приложений, Веб-разработка, локализация, мультиязычность, проектирование базы данных, Проектирование и рефакторинг, метки: , , ,

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

в 18:56, , рубрики: continuous integration, php, phpunit, selenium, yii, Проектирование и рефакторинг, тестирование, тестирование веб-приложений, метки: , , , , ,

Мы часто экспериментируем с архитектурой, кодом, производительностью. Постоянно добавляем новый функционал. Мы постепенно обвязываем Yii своей “архитектурной” прослойкой — шардинг, работа с временно недоступными данными, разнообразные кеши и многое другое. Да, плод нашей работы, когда он будет заврешен, пойдет в Open Source.

Задача применяемой у нас Непрерывной Интеграции (Continuous Integration, CI) — не тестирование. Задача CI — обезопасится от разрушительных изменений в следствие рефакторинга, добавления нового функционала, изменений архитектуры. Также мы защищаемся от “плохого кода”, часто повторяющихся багов, “кривых” merge.

Для своего CI мы используем Jenkins под Debian. Время на развертку CI я затратил 12 часов — до полностью рабочего состояния. На поддержку CI я не трачу ни минуты в день — я не пишу тесты на каждую мелочь, не практикую TDD. Тем не менее, CI работает и спасает нас от глупых ошибок.

“Давайте будем внимательней”/”Давайте не делать ошибок” — взывал я к разработчикам, но это помогало лишь временно и то не на все 100%. Людям свойственно ошибаться, забывать, совершать оплошности. Нет, я не изобрел “серебряную пулю” для web-проектов и даже маленьку пульку для Yii — я придумал как стабилизировать свое приложение. Ваше приложение отличается от моего и мои методы у Вас могут не работать, да и не должны — я же делал их не для Вашего приложения, если мои методы работаю у Вас — примите это как чудо или как везение. Зато идея такого CI будет работать везде. Всего лишь идея.

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

в 18:35, , рубрики: Model View Controller, mvc, QML, qt, qt quick, Qt Software, Программирование, Проектирование и рефакторинг, метки: , , , ,

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

Model-View в QML:

  1. Model-View в QML. Часть нулевая, вводная
  2. Model-View в QML. Часть первая: Представления на основе готовых компонентов
  3. Model-View в QML. Часть вторая: Кастомные представления

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

в 10:03, , рубрики: inheritance, javascript, наследование в javascript, ооп, ооп js, Проектирование и рефакторинг

Понимание ООП на джаваскрипте (ES5), часть 2

Замечания о переводе

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

Для полноты статьи и единого стиля, перевод начинается с вопросов наследования, несмотря на то, что они уже были упомянуты в конце первой части. Далее рассматриваются разнообразные задачи наследования так, как их рассмотрел автор. Надо сказать, что автор широко использует новые конструкции ES5 (объяснив это в конце), которые работают не во всех браузерах и заслоняют от понимания реализацию их на низком уровне языка, на котором они изначально применялись. Для настоящего понимания наследования следует обратиться к более глубокому разбору реализаций или к реализациям методов-обёрток из ES5: Object.create, Object.defineProperty, Function.bind, get и set literals, Object.getOwnPropertyNames, Object.defineProperty, Object.getOwnPropertyDescriptor, Object.getPrototypeOf. Часть их разбирается в статье (Object.create, get и set, Object.defineProperty, bind), но не всегда в порядке появления. Таким образом, статья стремится преподнести не реализацию наследования вообще, а ту реализацию, которую успели формализовать в рабочем черновике стандарта EcmaScript 5. Это лучше, чем ничего, но несколько меньше, чем полное понимание реализаций наследования.

Зато, данная часть статьи в нескольких (4) крупных примерах кода демонстрирует чистейшее прототипное наследование, которому не требуется привлекать понятие конструктора (хотя он там, в .create(), незримо присутствует), о котором много говорят и которое исключительно редко в чистом виде встречается.

Краткое содержание первой части

1. Объекты
  1.1 Что есть объекты? (список свойств)
  1.2 Создание свойств (Object.defineProperty)
  1.3 Описатели свойств (Object.defineProperty)
  1.4 Разбор синтаксиса (bracket notation: object['property'])
  1.5 Доступ к свойствам (через скобочную нотацию)
  1.6 Удаление свойств (оператор delete)
  1.7 Геттеры и сеттеры (методы доступа и записи)
  1.8 Списки свойств (getOwnPropertyNames, keys)
  1.9 Литералы (базовые операторы) объекта
2. Методы
  2.1 Динамический this
  2.2 Как реализован this
    2.2.1 Если вызывается как метод объекта
    2.2.2 При обычном вызове функции (this === global)
    2.2.3 При явном указании контекста (.apply, .call)
  2.3 Привязывание методов к контексту (.bind)
Cодержание части 2

3. Прототипное наследование
  3.1 Прототипы
  3.2 Как работает [[Prototype]]
  3.3 Переопределение свойства
  3.4 Миксины (примеси)
  3.5 Доступ к экранированным ('перезаписанным') свойствам
План части 3

4. Конструкторы
  4.1 Магия оператора new
  4.2 Наследование с конструкторами
5. Соглашения и совместимость
  5.1 Создание объектов
  5.2 Определение свойств
  5.3 Списки свойств
  5.4 Методы связывания
  5.5 Получение [⁣[Prototype]⁣]
  5.6 Библиотеки обратной совместимости
6. Синтаксические обёртки
7. Что читать дальше
8. Благодарности
Примечания

3. Прототипное наследование

До сих пор мы рассматривали, как определяются методы в объектах и как их повторно используют в других объектах при явном указании контекста, но это — всё же не лучший путь использования и расширения объектов.

Далее в игру вступает наследование. Оно лучше разделяет понятия, когда объекты наделяются своими методами на основе методов других объектов.

Прототипное наследование идёт дальше и может избирательно расширять методы, описывать общее поведение и использовать другие занятные приёмы, которых мы коснёмся. Печалит лишь то, что модель наследования в JS немного ограничена, и для обхода трудностей эти приёмы будут временами избыточны выносить мозг.Понимание ООП на джаваскрипте (ES5), часть 2
Читать полностью »

в 19:37, , рубрики: design patterns, ruby, template method, Проектирование и рефакторинг

Введение

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

Я настроятельно рекомендую книгу Russ Olsen — Design Patterns in Ruby. Наш цикл постов будет черпать вдохновение оттуда и будет чем-то вроде краткой выжимки. Таким образом, если вам понравится то что вы читаете (а я надеюсь на это!), книга будет отличным продолжением.

Мы рассмотрим различные паттерны проектирования и научимся их применять. Сегодняшняя тема — Шаблоный метод, простейший паттерн проектирования.
Читать полностью »

в 12:23, , рубрики: веб-аналитика, нагрузка, прогнозирование, Проектирование и рефакторинг, метки: ,

При разработке/создании web-сайта, мобильного приложения, WEB-сервиса – иными словами Информационной системы (ИС) встает вопрос о требующих аппаратных ресурсах – количестве серверов (виртуальных машин).
Методология расчета нагрузки, количества пользователей информационной системы — web сайта или сервиса
Приведённая методика описывает расчет количества пользователей и «оборудования» для территории Российская федерация.

Исходные данные

  • Веб сайт «Визитка»;
  • WEB-сервис для мобильных приложений, работающий по протоколу http/https, взаимодействующий с Базой данных;
  • База данных SQL (NOSQL);
  • WEB-клиент – реализующий функционал мобильного приложения для web пользователей, также взаимодействующий с Базой данных.

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

в 14:53, , рубрики: gtd, качество кода, Программирование, Проектирование и рефакторинг

Изменять код
В процессе разработки программного обеспечения нет такого понятия, как «стагнация». Все, что вы разрабатываете сейчас — просто очередная версия компонента, который вероятно будет меняться в будущем. Изменение является самой распространенным явлением в мире разработки программного обеспечения и вам лучше принять это как факт. Рассчитывайте на возможные изменения всего, что вы разрабатываете и поэтому проектируйте ваш код более модульным. Это упрощает изменения и в тоже время увеличивает качество кода. Старайтесь придерживаться концепций DRY и YAGNI. Вы часто будете в ситуации когда вы смотрите на ваш код и представляете, что вы могли бы сделать это лучше. Так пусть эта мысль не мешает вам спать. Садитесь сразу за дело и рефакторинг! Если не сделаете это сейчас, вы возможно никогда этого не сделаете. Чем дольше ждете, тем сложнее и дороже это будет. И это может вырасти в лишнюю головную боль с которой не захочется связываться.
«Хороший код — это код который легко изменять. Код стремится измениться до момента, когда его уже не легко изменять. Весь код становится плохим кодом.» Неизвестный автор.
Читать полностью »

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