Clean Architecture (Чистая архитектура) (Рубрика #Architecture)

Я прочитал эту книгу Дяди Боба (Роберта С. Мартина) шесть-семь лет назад и нашел концепции достаточно интересными, а по самым интересным частям я даже сделал подробные разборы: "Дизайн и архитектура, парадигмы программирования" и "Принципы дизайна модулей и разделения по компонентам", но все это было до старта этого канала. Поэтому сегодня я решил исправить это недоразумение и рассказать об этой книге, в которой Дядя Боб подчеркивает важность разделения ответственности и независимость от фреймворков, баз данных и пользовательских интерфейсов. Дядя Боб это делает очень ультимативно, что сильно подрывает веру в его подход. Ключевыми идеями являются следующие
Правило зависимостей: зависимости исходного кода должны указывать только внутрь, в направлении высокоуровневых политик. Это создает систему, в которой бизнес-правила не зависят от технических деталей.
Слоеность архитектуры: при реализации этого правила у нас появляются отдельные слои
- Entities (cущности) - основные бизнес-объекты и корпоративные бизнес-правила
- Use cases (варианты использования) - бизнес-правила конкретного приложения. Тут забавно, что этот термин взят из UML, где так называется один из видов диаграмм, про которые я рассказывал раньше
- Interface adapters (адаптеры интерфейса) - контроллеры, презентеры и шлюзы
- Framework & drivers (фреймворки и драйверы) - внешние инструменты, базы данных, UI-фреймворки
Этот архитектурный подход близок к гексагональной архитектуре (hexagonal architecture) или порты и адаптеры и луковая архитектура (onion architecture). Она также активно включает принципы SOLID, особенно принцип инверсии зависимостей, на котором строится вся слоистость и правило зависимостей. Боб говорит о том, что архитектура должна "кричать" о своем назначении — при взгляде на структуру кодовой базы она должна отражать бизнес-домен, а не технические детали.

С точки зрения применимости clean architecture наиболее полезна в следующих сценариях:
- Сложные или долгоживущие приложения, где поддерживаемость является критически важной
- Системы, где доменную модель решили выделить отдельно и использовать стиль DDD (domain driven design)
- Проекты, требующие четкого разделения между бизнес-логикой и инфраструктурой
Она помогает создавать системы, которые могут развиваться со временем в соответствии с изменяющимися бизнес-потребностями, и обеспечивает гибкость для замены фреймворков, баз данных или UI-технологий с минимальным влиянием на основную бизнес-логику.

Но этот подход заслуженно критикуют за
- Избыточную сложность для малых или простых проектов с прямолинейными требованиями
- Чрезмерную слоистость и натыкивание интерфейсов без явных преимуществ, что приводит к "злоупотреблению интерфейсами"
- Избыточный шаблонный код и абстракции, которые затрудняют понимание системы
- Чрезмерно крутую кривую обучения для инженеров и строгую дисциплину для правильной реализации
- Замедление начального развития проекта из-за предварительных усилий по проектированию
- Низкую производительность итогового решения из-за чрезмерного количества абстракций

Итого, я видел подходы к применению Clean Architecture для повышения качества кода в существующих проектах, но я уже активно не писал код сам, когда Uncle Bob явил свою концепцию миру. Именно поэтому я не могу оценить из первых рук насколько с ней получаются хорошие приложения:) Но мне кажется, что это как с любым подходом - можно сделать хорошо, а можно тяп-ляп ... Чистая архитектура тут не исключение.

#Architecture #Software #Engineering #DistributedSystems #SystemDesign

