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

Вам сказали развернуть систему мониторинга, вы выбрали связку Prometheus + Grafana. Развернули Grafana на своих серверах (VM/Docker/Kubernetes) и подключили Data Source Prometheus (а возможно вам еще сказали развернуть логирование и вы используете Grafana Loki) и далее по гайдам из ютуба начали создавать свои дашборды и настраивать алерты.

Все работает идеально, но в один момент вы начинаете думать о том, чтобы хранить созданные сущности Grafana в коде, чтобы их можно было легко восстановить в случае потери данных или же развернуть при создании новой среды (dev/prod). Экспортировать дашборды не составит труда, это можно сделать и через GUI, но как же источники данных, политики уведомлении, contact points и сами алерты?

Знакомая история? Возможно, что нет. А у меня да!

Абстрактный тип данных. 

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

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

А в конце интересный опрос про использование статических анализаторов.

Привет, Хабр! Представьте: вы – член большой команды среди десятка таких же команд на крупном и зрелом проекте. Казалось бы, все процессы уже выстроены, все масштабные разработки завершены и теперь остается только с наслаждением разрабатывать и дополнять проект новыми интересными фичами.

Гармония и красота.

Но откуда ни возьмись, появляется она – недоработанная масштабная функциональность, словно щупальцами оплетающая все базовые процессы сразу. Как монстр, затаившийся в пещере, она не давала покоя бизнесу вот уже 3 года, и успела  «сожрать» несколько команд разработки. И вот бизнес снова объявил охоту на монстра… а вы оказались в этом отряде самоубийц героев, призванных положить конец бесчинствам чудовища. 

Цели озвучены, задачи поставлены, команда в ужасе собрана. Но вот незадача, поле для сражений одно: либо ваша команда будет монстра рубить, либо остальные команды – семена сажать. И что же делать?

Как и множество больших сервисов, Яндекс Еда основана на микросервисной архитектуре. В общей сложности у нас чуть больше 200 микросервисов. Но есть один сервис, который совсем не микро – легаси-монолит.

Он написан на PHP 7.2 разработчиками разного уровня и в разное время. Мы подумали, что так больше нельзя, и решили навести порядок. В ходе разбирательств выяснилось, что версия языка, на котором всё написано, устарела и уже не поддерживается, что ведёт к рискам безопасности. Делать нечего — мы приняли решение обновиться до 8-й версии.

В этой статье я расскажу, чего стоило нам проапгрейдить монолит, сколько тестов мы сломали и как в этом проекте поучаствовали почти все PHP-разработчики Яндекс Еды. Это интересный и уникальный опыт, которым я хотел бы с вами поделиться. В конце дам несколько советов тем, кто тоже захочет ввязаться в подобную авантюру.

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

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

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

Вопрос подготовки релизов и внесения новых изменений стоит перед любыми командами. Но чем масштабнее сфера применения каждого конкретного решения, тем важнее не допустить downtime, связанного с ошибками в новом функционале. В этом посте я расскажу о том, почему нам в Леруа Мерлен потребовалось развивать новый механизм работы с обновлениями, из-за чего не подошел ни один из популярных инструментов и что мы стали делать в итоге. Также мы обсудим различные подходы к организации функций Feature Toggle. Если вы тоже интересуетесь этой темой, приглашаю под кат!

Вам когда-нибудь говорили, что вы пишете плохой код? 

Здесь стыдиться нечего. Мы все пишем несовершенный код, когда только учимся. Хорошая новость в том, что улучшить его — довольно просто, главное — желание. 

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

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

Основной целью DTO является упрощение коммуникации между слоями приложения, особенно при передаче данных через различные граничные интерфейсы, такие как веб-сервисы, REST API, брокеры сообщений или другие механизмы удаленного взаимодействия. На пути к обмену информацией с другими системами, важно минимизировать лишние расходы, такие как избыточное сериализация/десериализация, а также обеспечить четкую структуру данных, представляющую определенный контракт между отправителем и получателем.

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

Из основной функциональности хочу выделить валидацию типов и данных, создание объекта и выгрузку в словарь.

 Мне давно хотелось узнать существуют ли программисты, которые понимают «делегирование» в рамках ООП так же, как я.  А когда я случайно обнаружил что в Шаблонах проектирования (Design Patterns) в фундаментальных трудах признанных классиков концепций программирования пропущено описание для Делегирования, у меня появился повод написать эту статью.

Так получилось, что я сначала познакомился с этой техникой на практике разрабатывая DirectShow фильтры и COM-объекты, которые составляют эти фильтры и меня особо не интересовало как все это по-умному называется пока это все прекрасно работает. Проблемы возникают, когда ты пытаешься объяснить кому-то КАК это работает, или когда ты пытаешься предложить кому-то хотя бы попробовать использовать определенную технику программирования. Вот именно при таких попытках у меня получилось сопоставить что то, что я использую очень подходит под определение Design Pattern: Delegation.

Давайте посмотрим будет это поводом посмеяться или задуматься.

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

Кто дочитает до конца найдет ответ на вопрос который задает название.

Если вы всерьёз заинтересовались созданием ИИ-бота, то вам пригодится набор инструментов для его разработки. Чтобы помочь определиться с правильным решением, Екатерина Саяпина, Product Owner личного кабинета платформы МТС Exolve, сделала небольшой обзор наиболее популярных ИИ-фреймворков.

В статье также пойдёт речь о решениях с функциями распознавания речи. Мы включили в подборку наиболее известные продукты, но если захотите углубиться именно в голосовые технологии, то изучите проекты с 5 тыс. звёзд на GitHub, среди которых DeepSpeech, Leon, Wav2letter и Annyang. Также рекомендуем обратить внимание на Voice API и подобные платформы для гибкой настройки всей цепочки коммуникаций.

Лучший способ понять теорию — получить больше опыта в разных проектах. Для системных и бизнес‑аналитиков я постоянно показываю подходы к работе через публикацию разборов задач: БД, API, Интеграции, требования, и все, что связано с проектированием систем.

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

Данная статья - моя попытка разобраться и объяснить архитектурный паттерн MVP with Router.

Про сам паттерн MVP в на просторах интернета можно найти довольно много информации, например по следующей ссылкам:

Архитектурные паттерны в iOS

Архитектурные паттерны в iOS: страх и ненависть в диаграммах. MV(X)

А вот про разновидность данного паттерна, которая решает проблему сборки, возникающую при использовании MVP информации не так уж и много. Давайте попробуем разобраться что такое Router применительно к паттерну MVP, зачем он нужен и как его использовать.

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

Самая сложная часть всего этого процесса оказалась не там, где мы предполагали изначально. Отсюда и идея для этой статьи – подсветить частный опыт, который, возможно, натолкнёт вас на какие-нибудь полезные идеи. В общем, тут не каузация, не агитация, а история одного рефакторинга. Давайте обо всём по порядку.

Давайте начнем с тривиального, но неоспоримого факта: программное обеспечение постоянно развивается – устаревает и обновляется, видоизменяется и дает дорогу новому.

Заметным исключением является наборная система TeX, разработанная Дональдом Э. Кнутом (D.E.Knuth). Предполагалось, что эта система должна быть совершенной, но даже в ней можно найти свои недочеты. Тем не менее, это уже отдельная тема для другой статьи.

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