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

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

В ПО, которое разрабатывает наша команда используются денежные значения в рублях и копейках. Мы изначально знали, что использование примитивов для выражения денежных значений — это антипаттерн. Однако по мере разработки приложения мы всё никак не могли наткнуться на проблемы связанные с использованием примитивов, нам, видимо, везло и всё было нормально. До поры до времени.
Мы совсем забыли про эту проблему и использование примитивов типа int и decimal расползлось по всей системе. И теперь, когда мы написали первый метод, в котором прочувствовали проблему, пришлось вспомнить про это технический долг и переписать всё на использование денежной абстракции вместо примитивов.
Читать полностью »

    В Caché есть несколько различных способов пройтись по коллекции и выполнить какие-нибудь действия с ее элементами. Самым простым является while-цикл. Такой способ позволяет решить поставленную задачу в императивном стиле. Разработчику приходиться явно заботиться об итераторе, о переходе к следующему элементу и о проверке выхода за пределы коллекции.
    Но разве это то, о чем должен заботиться разработчик?! Разработчик должен решать поставленную перед ним задачу, за максимально короткое время с максимально хорошим качеством кода. Было бы очень здорово просто взять коллекцию и применить к ней функцию, которая выполняет необходимые действия на каждом элементе этой коллекции. Не проверять границ, не создавать итератор, не вызывать вручную функцию на каждом элементе. Такой способ решения задач называется декларативным программированием.

Declarative programming is when you write your code in such a way that it describes what you want to do, and not how you want to do it.

(c) 1800-information
Давайте подумаем, как же решить поставленную задачу декларативно, используя средства и возможности Caché.Читать полностью »

Последнее время в Email-маркетинге все чаще используются автоматические рассылки определенным группам потребителей. Типичные задачи:

  • поздравить с днем рожденья
  • позвать на сайт, если потребитель на него долго не заходил
  • сделать персонализированное предложение (делим потребителей на сегменты и рассылаем каждому сегменту свое письмо)

В этой статье мы расскажем, как мы решали эту задачу — от написания каждой отдельной рассылки разработчиком с нуля 3 года назад, до заведения рассылок менеджером через веб-интерфейс в настоящее время. Рассказ может быть интересен не только тем, кто занимается Email-маркетингом но и вообще всем, кому приходится реализовывать периодическое выполнение сложных операций над определенными выборками потребителей (знаю, что звучит очень абстрактно, но в итоге именно такую абстрактную задачу нам и пришлось решить).

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

Чтобы направить всю энергию системы в необходимом направлении, нужно эту систему ограничить правилами.

Архитектурный дизайн мобильных приложений: часть 2 - 1


Привет!

Продолжаем серию статей об архитектурном дизайне мобильных приложений. Под катом поговорим о проектировании слоёв UI.

Добро пожаловать!Читать полностью »

Все чаще и чаще я вижу, что люди уклоняются от новейших технологий, делая выбор в пользу обратной совместимости. «Мы не можем повышать минимальные требования к PHP до 5.5, потому что у нас 50% пользователей еще на 5.4» говорят они. «Нет никакого способа обновиться до Guzzle 4+, у нас бекенд на версии 3 и переделывать его слишком долго и дорого». И самый лучший аргумент от WordPress: «Мы не может придти к полному ООП, потому что большинство пользователей сидят на shared-хостингах с 5.1 или не знают про MVC».

Нонсенс.

Legacy-код – это большое НЕТ

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

Наименование: Functional Decomposition (функциональная декомпозиция)
Другие наименования: No Object-Oriented AntiPattern «No OO»
Масштаб: приложение
Рефакторинг: объектно-ориентированный реинжиниринг

Функциональная декомпозиция — хорошая практика процедурного программирования, так как она позволяет разделить приложение на отдельные функциональные модули.

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

Сегодня немного лирики: как мы решаем, что попадает в базовый функционал решения, а что нет.
Тему настоящего текста дала известная (на хабре) статья про 1С, освещавшая помимо прочего, подход уважаемой корпорации к развитию функционала коробочных конфигураций.

Нашу платформу объединяет с 1С концепция монолита (в противовес модульной схеме некоторых коллег, что на слуху), а вот подход к композиции базовой конфигурации у нас по сравнению с 1С совершенно противоположный.
Читать полностью »

Антипаттерны проектирования: Dead End - 1В статье описываются возможные проблемы, которые могут возникнуть при модификации повторно используемых компонентов. Также приводятся рекомендации, как эти проблемы избежать. Перевод является вторым в серии (один антипаттерн — одна статья), ссылка на первый перевод находится в конце статьи.

Наименование: Dead End (тупик)
Другое наименование: Kevorkian Component (мертвый компонент)

Суть проблемы

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

От переводчика: Некоторые термины, которые использует автор, не имеют общепринятого перевода (ну, или я его не знаю:), поэтому я решил оставить большинство на языке оригинала — они всё равно понятны и для тех, кто пишет под android, но не знает английский.
Куда писать об ошибках и неточностях, вы знаете.

За последние несколько месяцев, а также после дискуссий на Tuenti с коллегами вроде @pedro_g_s и @flipper83 (кстати говоря, 2 крутых Android-разработчика), я решил, что имеет смысл написать заметку о проектировании Android-приложений.

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

«Я точно не знаю, что делает этот класс, но я уверен, что это важно!»

У паттернов проектирования — типовых решений, есть антиподы — типовые ошибки в проектировании. О паттернах проектирования написано достаточно книг, о антипаттернах — единицы. Вашему вниманию представлен вольный перевод статьи с сайта SourceMaking, описывающий один из таких антипаттернов (всего на сайте в разделе Software Development Antipatterns их представлено 14).
Антипаттерны проектирования: Poltergeists - 1
Наименование: Poltergeists (полтергейсты)
Другие наименования: Gypsy (цыган), Proliferation of Classes (рост количества классов), Big DoIt Controller Class
Масштаб: приложение
Рефакторинг: Ghostbusting (охота за привидениями)
Причина появления: непонимание концепций ООП, лень продумать архитектуру классов
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js