Проектирование и рефакторинг *

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

Некая недосказанность всегда присутствует на первых свиданиях. Жаль, что она в плоскости тех.задания.  Когда времени мало – проще танцевать от требований и ограничений, а не заниматься подтверждением  парадокса выбора. Поэтому будем сразу говорить об архитектуре. На собеседованиях только и разговоров, что об архитектуре и о дизайне. Там говорят о том, как чертовски здорово наблюдать за огромным монолитным легаси, как он тает в волнах.

Сегодня мы рассмотрим методы формализации требований: Use Case и User Story. В статье рассмотрим оба метода, сравним их преимущества и недостатки. А также рассмотрим, когда и при каких ситуациях использовать каждый из методов.

Приветствую! С вами Вадим, frontend разработчик компании «Перспективный мониторинг». Сегодня хочу поделиться нашей типовой структурой frontend приложения, рассказать об архитектурной методологии, которую мы используем, а также основных проблемах, с которыми нам пришлось столкнуться, и способах их решения.

У нас есть небольшой демо-проект - hba-demo-todo-app, доступный для всех желающих. Это минимальная конфигурация, далекая от реальных проектов, но для демонстрации кода я буду использовать именно ее.

SOLID-ная статья о принципах SOLID, которую вы можете предложить тем, кто хочет понять эти принципы в контексте языка Go. Или прочитать самостоятельно, если это интересно и вам.

И да, как сказал бы волк из небезызвестного мультика: «SOLID? Шо, опять?»

Асинхронная обработка событий – один из базовых инструментов на сегодняшний день, позволяющий создавать масштабируемые и отзывчивые приложения. Сегодня мы рассмотрим два инструмента из Spring Framework – Spring Events и Spring AMQP, которые помогают управлять асинхронными задачами.

Всем привет, меня зовут Андрей, я — php-разработчик в wpp.digital.

Сегодня я поделюсь с вами историей. Она о том, как поверхностное понимание (или непонимание) паттернов проектирования отстрелило мне ногу. А еще поделюсь примером реализации простой истины: знание чего-то не равно умению это применять. Кстати, главным героем поэмы являюсь (неожиданная информация) я.

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

Теперь к задаче.

В новом переводе от команды Spring АйО, Siva Katamreddy, девелопер адвокат в AtomicJar (Testcontainers), поделился своими мыслями о популярных в наши дни TDD, Clean, Hexagonal, Onion и Ports & Adapters. Он также постарался ответить на вопрос, который, возможно, волнует не только его: "Действительно ли мы, разработчики, так любим всё усложнять?".

Привет, Хабр!

Ansible — это инструмент для автоматизации, который облегчает управление конфигурациями, развертывание приложений и оркестрацию сложных задач. Его главная сила заключается в простоте использования и высокой читаемости плейбуков, которые представляют собой сценарии автоматизации, написанные на YAML.

Плейбуки в Ansible — основной инструмент Ansible. Плейбук состоит из одного или нескольких игр (plays), каждая из которых, в свою очередь, содержит задачи (tasks). Эти задачи выполняются последовательно, что позволяет создавать сложные, но легко читаемые сценарии автоматизации.

В этой статье мы рассмотрим как работать с плейбуками в Ansible.

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

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

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

Как управляют лицензиями на софт в Группе MOEX и получают уверенность в том, что расходы на них эффективны?

Всем привет! Меня зовут Кирилл и я работаю фронтенд-разработчиком. Я расскажу о том, как мы перевели несколько тысяч файлов, написанных на JavaScript, с легаси кода, который использовал goog.module, на новые ES6-модули с помощью построения и преобразования абстрактного синтаксического дерева.

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

Привет, Хабр!

Сегодня поговорим о балансировке нагрузки по DNS с использованием инструмента — Consul. Сейчас в основном все приложения разбиваются на множество мелких сервисов, и поэтому часто нужно сделать так, чтобы трафик равномернно распределился и имел высокую доступность.

Consul — это open-source инструмент от HashiCorp, который обеспечивает сервис-дискавери, проверку состояния сервисов, балансировку нагрузки и глобально распределенное хранилище ключ-значение.

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

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

Всем привет! Это мой первый пост на Хабре, в котором я бы хотел поделиться процессов разработки своего сервиса для публикации препринтов ScienceArchive.

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

С исходниками проекта также можно ознакомиться на GitHub.

Я java-программист по профессии и алкоголик go-developer по зову души. И вот в один прекрасный день я подумал о том, что раз уж в Go есть пакет reflect, то должны быть и способы АОП, прямо как в java. Если вкратце, я захотел генерировать обертки для функций в рантайме, позволяя красиво оборачивать логи, мониторинги, трейсинги, и прочие довольно однотипные штуки, по аналогии с тем, как я проделывал это в java.

Если вам стало интересно, что у меня из этого вышло, добро пожаловать под кат!

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

Привет, Хабр!

Сегодня мы рассмотрим одну из основополагающих концепций SOLID-принципов — принцип единственной ответственности или сокращенно - SRP. Разберем, что такое SRP и как правильно его применять в Python.