Вашему вниманию предлагается перевод поста Гергелия Ороса, занимающего должность Engineering Manager в Uber. В нем он делится своим взглядом на проектирование крупномасштабных систем, основанном на собственном практическом опыте работы в Uber и Microsoft. В сочетании с комментариями на Hacker News, которые добавляют весомые контр-аргументы и дополняют точку зрения автора, его статья стала одним из самых интересных постов недели. В статье используется термин «дизайн кода» для сравнения с традиционной «архитектурой» — о нем подробнее можно прочитать здесь.
На мою долю выпало достаточно опыта в проектировании и создании крупномасштабных систем. Я принимал участие в переписывании распределенной системы платежей в Uber, проектировании и релизе Skype на Xbox One и выпуске в открытый доступ RIBs — мобильного архитектурного фреймворка, созданного в Uber. Все эти системы имели тщательно продуманный дизайн, прошли через несколько итераций, с ними связано множество совещаний, проведенных у маркерной доски, и других обсуждений. Затем придуманный дизайн сводился к дизайн-документу, который распространялся среди других разработчиков для сбора дополнительной обратной связи, который продолжался до тех пор, пока мы не переходили к разработке.
Все эти системы отличали большие масштабы: их создавали сотни разработчиков — или они использовали их в своих разработках — и сегодня они бьются в сердцах систем, которыми ежедневно пользуются миллионы людей. Причем, эти проекты создавались не с нуля. Система платежей должна была заменить две другие существующие платежные системы, используемые десятками других систем и дюжинами команд, и все это — без какого-либо ущерба для бизнеса. Переписывание приложения Uber было проектом, над которым одновременно работало несколько сотен инженеров — он включал в себя портирование всей существующей функциональности на новую архитектуру.
Позвольте мне начать с того, что может прозвучать неожиданно. Во-первых, мы никогда не пользовались стандартными средствами планирования архитектуры ПО для работы над дизайнами этих систем. Мы не использовали ни UML, ни модель 4+1, ни ADR, ни C4, ни диаграммы зависимостей. Мы рисовали множество диаграмм, но ни одна из них не следовала никаким строгим правилам. Нужны были лишь старые добрые прямоугольники и стрелочки — и мы получали диаграммы, похожие на эту, описывающую информационные потоки, или другую, изображающую структуру класса и отношения между компонентами. Две диаграммы в одном дизайн-документе часто имели разный стиль, поскольку зачастую они добавлялись или редактировались разными людьми.
Во-вторых, у нас не было архитекторов, которые владели бы дизайном. Не было ни IT Architect, ни Enterprise Architect. Это правда — ни в Uber, ни в Skype/Mircrosoft нет штатных позиций для архитекторов ПО. Ожидается, что инженеры высших уровней — например, в должности Staff Engineer — по-прежнему регулярно пишут код. На всех наших проектах есть опытные инженеры — однако, ни один человек не владеет архитектурой или дизайном единолично. В то время, как опытные инженеры являлись движущей силой процесса дизайна, в обсуждение были вовлечены и остальные разработчики, включая даже зеленых «джунов» — причем они часто оспаривали решения других и выносили на обсуждение альтернативные варианты.
В-третьих, мы практически никогда не ссылались на распространенные архитектурные паттерны и другой общепринятый жаргон, который используется в популярной литературе по архитектуре ПО вроде руководства Мартина Фаулера. Не было упоминаний микросервисов, serverless-архитектуры, границ приложений, событийно-ориентированной архитектуры (event-driven architecture) и всего остального. Некоторые из этих терминов всплывали во время сессий мозгового штурма; однако, у нас не было никакой необходимости ссылаться на них самих в проектной документации.
Проектирование ПО в технологических компаниях и стартапах
Так как же мы со всем справились? И почему мы не стали следовать распространенным подходам к архитектуре ПО?
Я обсуждал этот вопрос с коллегами-инженерами, работающими в других технологических компаниях — как размеров FANG (Facebook, Amazon, Netflix, Google), так и мелких стартапов. Большинство команд и проектов — неважно, были ли они большими или маленькими — объединял схожий подход к дизайну и реализации:
- Начните с бизнес-задачи. Какую проблему мы пытаемся решить? Какой продукт мы пытаемся создать и почему? Как мы cможем измерить его успешность?
- Устройте мозговой штурм для выбранного «подхода». Соберитесь с командой и за несколько сессий найдите рабочее решение. Не стоит слишком затягивать с этой фазой. Начните с верхнего уровня и постепенно опускайтесь вниз на уровни ниже.
- Изобразите ваш подход на доске. Соберите команду вместе, и пусть один из вас изобразит подход, к которому склоняется команда. Вы должны быть способны понятно объяснить архитектуру вашей системы/приложения при помощи доски — начиная с самого верхнего уровня и по необходимости спускаясь все ниже и ниже. Если у вас возникают трудности с каким-либо объяснением или оно недостаточно понятно для коллег, то вам нужно лучше проработать детали своего решения.
- Зафиксируйте его в виде простой документации с простыми диаграммами, основанными на том, что вы ранее объясняли при помощи вайтбординга. Сведите жаргон к минимуму: вы хотите, чтобы даже джуниоры могли понять, о чем идёт речь. Используйте в своём описании понятный и лёгкий язык. В Uber мы используем документ, напоминающий RFC, который основывается на простом шаблоне.
- Обсудите компромиссы и альтернативы. Хороший дизайн ПО и хорошая архитектура заключаются в правильном выборе компромиссов. Сам по себе ни один из выборов дизайна не является плохим или хорошим: все зависит от контекста и целей. Разделена ли ваша архитектура на различные сервисы? Упомяните, почему вы приняли решение не делать один большой сервис, к которого могли бы быть свои другие преимущества вроде более простого и быстрого деплоя. Вы решили расширить модуль или сервис новой функциональностью? Вместо этого взвесьте возможность разработки отдельного сервиса или модуля, и какие плюсы и минусы будет нести данный подход.
- Распространите дизайн-документ внутри команды/организации и соберите обратную связь. Раньше в Uber мы рассылали все дизайн-документы ПО всем нашим инженерам — до того момента, пока наш штат не вырос до 2000 человек. Теперь, когда мы выросли до таких масштабов, мы по-прежнему стараемся охватить как можно большую аудиторию — но в то же время стали следить, чтобы уровень информационного шума не превышал допустимого предела. Стимулируйте других задавать вопросы и предлагать альтернативы. Будьте прагматичны насчет временных лимитов на обсуждение фидбека и его включение в документ там, где это нужно. Конкретные пожелания можно применить сразу и быстро, в то время как детализированную обратную связь лучше разбирать с человеком лично на месте.
Почему наш подход отличается от того, что обычно упоминается в литературе по архитектуре ПО? На самом деле, наш подход принципиально не так уж сильно отличается от того, что описано в руководствах по архитектуре. Почти все руководства предлагают начинать с бизнес-задачи, а также с описания решений и компромиссов — мы тоже делаем это. Чего мы не делаем — так это не используем более сложные средства, за которые выступают многие архитекторы и книги по архитектуре. Мы документируем дизайн максимально просто, используя для этого самые простые и очевидные инструменты, вроде Google Docs или Office 365.
Я полагаю, что основное различие в нашем подходе сводится к инженерной культуре различных компаний. Высокая степень автономии и сведенная к минимуму иерархия — это черта, которая является общей у современных технологических компаний и стартапов; в случае с более традиционными компаниями, это далеко не всегда справедливо. Также это причина, почему в этих местах чаще прибегают к «дизайну, основанному на здравом смысле» вместо дизайна на основе процесса со строгими правилами.
Мне известны банки и автомобильные компании, где разработчиков активно отговаривают от того, чтобы принимать какие-либо архитектурные решения без того, чтобы подняться вверх по цепочке, получить одобрения от архитекторов на несколько уровней выше, которые наблюдают за несколькими командами. Это делает процесс медленнее, и при большом количестве запросов архитекторы становятся перегруженными. Поэтому эти архитекторы создают еще больше формальных документов, в надежде на то, что система станет более понятной — используя все те инструменты, которые описывает знакомая вам литература. Эти документы подкрепляются подходом «сверху вниз», поскольку он действует на инженеров запугивающим образом — ведь они не архитекторы, и не должны сомневаться или оспаривать решения, ведь они уже были задокументированы при помощи формальных методов, в которых они слабо разбираются. Поэтому они обычно так и не поступают. Честно говоря, эти компании поступают подобным образом для того, чтобы сделать разработчиков взаимозаменяемым ресурсом — ведь это позволяет им перекидывать людей с одного проекта на другой в сжатые сроки. Для вас наверняка не будет сюрпризом то, что для разных окружений лучше подходят различные инструменты.
Простой дизайн ПО без жаргонизмов вместо архитектурных паттернов
Целью проектирования системы должна быть простота. Чем проще система, тем проще она для понимания — и тем проще находить в ней проблемы, а также реализовывать ее. Чем яснее язык, которым она описана, тем доступнее ее дизайн. Избегайте пользоваться жаргоном, который не будет понятен каждому члену команды — даже самый неопытный из ваших коллег должен иметь возможность на уровне остальных понимать, о чем идет речь.
Чистый дизайн похож на чистый код: он легко читается и его просто понять. Существует много отличных способов написать чистый код. Однако, вы часто услышите что кто-либо предлагает начать с применения паттернов проектирования «банды четырех» к вашему коду. Чистый код начинается с принципа единственной ответственности, понятных наименований и простых для понимания соглашений. Эти принципы в равной степени применимы к чистой архитектуре.
Так в чем заключается роль архитектурных паттернов? Я нахожу их полезными — настолько же, насколько полезны и паттерны проектирования кода. Они могут подать вам идеи насчет того, как вы можете улучшить свой код или архитектуру. Взять паттерны проектирования кода: я отмечаю для себя, когда замечаю в коде синглтон — и поднимаю брови и копаю глубже, когда я вижу класс, который ведет себя как фасад, а на деле всего лишь пробрасывает вызовы. Но еще не наступил тот день, когда я бы подумал «здесь прямо-таки напрашивается абстрактная фабрика». По правде говоря, у меня ушло много времени на то, чтобы понять, что делает этот паттерн и прежде чем меня осенило; понимание пришло в результате плотной работы с инъекцией зависимостей (dependency injection) — одной из немногих областей, где этот паттерн широко распространен и крайне полезен. Я также признаюсь, что пусть я и потратил много времени на чтение и осознание паттернов проектирования «банды четырех», они имели гораздо меньшее влияние на мой профессиональный рост как программиста, чем фидбек, который я получил от других разработчиков относительно своего кода.
Аналогичным образом, знание распространенных архитектурных паттернов — это полезная штука: оно помогает сократить время обсуждений с теми людьми, кто понимает их тем же образом, что и вы. Но архитектурные паттерны не являются целью, и они не станут заменой для более простых вариантов дизайна систем. Когда вы проектируете систему, то можете вдруг осознать, что случайно применили некий распространенный паттерн — и это хорошо, ведь позже вам будет проще сослаться на использованный подход. Но никогда не стоит брать один или несколько паттернов и использовать их в качестве молотка, для которого вам будут везде мерещиться гвозди.
Архитектурные паттерны появились на свет, когда инженеры обратили внимание на то, что в определенных ситуациях имеет смысл принимать схожие решения относительно дизайна и его реализации. Со временем эти решения получили названия, были записаны и обсуждены широкой общественностью. Архитектурные паттерны — это инструменты, которые появились уже после того, как решения были найдены, в надежде на то, что это поможет сделать жизнь остальных проще. Как инженер, вы должны ставить своей целью самостоятельный поиск решений для своих задач и обучаться в ходе этого процесса — вместо того, чтобы брать «хайповый» архитектурный паттерн в надежде на то, что это решит вашу задачу.
Как научиться лучше проектировать системы
У меня часто спрашивают совета: как «прокачаться» в архитектуре и дизайне систем? Опытные инженеры обычно рекомендуют почитать про архитектурные паттерны, а также книги по архитектуре ПО. Я на все сто поддерживаю рекомендацию читать как можно больше — особенно книги, поскольку они позволяют погрузиться в тематику гораздо глубже, чем короткие посты — однако, у меня есть несколько более практических рекомендаций.
- Привлеките одного из членов команды и вместе займитесь вайтбордингом. Нарисуйте на доске то, над чем вы работаете, и объясните смысл изображенного. Убедитесь, что ваши коллеги понимают, о чем идет речь. И, когда вас наконец поймут, попросите обратную связь.
- Опишите ваш дизайн в виде простого документа и поделитесь им со своей командой, попросив у них обратную связь. Не имеет значения, насколько проста или сложна задача, над которой вы работаете — это может быть как небольшой рефакторинг, так и крупномасштабный проект — вы должны сжато резюмировать ее. Сделайте это таким образом, чтобы для вас этот документ имел смысл, а для остальных — был понятен; для вдохновения — вот вам пример, как это делается в Uber. Поделитесь этим документом со своей командой в формате, который позволяет комментирование — например, при помощи Google Docs, Office 365 или чего-то подобного. Попросите других дополнить его своими соображениями и вопросами.
- Создайте два различных дизайна и противопоставьте их. Когда большинство из нас проектируют архитектуру, обычно они идут одним путем: тем, который всплывает в их голове. Однако, архитектура — это не что-то черно-белое. Придумайте второй вариант дизайна архитектуры, который тоже может сработать в вашей ситуации. Противопоставьте оба дизайна и объясните, почему один лучше другого. Укажите, что вы рассматривали второй вариант некоторое время в качестве альтернативы, и объясните, почему вы приняли решение не в его пользу.
- Определитесь насчет компромиссов, которые вы готовы сделать — выясните, зачем вы их принимаете, и чего хотите добиться с их помощью. Четко установите существующие ограничения, которые вы были вынуждены принять во внимание.
- Проводите ревью чужих дизайнов. Причем делайте это с умом. Если у вас в компании есть культура обмена дизайнами, которыми люди делятся при помощи вайтбординга, совещаний или документов — берите от них больше. Обычно во время ревью люди воспринимают чужой дизайн кода как наблюдатели; вместо этого, задавайте уточняющие вопросы для тех частей, которые вам не совсем понятны. Спросите, какие альтернативы они рассматривали. Спросите, на какие компромиссы они решились и какие ограничения они рассматривали. Побудьте адвокатом дьявола и предложите другую, возможно более простую альтернативу — даже если она не лучше их решения — и спросите, что они думают насчет вашего предложения. Пусть вы не настолько хорошо продумали свой дизайн по сравнению с тем, кто его презентует — ваше обсуждение по-прежнему может привнести что-то новое и поможет вам лучше понять задачу, которой вы занимаетесь.
Лучший дизайн ПО прост и легок для понимания. В следующий раз, когда вы будете начинать новый проект, вместо того, чтобы размышлять над вопросом "Как я буду проектировать эту систему, какие опробованные в бою паттерны я должен использовать и при помощи какой формальной методологии я должен ее задокументировать?", подумайте — "Как я могу прийти к наипростейшему возможному дизайну — такому, который будет легко понятен любому?".
Лучшие практики архитектуры ПО, архитектурные паттерны корпоративных приложений, формальные способы описания систем — все это инструменты, которыми полезно владеть, поскольку однажды они могут вам очень сильно пригодиться. Но при проектировании систем стоит начинать с простого и продолжать придерживаться максимальной простоты. Старайтесь избегать сложности, которую неизбежно привносят в ваши системы более сложные архитектуры и формальные инструменты.
Данный пост вызвал бурное обсуждение среди работников индустрии, которые поделились своим опытом и отношением к архитектуре ПО. Вы можете ознакомиться с этими дискуссиями на Hacker News, Lobste.rs и Reddit.
В то время, как большинство комментаторов согласно с основным посылом статьи, другие замечают, что в реальности подобный подход может быть слабо применим к миру «кровавого энтерпрайза», где архитекторы недаром «едят свой хлеб»; они задаются вопросом — как будет выглядеть спроектированная подобным образом система 20 лет спустя и вспоминают «теорию разбитых окон», а также рассказывают про интеграцию 300 IT-систем, которая по определению не может быть простой — ведь каждая из них имеет уникальное API, часть систем работает на Коболе и каждую из них обслуживает от 5000 до 7000 операторов.
Комментарии (57)
Wundarshular
23.09.2019 05:26Статья хорошая, но что-то подобное я читал в книге, кажется, 1989 года о системном анализе. Иными словами, для меня представленное в тексте статьи не является чем-то новым, но вызывает удивление, что пришли к этому только сейчас.
Разумеется, «тогда» не было возможности всё сделать «как надо», и пришлось делать «как есть». Да.
mad_nazgul
23.09.2019 09:06Ну… Любая идея будет «извращена» до полной противоположности.
Выделение роли архитектора, это применения принципа «разделяй и властвуй».
Т.е. вполне нормальная и очевидная вещь.
Т.к. «сложность» системы надо «есть по частям».
Например «сверху вниз», т.е. от общего (архитектуры) к частному (реализации).
Но в иерархических системах это стало просто еще одним способом «переноса ответственности» и бюрократизации.
Типа «У вас претензии к пуговицам есть?»
Программисты говорят что архитектура кривая, а архитекторы говорят, что реализация говно.
И у всех есть куча доводов в вою пользу.vladshulkevich
24.09.2019 09:15Те и другие могут говорить что угодно. Конечная оценка все равно произойдет по удовлетворенности клиента, кем бы он ни был. Продукты, которые мы считаем хорошими или близкими к идеальным, это те продукты, команды которых научились управлять сложностью. А не рисовать красивые семислойные архитектуры. Или даже их имплементировать.
mad_nazgul
24.09.2019 09:48Кровавый Ынтыпрайз смеётся над вашей наивностью.
Удовлетворенность клиента в кровавом Ынтырпрайзе определяется размером отката ЛПР. :-)vladshulkevich
24.09.2019 09:59Как будто этот «клиент» не знает, что то, за что получен откат, это унылое говно. Нет, не так. УНЫЛОЕ ПОЛНОСТЬЮ НЕРАБОТОСПОСОБНОЕ ГОВНО. Мое высказывание было не про таких «клиентов», а про сложность и управление ею.
mad_nazgul
24.09.2019 11:27Может и не знать. Т.к. «клиент» и ЛПР это могут быть разные люди.
Сложностью можно управлять по разному.
Тот же самый кровавый Ынырпрайз с оверинжиниингом и кучей абстракций над абстракциями, таки делает свое дело.
И как то управляется.vladshulkevich
24.09.2019 11:36Хреново он управляется. Не буду приводить стопитцот примеров, только один. Если в энтерпрайзе имеются куски кода на Коболе, то с большой долей вероятности эти куски — лучшее что там есть. Все остальные навороты, декораторы и фасады чем дальше, тем ситуацию все более ухудшают. Брукс свой «Мифический человеко-месяц» написал в 1969, если что. С тех пор мало что изменилось.
mad_nazgul
24.09.2019 12:55Ну хреново/не хреново это дело вкуса.
Но программы работают, иногда изменяются.
Проблема бывает когда стоимость изменений сравнима с переписыванием с нуля, но так обычно очень редко бывает.
b_idler
23.09.2019 16:44+1Думаю, всё просто сильно зависит от размера продукта. Когда продукт разрабатывают тысячи разработчиков, то им приходится соблюдать архитектурные гайдлайны, вводить некоторые практики и т.п. Но потом многие небольшие проекты начинают использовать эти слишком сложные инструменты (как например, «микросервисность в каждый дом» или «фабрика на каждую ответственность»), и в итоге получают необходимость в поддержки этой сложной инфраструктуры. Но потом опять появляются разумные люди, вспоминают про KISS и говорят, что пора вернуться собственно к проблеме вместо использования всех хайповых практик — и появляется новая хорошая статья.
trueMoRoZ
23.09.2019 07:40Скажите, а Skype на Xbox One таки получился норм?
eumorozov
23.09.2019 08:57Он и на Linux и на Android такой прям «норм»… С каждой версией все хуже, и думаешь: «Если оно при рождении было ужасно, то каким станет еще через несколько лет?..»
trueMoRoZ
23.09.2019 09:24вот тогда и возникает вопрос: а стоит ли доверять автору статьи? или автор не виноват — это майкрософт уже всё портит?
eumorozov
23.09.2019 09:27Не знаю, возможно, они специально для Linux его кривым делают. Windows не пользуюсь. К тому же, Microsoft большой — уверен, что в разных командах разные подходы.
mad_nazgul
23.09.2019 11:51Под windows такое же унылое Г, как и под Linux. Electron же.
igor_suhorukov
23.09.2019 23:01Под windows его душит их же ms teams. Скайп же стал ужаснее и нестабильнее с каждым новым релизом.
le1ic
23.09.2019 17:01Несколько лет назад, уже в эпоху МС, скайп для Linux поддерживался одним! человеком, и это был не единственный его проект. Говорили, о том, чтобы закрыть его вообще. Как сейчас, не знаю.
v2kxyz
24.09.2019 08:04Что то мне подсказывает, что Skype это не только клиентская часть. И судя по деятельности автора в Uber, переписывал(или писал) он серверные части, возможно тоже про платежи.
А так в статье особо ничего нового не написано — не применяй паттерн или целую методологию проектирования просто потому что можешь, объясняй понятными словами.
Eldhenn
23.09.2019 12:05Да он и на винде «норм». Поиск работает на месяц назад, просмотр истории на целых три месяца…
Polaris99
23.09.2019 13:18Вообще не понимаю, как им теперь на Винде пользоваться можно. Сообщения показывает только тогда, когда его принудительно запустишь, хотя в трее исправно висит и ресурсы жрет. Для подгрузки истории сообщений требует реально заметного глазу времени. Ну и самый важный аргумент — с таким качеством связи вообще его как средство связи нельзя использовать, уж не знаю, с чем это связано, но я ни заниматься с преподавателем по скайпу не могу, постоянный гул с эхом, ни на работе использовать — связь рвется стабильно. Такого даже в бородатые нулевые с ним не было на куда менее мощной технике и модемном соединении. Даже не знаю, как у них вышло так улучшить систему.
nicholas_k
23.09.2019 10:22+3Наконец то кто то громко озвучил то, как это происходит в реальной жизни.
Конечно, очень прибыльно продавать лычки XXX Architect и рисовать красивые картинки в рамках того или иного фреймворка. Но к реальной разработке это имеет очень опосредованное отношение.
Разработке нужна архитектура понятная каждому разработчику, а не паре тройке избранных, которые будут толковатьТорупроект по своему желанию и усмотрению.
EvgeniiR
23.09.2019 11:21+1Разработке нужна архитектура понятная каждому разработчику, а не паре тройке избранных, которые будут толковать Тору проект по своему желанию и усмотрению.
Ну то есть вы считаете что можно на крупный проект посадить с десяток джунов клепать привычный и понятный им и большинству процедурный код и всё норм?
Если проекты дольше пары лет не живут — может и сойдёт, но последующие выводы что архитектура — удел теоретиков на OOPSLA(и такое встречается в интернете и на Хабре) скорее походят на психологическую защиту а не инженерное решение.
А по поводу пары-тройки избранных — есть методики распространения знаний в команде(Code Review, Pair programming). Уже пол века как есть.
По поводу статьи — если отбросить большую часть воды, единственный тезис что останется:Старайтесь избегать сложности, которую неизбежно привносят в ваши системы более сложные архитектуры и формальные инструменты
Я согласен с ним в плане того что люди часто в простые проекты затаскивают излишне усложнённые решения, но это, опять же — из-за не понимания их ценности и собственных целей. И в такой ситуации действительно, самым правильным решением может оказаться делать «как умеем», только ориентироваться всё же не на самого слабого человека в команде, а подтягивать уровень команды насколько это возможно.
Конкретно архитектура — ограничения, с ростом проекта и количества разработчиков, нужно тщательно продумывать ограничения чтобы не превратить всё в кашу.EvgeniiR
23.09.2019 11:59P.S.
В-третьих, мы практически никогда не ссылались на распространенные архитектурные паттерны и другой общепринятый жаргон, который используется в популярной литературе по архитектуре ПО вроде руководства Мартина Фаулера. Не было упоминаний микросервисов, serverless-архитектуры, границ приложений, событийно-ориентированной архитектуры (event-driven architecture) и всего остального. Некоторые из этих терминов всплывали во время сессий мозгового штурма; однако, у нас не было никакой необходимости ссылаться на них самих в проектной документации.
Вот тут явно что-то не то, ибо в Убере как раз во всю используется event-driven-architecture, существуют чёткие границы между командами и т.п. (их блог — https://eng.uber.com/ )
Может быть они в свою техническую документацию копируют описание паттерна без его названия, иначе я этот абзац никак объяснить не могу )Nemutaisama
23.09.2019 16:32Ну насколько я понимаю, акцент не на отказ от стандартных архитектурных паттернов, а на изменение причины и следствия.
То есть вместо весьма популярного подхода «вот этот паттерн очень хорош, давайте строить наш проект опираясь на него» предлагается мыслить в ключе «разложите вашу бизнес логику, рассмотрите несколько вариантов построения системы, скомпонуйте их в оптимальный. Вероятно он будет попадать под один или несколько шаблонов, ну и ок»
В общем стандартное «не надо паттернов ради паттернов»
nicholas_k
24.09.2019 10:50Ну то есть вы считаете что можно на крупный проект посадить с десяток джунов клепать привычный и понятный им и большинству процедурный код и всё норм
Разве я хоть одним словом намекнул, что на проекте должны работать одни джуны? И уж тем более привязывать стиль программирования к архитектуре вообще странно.
Можно в процедурном стиле писать качественно и ровно ту же самую архитектуру реализовать отвратительно с помощью механизмов ООП.
Я сказал ровно то, что хотел сказать — архитектура должна быть понятной разработчикам. Если архитектура как совокупность документов ни в какой своей части непонятна джуну, то это плохая архитектура.
Потому что архитектура призвана снижать сложность разработки путем упорядочивания прикладывания усилий. Естественно, инструменты слежения за не очень квалифицированными разработчиками должны быть.
Но если джун постоянно косячит против архитектуры, то это уже не проблема джуна, а ваша — либо вы приняли дебила на позицию, либо не смогли донести до него направление, в котором надо двигаться.EvgeniiR
24.09.2019 12:20Я солидарен с тезисом «Архитектура должна быть понятна всем разработчикам», но я против того как преподносится это в статье.
На крупном проекте вполне могут быть люди которые обладают большим количеством информации о проекте, и имеют лучшее представление как всё происходит на более высоком/низком уровне, лучшие познания в архитектуре, и могут могут предлагать лучшие архитектурные решения, которые могут быть не понятны какой-то части разработчиков. Возможно даже большей части, т.к. возможных решений много, а не типовых проектов не так уж.
И решением в данном случае будет совместное обсуждение предлагаемых решений( и принятие/отказ от них), и ввод в курс дела разработчиков которые не имели с ними дела, а не отказ от решения в пользу того что понятно большинству.
gecube
24.09.2019 13:08И мы опять приходим к тому, что вся сила в коммуникациях. Они должны быть регулярными и плодотворными. Есть же выражение, что тот продукт, который генерирует некая организация, является отражением ее оргструктуры (а следствие — и коммуникативных связей). И, напротив, если нужно сделать новый, качественный продукт — нужно менять структуру коммуникаций к лучшему.
asakasinsky
23.09.2019 12:14-1Зафиксируйте его в виде простой документации с простыми диаграммами, основанными на том, что вы ранее объясняли при помощи вайтбординга. Сведите жаргон на минимум: вы хотите, чтобы даже джуниоры могли понять, о чем идёт речь.
Сведите жаргон на минимум.
Вайтбординг.
хм…
Далее по тексту разъясняется.
Нарисуйте на доске то, над чем вы работаете, и объясните смысл изображенного.
Если доски нет — займусь блокнотингом или тетрадингом. Думаю, что также сойдёт простой бумагинг или на-асфальте-мелинг.
BOM
23.09.2019 12:22На самом деле, наш подход принципиально не так уж сильно отличается от того, что описано в руководствах по архитектуре.
Потому что вы его уже знали. Это часть профессиональной деградации, когда тебе кажется, что все и так очевидно и просто, зачем об этом везде пишут.
Правила нарушают новички и эксперты, только результат у них разный, потому что нарушать правила можно по-разному. Правила это не концепции, которые являются единственно верными, это концепции, которые проверены временем и работают, но это не значит, что все остальное не работает. Проблема в том, что всего остального очень много и выбрать что-то не очень хорошо работающее из него при отсутствии компетенции вероятность крайне высокая.
в Skype/Mircrosoft нет штатных позиций для архитекторов ПО
Я частично согласен с мнением, что роль архитекторов переоценена, и достаточно тепло отношусь к компании Microsoft в целом, но не приводил бы в пример продукт под названием Skype в его нынешней инкарнации.
dss_kalika
23.09.2019 12:39Статья странная.
В ней призывается отказаться от архитекторов и описывается то, как работали архитекторы проекта. =)
Построение взаимодействия создателей проекта, применение/не применение паттернов, рисование где угодно, отказ от сложных решений (или наоборот их привнесение) — всё это задачи архитектора и автор статьи (или указанные им люди) именно этом и занимались. т.е. дефакто были архитекторами )
Может я что то не понимаю? )
sgjurano
23.09.2019 12:57Основной посыл: в современных IT-компаниях роль архитекторов выполняют разработчики, следовательно лучше говорить на понятном для них языке.
EvgeniiR
23.09.2019 13:19+1Основной посыл: в современных IT-компаниях роль архитекторов выполняют разработчики, следовательно лучше говорить на понятном для них языке.
Посыл хороший, плюсую)
Если так складывается что «архитекторы проекта» это часть людей которая сидит где-то у себя в кабинете и принимает решения которые аффектят всю команду, списывая им кучу страниц технической документации и правил по написанию кода, явно что-то идёт не так.
На мой взгляд, проблема этой статьи в том, что автор слишком уж фокусируется на тезисе «принимайте простые решения», дополняя это некоторой частью воды, и после прочтения, особенно после того как автор называет названия паттернов «жаргоном», «хайпом», складывается впечатление что делать нужно исключительно решения понятные даже студенту(вспомним Дядю Боба про «every 5 years the number of programmers doubles»).
Думаю что очень верно подметил комментатор выше про
Потому что вы его уже знали. Это часть профессиональной деградации, когда тебе кажется, что все и так очевидно и просто, зачем об этом везде пишут.
И «простые» для разработчиков Uber решения находятся далеко за границами известного в каком-нибудь средне-маленьком проекте. (Как, например, event-driven-architecture которую Uber активно используют, или микросервисы — https://eng.uber.com/building-tincup/).
dss_kalika
24.09.2019 13:54+1Эм… а что, кто то берёт архитекторов, которых не понимают программисты? Тогда это не архитекторы, вот и всё. )
Архитектура программного обеспечения переоценена, простой и понятный дизайн — недооценен
заголовок статьи. И он противоречит сам себе, потому что простой и понятный дизайн — это тоже архитектура ) просто хорошая.sgjurano
24.09.2019 13:58Честно говоря, за 10 лет в отрасли я встречал выделенных архитекторов только один раз — они делали gosuslugi.ru.
Ни в Яндексе, ни в Авито я их не встречал (хотя в Авито есть команда архитектуры, но занимаются они инфраструктуро
dss_kalika
24.09.2019 14:09Тимлид? Начальник отдела? Прочие люди, которые и решают как будет строиться проект?
Если хочется вкорячить крутое решение — кто решает вкорячивать или нет? Тот и архитектор.
И он не обязательно должен быть выделенным. Более того — не обязательно он должен быть одним человеком. И необязательно, что он при этом сам не работает разработчиком. =)
Архитектор — это не обязательно личность. Это роль. И проект без этой роли — будет ужасен.
ЗЫ: у меня на одном месте работы была позиция у человека — архитектор. в других — эти функции исполняли тимлиды.
Так же — архитекторы бывают разного уровня — проекта, команды, продукта, всея структуры итп…
ЗЫЫ: в яндексе и авито каждый разработчик делает что хочет, пишет как хочет, внедряет любые решения? Думаю они всё-же это согласуют с кем то. Вот этот кто то — и есть архитектор. Или глас его )sgjurano
24.09.2019 14:16Про роль согласен.
Про Яндекс и Авито: разработчик проекта всегда является его архитектором, по крайней мере так всегда было вокруг меня.
dss_kalika
24.09.2019 14:17А если разработчиков целая команда? о_О
Нет, понятно, что когда проект из одного разработчика, то он сам выполняет роль архитектора… но это тоже не значит, что этой роли нет )sgjurano
24.09.2019 14:21Если разработчиков целая команда, то роль архитектора обычно выполняет тот, кто дольше всех работает над этим проектом :)
dss_kalika
24.09.2019 14:31Ну вот и ответ.
Архитектор есть, его не может не быть.
Вопрос только в том, хороший он архитектор или плохой.
В статье рассматривают примеры хороших архитектурных подходов и не очень. Но и то и другое — это архитектура )v2kxyz
24.09.2019 16:19А если команда собирается и обсуждает предложенные решения и коллегиально выносит вердикт — делаем так, то кто архитектор? Причем предлагать решения может любой разработчик. Этот подход собственно и описан в статье.
Подозреваю ответ, что все, но тогда это равнозначно, что его нет.
leventov
25.09.2019 15:20"Коллегиально" — это голосованием? Если двое новичков на проекте будут за одно решение, а двое опытных инженеров — за другое, что делать будете?
v2kxyz
25.09.2019 15:51Одна сторона должна убедить другую. Описанная вами ситуация, ИМХО, маловероятна, а вот по одному опытному+джуниору с каждой стороны — более чем. А если никого не убеждать, то это может привести к проблемам мотивации одной из сторон — «вот опять фигню делаем» со всеми вытекающими.
P.S. Такой подход не применим везде и всюду, есть люди которые не хотят принимать/предлагать никаких решений, следовательно для мест скопления таких людей архитектор нужен, иначе будет хаос. Хотя и с архитектором он может быть.
dss_kalika
26.09.2019 09:42+1Тогда роль архитектора выполняет коллегия.
Но если проект на пару сотен человек, то посмотрю как это будет «коллегиально».gecube
26.09.2019 13:38Не надо проект на пару сотен человек. Мы же понимаем, что эффективно может перформить только команда размером, что сможет съесть максимум две пиццы. Но это не отменяет того, что если уже есть десяток команд, то должен быть человек, который обладает видением и как всё это хозяйство будет развиваться дальше. Какие новые сервисы будут появляться, как будут изменяться существующие. А как его назвать, этого человека — вторично. Пускай будет архитектором предприятия. Или СТО. Или директором или замдира по айти.
DeepFakescovery
23.09.2019 16:05Является ли повторяющийся код — чистым кодом?
rboots
23.09.2019 16:25Если повторяется два раза — вполне может являться чистым, так как повторение может быть обусловлено случайностью, а не общей природой частей, и в дальнейшем при добавоении фич эти участки будут различаться. Так же дублирование кода является одним из способов бороться со связанностью, пусть и не самым безупречным. Поэтому однозначного ответа тут нет.
vladvul
23.09.2019 16:49повторяющийся код не чистый, но простой. Не следует устранять повторение переусложняя.
KISS >> DRY
rboots
23.09.2019 16:16Нужно знать меру во всём, а то джуниоры начитаются таких статей и будут писать лапшевидный код, ссылаясь на то, что Орос сказал не тратить время на архитектуру.
Ermit
23.09.2019 16:26Создавать большие работающие устойчивые системы — это искусство. Если бы эта деятельность могла быть формализована — она уже была бы формализована.
leventov
23.09.2019 21:55Она формализована, просто никто кроме НАСА не хочет платить за такую формализацию.
InOdinWeTrust
23.09.2019 22:05А еще есть ISO, IEEE. В стандартах описано все, чтоб строить отличные большие устойчивые системы.
Ermit
23.09.2019 23:17Если бы этот процесс был формализован, то этот метод можно было применить к любой другой проблемной области. )) За метод нужно платить только один раз.
leventov
25.09.2019 15:14За этот метод вообще ничего не надо платить, он, в принципе, описан прямо в статье по ссылке. Ему очень дорого следовать.
eumorozov
24.09.2019 07:51+1Инутитивно кажется, что формализовать это — все равно, что формализовать написание интересных книг. Теоретически вроде и можно, но:
1) не каждый, кто следует правилам, сможет написать интересную книгу
2) парадоксально, но самые интересные книги будут большинство этих правил нарушать
gecube
Полностью согласен! Отличная статья.
Насчет архитекторов — все очень сильно зависит от того, что мы делаем. Производится ли in-house разработка или берутся готовые решения ("коробки"), а потом сшиваются вместе через интеграции.
Должна быть некая гибкость и баланс между обеими крайностями: когда каждая команда решает, что ей нужно и как ей быть, и полностью зарегулированной историей, когда сверху спускают 100500 регламентов, которые имеют взаимоисключающие параграфы (в частности — регламенты про используемый стек от ОСи до прикладного ПО, ИБ и пр. пр.).
Действительно — впереди разработки должно быть понимание бизнес-задачи, а перед ним — САМ бизнес-процесс, который мы как разработчики и будем воплощать в цифровой форме, а не наоборот.