Comments 13
хорошо бы вы написали так:
вот предлагаемая архитектура (включая и клиент и сервер)
проверим, насколько она хрупка
вот компонент на сервере, который часто/редко меняется и при его изменении понадобится изменить эти компоненты на сервере и эти на клиенте
на самом деле, не так и много компонент на сервере потребует изменений компонент на клиенте и обратно
тут скорее будет API first (контракт, для которого понадобится и изменения на клиенте и на сервере), когда и клиент и сервер должны реализовать этот API
только вот картинка будет некрасивая
В общем, Чистая Архитектура это та архитектура которую мы называем Чистой. Ясно-понятно.
У вас в начале был разговор про масштабируемость, а в конце вывод что "время покажет". Так что с масштабируемостью-то стало? Она улучшилась или ухудшилась? На сколько? Сколько файлов теперь надо поменять для добавления новой фичи? Что и спроизводительностью стало? Багов больше или меньше стало?
Чистая Архитектура это та архитектура которую мы называем Чистой
Не уверен, что это взято на основе этих статей.
Как мне казалось, в первой части термин был выведен чуть более четко :)
Она улучшилась или ухудшилась?
Улучшилась.
На сколько?
Если говорить про субъективные ощущения, то достаточно сильно, чтобы написать об этом статью :)
Если говорить про цифры, то устранение компонентов, перечисленных в первой статье и части компонентов из второй, увеличило ТТМ фич до 2 штук в 2 недели (за спринт) на моей позапрошлой работе, в команде из двух разработчиков на проекте, в котором было 60+ разработчиков.
До этого была фича в неделю, стало быть улучшилось примерно в 2 раза.
Закрепление этих практик на следующей работе также показало положительную динамику, но я уже был не в фича-команде. К сожалению не могу ссылаться на метрики прошлой работы, но таковые велись и они существенно улучшились.
Методы из экстремальной экономии ввелись в дополнение к остальным практикам на текущей работе и применяются во всей совокупности относительно недавно, потому и использовал слова "время покажет".
Думаю можно было применить эти слова не ко всей совокупности, а лишь к той её части, которая ввелась недавно. Моя ошибка.
Но за то время, что мы применяем всю совокупность, могу смело сказать - "5 минут, полёт нормальный!".
Сколько файлов теперь надо поменять для добавления новой фичи?
В зависимости от фичи. От 5 классов и более.
Если откатываться назад и возвращать лишние компоненты, то минимальное количество было бы пропорционально больше.
Что и с производительностью стало?
Если говорить про производительность приложения в Runtime, то, ожидаемо, отсутствие лишних компонентов не скажется никак. Обфускатор под капотом в любом случае срезал бы их количество.
Если говорить про Build Time, то мы получили положительную динамику в совокупности с преимуществами применяемой структуры.
В сравнении с оптимизациями gradle, цифры, разумеется, не такие внушительные, чтобы рассматривать сокращение Build Time, как цель.
Целью преследовалось улучшение масштабируемости проекта и сокращение ТТМ, но про него я уже сказал в этом же комментарии выше.
Багов больше или меньше стало?
К сожалению нигде не велась статистика на подобии "bug per minute". Полагаю, что в убранных проксирующих компонентах и интерфейсах сложно было бы заложить баги в принципе.
Но могу предположить корреляцию сокращения компонентов с сокращением количества багов обусловленную большей концентрацией разработчиков над теми компонентами, в которых действительно есть какая-то логика, нежели проксирование.
___________
Спасибо за ваши вопросы!
Не уверен, что это взято на основе этих статей.
Как мне казалось, в первой части термин был выведен чуть более четко :)
Цитата:
Любая архитектура может быть чистой, если придерживаться принципов. Если вы обеспечили структуру проекта в соответствии со схемой, которую привёл Мартин, это ещё не значит, что вы достигли тех целей, которые он ставил перед собой.
и далее
Не обременяйте себя стереотипными взглядами на ЧА. Вполне возможно, что негативный опыт других разработчиков берёт начало не в ЧА, а в неправильном представлении о ней.
Я по-другому не могу это интерпретировать, кроме как "ЧА это то как мы ее представляем и конкретных критериев тут нет". Ну или проще говоря "как назову, так и будет"
Если говорить про цифры, то устранение компонентов, перечисленных в первой статье и части компонентов из второй, увеличило ТТМ фич до 2 штук в 2 недели (за спринт) на моей позапрошлой работе, в команде из двух разработчиков на проекте, в котором было 60+ разработчиков.
Вот это уже интереснее, правда это не про масшатбируемость и я не понял причем тут 60+ разработчиков, если метрика про двух, но да ладно. Т.е. раньше два разработчика делали одну фичу за спринт, то теперь могут делать две за спринт.
Закрепление этих практик на следующей работе
Тут опять надо бы конкретику: сколько было, сколько стало, сколько удалили... Но это скорее другая статья ;)
Но за то время, что мы применяем всю совокупность, могу смело сказать - "5 минут, полёт нормальный!"
5 минут не считается.
В зависимости от фичи. От 5 классов и более.
Извините, но это какой-то странный ответ. 5 классов это много или мало? А было сколько?
Обфускатор под капотом в любом случае срезал бы их количество.
WAT? Это как?
Если говорить про производительность приложения в Runtime
Тут много что можно смотреть и мерять: рендеринг, время старта, память, батарейку, сеть и тп
К сожалению нигде не велась статистика на подобии "bug per minute"
Very nice code quality management. Вы в VK работаете да?
Я имел ввиду количество багов на 100 строк кода, например. Вы же удалили код, значит метрика должна была улучшиться, так? Можно чуть шире посмотреть, например на тестовое покрытие, которое тоже может улучшиться, когда удаляют код.
сокращением количества багов обусловленную большей концентрацией разработчиков
Хз. Мне кажется тут прямая зависимость. Чем больше разработчиков, тем больше багов. Разработчики источник багов жеж.
----------------------------
Да, я сегодня "токсик" и заноза в заднице. Пятница жеж :))
Я по-другому не могу это интерпретировать, кроме как "ЧА это то как мы ее представляем и конкретных критериев тут нет". Ну или проще говоря "как назову, так и будет"
Приведённые вами цитаты отвечают не на вопрос, "что такое ЧА"
Определение ЧА было в первой части статьи.
Из определения важно было понять, что "чистота" - это свойство.
Также была приведена характеристика, на которую оно влияет.
Обе приведённые вами цитаты говорят о том, что ЧА не имеет одной единственно верной структуры и между проектами структура может отличаться в зависимости от нужд проекта
Во второй цитате отмечаю, что люди хающие ЧА скорее всего реализовали структуру из книги, которая не была масштабируемой для их проекта. И мнение скорее всего идёт по логике - структура-то из книги, а значит ЧА фигня.
правда это не про масшатбируемость и я не понял причем тут 60+ разработчиков, если метрика про двух, но да ладно
В книге хорошо описана ситуация, из которой видно, что увеличение количества разработчиков на проекте может незначительно влиять на увеличение количества строк в кодовой базе, а стало быть и на количество поставляемых фич в целом. В первой части статьи я упоминал об этом приведя графики из книги в пример.
Также, если двое человек поставляли по 2 фичи в месяц на проекте - это не значит, что через 5 лет этот показатель сохранится. Тут идёт зависимость от увеличения количества строк в кодовой базе.
Быстрее нарастить код можно за счет большего количества разработчиков. А стало быть и увеличение количества разработчиков - это тоже способ масштабирования.
Только вот если 2 человека писали код в одном классе, то недостатки архитектуры вылезут моментально при таком масштабировании. В книге этот момент описывается в части про SRP, где одним из индикаторов его нарушения приводится увеличение количества конфликтов на МР-ах.
ЧА должна без проблем усвоить увеличение количества разработчиков и увеличение строк кода в кодовой базе с течением времени.
Я указал общее количество разработчиков на проекте, чтобы каждый смог сравнить, сможет ли их проект выдержать подобное масштабирование.
5 минут не считается.
Мне показалась данная метафора уместной. Будто бы масштабный проект это ракета, 5 минут полёта которой без отклонений - это существенный результат, но радоваться пока рано. Мы затаили дыхание в надежде, что всё и дальше будет хорошо :)
WAT? Это как?
Извиняюсь, моя ошибка. Хотел написать более развёрнутый ответ про совокупность компилятора и обфускатора, потом подумал, что упомянуть про оптимизацию компилятором будет достаточно для ответа. Только вот удалил я не то. Сами понимаете, пятница :)
В общем компилятор всё равно проводит оптимизации для релизных сборок. В том числе оптимизацию вызовов. Соответственно под нож оптимизации подпадут проксирующие.
Тут много что можно смотреть и мерять: рендеринг, время старта, память, батарейку, сеть и тп
Всё это можно подвести под Runtime характеристики. К сожалению на них влияния не будет, а даже если и было бы, то настолько незначительное, что об этом не стоило бы и говорить
Всё таки мы говорим про архитектуру приложения, а не аппаратных компонентов.
BuildTime улучшится в том числе и из-за облечения работы компилятору (меньше компонентов - меньше работы).
Про TTM уже говорил
Very nice code quality management. Вы в VK работаете да?Я имел ввиду количество багов на 100 строк кода, например. Вы же удалили код, значит метрика должна была улучшиться, так?
Будь то "bug per minute" или "bug per row", это всё неизмеримые характеристики. Если бы внесении кода в проект все отчитывались о количестве багов в нём,, то зачем они вообще вносили этот код?
Да и "баги на 100 строк кода" можно было бы размывать бесполезным кодом. Так сказать снизить концентрацию багов, но не их количество.
Но если вас интересует именно метрики, то могу предложить Crash-Free. Этот показатель улучшался на протяжении удаления лишних компонентов.
Но если говорить именно о падениях на нашем проекте, то сложно оценить, насколько экономия повлияла на уменьшение их количества.
То, насколько уменьшиться именно количество багов, существенно зависит от начальной структуры.
Если никакой структуры не было, то влияние будет колоссальным.
Можно чуть шире посмотреть, например на тестовое покрытие, которое тоже может улучшиться, когда удаляют код.
А вот тут наоборот, если удаляют код, покрытый тестами (а проксирование тоже покрывалось тестами), уменьшается покрытие.
Вопрос в качестве покрытия - оно улучшилось.
Плюсом является то, что разработчики меньше времени тратят на покрытие.
Хз. Мне кажется тут прямая зависимость. Чем больше разработчиков, тем больше багов. Разработчики источник багов жеж.
Чем больше разработчиков или чем больше кода?
Если дать разработчику время, чтобы написать столько же кода, сколько написали 10 разработчиков, внесёт ли он меньше багов, чем они? Зависит от навыков разработчика.
Сильно дискуссионная тема, чтобы пытаться её развивать в комментариях.
Зато тема богатая на шутки :)
Да, я сегодня "токсик" и заноза в заднице. Пятница жеж :))
Наоборот, круто, что есть вопросы! Значит тема интересная.
Меня это радует :)
___________
Спасибо за ваши вопросы!
случайно пропустил пару вопросов
Извините, но это какой-то странный ответ. 5 классов это много или мало?
Много или мало - субъективная оценка.
Указал количество для разработчиков, чтобы каждый мог сравнить с собственным количеством и самостоятельно оценить.
А было сколько?
Для структуры из первой схемы минимум соответствует количеству компонентов на ней - 13.
Я попробую по-коротче, т.к. многое в вашем ответе просто мелочь.
Много или мало - субъективная оценка.
"много" и "мало", действительно, субъективная оценка, а вот 5% и 10% - нет. О чем и был вопрос. Абсолютные цифры редко бывают информативны, когда объемы постоянно меняются. Вы бы знали это, если бы действительно измеряли этот параметр.
Приведённые вами цитаты отвечают не на вопрос, "что такое ЧА"
Приведенные цитаты это ваш вывод в статье. И я с ним абсолютно согласен - ЧА это просто культ имеющий мало связи с реальностью. Бессмысленно рассуждать об архитектуре в отрыве от задач, которые нужно решить. Не существует кода, который хороший или плохой сам по себе, сложно даже сказать корректный код или нет, если мы не знаем какую задачу он решает, но адепты "культа ЧА и SOLID" почему-то считают по-другому. У них, почему-то, существует сферическая (а она действительно сферическая, судя по картинкам) архитектура в вакууме (и она, действительно, в вакууме, т.е. оторвана от реальности, как следует из диалога с Кейси https://github.com/unclebob/cmuratori-discussion/blob/main/cleancodeqa.md и критики Кейси же https://www.youtube.com/watch?v=tD5NrevFtbU). Ладно, мы слегка отклонились.
В книге хорошо описана ситуация, из которой видно, что увеличение количества <и далее. я все не стал цитировать>
Да, увеличение числа разработчиков это про масштабирование, но вы-то ответили про TTM Цитата: <увеличило ТТМ фич до 2 штук в 2 недели (за спринт) на моей позапрошлой работе>.
Что же до SRP, то это самоочевидный принцип еще со времен LISP и рассуждений о чистых функциях, к ЧА он имеет отношение постольку-поскольку, со всеми же недостатками, которые ЧА игнорирует.
Будь то "bug per minute" или "bug per row", это всё неизмеримые характеристики.<...>
Seriously? Баги напрямую влияют на потребительские свойства продукта, а вы их не измеряете?
Меня интересует что вы оптимизируете и как вы это измеряете. Или у вас архитектура ради архитектуры?
Размытие кода "бесполезным кодом" во-первых ухудшит производительность разработчиков, т.к. на бесполезный код надо тратить время, во-вторых есть вполне реальный шанс что в "бесполезном коде" тоже будут баги, в-третьих вас уволят быстрее чем вы увидите разводнение :). Если же в бесполезном коде нет багов, то я бы присмотрелся как это так людям удается писать код без багов. ;)
Если никакой структуры не было, то влияние будет колоссальным.
вот и продемонстрируйте это на реальном примере.
Сильно дискуссионная тема
Абсолютно нет - разработчики ЕДИНСТВЕННЫЙ источник багов. Чем их больше, тем больше багов, независимо от их квалификации.
Будто бы масштабный проект это ракета
Масштабный проект это марафон - быть первым на первых 5 минутах ничего не решают.
В общем компилятор всё равно проводит оптимизации<...>
Первое, относительно итерфейсов и виртуальных вызовов, то компилятор, Proguard и R8 далеко не всегда делают коллапс, инлайнинг и статический вызов. Второе, оригинальная идея для введения интерфейсов была в том, что они, помимо полиморфизма, помогают изолированно тестировать компоненты. Как там с параметром Testability? Лучше? Хуже?
К сожалению на них влияния не будет
Из того что вы привели в статье такой вывод сделать сложно - не понятно что вы поменяли и как. Измерений вы тоже не привели, так что тоже не ясно. Без измерений это все только ваши субъективные ощущения.
Вы хорошо реагируете на критику. Только за это я бы ставил плюс каждому вашему комментарию. Но хотелось бы увидеть статью типа: вот проблема, вот тут мы измеряем, вот тут мы пытаемся ее решить, вот так поменялись параметры.
"много" и "мало", действительно, субъективная оценка, а вот 5% и 10% - нет. О чем и был вопрос. Абсолютные цифры редко бывают информативны, когда объемы постоянно меняются. Вы бы знали это, если бы действительно измеряли этот параметр.
В плане количества компонентов мне сложно понять смысл данных измерений.
Возможно мы с вами друг друга не до конца понимаем.
Минимум по компонентам виден на схемах.
Для первой структуры был минимум 13 компонентов + 5 из них покрывается Unit-тестами.
В последних примерах был минимум в 5 компонентов + 2 из них покрывается Unit-тестами.
Возможно вы хотите услышать, как было удалено 11 лишних классов.
Но если мы изначально использовать указанные структуры, то мне сложно будет презентовать информацию о том, как не было написано 11 лишних классов.
Ну а дальше в дело вступает масштабирование по количеству featue. Если их у вас на проекте 100, то получаем экономию минимум в 1100 компонентов :)
Только вот максимум трудноизмерим. В рамках одного экрана-feature может быть несколько UseCase-ов, Repository, источников данных. Между собой эти цифры не связаны. Но большинство featue - это "дай-покажи".
Предупреждая ваш вопрос. Нет, я не измерял, сколько минимальных feature в отношении к не минимальным :)
Боюсь, что тут я полагался лишь на субъективные ощущения от опыта, когда работал в feature-команде :)
Приведенные цитаты это ваш вывод в статье.
Попробую привести пример на автомобилях.
Какой-то блогер говорит - "насколько же круто ездить на чистом автомобиле". И показывает свой чистенький красный автомобиль.
Подписчики бегут в салон с автомобилями и говорят - "мы хотим чистый автомобиль!". Им предлагают на выбор всех цветов и оттенков.
Они - "Это не чистые автомобили!". Находят глазами красный и говорят - "Это чистый автомобиль!".
Настолько часто происходит такая ситуация, что продавцы, слыша слова "Чистый автомобиль", сами считают, что речь может идти только о красном.
И в рамках этого примера ваши слова "культа ЧА", очень даже уместны, мне понравилось :)
Я просто пытался сказать, что любой автомобиль может быть чистым.
Тьфу ты.. Архитектура!
В первой части было:
- заявлено, что схема из книги не ЧА, а лишь вариант её реализации;
- дано определение;
- заявлено, что любая архитектура может быть чистой, но при условии.
Также и любой автомобиль может быть чистым, при определённых условиях - возить в автомойку, не раскидывать вещи по салону и т.п.
Да, увеличение числа разработчиков это про масштабирование, но вы-то ответили про TTM
А, теперь я понял о чем речь :)
Да, я ответил про ТТМ в рамках масштабированного проекта по числу разработчиков и модулей. В предисловии было упомянуто про 300+ модулей и 60+ разработчиков.
TTM, как основной показатель для архитектуры, не должен упасть. А в идеале должен расти при изменениях в ней. То, что показатель вырос примерно в 2 раза, в условиях этих количеств, я считаю отличным показателем того, что архитектура хорошо масштабируема.
Seriously? Баги напрямую влияют на потребительские свойства продукта, а вы их не измеряете?
Могу показаться наивным, но мы их фиксим, а не мерим :)
Не уверен, что кто-либо может уверенно сказать точное количество багов на своём проекте. А сколько из багов - фичи? :)
В плане метрик я предложил показатели Crash-Free, вроде как стандартная штука, да и мерить гораздо проще, т.к. обладает более точными критерями :)
Меня интересует что вы оптимизируете и как вы это измеряете. Или у вас архитектура ради архитектуры?
А, ну так вопрос более понятен. Мы оптимизируем время на разработку, как способ сокращения ТТМ.
Размытие кода "бесполезным кодом" во-первых ухудшит...
Да я ж рассуждал об абсурдности показателя "bug per row". О том, что оный был бы ярким примером фразы, что "есть ложь, гнусная ложь и статистика".
вот и продемонстрируйте это на реальном примере.
Я демонстрирую на примере старой структуры, максимально приближенной к той, к которой все стремятся, когда говорят о ЧА.
Все примеры структуры взяты из реального опыта, просто с разных проектов.
На схемах видно, что минимальное количество компонентов на фичу снизилось чуть больше, чем в 2 раза.
Абсолютно нет - разработчики ЕДИНСТВЕННЫЙ источник багов. Чем их больше, тем больше багов, независимо от их квалификации.
С этим я спорить не буду :)
Но ставлю под сомнение вашу фразу "Чем больше разработчиков, тем больше багов".
Считаю, что один разработчик, если дать ему достаточно времени, чтобы догнать проект, который пилился десятью разработчиками, способен внести багов не меньше, а то и больше, т.к. концентрации одного человека на всех направлениях будет не достаточно.
И вот это уже дискуссионная тема о разработчиках в вакууме и вне его :)
Масштабный проект это марафон - быть первым на первых 5 минутах ничего не решают.
Это верно, но я говорю про уже разогнавшийся проект. В архитектуре которого внесли определённые изменения не в первом году его жизни. При этом не потеряли скорости
Первое, относительно итерфейсов и виртуальных вызовов, то компилятор, Proguard и R8 далеко не всегда делают коллапс, инлайнинг и статический вызов.
Понимаю, я бы мог сказать, что при условии, что компилятор не провёл этих оптимизаций, мы экономим на нескольких вызовах. Но это настолько незначительно, что говорить об этом не стоит.
Влияния на Runtime не будет.
Как там с параметром Testability? Лучше? Хуже?
Об этом было в первой части статьи - нет изменений совсем.
Из того что вы привели в статье такой вывод сделать сложно - не понятно что вы поменяли и как. Измерений вы тоже не привели, так что тоже не ясно. Без измерений это все только ваши субъективные ощущения.
Моя вина, что не сделал дополнительного акцента в статье на это.
Чуть выше уже ответил на подобный вопрос, что мы оптимизируем время на разработку, как способ сокращения ТТМ.
___________
Спасибо за замечания!
CA описывает архитектуру системы, а не отдельного компонента. Один из тезисов говорит про независимость от UI.
Бизнес логика по классике живёт на сервере, а ваше приложение под Android это тонкий клиент. Интересно, не является-ли такой клиент, в терминах данной архитектуры фактически тем самым UI, независимость от которого они хотят добиться?
Если ответ да, то изначальное желание затащить еще какую-то CA внутрь клиента, выглядит немного сюрриалистично.
CA описывает архитектуру системы, а не отдельного компонента.
Автор в книге регулярно использовал термин "компонент" то к классам, то к сервисам в целом. Всё зависело от того, о каком уровне абстракции он рассуждал в данный момент.
Всё связано.
Интересно, не является-ли такой клиент, в терминах данной архитектуры фактически тем самым UI, независимость от которого они хотят добиться?
UI для клиента - такой же внешний слой архитектуры, как Api для бекенда.
Можно ли сказать, что приложение - это UI?
Думаю можно сказать, что телефон - это среда предоставления UI для сервиса в целом.
Но само приложение - это не UI.
Не смотря на всю тонкость клиентов, телефон является не только средой предоставления UI.
На уровне клиентов можно организовать
кеширование;
взаимодействие с внешними сервисами, такими как пуши, локация и т.п.;
взаимодействие с аппаратными компонентами, такими как камера, Blutooth и т.п.;
эксперименты (особенно касающиеся UI слоя);
разного рода аналитику;
Feature-тоглы;
и т.п.
К тому же не стоит забывать, что бекенд разработчиков не всегда хватает. Да и ситуации бывают разные. Иногда для MVP бизнес логика может утечь и в клиент.
Также бизнес логика на клиенте может быть оправдана не только моментом.
Т.о. мобильные клиенты стремятся быть тонкими, но это скорее стремление к идеалу.
А значит архитектура нам всё еще нужна.
___________
Спасибо за ваш вопрос! :)
А значит архитектура нам всё еще нужна.
Нужна-ли здесь CA или может быть какая-то другая архитектура?
Для предисловия позволю себе скопировать пример из другого обсуждения выше
Какой-то блогер говорит - "насколько же круто ездить на чистом автомобиле". И показывает свой чистенький красный автомобиль.
Подписчики бегут в салон с автомобилями и говорят - "мы хотим чистый автомобиль!". Им предлагают на выбор всех цветов и оттенков.
Они - "Это не чистые автомобили!". Находят глазами красный и говорят - "Это чистый автомобиль!".
Настолько часто происходит такая ситуация, что продавцы, слыша слова "Чистый автомобиль", сами считают, что речь может идти только о красном.
Если вы хотите купить автомобиль, то вы хотите, чтобы он был чистым:)
Нужна-ли здесь CA или может быть какая-то другая архитектура?
Нужна :)
И да, это может быть "какая-то другая архитектура", нежели та, что приведена в примере из книги.
___________
Спасибо за ваш вопрос! :)
"Прелесть" всех статей про Чистую Архитектуру - это Абстракция, т.е. возможность использовать слова Парадигма, Подход, Инкапсуляция и пр. Причём, их могут использовать и Знающие люди, и Проходимцы. На выходе мы можем получить как хороший код, так и Фабрику-Фабрик-Репозитория. И отличить Профи от Шарлатана очень сложно. Подобные притчи давно используются в религиях по тем же причинам.
Кстати, сам Боб пишет довольно пространственно, некоторые тезисы бывают слишком радикальны (чувствуете, сюда что угодно можно подтащить). Но выступает - просто блеск! Когда я посмотрел записи его выступления - он делает всё шииииикарно: начинает с забавного отстранённого от ИТ факта, юморит, аппелирует к здравому смыслу. Как дядька, кто хотел сделать разработку лучше - молодец! Как пособник усложнения кода... ну, тут каждый сам решит.
Вы за это заплатите! Цена Чистой Архитектуры. Часть 2