Pull to refresh
34
-1
Dmitrii Mamonov @dm_wrike

User

Send message

И подсветить какие проблемы она решает,
а где мешает :)

Хочется немного дополнить, к тому что вы говорите.

Мне кажется что следующая модель роста сложности и борьбы с ней может быть релевантной.

Первое: мы начинаем разрабатывать приложение, без модулей, (монолит да), и поначалу все идет хорошо, но где нибудь через год возникает ощущение что все как то связано сложным и странным образом.

Решение: а давайте организуем код по модулям и как то его упорядочим.

Второе: модульный монолит можно развивать еще какое то время, прежде чем возникнет вторая проблема, трудоемкость изменений (это тоже своего рода сложность, сложность тестирования). Если приложение -- достаточно крупный монолит, количество изменений в единицу времени будет только увеличиваться и также будет увеличиваться время необходимое на тестирование. В итоге процесс выпуска новых релизов начинает болезненно буксовать.

Решение: Микросервисы. То что раньше было (или могло быть) модулями теперь становятся отдельными приложениями (взаимодействующими через API, который нужно разрабатывать дополнительно, что overhead, но оправдано). Таким образом объем тестирования сокращается до отдельного сервиса и его связей (а не всего приложения целиком). Да, разрабатывать микросервисы немного более трудоемко чем модульным монолит (за счет API overhead), но это окупается на большой дистанции.

Третье: как я говорил в статье, модульность вообще (и микросервисы в частности) не снижают общую сложность приложения. Это способ лучше организовать связи и облегчить тестирование и раскатывание изменений. Однако, с ростом приложения общая сложность продолжает возрастать и в какой то момент его развитие стопорится потому что "все слишком сложно", и просто чтобы понять какие и где нужно сделать изменения нужно долго разбираться (иногда месяцами).

Решение: bounded contexts (собственно о чем в бОльшей степени статья). Нужно менять системную архитектуру приложения, вводить границы (ограничивающие сложность) и это уже не может быть сделано только на техническом (инженерном уровне), сам продукт нужно менять что бы такой подход к уменьшению сложности сработал. И добиться этого становится действительно тяжело :)

Ну вы же сами перечислили список. Это багфиксы, нужные и полезные. Совсем не то что "давайте напихаем больше фичей" 🙂

Мой тезис в том что приложения которые фокусируются на стабильности (literature programming) конечно существуют, но являются редким исключением.

P. S. Рад видеть что за вами не заржавеет, респект 👍

Да, но. Это задача архитектуры (системной архитектуры, если быть точным) влиять на подход к решению бизнес задач. Если просто добавлять ещё и ещё - сложность будет неизбежно рост вплоть до момента стагнации, когда ничего полезного за разумные время/деньги в систему уже не добавить.

Разделение продукта на bounded contexts позволяет снизить сложность за счёт того что каждый такой домен ограничен. И это работает.

Однако, такой подход приводит к тому что не все становится возможным сделать "как хочется", что может вызывать критику и сопротивление. Также, это долгосрочная история, что усложняет дело ещё сильнее.

Надстройки (LaTeX), инструменты - да. Но не сам TeX. Его смысл наоборот, в том чтобы быть стабильным. Это не случайность что версия TeX сходится к pi: 3.141592653 - текущая, если верить Википедии.

Да, финансовые приложения это отличный источник примеров расширяемой архитектуры.

Спасибо :) Мы (по понятным причинам) ведем OKR в самом Wrike, так что ваши наработки
мы использовать не сможем. Однако, сам Google «говорит» что они используют для ведения
OKR спредшиты, и это выглядит вполне адекватным.
(смотрите комментарий ниже, почему то в тред не попал)
Большое спасибо за комментарий, простите что отвечаю с большой задержкой, был в отпуске.

Не знаю насколько мне удалось это донести в статье, но я имел в виду что в различных проектах под Архитектурой могут пониматься совершенно разные вещи (и это нормально). Важно четко понимать, что в вашем проекте Архитектура, а что Реализация.

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