Vibe Coding Is The Future (Рубрика #AI)

Интересное видео от Y Combinator с обсуждением vibe coding, подхода к программированию, который описал Андрей Карпаты, сооснователь OpenAI и бывший директор по ИИ в Tesla. В феврале 2025 года он опубликовал твит, описав личный опыт использования Cursor Composer с интеграцией Whisper для голосового управления. В итоге, ребята из Y Combinator решили разобрать насколько этот подход к разработке меняет правила игры. Основные моменты обсуждения следующие

1) Роль инженера в эпоху ИИ
Согласно опросу YC, 25% основателей утверждают, что 95% их кодовой базы генерируется ИИ. Это не означает исчезновения технических навыков, но переопределяет приоритеты и ключевая компетенция смещается в сторону продуктового мышления - умения определять, что строить, а не как это кодировать. Интересно, что мы недавно именно это обсуждали с S0ER в подкасте Code of Leadership
2) Инструменты и рабочие процессы
Cursor и Windsurf стали фаворитами благодаря интеграции с кодовой базой и автономному анализу файлов. Gemini выделяется длинным контекстным окном, позволяя загружать всю кодовую базу для исправления ошибок. Sonnet и Deepseek конкурируют в качестве движков для генерации, тогда как Devin пока ограничен простыми задачами. При этом отладка остаётся слабым звеном: ИИ часто неспособен исправить ошибки, требуя полной перегенерации кода. Основатели сравнивают это с перегенерацией изображений в Midjourney с тем же промптом - вместо точечных правок код переписывается с нуля.
3) Трансформация найма и образования
Классические алгоритмические собеседования устаревают. Компании вроде Stripe и Gusto переходят к оценке практической продуктивности, например, созданию прототипа за 3 часа. Однако для масштабирования проектов критически важны системные архитекторы - специалисты, способные оптимизировать инфраструктуру под высокие нагрузки. Поколение Z, начинающее карьеру с ИИ-инструментами, демонстрирует уникальные преимущества. Обученные в «цифровой среде», они избегают классического синтаксического бремени, фокусируясь на логике и продуктивности. Однако без фундаментального понимания архитектуры (как в случае с Twitter и его проблемами масштабирования) даже генерируемый код рискует стать "техническим долгом".
4) Будущее разработки: Рекомендации и риски
- Интеграция ИИ в образование: Учебные программы должны совмещать генерацию кода с глубоким пониманием системного дизайна.
- Пересмотр метрик найма: Акцент на навыках отладки, код-ревью и продуктовом видении вместо алгоритмических головоломок.
- Инвестиции в инструменты отладки: Текущие LLM слабы в анализе ошибок - это направление станет ключевым для следующих версий моделей.

Все эти тезисы авторы подкаста подтверждают цитатами из общения с основателями стартапов, что входят в Y Combinator.

#AI #Software #Engineering #Management #SystemDesign #ProductManagement #Productivity #Architecture

[1/3] A Prompt Pattern Sequence Approach to Apply Generative AI in Assisting Software Architecture Decision-making (Рубрика #Architecture)

В декабре 2024 года вышел whitepaper на тему использования Gen AI в архитектуре. Я заинтересовался этой темой и решил прочитать что же придумали ребята. Оказалось, что это некоторый co-pilot для архитекторов, который помогает правильные решения. Для этого авторы предлагают использовать паттерны промптинга, что объединяются в цепочку подготовки, анализа и принятия архитектурных решений. Основные паттерны здесь следующие
- Software architect persona pattern
- Architectural project context pattern
- Quality attribute question pattern
- Technical premises pattern
- Uncertain requirement statement pattern
- Prompt pattern sequence
Эти паттерны авторы исследования опробовали на 3 компаниях - двух настоящих (leading automobile financing bank's technological portal и leading retail pharmacy network) и одной вымышленной компании, что по легенде делает cloud-based CRM.

В самом начале авторы рассказывают как выглядит их подход к описанию указанных выше паттернов, куда входят как стандартные аттрибуты вида: Name, Context, Problem, Forces, Solution, Rationale и Consequences, а также расширенный список
- Specializes: описывает, как текущий стандарт специализируется или расширяет существующие стандарты, уточняя их связь и адаптацию для решения конкретных задач или контекстов.
- Statement template: предоставляет краткое описание или структурированное резюме стандарта, позволяя быстро понять его суть.
- Concrete statement example: приводит реальный пример использования шаблона описания, демонстрируя его применение на практике.
- Related patterns: содержит информацию о других паттернах, связанных с текущим, включая зависимости, предпосылки и рекомендации по совместному использованию (связанные паттерны вынесены в приложение к статье)
- Usage example: приводит практический пример из реальной жизни, показывающий применение паттерна и его полезность в конкретной ситуации.
- Known uses: представляет исторические или текущие примеры успешной реализации паттернов, подтверждая их эффективность и предоставляя ссылку на выполненный запрос для получения дополнительных деталей.

Сам flow работы с паттернами и Gen AI инструментами по мнению авторов статьи выглядит так
1) Архитектор ищет подходящие паттерны из списка выше
2) Дальше он применяет их для своего конкретного проекта и получает подсказки и предложения
3) Дальше он принимает решения после анализа сгенерированных подсказок и своего знания проекта

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

