• Архитектура кода

      В этой статье я хочу поделиться своим личным опытом, связанным с правильной организацией кода (архитектурой). Правильная архитектура существенно упрощает долгосрочную поддержку.
      Это очень философская тема, поэтому я не могу предложить ничего более, чем мой субъективный анализ и опыт.

      Проблемы, симптомы


      Мой начальный опыт программиста был весьма безоблачным – я без лишних проблем клепал вебсайты-визитки. Писал код, как я это сейчас называю “в строчку” или “полотном”. На маленьких объемах и простых задачах все было хорошо.

      Но я сменил работу, и пришлось разрабатывать один единственный вебсайт в течение 4-х лет. Естественно, сложность этого кода была несопоставима с визитками из моей прошлой работы. В какой-то момент проблемы просто посыпались на меня – количество регрессии зашкаливало. Было ощущение, что я просто хожу по кругу – пока чинил “здесь”, сломал что-то “там”. И поэтом это “здесь” и “там” банально менялось местами и круг повторялся.

      У меня исчезла уверенность в том, что я контролирую ситуацию – при всем моем желании недопустить баги, они проскакивали. Все эти 4 года проект активно разрабатывался – мы улучшали уже существующий функционал, расширяли, достраивали его. Я видел и чувствовал, как удельная стоимость каждого нового рефакторинга/доработки растет – увеличивался общий объем кода, и соответственно увеличивались затраты на любую его правку. Банально, я вышел на порог, через который уже не мог переступить, продолжая писать код “в строчку”, без использования архитектуры. Но в тот момент, я этого еще не понимал.
      Читать дальше →
    • Мясорубка, супер-роботы и НИИ (Не Искусственный Интеллект)

        Если вы уже не первый год ведете какой-то проект, поверьте не похож ли он на нож мясорубки из истории №1 или на тарелку из истории №2


        Это поможет вам оптимизировать свой проект выкинув из него все лишнее, что только тормозит его.

        История №1


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

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

        В 1987 году отдел роботизации и автоматизации завода «Электросила» разработал безумно дорогого супер-робота, который точно повторял движение рук рабочего (напоминаю, что это было 30 лет назад (!)), но его производительность оказалась столь малой, что рабочего вернули на заточку, чуть ли не на следующий день.

        Для решения проблемы, был вызван внешний консультант из одного НИИ. Консультант начал свою работу, естественно с анализа….
        Читать дальше →
      • Знакомство с реактивными потоками – для Java-разработчиков

        • Перевод
        Привет, Хабр!

        Сегодня мы вернемся к одной из тем, затрагиваемых в нашей замечательной книге "Реактивные шаблоны проектирования". Речь пойдет об Akka Streams и потоковой передаче данных в целом — в книге Роланда Куна этим вопросам посвящены главы 10 и 15-17.
        Читать дальше →
        • +12
        • 4,7k
        • 3
      • Три истории микросервисов, или MSA для Enterprise

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


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

          Микросервисы — одна из самых важных и значимых составляющих Web-scale архитектуры, имеющая наибольшие последствия для переделки устройства техник и паттернов в Enterprise. Трудно сейчас сказать, на каком участке сейчас находится сама технология — может быть, на самом верхнем пике, и нам предстоит еще десять раз разочароваться. Но, тем не менее, это не повод не изучать её прямо сейчас.
          Читать дальше →
          • +22
          • 3,4k
          • 1
        • Держим дизайн системы под контролем, используя изолированное юнит-тестирование

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



            Сегодня мы поговорим о том,

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


            Читать дальше →
          • О декораторах, сквозной функциональности, CQRS и слоеной архитектуре

              Разработчик SimpleInjector очень любит «декораторы», особенно в сочетании с дженериками вида
              QueryHandler<TIn, TOut>, CommandHanler<TIn, TOut>.

              Такой подход позволяет «навешивать» на обработчики то, что принято называть cross-cutting concerns без регистрации и смс interception и особой уличной магии вроде Fody или PostSharp.

              CQRS не top level architecture, поэтому хочется иметь такие-же декораторы и для классических Application Service. Под катом я расскажу как это сделать.
              Читать дальше →
            • AdBlock похитил этот баннер, но баннеры не зубы — отрастут

              Подробнее
              Реклама
            • Большой комок грязи, часть 2

                Продолжение перевода статьи «Big ball of Mud».

                ОДНОРАЗОВЫЙ КОД


                он же
                QUICK HACK (быстрый хак)
                KLEENEX CODE (код на салфетке)
                DISPOSABLE CODE (утилизируемый код)
                SCRIPTING (скрипт)
                KILLER DEMO (демо-убийца)
                PERMANENT PROTOTYPE (постоянный прототип)
                BOOMTOWN (быстро выросший город)

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

                То же самое происходит и с прототипированием системы — вы не сильно переживаете о том, насколько красив и эффективен ваш код. Вы знаете, что код нужен вам только для того, чтобы показать работающий прототип. Как только он готов, код будет выброшен и прописан заново уже более тщательно. Когда подходит время демонстрации, возникает непреодолимое желание нагрузить его крутыми, но, по сути, бесполезными функциями. Иногда такая стратегия бывает “принести успешной”. Клиент, вместо того чтобы спонсировать разработку следующего этапа проекта, остается доволен прототипом.
                Читать дальше →
                • +13
                • 5,2k
                • 2
              • Matthias Noback Об Идеальной Архитектуре — Слои, Порты и Адаптеры (Часть 3 — Порты и Адаптеры)

                • Перевод

                Matthias Noback (автор A year with Symfony) опубликовал цикл из трех статей, в котором описал свои взгляды на идеальную архитектру корпоративных приложений, сформировавшуюся за долгие годы практики.Первая часть является вводной и не представляет особого интереса(можно ознакомиться в оригинале). Перевод второй — по ссылке. И так как он вызвал БЕШЕННЫЙ ажиотаж(целых ДВА человека подискутировали со мной в комментах), то не перевести третью было бы преступлением.


                В предыдущей статье мы обсудили разумную систему расслоения проекта, состоящую из трех слоёв:


                • Домен
                • Прикладной слой
                • Инфраструктура

                Сейчас, подробно рассмотрим инфраструктурный слой.

                Читать дальше →
                • +12
                • 3,6k
                • 1
              • Как запилить фичу и не выстрелить себе в ногу

                  Основная цель проектов – зарабатывать деньги. Проект над которым мне довелось работать, не стал исключением.


                  Я разработчик компании Колёса Крыша Маркет и сегодняшний пост будет посвящен тому, как мы дифференцировали цены на платные услуги на нашем “classified”.


                  Наша компания разрабатывает 3 продукта, каждый под 3 платформы – web, android и ios. Пользователи могут применять к объявлениям различные платные услуги, например, платное продление срока жизни объявления или размещение в блоке горячих предложений.


                  Когда меня привлекли к этому проекту, у меня в голове еще до начала обсуждения держалась мысль, что за дифференцированные цены?


                  Дифференцированная цена — цена формирование которой зависит от характеристик объявления (регион, марка, модель, год и т.д.).


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

                  Читать дальше →
                • Анатомическая метафора кода. Где у кода мускулы

                    Размышлял как-то о коде, программировании и всём таком; бродили всякие мысли. А что если взять, например, и заставить двух разработчиков написать несложные программы по одному ТЗ. Программисты одинакового уровня. Пишут независимо друг от друга. Код у них, естественно, получится разный. Однако если вытащить из кода каждой программы строчки, выполняющие реальную работу (преобразования исходных данных в необходимый результат), и свалить их в две большие «кучи», то эти «кучи» вроде бы должны оказаться сильно похожими. Потому что исходя из поставленной задачи оба программиста, наверное, применят похожие вычисления и преобразования данных. (На самом деле это маловероятно, так как и алгоритмы тоже, скорее всего, будут выбраны разные.)

                    Тогда и появилась эта безумная аналогия.

                    Весь код, который выполняет реальную работу: производит вычисления, преобразует данные, проверяет условия и т. д. — это «мясо». «Мышцы» программы. Код, который отвечает за структуризацию — «сухожилия». То, с помощью чего мышцы крепятся к костям. Начало и конец мышцы, альфа и омега. То, благодаря чему каждый отдельный мускул остаётся самостоятельным, а не слипается в бесформенный фарш. А что тогда «кости»? Кости, подумалось мне, — это, наверное, архитектура программы.



                    Читать дальше →
                  Самое читаемое