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

​​В ряде случаев приложение, написанное на языке Objective-C, для улучшения функционирования и расширения его возможностей, приходится переписывать на Swift. Осуществление перевода на язык Swift сразу всего кода не всегда рационально, гораздо разумным представляется переписывание  класса за классом. При этом сборка становится гибридной и соответственно необходимо делать так, чтобы все объявления были видимы в коде на обоих языках. 

Ввиду того, что крупные проекты содержат множество файлов понять как последние связаны друг с другом может быть затруднительным. В этой связи прежде чем приступить к переводу логичным явилось бы создание скриптов, которые позволят визуализировать зависимости между файлами Objective-C и сделать анализ проекта более удобным и понятным. 

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

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

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

100% sound null safety. Records, patterns, and class modifiers. And a peek into the future.

Привет с Google I/O 2023. Сегодня в прямом эфире из Mountain View мы анонсируем Dart 3 — крупнейший релиз Dart на сегодняшний день! Dart 3 содержит три мажорных улучшения. Во-первых, мы завершили путь к 100-процентной null-безопасности. Во-вторых, мы добавили новые языковые возможности: записи (records), паттерны (patterns) и модификаторы классов (class modifiers). В-третьих, мы даем предварительный прогноз на будущее, в котором расширим поддержку наших платформ, добавив нативный код для web с помощью Wasm-компиляции. Давайте углубимся в детали.

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

Необходимость шаблона сверх https://start.spring.io вызвана следующими типами доработок:

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

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

Спроектировать и построить приложение не так-то просто. Как правило, всё упирается в продуманную архитектуру, которая должна быть масштабируемой и легко поддерживаемой. Данный материал предлагает вполне элегантный способ, в некотором роде основанный на чистой архитектуре (Clean Architecture).

Рассмотрены:

• взаимодействия слоёв

• структура папок

• основные характеристики каждого уровня

Предлагаю определить сильные и слабые стороны данного предложения.

Обновления в реальном времени, feature flagging и A/B тестирование – что, если я скажу вам, что вы можете включить эти мощные функции в своё приложение Flutter с минимальными усилиями по разработке и без каких-либо затрат? В этой статье я расскажу о нескольких реальных случаях использования, когда Firebase Remote Config может помочь вам при создании приложений Flutter.

Если вы предпочитаете видеоконтент, посмотрите видеоверсию этой статьи на YouTube (EN).

В своём прошлом посте я рассказал теорию своего подхода к декомпозиции систем на модули. Теперь пришло время проверить её на практике.

Кэмп - реальный проект, который стоил семизначную сумму для заказчика, выполнялся командой из 12 человек (включая двух бакэндеров) и сейчас запущен в промышленную эксплуатацию. Суммарно на выполнение проекта было затрачено 5500 человеко/часов, из которых 950 - на бакенд.

Привет, Хабр! Зачем нужна архитектура и какие цели она должна выполнять?

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

Привет Хабр

Всегда интересовался программной архитектурой. Читал много статей и примеров. Подходов много, и лучшего конечно же нету.

Данная статья будет показывает мой взгляд на проектирование архитектуры в Unity в компонентно-ориентированном подходе (КОП). Кода в статье не будет!

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

В Dart 3.0.0 появилось много новых вещей. Об одной из таких – модификаторы классов – мы сегодня и поговорим.

Спойлер: 5 новых модификаторов + их комбинации: Base, Interface, Final, Sealed и Mixin.

На этой неделе мы выпустили Squadus — единое цифровое рабочее пространство, которое позволяет компаниям удобно и гибко структурировать коммуникации. На создание этого on-premise решения ушло порядка трех лет; для ускорения разработки Squadus мы скомбинировали наши технологии и компоненты СПО.

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

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

Использование библиотеки MediatR при реализации бизнес‑логики в проектах, реализуемых на базе.NET

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

Именно так я решил назвать эту статью, чтобы описать свои эмоции на прожаривании кода спонтанном публичном код-ревью моего open-source Portal от участников Go-чата, в котором я активно участвую. Главным ревьюером был Глеб Яльчик, что делало ситуацию ещё более волнительной для меня. Расскажу, как я на это решился, что мы обсудили, к чему пришли и какой эффект это дало. А внедрять Portal мы будем на примере мини-приложения по мотивам (всеми любимой) мобы Dota.

Примечание: это приложение будет что-то делать только в учебных целях, чтобы понять, как Portal сможет нам помочь передавать данные. Логика в нём будет достаточно простой, без ряда проверок и, возможно, с багами. Если станет достаточно интересно, то можем обсудить и его в комментариях!

Всем привет! Один из проектов на работе у нас изначально создан на create-react-app утилите. Встал вопрос по поводу того, можно ли как-то оптимизировать сборку по скорости и весу сжатого проекта, так как есть большие планы на рост проекта и не хотелось бы, чтобы что-то начало тормозить, и этим соответственно я и занялся. Хочу рассказать о том, как все проходило, какие шаги были пройдены и что в итоге получилось. Также в конце приложу код всей конфигурации.

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

По традиции, для самых жаждущих и нетерпеливых, эта статья будет о:

• С чего начинается построение любой архитектуры?

• За счет чего реализуются потенциальные бизнес возможности?

• Кто нужен для реализации намеченных возможностей?

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

• Из чего должна складываться структура продукта и как он должен реализовывать функциональные требования?

Если нет интереса к предисловию, то переходите к первому "почему". Для тех, кто хочет сложить причинно-следственные связи - добро пожаловать.

Всем привет!

Меня зовут Михаил Копченин, я backend-разработчик сервиса биллинга #CloudMTS.

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

На эксперименты с ЧА нас сподвиг модуль биллинга, который разросся до пухлого монолита. Так бывает, когда в mvp хочется быстрее добавлять новые фичи, а вопросы оптимальности архитектуры откладываются на потом.

Существует замечательная теория, что все проблемы с хранением пользовательских данных в базах — это последствие отсутствия единых идентификаторов. Дескать, номер паспорта может меняться, ФИО может дублироваться у нескольких пользователей, а «внутренние» идентификационные номера в различных ведомствах могут не совпадать.

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

Так оно или нет? Можно спорить, можно смотреть на опыт внедривших стран. Я же постараюсь описать типовые ошибки при проектировании и разработке систем, хранящих Единый Идентификатор.