Примеры которые вы приводите можно отнести в категорию «фундаментальные решения» или «то что дорого изменить», и они вполне могут быть отнесены к Архитектуре. Но не обязательно.
Например, подбор конкретного железа это скорее вопрос обслуживания Production, чем Архитектурный. Повторюсь: если для конкретного проекта правильный выбор железа критически важен (и его следует делать с пониманием внутреннего устройства системы), — этот вопрос может быть и Архитектурным.

При этом декларативные SQL-запросы почти никогда не относятся к архитектуре (структура запросов, например, избежание JOIN-ов ради данных в кеше — может относиться).

Сам по себе полный перечень SQL запросов к Архитектуре (скорее всего) не относится.
Но возможность использовать в реализации SQL запросы «защищает» Архитектуру
от необходимости описания всех возможных (используемых) способов получения данных.
При этом запрет на JOIN, это определенно Архитектурное решение. И на это решение
можно вполне написать тест, который будет проверять реализацию (сам код) на соответствие этому принципу.

Схема БД иногда относится к архитектуре, а иногда нет. Например, если система разбита на мелкие микросервисы с собственными БД, то схемы этих БД зачастую не относятся к архитектуре — их можно в любой момент переписать и поэтому их структура не важное решение и точно не важнейшее.


Хороший пример. Конечно, схема БД это не всегда Архитектура. В вашем примере схему
хранения данных вполне можно считать деталью реализации (при условии что сервисы
действительно не имеют доступа к базам друг друга). Но что в этом случае Архитектура?
Вероятно API.

Дизайн, визуальное представление (форма системы), это важная часть Архитектуры.
Понять устройство системы не имея никакого ее графического выражения представляется крайне затруднительным. Но вы правы, Архитектура это не только дизайн. Например,
принципы организации микросервисов это тоже Архитектура.
Прошу прощения что затянул с ответом, не хотелось отвечать на вопрос впопыхах.

Изначально я планировать в статье раздел про UML, потом отказался от этой идеи
поскольку объем статьи и без того получился изрядный, а прям пользы от темы UML мало.

Мое отношение к UML следующее: UML это неудачная попытка микроменеджить реализацию.

Утверждение достаточно острое, постараюсь пояснить его на примере и в исторической перспективе.

Пример. Один мой однокурсник как то поделился жизненным опытом. Он работал
в outsource компании, и его подключили к реализации очередного проекта.
Проект как раз был «спроектирован» в UML «настоящими архитекторами». То есть в
разработку передали автоматически сгенерированный код проекта, со всеми классами,
интерфейсами и рыбами методов. Собственно разработчиком нужно было «всего лишь»
написать реализацию каждого метода. Дословно передать что мой товарищ сказал о
такой «архитектуре» я не могу, в печати такие термины использовать не принято.
Суть его соображений сводилась к тому что это был очень плохой подход.

Глубокого исторического исследования именно UML я не проводил, но у меня
есть некоторые соображения на эту тему на основе книги Ф.Брукса «Мифический Человеко-месяц»

На заре программирования (в 40-х), когда программы писались непосредственно в машинных
кодах, имел смысл планировать алгоритмы в виде блок-схем (в университетах возможно
и по сей день этому учат). Тогда в этом был смысл, поскольку программы были очень маленькие, а выразительные средства программиста (машшинный код) очень бедные.

Но уже с появлением assembler необходимость в блок схемах отпала. Тем не менее,
разработчиков еще несколько десятилетий заставляли рисовать блок-схемы их алгоритмов,
в автоматизации чего разработчики крайне преуспели. Тогда было модно хвастаться
своими разработками по автоматической генерации блок-схем из кода (о чем пишет Брукс).

Меньше в 80-х, и в пике в 90-х, в программировании доминировала концепция ООП.
Тогда казалось что вот он «святой грааль» программирования, у нас теперь есть объекты,
и в их терминах наконец то можно будет описывать высокоуровневое представление системы.
(Такие мысли выражает Брукс в дополнении ко второму изданию книги, от 95 года).

