Я попробую по-коротче, т.к. многое в вашем ответе просто мелочь.
Много или мало - субъективная оценка.
"много" и "мало", действительно, субъективная оценка, а вот 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? Лучше? Хуже?
К сожалению на них влияния не будет
Из того что вы привели в статье такой вывод сделать сложно - не понятно что вы поменяли и как. Измерений вы тоже не привели, так что тоже не ясно. Без измерений это все только ваши субъективные ощущения.
Вы хорошо реагируете на критику. Только за это я бы ставил плюс каждому вашему комментарию. Но хотелось бы увидеть статью типа: вот проблема, вот тут мы измеряем, вот тут мы пытаемся ее решить, вот так поменялись параметры.
Не уверен, что это взято на основе этих статей. Как мне казалось, в первой части термин был выведен чуть более четко :)
Цитата:
Любая архитектура может быть чистой, если придерживаться принципов. Если вы обеспечили структуру проекта в соответствии со схемой, которую привёл Мартин, это ещё не значит, что вы достигли тех целей, которые он ставил перед собой.
и далее
Не обременяйте себя стереотипными взглядами на ЧА. Вполне возможно, что негативный опыт других разработчиков берёт начало не в ЧА, а в неправильном представлении о ней.
Я по-другому не могу это интерпретировать, кроме как "ЧА это то как мы ее представляем и конкретных критериев тут нет". Ну или проще говоря "как назову, так и будет"
Если говорить про цифры, то устранение компонентов, перечисленных в первой статье и части компонентов из второй, увеличило ТТМ фич до 2 штук в 2 недели (за спринт) на моей позапрошлой работе, в команде из двух разработчиков на проекте, в котором было 60+ разработчиков.
Вот это уже интереснее, правда это не про масшатбируемость и я не понял причем тут 60+ разработчиков, если метрика про двух, но да ладно. Т.е. раньше два разработчика делали одну фичу за спринт, то теперь могут делать две за спринт.
Закрепление этих практик на следующей работе
Тут опять надо бы конкретику: сколько было, сколько стало, сколько удалили... Но это скорее другая статья ;)
Но за то время, что мы применяем всю совокупность, могу смело сказать - "5 минут, полёт нормальный!"
5 минут не считается.
В зависимости от фичи. От 5 классов и более.
Извините, но это какой-то странный ответ. 5 классов это много или мало? А было сколько?
Обфускатор под капотом в любом случае срезал бы их количество.
WAT? Это как?
Если говорить про производительность приложения в Runtime
Тут много что можно смотреть и мерять: рендеринг, время старта, память, батарейку, сеть и тп
К сожалению нигде не велась статистика на подобии "bug per minute"
Very nice code quality management. Вы в VK работаете да? Я имел ввиду количество багов на 100 строк кода, например. Вы же удалили код, значит метрика должна была улучшиться, так? Можно чуть шире посмотреть, например на тестовое покрытие, которое тоже может улучшиться, когда удаляют код.
сокращением количества багов обусловленную большей концентрацией разработчиков
Хз. Мне кажется тут прямая зависимость. Чем больше разработчиков, тем больше багов. Разработчики источник багов жеж.
----------------------------
Да, я сегодня "токсик" и заноза в заднице. Пятница жеж :))
В общем, Чистая Архитектура это та архитектура которую мы называем Чистой. Ясно-понятно. У вас в начале был разговор про масштабируемость, а в конце вывод что "время покажет". Так что с масштабируемостью-то стало? Она улучшилась или ухудшилась? На сколько? Сколько файлов теперь надо поменять для добавления новой фичи? Что и спроизводительностью стало? Багов больше или меньше стало?
Clean Architecture, SOLID и святой Uncle Bob. Так и есть. Основной бизнес Дядюшки Боба - чтение лекций на тему CA, а не создание всяких систем. Об этом надо всегда помнить, когда читаешь его опусы :) В защиту MVVM скажу, что название, действительно, не слишком удачное, но разделение обязанностей в ней вполне адекватное.
Еще момент. Где-то, наверное, уже писал об этом. Важно различать знание и навык. Знание не всегда предполагает навык, и наоборот. Например, вы можете знать грамматику языка и выучить словарь, но заговорить на языке вам это мало поможет (я упрощаю, конечно). И на оборот, вы можете говорить на иностранном языке, но при этом не знать грамматику или знать очень поверхностно. В программирование тоже самое: рассуждать о коде и писать код - разные вещи. Поэтому, спрашивая, например, SOLID или устройство String в Java, нельзя предполагать что человек сможет написать реализацию строк или применить принципы SOLID. И обратное, можно писать вполне сносный код и не знать что есть SOLID или как устроены строки.
Проблема в том что вы фокусируетесь на вопросах, а надо смотреть на кандидата. Про тот же HashSet, например, можно не один час рассказывать, но ожидается ведь не это, а какой-то вполне определенного формата ответ. Если вопросов 10, то времени мало на развернутый ответ и дадут, может и не то что вы ожидаете. Я считаю, что давать надо такие вопросы, на которые кандидат расскажет что он знает, а не какой-то определенный ответ. Более открытые, как мне кажется. Нужно дать кандидату такую возможность, а не загонять его в прокрустово ложе формальных вопросов - ответов.
Эпитет про низкий уровень кандидатов я прочитал как "к нем не приходят из Caltech, MIT и Harvard", ну или из Российских топ-вузов, топ-компаний и тп. Интересно почему? Либо надо работать с тем что есть, либо придумать способ получить что хочешь.
D&I не относятся к этой статье. В статье много что опускается, т.к. иначе пришлось бы писать целую книгу. На счет метафор. Это вы зачем-то про D&I начали говорить и обсуждать проблемы найма в США, когда в статье больше говориться о проблемах найма в России. Вы на основе D&I предлагаете игнорировать всё остальное? Если нет, то причем тут D&I?
Я тоже слегка устал объяснять что на GC свет клином не сошелся. Есть и другие, более важные и релевантные вопросы.
а что ему нужно изучать...
Я понимаю, что у вас искажение профессиональное, и вы считаете что все что вы знаете - важно, и это должен знать каждый. Это очень и очень спорное утверждение. Даже если чисто технически подходить, то вопрос про GC почти бесполезен, т.к. позволяет узнать только про знания GC, но не позволяет ничего узнать про знания за пределами GC. Утверждение что "если знает GC в <язык>, то знает и, например, как работает <что-то еще> - очень и очень спорно. В iOS, до недавнего времени, не было GC, например, может и сейчас нет - я не знаю. Я еще раз повторю, задача интервьюера не выяснить знает ли кандидат ту или иную технологию - задача выяснить что он в целом знает и умеет. У меня вообще сложилось впечатление что большинство интервьюеров (тута) кроме GC больше ничего и не знают
Чтобы человек заинтересовал бигтех, он должен....
Я пол-статьи посвятил тому что ищет бигтех, а вы мне про Оракл пишите. Даже как-то обидно.
Вы отстали от темы в ветке. Речь не про администраторов, которые ключи тюнят, про software engineer. Они не тюнят ключи GC. Далее, если вы будете нанимать инженера, который над ядром работал, и на вопрос про алгоритмы GC HotSpot от ответит "я с этим не работал", то какие у вас буду дальнейшие действия? Отказ? Про прикладника я вообще молчу - там GC высплывает редко и до этого момента проекту надо еще дожить, а прикладнику - не уволиться. Предлагаю закрыть тему. Мне не удается расширить контекст восприятия этого вопроса за пределы "нужен или не нужен GC".
Нигде и не утверждается что они успешны именно из-за рекрутинга. Рекрутинг это важная часть, но не достаточная. В начале у них рекрутинг работал по одному сценарию, а потом - по другому. Если вы считаете что там рекрутинг не правильный - напишите об этом, было бы интересно почитать.
Я, кажется, уже дважды ответил на этот вопрос где-то. Это моя недоработка. Читайте это как "В культурах США и России есть различия". Какие именно - для данной статьи не сильно важно.
Тема про вопросы вообще большая и многогранная и коротко не ответишь на все. Давайте с другой стороны зайдем. У вас есть 100 вопросов - выберите 3, которые вы зададите на интервью. Все вопросы так или иначе имеют какую-то ценность. Какие-то больше, какие-то меньше. Мой аргумент в том что есть более релевантные вопросы, которые позволяют узнать больше о кандидате.
Я попробую по-коротче, т.к. многое в вашем ответе просто мелочь.
"много" и "мало", действительно, субъективная оценка, а вот 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 и рассуждений о чистых функциях, к ЧА он имеет отношение постольку-поскольку, со всеми же недостатками, которые ЧА игнорирует.
Seriously? Баги напрямую влияют на потребительские свойства продукта, а вы их не измеряете?
Меня интересует что вы оптимизируете и как вы это измеряете. Или у вас архитектура ради архитектуры?
Размытие кода "бесполезным кодом" во-первых ухудшит производительность разработчиков, т.к. на бесполезный код надо тратить время, во-вторых есть вполне реальный шанс что в "бесполезном коде" тоже будут баги, в-третьих вас уволят быстрее чем вы увидите разводнение :). Если же в бесполезном коде нет багов, то я бы присмотрелся как это так людям удается писать код без багов. ;)
вот и продемонстрируйте это на реальном примере.
Абсолютно нет - разработчики ЕДИНСТВЕННЫЙ источник багов. Чем их больше, тем больше багов, независимо от их квалификации.
Масштабный проект это марафон - быть первым на первых 5 минутах ничего не решают.
Первое, относительно итерфейсов и виртуальных вызовов, то компилятор, Proguard и R8 далеко не всегда делают коллапс, инлайнинг и статический вызов. Второе, оригинальная идея для введения интерфейсов была в том, что они, помимо полиморфизма, помогают изолированно тестировать компоненты. Как там с параметром Testability? Лучше? Хуже?
Из того что вы привели в статье такой вывод сделать сложно - не понятно что вы поменяли и как. Измерений вы тоже не привели, так что тоже не ясно. Без измерений это все только ваши субъективные ощущения.
Вы хорошо реагируете на критику. Только за это я бы ставил плюс каждому вашему комментарию. Но хотелось бы увидеть статью типа: вот проблема, вот тут мы измеряем, вот тут мы пытаемся ее решить, вот так поменялись параметры.
Цитата:
и далее
Я по-другому не могу это интерпретировать, кроме как "ЧА это то как мы ее представляем и конкретных критериев тут нет". Ну или проще говоря "как назову, так и будет"
Вот это уже интереснее, правда это не про масшатбируемость и я не понял причем тут 60+ разработчиков, если метрика про двух, но да ладно. Т.е. раньше два разработчика делали одну фичу за спринт, то теперь могут делать две за спринт.
Тут опять надо бы конкретику: сколько было, сколько стало, сколько удалили... Но это скорее другая статья ;)
5 минут не считается.
Извините, но это какой-то странный ответ. 5 классов это много или мало? А было сколько?
WAT? Это как?
Тут много что можно смотреть и мерять: рендеринг, время старта, память, батарейку, сеть и тп
Very nice code quality management. Вы в VK работаете да?
Я имел ввиду количество багов на 100 строк кода, например. Вы же удалили код, значит метрика должна была улучшиться, так? Можно чуть шире посмотреть, например на тестовое покрытие, которое тоже может улучшиться, когда удаляют код.
Хз. Мне кажется тут прямая зависимость. Чем больше разработчиков, тем больше багов. Разработчики источник багов жеж.
----------------------------
Да, я сегодня "токсик" и заноза в заднице. Пятница жеж :))
В общем, Чистая Архитектура это та архитектура которую мы называем Чистой. Ясно-понятно.
У вас в начале был разговор про масштабируемость, а в конце вывод что "время покажет". Так что с масштабируемостью-то стало? Она улучшилась или ухудшилась? На сколько? Сколько файлов теперь надо поменять для добавления новой фичи? Что и спроизводительностью стало? Багов больше или меньше стало?
Clean Architecture, SOLID и святой Uncle Bob. Так и есть. Основной бизнес Дядюшки Боба - чтение лекций на тему CA, а не создание всяких систем. Об этом надо всегда помнить, когда читаешь его опусы :)
В защиту MVVM скажу, что название, действительно, не слишком удачное, но разделение обязанностей в ней вполне адекватное.
Еще момент. Где-то, наверное, уже писал об этом. Важно различать знание и навык. Знание не всегда предполагает навык, и наоборот. Например, вы можете знать грамматику языка и выучить словарь, но заговорить на языке вам это мало поможет (я упрощаю, конечно). И на оборот, вы можете говорить на иностранном языке, но при этом не знать грамматику или знать очень поверхностно. В программирование тоже самое: рассуждать о коде и писать код - разные вещи. Поэтому, спрашивая, например, SOLID или устройство String в Java, нельзя предполагать что человек сможет написать реализацию строк или применить принципы SOLID. И обратное, можно писать вполне сносный код и не знать что есть SOLID или как устроены строки.
Обычно, кто умеет писать, тот умеет и читать. А вот обратное не всегда работает.
Проблема в том что вы фокусируетесь на вопросах, а надо смотреть на кандидата. Про тот же HashSet, например, можно не один час рассказывать, но ожидается ведь не это, а какой-то вполне определенного формата ответ. Если вопросов 10, то времени мало на развернутый ответ и дадут, может и не то что вы ожидаете. Я считаю, что давать надо такие вопросы, на которые кандидат расскажет что он знает, а не какой-то определенный ответ. Более открытые, как мне кажется. Нужно дать кандидату такую возможность, а не загонять его в прокрустово ложе формальных вопросов - ответов.
Конкретный алгоритм почти никогда не спрашивают на алгосекции. Важно умение распознать и применить.
Эпитет про низкий уровень кандидатов я прочитал как "к нем не приходят из Caltech, MIT и Harvard", ну или из Российских топ-вузов, топ-компаний и тп. Интересно почему?
Либо надо работать с тем что есть, либо придумать способ получить что хочешь.
D&I не относятся к этой статье. В статье много что опускается, т.к. иначе пришлось бы писать целую книгу.
На счет метафор. Это вы зачем-то про D&I начали говорить и обсуждать проблемы найма в США, когда в статье больше говориться о проблемах найма в России. Вы на основе D&I предлагаете игнорировать всё остальное? Если нет, то причем тут D&I?
извините, контекст потерял )
Я тоже слегка устал объяснять что на GC свет клином не сошелся. Есть и другие, более важные и релевантные вопросы.
Я понимаю, что у вас искажение профессиональное, и вы считаете что все что вы знаете - важно, и это должен знать каждый. Это очень и очень спорное утверждение. Даже если чисто технически подходить, то вопрос про GC почти бесполезен, т.к. позволяет узнать только про знания GC, но не позволяет ничего узнать про знания за пределами GC. Утверждение что "если знает GC в <язык>, то знает и, например, как работает <что-то еще> - очень и очень спорно. В iOS, до недавнего времени, не было GC, например, может и сейчас нет - я не знаю. Я еще раз повторю, задача интервьюера не выяснить знает ли кандидат ту или иную технологию - задача выяснить что он в целом знает и умеет.
У меня вообще сложилось впечатление что большинство интервьюеров (тута) кроме GC больше ничего и не знают
Я пол-статьи посвятил тому что ищет бигтех, а вы мне про Оракл пишите. Даже как-то обидно.
Вы отстали от темы в ветке. Речь не про администраторов, которые ключи тюнят, про software engineer. Они не тюнят ключи GC.
Далее, если вы будете нанимать инженера, который над ядром работал, и на вопрос про алгоритмы GC HotSpot от ответит "я с этим не работал", то какие у вас буду дальнейшие действия? Отказ?
Про прикладника я вообще молчу - там GC высплывает редко и до этого момента проекту надо еще дожить, а прикладнику - не уволиться.
Предлагаю закрыть тему. Мне не удается расширить контекст восприятия этого вопроса за пределы "нужен или не нужен GC".
вы забыли написать "были"
Нигде и не утверждается что они успешны именно из-за рекрутинга. Рекрутинг это важная часть, но не достаточная. В начале у них рекрутинг работал по одному сценарию, а потом - по другому. Если вы считаете что там рекрутинг не правильный - напишите об этом, было бы интересно почитать.
Ваш аргумент звучит примерно так: (1945 год) давайте не будем использовать германские ракетные технологии, потому что они нацисты с конц-лагерями.
У США полно проблем, никто не спорит с этим, но к теме это не относится.
Я, кажется, уже дважды ответил на этот вопрос где-то. Это моя недоработка. Читайте это как "В культурах США и России есть различия". Какие именно - для данной статьи не сильно важно.
Тема про вопросы вообще большая и многогранная и коротко не ответишь на все. Давайте с другой стороны зайдем. У вас есть 100 вопросов - выберите 3, которые вы зададите на интервью.
Все вопросы так или иначе имеют какую-то ценность. Какие-то больше, какие-то меньше. Мой аргумент в том что есть более релевантные вопросы, которые позволяют узнать больше о кандидате.
В любом случае это ваши, как компании, проблемы. Либо вы не там ищете, либо процесс найма сломан, либо вы решаете проблемы, оторванные от реальности.
предлагайте