Практика реализации Референсной архитектуры SDLC в Телекоме
Практический опыт применения Референсной архитектуры в крупном swap-проекте для мобильного оператора связи.
Практический опыт применения Референсной архитектуры в крупном swap-проекте для мобильного оператора связи.
Не так давно Ситимобил стал активно развивать не только клиентское, но и водительское приложение, значительно расширив для этого штат разработчиков, тестировщиков, дизайнеров и других специалистов. Помимо повышения качества кодовой базы, избавления от багов, разработки новых фич и разного рода улучшений технической части, важным направлением развития было улучшение визуальной составляющей приложения. Ежедневно им пользуется огромное количество водителей, и для них, как и для клиентов такси, важно, чтобы инструмент, позволяющий ежедневно зарабатывать, был удобен и приятен на вид.
До определенного момента у нас получалось итеративно развивать и улучшать внешний вид отдельных фич, однако целостности в масштабах всего приложения это не имело, так как основная часть выглядела сильно устаревшей, а её навигация не соответствовала идеям команды дизайна. В общем, продуктовые команды за это не брались: нет времени, нужно продукт развивать и фичи пилить. А команда инфраструктуры уже занималась не менее важными делами.
Вот какие изменения должны были произойти.
В данной статье мы рассмотрим ключевые вопросы касательно проектирования классов на языке Swift и их особенности. Посмотрим как это сделать правильно, как не допускать ошибки, избежать проблем и как правильно управлять зависимостями между объектами.
Соблюдать принципы чистой архитектуры – значит обеспечить удобство тестирования, поддержки и модернизации приложения. Понимание архитектуры и state management – это база, необходимая начинающему специалисту для успешной командной работы. В этой статье мы расскажем, как с помощью Cubit реализовать чистую архитектуру на примере стартового приложения Flutter – счетчика нажатий на кнопку.
Прим. перев.: автор этой статьи — engineering manager из Испании, работающий в цифровой торговой площадке Adevinta, представленной в 16 странах, — делится своими наблюдениями о частых проблемах, которые он встречал у создателей микросервисов. Об этих вызовах стоит знать заранее, чтобы не столкнуться с ними тогда, когда их решение может оказаться слишком затратным.
Когда пост Мартина Фаулера о микросервисах вышел в 2014 году, команды, в которых я работал, уже занимались SOA-приложениями. Эта статья и последующий хайп коснулись почти каждой команды разработчиков в мире. Стек Open Source-софта от Netflix был самым крутым в то время, поскольку позволял инженерам по всему миру перенимать опыт Netflix в распределенных системах. Если мы взглянем на работу разработчиков программного обеспечения сегодня, более шести лет спустя, большая её часть касается архитектуры микросервисов.
Если у вас есть свой бизнес или вы работаете в бизнес-подразделении более-менее крупной компании, особенно на руководящей позиции, вы, скорее всего, сталкивались с заказной разработкой программного обеспечения или столкнетесь с ней, когда захотите улучшить свои результаты. Под заказной разработкой я подразумеваю не только контрактные отношения с подрядной организацией, но ваших собственных штатных IT-шников.
Перед началом разработки, как водится, нужно составить план - ресурсы, сроки, деньги - все как у людей. Вы приходите на встречу с легким сердцем: задача небольшая, нужно всего-то добавить пару форм и отчет, а вы, хоть и не специалист, но понимаете, что это не может быть сложным. Но все меняется, когда разработчики называют сроки.
— Два месяца? На простейший функционал? Это неприемлемо! — вы пытаетесь давить, пугать, просить, торговаться; разработчики явно нервничают, но сроки не двигают. В итоге вы приходите к какому-то компромиссу, который не нравится никому, злые и недовольные.
Мы попробуем разобраться, почему так происходит и откуда берутся эти огромные сроки и оценки. К написанию этой статьи меня подтолкнул недавний кейс: наш диалог с заказчиком дошел, казалось, до абсурда. Причем — уверен — заказчик думал так же. В этой статье я разберу наш реальный кейс и на его примере станет понятно, что стоит за непониманием и конфликтами, с которыми сталкивалось большинство заказчиков. Эта статья — в первую очередь для тех, кто выступает в роли заказчика.
Эта статья является переводом материала «Domain model isolation».
Термин «изоляция модели предметной области» уже давно используется, но его значение может быть не таким очевидным, как многие думают. В этом посте автор оригинала попытается описать, что значит правильно изолировать модель предметной области и почему это важно.
Одно из самых больших изменений в C# 8 — это nullable reference types. Ранее Андрей Дятлов (JetBrains) рассказал на конференции DotNext о трудностях и проблемах, которые вы можете встретить при работе с ними. Доклад понравился зрителям, поэтому теперь для Хабра готова его текстовая версия.
Наиболее полезным пост будет для тех, кто планирует использовать nullable reference types в больших проектах, которые невозможно перевести на использование NRT и проаннотировать целиком за короткое время; проектах, в которых используются собственные решения для ассертов или исключений, либо методы со сложными контрактами, связывающими наличие null во входных и выходных значениях, так как эти методы придется аннотировать для корректной работы компилятора с ними.
Я оставляю ссылку на оригинальный доклад. Дальше повествование пойдет от лица Андрея Дятлова, а пока что последний момент от меня: мы уже вовсю готовим осенний DotNext, и до 16 августа включительно принимаем заявки на доклады, так что если вам тоже есть о чем поведать дотнетчикам, откликайтесь.
В этой статье я постарался подробно рассказать о том, как использовать диаграмму классов UML на практике. В качестве основного примера был взять мой проект "Построитель графиков функций". Помимо этого статья наполнена множеством маленьких примеров, поясняющих отдельные элементы диаграммы.
В интернете немало публикаций на тему реализации Dependency Injection (далее - DI) в React, также существует немало сторонних npm-пакетов, таких как inversify-react, react-simple-di и других. Но, по моему мнению, DI настолько просто реализуется средствами самого React, без дополнительных выкрутасов и boilerplate-кода, что никакая сторонняя библиотека во многих случаях попросту не нужна. В данной небольшой статье я постараюсь обосновать это свое мнение. Примеры кода будут приведены на TypeScript.
Прим. перев.: системный архитектор Avery Pennarun, создавший VPN-решение Tailscale на базе WireGuard, размышляет об отличиях монолитов с модулями от микросервисов. Он рассказывает об эволюции подхода к модульности вообще и о том, почему изоляция до сих пор далека от совершенства, а также делится своим мнением о том, когда проводить границы между сервисами рационально.
В последнее время меня часто спрашивают, в каких случаях переход на микросервисы — хорошая затея. В статье «Systems design explains the world» я размышляю о таких типичных проблемах, как эффект второй системы, дилемма инноваторов и других. Может ли проектирование систем дать ответ на вопрос о микросервисах? Да, хотя ответы могут вам не понравиться.
Привет, Хабр!
Меня зовут Иван Маслов, я работаю в Страховом Доме ВСК на должности руководителя направления RPA. Расскажу Вам об опыте использования роботов, и о том как упростить работу с legacy системами. Уверен, будет интересно всем: и тем, кто скептически относится к роботам, и тем, кто хочет побольше о них узнать. Подробности под катом.
Конечный Автомат (State Machine), также называемый Automata (да, как и игра), - это концепция для разработки, организации рабочих и технологических процессов с учетом текущего «состояния» какой-то задачи, изменения её состояний и, по возможности, для автоматизации процесса.
Я объясню на примере. Предположим, что я хочу купить молоко, тогда в такая задача будет иметь примерно следующие состояния...
Эта статья является переводом материала «Immutable architecture».
В этом посте автор оригинала хотел бы показать общий подход к внедрению иммутабельности в кодовую базу на архитектурном уровне.
Прежде всего, термин «Иммутабельность», применяемый к структуре данных, такой как класс, означает, что объекты этого класса не могут изменяться в течение их жизненного цикла. Существует несколько типов иммутабельности со своими нюансами, но это не являются для нас существенным. По большей части мы можем сказать, что класс является либо изменяемым, что означает, что его экземпляры могут изменяться тем или иным образом, либо иммутабельным (неизменяемым), что означает, что как только мы создадим экземпляр этого класса, мы не сможем изменить его позже.
Архитектура приложения — это его технологическая база, которая учитывает риски проекта, бюджет, требования и ограничения, потребности в масштабировании.
Помимо разработки архитектуры, на старте требуется приблизительно оценить объем и стоимость проекта. Для этого мы в своей практике используем одну из проверенных методологий создания архитектуры ПО — Attribute-Driven Design (ADD). При этом мы опираемся на атрибуты качества того или иного IT-продукта. На их основе мы на этапе оценки (пресейла) создаём архитектурную концепцию системы.
Рассмотрим этапы работы с архитектурной концепцией, возможные сложности и решения, исходя из опыта нашего Архитектурного комитета. Мы надеемся, что статья будет полезна архитекторам и разработчикам, желающим освоить методологию ADD, и может быть интересна смежным специалистам.
Мы в KTS делаем проект для Пятерочки – новый личный кабинет сотрудника. Продукт объединяет уже существующие сервисы и автоматизирует бизнес-процессы, которые раньше выполнялись вручную.
Над личным кабинетом работает много команд, поэтому нужен удобный механизм параллельной разработки модулей-микрофронтендов. Мы попробовали три способа встраивания: iframe, NPM-пакеты и Webpack Module Federation. В статье анализируем преимущества и недостатки каждого из них и рассказываем, почему переходили от одной технологии к другой.
Всем привет! В этой статье хочу поделиться опытом построения системы доменных событий (domain events) в нашем модульном монолите и микросервисах, рассказать о том, как мы гарантируем их доставку, следим за консистентностью в рамках транзакций, используя transactional outbox, чем доменные события отличаются от интеграционных и всё это в рамках multi tenant приложения. Подробнее под катом.
Прежде чем разбираться с реализацией серверного UI (SDUI) от Airbnb, важно понять, что это вообще такое и какие преимущества оно дает относительно традиционного клиентского UI.
Обычно данные обрабатываются серверной частью, а за работу интерфейса отвечает конкретный клиент (веб-браузер, приложения для iOS, Android). В качестве примера возьмем страницу Airbnb со списком предложений. Чтобы отобразить этот список пользователю, клиент может запросить данные у бэкенда, а затем преобразовать их в UI.
И здесь есть несколько трудностей. Во-первых, на каждом клиенте нужно реализовать специфичную для списка логику, обеспечивающую преобразование и отрисовку данных. Если по ходу развития проекта вносить изменения в то, как список отображается, эта логика быстро усложняется и становится негибкой.
Во-вторых, функциональность всех клиентов должна быть единообразной. Логика экрана со списком быстро усложняется, и при этом у каждого клиента есть свои тонкости и особенности реализации для обработки состояния, отображения UI и т. д. Поэтому клиенты по реализации начинают быстро расходиться друг с другом.
Наконец, у мобильных приложений возникают сложности с версиями: при добавлении новых функций на страницу со списком нужно выпускать новую версию приложения, и пока пользователи не обновятся, у нас мало возможностей определить, насколько удобны эти функции и насколько хорошо их приняли.
А что, если клиент даже не будет знать, что он отображает список предложений? Можно ли передавать клиенту напрямую UI, а не данные для построения интерфейса? Именно это и происходит в случае SDUI: мы передаем UI и данные вместе, а клиент отображает всё это независимо от того, что конкретно там внутри.