#Architecture #GenAI #AI #ML #Software #Engineering #SystemDesign #DistributedSystems #Project

How To Build The Future: Aravind Srinivas (Рубрика #AI)

Интересное интервью CEO и ко-основателя Perplexity ребятам из Y Cominator. Я сам с большим удовольствием пользуюсь Perplexity как основным поисковым движком, а также ассистентом для размышлений. Именно поэтому мне было интересно глянуть историю о том, а как была создана компания, как она развивалась и куда идет сейчас. В итоге, основные идеи этого выступления примерно следующие

1) Происхождение Perplexity и путь основателя
Аравинд начал свой путь в ИИ с обучения в Индии, после чего переехал в США, где стажировался в OpenAI под руководством Ильи Суцкевера. Именно Суцкевер указал ему на важность обучения без учителя и обучения с подкреплением. После работы в Беркли над неконтролируемыми и генеративными моделями и стажировки в Google, Аравинд пришел к идее, что создание компании с ИИ и разработка продукта неразрывно связаны. Идея Perplexity родилась из поста Дэниела Гросса о создании следующего Google и концепции улучшения формулировки запросов с помощью суффиксов. Первоначально команда экспериментировала с вертикальным поиском и базами данных, используя модели OpenAI Codex для создания SQL-запросов. Это был продукт b2b для поиска по базам данных внутри компаний-закачиков
2) Эволюция продукта
Первый прототип Perplexity был создан за выходные и вдохновлен статьей WebGPT. Хотя изначально использовалась медленная модель 175 AGP, команда применила эвристический подход, выбирая первые k ссылок и краткие описания из кэша. Аравинд отмечает парадоксальный момент: "глупый подход сработал, когда модели стали лучше следовать инструкциям". Это позволило решить проблемы с задержкой в пользовательском интерфейсе, сократив время ответа с 7 секунд до приемлемого значения. Ключевым фактором успеха стала возможность задавать дополнительные вопросы, что удвоило время взаимодействия пользователей с продуктом.
3) Конкурентное преимущество и стратегия
Аравинд не видел прямой конкуренции с Google из-за перегруженности их интерфейса, хотя запуск чата Bing от Microsoft вызвал некоторое беспокойство. В отличие от Google, Perplexity фокусируется на том, что "пользователь всегда прав", требуя уточнений от ИИ. Потребительские продукты, по мнению Аравинда, должны быть проще и удобнее для пользователей.
4) Корпоративная культура и подход к разработке
Основной показатель эффективности компании — количество запросов в день. Еженедельные и ежемесячные данные помогают управлять командой без жесткой иерархии. Компания активно использует Twitter для общения с клиентами, ценя прямолинейную критику больше, чем комплименты. Аравинд подчеркивает важность "дотошных и одержимых людей в команде" и постоянной "борьбы с энтропией" для поддержания качества.
5) Будущее и видение
Аравинд видит Perplexity как "более интеллектуальный поиск", чем Google, стремясь создать место для полного пользовательского опыта. Он планирует построить систему из небольших моделей и графов знаний, уделяя особое внимание управлению ИИ и новым моделям монетизации. В отличие от Google, компания позиционирует себя как организация, "заботящаяся о пользователях и продукте", способная быстро внедрять новейшие модели и обучать их. Это дает Perplexity преимущество в конкуренции с технологическими гигантами, которым сложнее интегрировать инновации из-за их размера и устоявшихся бизнес-моделей.

#AI #Software #Engineering #Storytelling #ML #Architecture

