Краткая шпаргалка с определениями принципов. Под катом плюсы/минусы SOLID, чтоб пройти собеседование на мидла\сеньора\архитектора, а в работе принять осознанное решение: «Применять ли здесь SOLID?»
Ошибки происходят в любом приложении. Говоря об ошибках, первым делом отметим, что все они делятся на два типа: ожидаемые ошибки, обусловленные бизнес-логикой, и неожиданные ошибки. Это различие очень важное, поскольку стратегии обработки ошибок первого и второго типа значительно отличаются.
Ожидаемые ошибки, связанные с бизнес-логикой — это «нормальная» часть эксплуатации системы. О таких ошибках в системе должно быть заранее известно пользователям, а вы должны быть способны эти ошибки исправлять, если они возникнут.
Пример ожидаемой ошибки, обусловленной бизнес-логикой — попытка получить объект из хранилища больших неструктурированных данных (blob storage) с последующей необходимостью обработать случай «объект не найден». Другой пример связан с регистрацией пользователя, когда клиент пытается взять себе логин, который уже занят. В принципе, это ожидаемая ситуация и, если она произойдёт, мы вернем пользователю качественное сообщение об ошибке.
Неожиданные ошибки — такие, которые можно себе представить, но просто их не ожидаешь в условиях нормальной эксплуатации системы. Теоретически, можно было бы попробовать смоделировать все возможные ошибки, но это титаническая работа, сама по себе не слишком полезная. Как правило, не существует способов качественно обрабатывать такие ошибки или как следует после них восстанавливаться.
Многие разработчики при обсуждении основ Clean Code называют одни и те же принципы — чаще всего упоминаются DRY, KISS и YAGNI. Эти концепции прочно закрепились в профессиональном сообществе и воспринимаются как обязательная часть хорошего кода.
Принцип RUG упоминается значительно реже. Чаще всего о нём узнают с опытом, а многие применяют его интуитивно, даже не подозревая, что для этого подхода существует отдельное название и формулировка.
Сегодня я хочу поговорить о принципе RUG и о том, какие рекомендации он даёт по написанию программного обеспечения.
RUG (Repeat Until Good) — это принцип, который говорит: можно повторять один и тот же код, пока это разумно.
На ранних этапах разработки важнее просто реализовать логику, исходя из текущих требований, чем пытаться сразу создать «идеальную» абстракцию. В этот момент задача — как можно быстрее получить рабочее решение, которое отражает текущие знания о системе. Но со временем, когда одна и та же логика начинает встречаться всё чаще, становится очевидно, что её удобнее и правильнее выделить в отдельную, чётко оформленную абстракцию, чтобы избежать дублирования и упростить дальнейшую поддержку.
Мы используем этот принцип каждый раз, когда пишем код. Ведь практически любую логику можно сделать более абстрактной и масштабируемой — вопрос лишь в том, когда наступает подходящий момент для этого.
Я буду использовать TypeScript, так как этот язык знаком большинству разработчиков. 😁
Вроде бы всем известно что инкапсуляция это полезная штука, но мало кто знает что в практических задачах она никогда не является целью. Да, она является признаком удачного решения, когда ее можно обнаружить идентифицировать в связанных фрагментах кода, или же ее отсутствие будет кричать о дырявости реализованной концепции. Но нельзя ставить себе целью инкапсуляцию — это абстрактное понятие обычно (практически всегда) трансформируется в фантомную цель которая уведет вас в сторону от решения вашей практической задачи.
На идею этой статьи меня натолкнула следующее цитата брошенная в запале дискуссии:
Вы часто видели, чтобы в тредах об ООП на «инкапсуляция помогает скрывать данные и реализацию» кто-то всерьёз отвечал «нет! компилятор можно пропатчить, чтобы он игнорировал private!
Вы тоже думаете что инкапсуляция это всегда про использование модификаторов private, public, protected ? Или каких-то других модификаторов? А чистый Си поддерживает инкапсуляцию? Но это все более менее известные вопросы, я предлагаю вам познакомиться (или вспомнить?) концепцию абсолютной инкапсуляции, которая не обходится только модификаторами, а обеспечивается чуть ли не инфраструктурой операционной системы. Естественно начнем с формулировки практической задачи в которой нам пригодится эта абсолютная инкапсуляция.
Эта статья продолжает тему о способах разделения больших проектов на части.
Привет! Сегодня поделюсь самыми «эффективными» способами разруливать рабочие конфликты, которые встречались на моём опыте. Гарантирую – после применения этих советов ты точно запомнишься всем в офисе. Правда, не факт, что в хорошем смысле…
Если вспомнить, что мы проходили в архитектуре за последние десятилетия, вырисовывается любопытная картина. Сначала были монолиты и мэйнфреймы, затем — двух- и трехзвенные архитектуры. Не так давно все активно занимались распиливанием монолита на микросервисы, массово внедряли CQRS. Казалось, нащупан стабильный путь развития. Но что дальше? Как раз об этом сегодняшняя публикация. Мы подготовили ее на основе доклада на True Tech Day от Олега Ивлева — директора по развитию технологий, и Марина Путниковича — руководителя центра практик «Архитектура» в МТС Web Services. Надеемся, получилось интересно!
Если вы никогда не интересовались паттернами DDD или это было давно и неправда, эта статья, к сожалению, мало чем сможет вам помочь. Если вы никогда не читали Вернона – я настоятельно рекомендую это сделать, его объяснения прекрасны, подробны и системны.
Если же вы знакомы с трудами классиков, но сочли их оторванными от жизни, либо были когда-то ими воодушевлены, попробовали воплотить их идеи на практике, но столкнулись с проблемами и разочаровались, то, возможно, я смогу вам помочь. Не потому что я – лучший в мире архитектор, программист или технический писатель, а потому, что я применяю Domain Driven Design на практике и советы, которыми я хочу поделиться, это не «ещё один пересказ Эванса», а отражение того, как это действительно может работать (как минимум в моей практике) в реальных проектах.
Почему зрелый проект начинается не с кода, а с инфраструктуры? Рассказываю, как простая автоматизация, тесты и документация экономят время, нервы и спасают от хаоса, особенно если вы пишете код с помощью ИИ.
За 20+ лет в разработке я прошёл путь от студента с книгой по C++ до техлида, но понял: управление людьми приносит меньше удовольствия, чем написание кода. Карьерный рост — это не всегда движение вверх по иерархии, иногда стоит выбрать то, что действительно нравится, а в IT можно хорошо зарабатывать просто программируя.
Привет, Хабр! Меня зовут Михаил Полукаров, я занимаюсь разработкой Desktop-версии корпоративного супераппа для совместной работы VK Teams.
Если вы тоже работали с большими проектами, где активно применяются объектно-ориентированные паттерны проектирования, то наверняка сталкивались с паттернами проектирования Factory Method или AbstractFactory. В процессе разработки я неоднократно ловил себя на мысли, что часто пишу однотипный код таких фабрик, и задумался о том, как можно было бы избежать таких самоповторений.
В этой статье я покажу, как сделать универсальную фабрику объектов, покрывающую большую часть потребностей, следующую принципам DRY (Don’t Repeat Yourself), а также как можно использовать некоторые «фишки» новых стандартов С++.
В мире разработки программного обеспечения управление состоянием объекта - одна из фундаментальных задач. Когда поведение объекта должно меняться в зависимости от его внутреннего состояния, разработчики часто обращаются к паттерну State. Однако здесь и возникает путаница: его нередко отождествляют с более общей концепцией — State Machine (Конечный автомат), а то и вовсе не видят разницы.
Погрузимся в мир управления состояниями — от простого к сложному!
Помню, когда я был джуном и даже миддлом, меня очень волновал вопрос: как же должна выглядеть структура приложения по умным книжкам и всяким бест‑практисам. На тот момент я уже повидал разные варианты архитектур, и все они выглядели корявыми, нелогичными, возникшими спонтанно из чьих‑то костылей.
Лет пять назад я обнаружил для себя Чистую архитектуру Дяди Боба и на некоторое время успокоился, пока поток новых источников постепенно не начал менять мое отношение и к этой книге. Но, если вы решили для себя, что Чистая архитектура — это ваш окончательный выбор, то я точно не буду вас отговаривать, потому что, на мой взгляд, это однозначно лучше, чем, наверное, 90% того, что вам встретится на рынке.
Впрочем, эта статья для тех, кому этого не достаточно: для тех, кто хочет глубже понимать эволюцию мысли в области дизайна приложений, основные вызовы и идеи.
Раньше мы в 3 частях [1, 2, 3] пробежались по основным идеям архитектуры систем. Поэтому, если вы ищете информацию по System Design, микросервисам и топологии команд, то вам туда. Эта же статья про архитектуру внутри кодовой базы: она посвящена концепциям программирования, влияющим на структуру приложения, поэтому описывает не только архитектурные подходы, но и иные идеи, оставляющие на дизайне свой отпечаток.
Для эффективной организации производства Информационных систем (ИС) требования должны стать каркасом, связывающим все этапы жизненного цикла ИТ‑продукта и передаваться от одной фазы к следующей, обеспечивая непрерывность и согласованность всего проекта. Так при реализации разработчики наделяют продукт функциональностью в соответствии с утвержденными требованиями. А тестировщики на основе спецификации требований разрабатывают план тестирования: к каждому функциональному требованию привязывают сценарии, тест‑кейсы и подтверждают, что готовое решение удовлетворяет требованиям, и так далее по цепочке.
Поэтому, когда спецификации требований разработаны и производство готово к переводу на этап реализации целевого продукта, крайне важно обеспечить надлежащий процесс приема/передачи инициативы команде разработки. Проектировщики не могут просто кинуть требования на стол разработчикам и считать свою часть работы выполненной. Процесс передачи должен быть регламентирован и по возможности соблюдаться.
Процедура передачи может регулироваться, например, управленческими правилами делегирования, а именно:
Большие языковые модели (LLM) становятся неотъемлемой частью инструментов генерации, анализа и автоматизации программирования. Их возможности позволяют автоматизировать разработку, искать ошибки, генерировать тесты, осуществлять перевод между языками программирования. Однако одно из ключевых ограничений — контекстное окно, то есть максимально возможная длина входных данных. С ростом объема современных программ эффективность работы LLM с длинным кодом становится всё более актуальной задачей, особенно учитывая вычислительные и финансовые издержки обработки длинных последовательностей.
Минификация кода — процесс сокращения программного текста до минимального, необходимого для сохранения семантики. Для современных LLM это уже не только техническая задача (как раньше для web‑ресурсов), а способ оптимизации использования ресурсов, экономия токенов, увеличение объема анализируемого кода, ускорение анализа и генерации. В данной статье рассматривается современное состояние исследований по минификации в контексте LLM, формулируются гипотезы о её влиянии, а также обсуждаются перспективы для программной лингвистики.
Вы знаете из чего и как строятся программы? Странно что ни в одной из статей о программной архитектуре вы не найдете упоминаний о том из чего эти программы строятся.
Я попробую изложить свое понимание, понимание профессионала с более чем 20-ти летним опытом построения, рефакторинга программ. Возможно я в чем-то, а может и совсем, буду не прав и ошибаюсь, но тогда в комментариях, а может и в новых статьях мы увидим откровения знающих профессионалов, которые разобьют в пух и прах мои рассуждения, то есть в любом случае должно быть интересно. Но, мне кажется, кто-то должен рискнуть начать рассуждать на эту тему.
Теперь есть продолжение про абсолютную инкапсуляцию-изоляцию.
Довольно долго я тягался с по-настоящему глупой проблемой на C++: мне не нравятся функции-члены, но я вынужден их писать, чтобы программисту было хоть немного удобнее работать. Функции-члены обеспечивают две вещи: разграничение областей видимости и обнаружимость. Разграничение областей видимости — менее актуальная из этих задач, поскольку в моём коде на C++ я и так не использую модификаторы private/public. Обнаружимость — большая проблема: я могу написать x.F, а IDE предложит x.Func(). Отлично! «Но правильные программисты пользуются только vim и скромными IDE». Что ж, привет вам, воображаемые мифические обычные программеры. Здесь вам ничего не угрожает, но, пожалуйста, уходя — надевайте сразу два беджика: «vim отстой» и «Я ненавижу emacs». Отлично помогает завязать разговор с «настоящими» программистами.
Интернет завален реализациями на Питоне, но иногда удобнее разбираться с технологиями на своём основном языке. Для мен;я это Kotlin.
Если вы программист, наверняка к вам приходят знакомые и предлагают писать агентов. Реализовав оного самостоятельно, вы поймете, что задача из себя представляет.
Статья обещает соблюдать два принципа, упрощающих восприятие:
‣ Движение от частного к общему, потому что легче воспринимать примеры, чем абстракцию.
‣ Быстрая обратная связь, как с REPL.
Агента реализуем так, чтобы легко было заменить лежащую в основе LLM. Посмотрим, как отличается работа при использовании REST API в сравнении с SDK, пощупаем Гигачат и Anthropic.
Ах да, 🪐 KOSMOS — акроним. Kotlin Open Synthetic Mind Orbiting System.
Привет! Меня зовут Евгений. Я — Full-Stack QA Engineer в Devscribed и сегодня хочу поделиться своим экспериментом — QA Mentor Bot. Это Telegram‑бот, который отправляет в телеграмм группу случайные вопросы по тестированию и сразу же генерирует на них развёрнутые ответы с помощью AI. В этой статье я расскажу, как устроен проект и с какими «подводными камнями» столкнулся в процессе разработки.
Четыре года назад на собеседовании я услышал от интервьюера о том, как замечательно паттерн Спецификация помогает справиться с проблемой разрастания репозитория. Я думаю, многие с этим сталкивались, когда количество методов типа getByThisAndThat(…) улетает за десяток, а то и за несколько десятков, и репозиторием становится пользоваться неудобно.
Вдохновившись таким позитивным отзывом, я изучил первоисточник и начал экспериментировать с использованием спецификации как со средством упрощения репозитория.
В этой статье я дам обзор оригинального паттерна, поделюсь своим неоднозначным четырехлетним опытом его применения (с конкретными примерами кода, разумеется) и выскажу свое мнение как о самом паттерне, так и о применении его (на самом деле, его вырожденного варианта) в репозитории.
Добро пожаловать в четвёртую и заключительную часть серии о новом Flowable Async Executor. До этого момента путь был довольно насыщенным:
Однако остаётся один важный вопрос: как мы пришли к текущей реализации? Что подтолкнуло нас к этим изменениям и почему? Как мы нашли узкие места и использовали эти данные для создания лучшего подхода? И, учитывая, что первая версия появилась более десяти лет назад, как Async Executor эволюционировал, сохраняя обратную совместимость?
Именно этому посвящена эта часть. Мы воспользуемся возможностью оглянуться назад и вспомнить различные реализации, которые появлялись за это время. Мы выделили четыре поколения Async Executor и кратко рассмотрим каждое из них. Поскольку Flowable является форком Activiti, история начинается с первой версии Activiti (5.0.0).
