Год назад возникла идея переписать весь Java-бекенд на Rust, который я уже несколько лет разрабатываю и поддерживаю. Я нашёл все аналоги библиотек и фреймворков из мира Java в экосистеме Rust:
Проектирование и рефакторинг *
Реорганизация кода
Организация кода это важно и легко на основе Layer Architecture
Всем привет! Думаю многие читали кучу книжек по поводу Hexagonal, Onion, Clean, Layer Architecture и у вас могли остаться спорные вопросы как в сложности понимания материала, так и в реализации данных подходов в ваших проектах. Сегодня я хочу затронуть тему “Организации кода” и показать насколько это важно и легко одновременно на примере Layer Architecture (Слоистая архитектура).
Статический анализатор подталкивает писать чистый код
Статические анализаторы помогают не только обнаруживать ошибки и дефекты безопасности, но и делать код чище. Выявляя лишние проверки, дублирующие действия и другие аномалии, можно сделать код проще, красивее и легче для чтения. Разберём это на практическом примере рефакторинга функции.
Декомпозиция программных компонент
Здравствуйте, меня зовут Дмитрий Карловский и я.. люблю власть. Когда я берусь за клавиатуру, каждый байтик начинает плясать под мою дудку. Но когда этих байтиков становится по настоящему много, уследить за всеми становится сложно. Поэтому давайте сравним популярные паттерны проектирования, позволяющие разделить большое приложение на компоненты, чтобы властвовать над ними максимально эффективно и независимо.
Так как одна и та же прикладная сущность встречается в приложении во многих местах, в разных контекстах, и должна иметь разное представление, то базовая декомпозиция заключается в выделении модели предметной области, которая является источником истины для всех мест её отображения.
Истории
Shiva — Open Source проект на Rust для парсинга и генерации документов любого типа
Идея проекта возникла у меня во время работы над проектом поисковика документов. Существует такая библиотека, как Apache Tika, написанная на Java, которая умеет парсить документы различных типов. Чтобы мой поисковик работал, он должен уметь извлекать текст из документов разных типов (PDF, DOC, XLS, HTML, XML, JSON и т. д.). Сам поисковик я писал на Rust. Но, к сожалению, в мире Rust нет библиотеки, которая умела бы парсить документы всех типов.
Rust — это не «memory safe C»
TL;DR:
— в Rust намного больше достоинств, чем просто скорость и безопасность
— в Rust по умолчанию CDD (compiler-driven development, разработка через компилирование). Это как TDD, только CDD
— Rust — не сложный язык, особенно если не гнаться за максимальной производительностью
В этой статье я бы хотел рассказать:
— почему взгляд на Rust как на "memory safe C" очень сильно сужает область его возможного применения
— почему я смотрю на Rust как на очень удобный в разработке язык высокого уровня, которому просто случайно повезло оказаться невероятно быстрым
— почему разработка на Rust быстрее, чем многие думают
— почему Rust — это один из лучших языков общего назначения
Best Practices по подключению к сторонним API в проекте
При разработке больших web-проектов нам часто приходится взаимодействовать с API сторонних или внутренних микросервисов. Когда количество таких взаимодействий растёт, настройки вызовов к другому API и подробности самих вызовов кратно множатся и могут растекаться по проекту.
В Домклике у нас микросервисная архитектура, и каждому сервису приходится взаимодействовать с десятком других. Чтобы межсервисное взаимодействие было предсказуемым, надёжным, удобным и отслеживаемым, мы следуем ряду практик при разработке, и в этой статье я расскажу вам о них.
Делаем код-ревью правильно
В начале своей карьеры я как-то работал над одним заказом, создавая платформу сентимент-анализа для социальных сетей. В то время Twitter ещё был Twitter’ом. Наша команда состояла из семи человек, среди которых я был джуниором. Мы были молоды и полны энтузиазма. Наш девиз можно было описать как: «Мы гибкие, быстрые и всё ломаем!». Да, мы действительно гордились своей скоростью. Код-ревью? Я вас умоляю. Мы считали эту практику бюрократическим пережитком корпоративного мира.
И что вы думаете? Через несколько месяцев наша база кода стала подобна минному полю. Причём баги нас волновали меньше всего, хотя их была уйма. Реальная проблема заключалась в том, что никто не мог понять код, написанный другими. У нас во многих местах дублировалась логика, и в модулях использовались разные стили кода. Всё было очень печально.
Тогда до нас дошло! Нужно взять всё под контроль. Код-ревью реально помогают сохранять код читаемым, обслуживаемым и масштабируемым.
Итак, в двух словах: если вы не проводите код-ревью, или делаете их «для галочки», то обрекаете себя на боль, пусть не сразу, но в конечном итоге однозначно. Это можно сравнить с возведением дома на фундаменте из песка. Какое-то время он, может, и простоит, но явно недолго. А в мире стартапов второго шанса у вас может уже не быть.
Проектируем микросервисы с Reactive Manifesto: 4 принципа распределенных систем
Работаете с распределенными системами или только пытаетесь к ним подобраться? Проектировать такие системы с нуля бывает сложно и страшно: чтобы учесть все нюансы, нужен определенный багаж знаний.
На помощь приходит Reactive Manifesto — документ, который обобщил опыт целого ряда компаний по созданию распределенных систем. Манифест формулирует главные принципы, на которые стоит опираться на этапе проектирования и эксплуатации таких систем.
Меня зовут Андрей Василевский, я системный архитектор в Lamoda Tech. В этой статье я на примерах из своей работы покажу, как применять Reactive Manifesto на практике. Статья будет полезна тем, кто только начал изучать распределенные системы, хочет закрепить теорию или тем, кто хочет структурировать проектирование микросервисов в своей компании.
Dart 3.1 и ретроспектива программирования в функциональном стиле в Dart 3
Сопоставление шаблонов (pattern matching) и исчерпывающие переключатели (exhaustive switches) объединяются для создания функциональных моделей данных, которые легко сочетаются с объектно-ориентированным ядром Dart. ?
Насмотренность в разработке: путь к чистому и качественному коду
В мире разработки программного обеспечения термин «Насмотренность» крайне редко встречается, в то время как дизайнеры постоянно всё насматривают 😅. Однако понятие насмотренности не менее важно для разработчиков, поскольку оно помогает понять, зачем и как нужно создавать красивый и чистый код.
Если вы только начинающий разработчик, вам будет полезно узнать как прокачивать насмотренность и что она дает.
4 вида распространённых ошибок в Event-Driven системах
В последние несколько лет в крупных компаниях наблюдается значительный рост внедрения event-driven (событийно-ориентированных) систем. Каковы основные причины этой тенденции? Это чистой воды хайп или есть веские причины, побуждающие к внедрению этой архитектуры? С нашей точки зрения, основными причинами, по которым многие компании выбирают этот путь, являются:
Ближайшие события
Сколько точек зрения у Архитектора в ИТ?
Судя по обилию статей «Кто такой архитектор в ИТ?» — нет общего понимания, чем он занимается, должен ли он вырасти из программиста или его можно сделать из системного аналитика. На самом деле ключевым качеством, которое сразу выделяет его среди остальных в ИТ, является способность смотреть на задачу с разных точек зрения. В статье приводится простой практический архитектурный кейс для очень известной системы, и выводы будут однозначные.
Анемичная модель предметной области и логика в сервисах
Анемичная модель предметной области (Anemic domain model) это такая модель, где сущности содержат только свойства, а бизнес-логика находится в сервисах. Ее противоположность это богатая модель предметной области (Rich domain model), где логика находится в сущностях, а cервиcы рекомендуют писать только в редких случаях.
В этой статье я хочу показать, почему логика в сервисах является более правильным подходом. Мы рассмотрим пример бизнес-требований и их реализацию с Anemic domain model.
Proof of Work и Proof of Stake для чайников
Привет, Хабр!
На старте блокчейн-технологий стояла задача создания системы, которая могла бы функционировать надежно и без централизованного контроля. Здесь помогают консенсусные алгоритмы. Консенсус в блокчейне — это согласие всех участников сети относительно ее текущего состояния, т.е это механизм, который позволяет децентрализованным сетям достигать общего согласия о том, какие транзакции считаются действительными и добавляются в блокчейн.
Для достижения консенсуса в блокчейне существуют механизмы Proof of Stake и Proof of Stake. Рассмотрим их в этой статье.
Пиррова победа Domain-Driven Design
TL;DR: DDD неизбежно ведёт к избыточному (на порядки больше минимально необходимого) количеству саг в проекте, которые, в свою очередь, неизбежно ведут к нарушению целостности данных в БД.
DDD вполне успешно решает поставленную задачу: дать разработчикам инструменты, которые позволят им справиться (корректно реализовать и поддерживать) со сложной предметной областью. Но эта победа оказалась пирровой: инструменты, обеспечивающие корректность данных в памяти, оказались неспособны гарантировать корректность данных в БД. А что толку от изначально корректных данных в памяти, если со временем (после их сохранения в БД и последующего чтения) они перестают быть корректными? По сути, у DDD есть фатальный недостаток: DDD неизбежно приводит к нарушению целостности данных (инварианта бизнес-логики) в БД.
Покрытие архитектуры as Code тестами
💬 На самом деле, моя идея написания тестов на архитектуру настолько проста, легко реализуема и при этом полезна, что я до сих пор толком не понимаю, почему я не встречал материалов на эту тему, и сама тема всё ещё не используется повсеместно 🙂
Статья написана по следам моих докладов на трёх крупных ИТ-конференциях, на каждой из которых ко мне подходили архитекторы и разработчики российских бигтехов, говорили, что я очень точно попал в их боли и предложил суперпрактику, которую они теперь будут внедрять. На всех трёх конференциях я получил высшие оценки от аудитории, а на двух из них доклад был признан лучшим в своей секции. В конце статьи приведена ссылка на видео доклада с одной из конференций.
В статье я поделюсь своей идеей и OpenSource-реализацией решения для написания тестов, разберу примеры тестов на небольшой учебной микросервисной архитектуре, а также расскажу про личный опыт и профит от применения этой практики.
Для разработчиков монолита тоже есть небольшой бонус: в OpenSource-репозитории появилась реализация и примеры тестов на архитектуру модульного монолита.
Мы пилили монолит — много нас, а он один. Полезные советы от команды Яндекс Еды
Про микросервисную архитектуру и переход на неё написаны сотни статей, однако почти все они больше теоретические и описывают ситуацию лишь верхнеуровнево. Редко где прочтёшь про то, как люди бесшовно вынесли высоконагруженный кусок монолита в отдельный сервис без даунтайма и факапов или даже с ними. Интересно узнать, какими же инструментами они пользовались, как подготавливались, каких подходов придерживались и какие выводы на будущее сделали. Всё это — полезный опыт, который может помочь избежать проблем. Вот я и подумал, что стоит им поделиться.
Вклад авторов
SergeyT 594.4m1rko 517.6AloneCoder 504.8alizar 491.7marshinov 412.8fillpackart 349.0tangro 309.0badcasedaily1 279.0ph_piter 276.2dartmessiah 233.0