[3/4] What Improves Developer Productivity at Google? Code Quality. (Рубрика #DevEx)

Продолжим рассмотрение статьи про developer productivity (1 и 2) обсуждение независимых переменных, а также построением самой модели.

Независимые переменные
Авторы взяли в качестве гипотезы 42 независимые переменные, которые по их мнению могли влиять на продуктивность. Эти 42 переменные схлопнулись до 39 после проверки на мультиколлинеарность. Эти данные были доступны из логов и результатов опросов. Все эти переменные были разбиты на 6 категорий
1) Code quality & technical debt - эти факторы связаны с качеством кода и техническим долгом, которые дальше разбираются в деталях. Кстати дальше авторы написали отдельные интересные статьи
- "Developer productivity for Humans, Part 7: Software Quality" - статья про качество, которую я уже разбирал
- "Defining, measuring and managing technical debt" - которую я разбирал с Димой Гаевским в подкасте Research Insights Made Simple, а также разбирал в отдельной статье
2) Infrastructure tools & support - здесь история про выбор инструментов, а также работу инфраструктуры. Часть из этих факторов были разобраны отдельно
- "Build Latency, Predictability, and Developer Productivity" - статья про важность не просто build time, а его предсказуемости и как это влияет на продуктивность, о которой я уже рассказывал
3) Team communication - здесь авторы говорят про коммуникации, дистанцию от менеджеров, код ревью. Кое-что авторы из этого разобрали в дальнейших статьях
- "Developer Productivity for Humans, Part 2: Hybrid Productivity" - это статья про то, как удаленная работа и удаленные коммуникации во время COVID повлияли на продуктивностьЯ рассказывал про нее раньше
- "Developer Productivity for Humans, Part 5: Onboarding and Ramp-Up" - это статья про то, как работает процесс онбординга и как на него повлиял COVID. Я рассказывал про нее раньше
4) Goals & priorities - это про ясность целей и про изменение приоритетов
5) Interruptions - здесь авторы замеряют влияние встреч
6) Organizational & process factors - проблемы из-за процессов, реорганизации и перемещения людей

Дальше авторы использовали квази-экспериментальный метод использования панельных данных для построения связи между воспринимаемой инженерами продуктивностью и независимыми переменными: 𝑦𝑖𝑡 =𝛼𝑖 +𝜆𝑡 +𝛽 * 𝐷𝑖𝑡 + 𝜖𝑖𝑡
Где
- 𝑦 - это самооценка продуктивности для инженера i в момент t
- 𝛼 - это независимые от времени необозреваемые параметры инженера, такие как образование или уровень навыков
- 𝜆 - это независимые от инженера эффекты от времени, например, изменение политики на всю компанию или сезонные эффекты (как январские каникулы в России)
- 𝐷𝑖𝑡 - это измеренные факторы продуктивности для инженера i в момент времени t
- 𝛽 - это причинно-следственныые эффекты факторов продуктивности 𝐷𝑖𝑡 в момент времени t
- 𝜖𝑖𝑡 - это ошибка во время t

Дальше авторы берут производную и получают формулу Δ𝑦𝑖𝑡 = Δ𝜆𝑡 + 𝛽 * Δ𝐷𝑖𝑡 + Δ𝜖𝑖𝑡 , где
- Δ𝜆𝑡 = 𝛾0 + 𝛾1 * 𝑇 и Δ означает разницу между соседними временными промежутками
- T - это категорийная переменная, что означает разницу между периодами
- после дифференцирования 𝛼𝑖 исчезает из уровнения, а Δ𝜆 можно явно контролировать, что говорит о том, что 𝛼𝑖 и 𝜆𝑡 не искажают результаты

Дальше авторы берут метод Feasible Generalized Least Squares (FGLS) и строят корреляции между зависимой и независимыми переменными и оценивают абсолютный эффект и статистическую значимость. Про результаты и ограничения исследования будет в последней части обзора.

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

Интервью с Глебом Михеевым про Individual Contributors, Site Reliability Engineering и надежность

Летом прошлого года мы записали выпуск подкаста "Фичи Катятся" с Глебом Михеевым, автором канала "Уставший техдир" (@tired_glebmikheev). Примерно в это время Глеб поменял работу и занялся AI-ассистентом в Сбере, поэтому снятое отправилось на полку. А сегодня Глеб опубликовал эту запись, где мы с ним много общались про развитие инженеров, проектирование систем, обеспечение их надежности и безопасности. В общем, за час мы успели обсудить много интересных тем. Вообще, мы часто с Глебом встречаемся на разнообразных конференциях и часто такие разговоры получаются очень насыщенными. Рад, что в этот раз мы записали такое общение на камеру:)

Сам выпуск доступен почти везде: ВК, Rutube, Spotify, Apple Podcast.

#Engineering #Software #Reliability #Architecture #Management #Processes #Leadership