Архитектура Android-приложений. Как повысить качество архитектуры, не говоря об архитектуре

Салют, Хабр! Я Марк, Android-разработчик, работаю над мобильным приложением для управления умным домом Салют. Для мира Android-разработки вопросы архитектуры, её надёжности и качества актуальны, но… на самом деле не так уж интересны. Интересно, чтобы приложения были надёжными, устойчивыми к ошибкам, поддерживаемыми и легко масштабируемыми. Самый популярный подход — по-прежнему архитектурные паттерны (MV* паттерны) и разделение архитектуры по слоям. Что никак не избавляет от ошибок. При этом существует множество подходов, которые делают архитектуру надёжнее, а в перспективе исключают целый класс ошибок, как введение в Котлине Null Safety избавило от класса ошибок NPE. Это проектирование на основе состояний (state-oriented programming), логика Хоара, программирование по контракту Бертрана Мейера. Возможно, и более серьёзные — например, формальные методы верификации. Отмечу, что в целом это общие принципы computer science, независимые от платформы. Но мой фокус — Android-разработка клиент-серверных приложений. Сейчас хотел бы поговорить, как создание своей системы типов в проекте исключает популярный класс логических ошибок — semantic type error. Поехали!

https://habr.com/ru/companies/sberdevices/articles/1045987/

#доменная_система_типов #Kotlin #типы #design_by_contract #Android #архитектура_приложений

Новый LAMP, или почему ваш Agent Pipeline — это Apache в 2006 году

Все усложняют работу с AI-агентами. А что если хватит markdown + git? Без LangChain, без VectorDB, без оркестраторов. Рассказываю что реально работает.

https://habr.com/ru/articles/1028226/

#AI_agent #LLM #pipeline #prompt_engineering #Design_by_Contract #методология_разработки #LangChain #RAG #developer_tools

Design by Contract в эпоху AI: как контракты Мейера защищают криптографию там, где тесты молчат

Design by Contract Мейера не взлетел в 1986 из-за двойной работы. AI-агент убирает вторую половину. Я построил PKI-систему с аппаратным TRNG, формальными контрактами на криптографию и открытым репозиторием, чтобы это доказать.

https://habr.com/ru/articles/1025244/

#Design_by_Contract #PKI #криптография #AI #TRNG #NIST #embedded #контракты #безопасность

Заменяем лишние if-проверки на assert для инвариантов кода в C/C++

Многие разработчики привыкли везде ставить if-проверки, даже для условий, гарантированных кодом. Зачем проверять то, что не может нарушиться? Такие проверки создают шум в коде и мусор в релизе. Assert решает эту проблему: документирует допущения и исчезает из финальной сборки. В статье покажу все преимущества assert'ов и предостерегу от подводных камней их использования.

https://habr.com/ru/articles/962668/

#C++ #C #assert #инварианты #ifelse #NDEBUG #Design_by_Contract #код_как_документация

Design by Contract на минималках: пишем assertions и улучшаем устойчивость на Go

Всем привет! Меня зовут Александр Иванов, я старший разработчик в YADRO, работаю над созданием средств управления элементами опорной сети и пишу на Go. Мы с командой разрабатываем продукт для сервисов сотовой связи — качество нашей работы влияет на пользовательский опыт тысяч людей. Поэтому часто мы ищем решения, как повысить устойчивость работы кода в продакшене. Об одном из таких решений я расскажу в этой статье. Design by Contract — подход к проектированию ПО, в котором взаимодействие компонентов системы основано на контрактах. Контракты описывают ожидания вызываемой и вызывающей функции и улучшают производительность кода.

https://habr.com/ru/companies/yadro/articles/888374/

#dbc #design_by_contract #defensive_programming #assertion #assert #продакшен #производительность