Я так понимаю что UML как раз и был той попыткой сделать язык описания архитектуры
в терминах ООП. Попыткой провальной. Если бы UML имел успех — мы бы им пользовались постоянно. В вопросе дизайна кода победили современны среды разработки,
предоставляющие обширный инструментарий рефакторинга кода (IntelliJ IDEA вышла в 2001).

Идеи заложенные в UML ведут к слишком детальному описанию, которое практически
идентично реализации, но ей не являются. А для разработки реализации не нужны
схемы и диаграммы, для реализации логики нужны полноценные инструменты рефакторинга.

Пожалуй, ни единого раза не сталкивался с тем, чтобы отсутствовала возможность перейти на уровень выше.

Интуитивно, чисто теоретически, думаю можно написать такой код который нельзя будет абстрагировать. Существует же Теорема Гёделя о неполноте. Но на практике я с вами полностью согласен.

И вот чтобы четко выделить архитектуру-архитектуру ПО без бизнеса вообще — ни разу не встречалось. Проекты-то не в воздухе возникают.

Из ваших слов мне кажется что у вас сложилось впечатление будто бы я позиционирую
архитектуру отдельно от продукта. Это совершенно не так. Смотрите:
А еще Архитектура — это то, каким образом приложение выполняет свое предназначение.


Конечно, архитектура должна в первую очередь выражать смысл продукта и его прикладную область, а технологии и сложности реализации тут вторичны (хотя их и приходится учитывать в архитектуре).

уровень перехода [к архитектуре] был в районе внешнего вида форм

Вы подняли интересную тему, которую мне не удалось вместить в объем статьи.
Еще Ф.Брукс младший писал (цитата не точная) что Архитектура это в первую
очередь интерфейс продукта и пользователя. В 1960-х это были инструкции
к программному обеспечению и параметры консольных команд. Тогда это были
чисто технические вещи. Суть я считаю не поменялась, но измелились технологии.
Сейчас интерфейс с пользователем почти всегда графический, и его проектирование
занимаются UX-дизайнеры. Тут получается любопытный парадокс. С одной стороны
часто кроме макетов интерфейса ничего нет. При, по факту, такие макеты и являются
единственным определением архитектуры. Те есть получается что работу архитектора
делает UX-дизайнер. Лично мне достаточно часто приходится сталкиваться с тудностями
такого подхода, когда архитектура вроде бы уже определена макетыми, эти макеты
уже со всеми согласованы, может быть даже разработка начата, но по факту макеты
поверхностные. Каждый из них в отдельности красивы, но консистентной внутренней
логики за ними не получается. Мне кажется что перекос архитектуры в сторону UX
сейчас слишком велик, и причина в том что макеты дизайнера гораздо нагляднее
того что может предложить архитектор. А люди, особенно менеджеры, склонны соглашаться
с тем что _выглядит_ проще, даже если на самом деле это не так.

При этом в некоторых моментах бизнес-решения влияли на такие глубоко технические вещи, что сходу и не поверишь.

Поделитесь если не секрет, очень любопытно.

Для менеджера от бизнеса диаграмма потоков данных — паутина с квадратиками. Но если в квадратики к названиям продуктов добавить например ежемесячные расходы на содержание, а в уголке диаграммы — месячную прибыль от всей системы в целом, то пустота и растерянность в глазах менеджера сменяется осмысленным выражением.

Согласен с вами, это очень разумный подход.

Зато июнь оживет при виде UMLек с классами или схемами модели данных части одного из продуктов.

Про модели данных также с вами согласен. Но UML диаграммы классов? Мне кажется
эта концепция устарела. Современные среды разработки дают шикарные возможности
по работе с кодом и навигации по нему, зачем нужны диаграммы классов я искренне не
понимаю. На мой вкус это уже аспект реализации и притом некий атавизм в виде блок схем которые рисовали на алгоритмы в третьей четверти прошлого века.

Приятно слышать, большое спасибо.

Архитектура действительно иерархична — есть архитектура продукта, фичи, сервиса, модуля.
Что является архитектурой-архитектурой, а что реализацией — зависит от проекта.
Конечно, это зависит и от точки зрения, но я считаю важно формально определить
хотя бы какую то часть кода как архитектуру — иначе получается что есть только реализация и мнения. А с этим сложно работать.

Высокоуровневая архитектура, то что можно «окинуть одним взглядом», согласен с вами, это действительно важно. Должно быть хотя бы что то на этом уровне. Хотя бы понятные модели данных.
Спасибо за развернутый комментарий и соображения. Кое в чем я хотел бы с вами
не то что поспорить, но по крайней мере уточнить.

1. Как мне кажется многие ваши соображения строятся на идеях Haskell, это просто наблюдение.

2. Про декларативность и алгебру — я использую термин декларативность для того
чтобы подчеркнуть отличие описания желаемого результата (декларативность) от
конкретного способа его достижения (имеративность). Ваши соображения про алгебру
имеют смысл, но алгебра сама по себе не дает свойства анализируемости. А в плане
описания архитектуры важно не только собственно само ее описание, но и возможность
представить это описание различными способами.

3. Про черное и белое — вы сами говорите «может быть сколько угодно уровней»,
и действительно, уровней абстракции может быть больше чем два. Но важно то что
эти уровни абстракции должны быть, и должно быть какие то компактное высокоуровневое
представление общей идеи которую можно рассматривать самостоятельно, не учитывая
все прочие более частные детали реализации. Иначе как во всем разобраться?

4. нужны языки описания различных аспектов архитектуры — не обязательно языки
в терминах языков программирования. и даже если язык есть — он сам по себе архитектурой
не является, но является средством ее выражения. Какие то архитектурные
свойства системы могут быть представлены просто в конфигурационных (yaml) файлах,
в аннотациях, в xml моделях или моделях описанных непосредственно на прикладном
языке программирования (но именно как декларация, т.е. модель).

Я понимаю общий смысл вашего комментария что в целом можно построить
единую формальную модель всего продукта в котором архитектура и реализация
будет органично (алгебры) стыковаться друг с другом с переходом от более высоких
уровней абстракции к, в конечном счете, к деталям реализации. Идеалистически
с вами можно было бы согласится.

Спасибо за комментарий и за вопрос. Начну с того, почему ответить на ваш вопрос не
так просто, но один пример из практики привести попробую.

Если в Архитектуру заложены определенные принципы, например, «клиентские приложения могут обращаться только к определенным типам микросервисов, но не ко всем», то при наличии модели коммуникации их можно проверять автоматически. Точно так же можно контролировать связи микросервисов и баз данных. Если есть определенные правила дизайна моделей данных, те же правила именования таблиц, то и их тоже можно проверять автоматически

Некоторые примеры того что можно формально тестировать в контексте архитектуры
я приводил в самой статье, и тут я старался выбрать максимально простые и компактные примеры.
Но раз вы спрашиваете, этого вероятно недостаточно. А сложность специфического примера
в том что для его понимания нужно раскрыть много контекста, а это уже выходит
за рамки статьи, которая и без того получилась слишком длинной.

То что можно назвать из нашей практики. Например, мы умеем шифровать
пользовательские данные при сохранении их в базу данных, причем каждая
отдельная строка может шифроваться отдельный ключем. Более того, шифрованию
подлежат не все колонки, а только содержащие пользовательскую информацию.
Если в колонке хранится значение enum — его шифровать не нужно. У нас есть
расширенное определение домена хранения данных, в котором в частности
для каждого атрибута определяется — поделит ли он шифрованию или нет.
По этим meta-данным выполняется тест, который парсит код приложения и
выявляет места в которых поддержку шифрования добавить забыли.

Не знаю, насколько этот пример нагляден без подробного объяснения, но такой пример есть.

По правде, как это сейчас модно говорить, у нас самих есть большое количество
возможностей для улучшения, как вообще в плане определения архитектуры,
так и в аспектах ее тестирования. Но то что у нас что то получилось или не получилось,
не мешает вам попробовать сделать лучше. А идея, как мне кажется, достаточно простая.
Думаю, будет не лишним раскрыть мой ответ в предыдущем комментарии.

Эффективность планирования можно оценивать на трех уровнях:
1. На уровне итогового влияния на конечный продукт и его интегральные метрики, такие как NPS (Net Promoter Score) — выполнение проекта это средство, цель — повышение ценности продукта
2. На уровне портфеля проектов — стали ли мы выполнять в квартал больше проектов и стала ли выше доля успешных проектов.
3. На уровне индивидуальных задач и SDLC (Software Development Life Cycle) — стали ли задачи проворачиваться быстрее (время от начала работы до ее завершения) за счет введения нового подхода к планированию.

Разберем все эти три уровня, один за другим.

1. Оценить эффект от внедрения OKR на уровне итогового влияния на весь продукт на уровне
объективных метрик (таких как NPS) действительно нет возможности. Систематическое
внедрение подобных метрик как раз и было следствием перехода на OKR,
о чем и говорилось в предыдущем комментарии.

2. Оценить эффект от внедрения OKR на уровне портфеля проектов можно,
но это в бОльшей степени будет субъективная оценка. И внедрение OKR (2015),
и перезапуск OKR (2017), это были длительные процессы и в тот же период
в компании происходили другие изменения: внедрение Scrum,
существенное расширение Engineering и так далее. Позитивные улучшения в
работе с портфелем проектов явно наблюдалось
(как в плане количества так и в плане доли успешно завершенных проектов),
но приписывать эти изменения только переходу на OKR было бы недобросовестно.
В статье указано что
внедрение OKR было однозначно полезным

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

3. Оценить эффект от внедрения OKR на уровне SDLC — тут, теоретически можно
было бы опереться на формальные метрики. SDCL мы измеряли и до внедрения OKR.
Однако, тут играют два фактора:
а) внедрение OKR (как уже говорилось) было длительным, и другие организационные изменения могли повлиять на объективные метрики по SDLC
б) OKR влияют на стратегическое планирование, а большинство частных задач разработки от него не зависят (из тех которые начаты)
Таким образом, достоверно говорить о влиянии OKR непосредственно на процесс разработки также было бы не корректным.

Была ли польза (повысилась ли эффективность планирования) от внедрения OKR — субъективно в этом нет сомнений.

Можно ли достоверно подтвердить это утверждение объективными метриками — увы, такой возможности нет, по описанным выше причинам.

я думал вы американский стартап

Так и есть, посто часть разработки у нас исторически в России (часть в Чехии).
Правда, стоит признать что мы уже не совсем стартап, продукт с 2006 года создается.

Если вдруг случатся перевод, постараюсь скинуть вам ссылку.

P.S. если мои ответы были для вас полезными, поставьте пожалуйста +1 к их оценке, если вам не трудно (или минус, если все наоборот, все честно).
Я ума не приложу, что такого в ответе «Английского варианта нет...», что за него мне поставили минус.
О, спасибо что заинтересовались!

Я уже расстроился что статью никто не прочитает (понятно какая тема сейчас в тренде), до OKR сейчас мало кому есть дело, главное закупить консервы на месяц
(и, возможно, это действительно главное).

Вообще, у нас есть планы заняться переводом материалов на английский,
так что вполне может быть что и эту статью переведем. Но никаких гарантий.
Английского варианта нет, я написал ее вот только только, само собой на русском.

А в чем ваш интерес в английской версии?
Спасибо за комментарий, очень рациональный вопрос)))

Увы, пример метрики, на которые в наибольшей степени повлиял переход на OKR
я привести не могу. Просто потому что введение таких метрик у нас стало
следствием перехода на OKR.
Большое спасибо за вопрос и ссылку на калькулятор)

Интересно что модель имеет развитие в сторону упрощения, что указано в статье. Не совсем понятно как должна выглядеть в такой вариации матрица ответов.

Не могу сказать совершенно достоверно, но у меня есть большое подозрение
что в калифорнийской модели реальное исследование целевой аудитории часто
заменяется экспертным мнением. Ну, ли часть спектра ответов просто игнорируется, если
исследование все же проводится.

Information

Rating
Does not participate
Works in
Registered
Activity