Конкретно этот принцип подходит и для структурного программирования, и для функционального, и для любых других. И в ООП у SRP ровно такие же проблемы, как и из примеров в статье, т.е. можно было бы вынести код не в функцию, а в классы и было бы то же самое.
Да, все так. Статья в большей степени про то, что наивное восприятие принципа SRP приводит к проблемам, особенно у молодого поколения. Так-то сам принцип по разному формулировался Мартином в разное время и начинался с относительного "наивного" определения и пришел по итогу к по сути к принципу loose coupling & high cohesion. И LCHC на мой личный взгляд является более объемлющим и более применимым в разработке на самом разных уровнях.
Да, все так, именно поэтому я и написал, что "может смотрит". Вообще говоря каков поп - таков приход, и руководитель подбирает людей обычно под себя, в том числе под свои недостатки, например, авторитарные нанимают сотрудников, которые будут подчиняться, а слишком свободолюбивых просто не возьмут.
Автор, конечно, молодец, также как и разработчики. Мне, конечно же, хотелось как минимум показать вид "сверху", как на тебя, как на разработчика может, и зачастую, смотрит руководитель. Этот взгляд может показаться неправильным, не справедливым, полным себялюбия и превосходства со стороны менеджера, но он позволяет лучше понять поведение "менеджера", и почему он принимает те или иные решения. Мне кажется, вне зависимости от того, считаешь ты своего руководителя упырем или нет, понимать логику его поведения - как минимум полезно.
Вы знаете, и примерял, и примеряю. И могу сказать, что и сейчас я замечаю в себе и ждуна, и обиженку, и звезду, но стараюсь не давать им мешать мне жить и действовать продуктивно.
В документациях по микросервисной архитектуре для сложных сущностей рекомендуют делать микросервисы-витрины, которые агрегируют данные из микросервисов-сущностей и предоставляют их потребителям.
Если эти сервисы-сущности используются только в микросервисе витрине, то зачем они вообще нужны? Не проще ли будет сразу ходить в БД?
Если используют другие сервисы, то там будут собираться методы, которые нужны разным бизнес-процессам. И чтобы сделать изменения в сервисе — надо все-равно ходить и смотреть как в других сервисах используется — какие на самом деле есть ограничения и инварианты на сущность.
Кроме того, если такой сервис используется во многих бизнес процессах, то его падение приводит к критичным последствиям, при этом нагрузка на него большая в плане RPS, и количество фич, которые все хотят добавить в этот сервис тоже большое. Что приводит к ненадежной и сильносвязанной архитектуре.
Если интересно, что по этому поводу считают люди в целом по индустрии, то Фаулер тоже считает сервис-сущность антипаттерном, например.
Вообще говоря то, что код не удовлетворяет DDD НЕ является реальной проблемой. Реальной проблемой будет — если его будет тяжело читать, поддерживать, рефакторить и т.д и т.п.
DDD — это лишь один из способов проектирования. Фактически любой код — это лишь человекочитаемый способ записи большого и сложного вычисления. Как минимум, он может быть организован не только с помощью абстракции ООП, но и функционального, логического и мета программирования и т.д. Кроме того, один тот же кусок кода может быть раздекомпозирован огромным количеством способов даже в рамках ООП.
В том и дело, что нельзя строить иерархии наследования классов основываясь на свойствах объектов предметной области (похожи они друг на друга или нет). Все зависит от конкретного поведения класса, а не той абстракцией, которую он пытается моделировать.
Это на самом деле частая проблема обучающих статей про ООП. Когда пытаются рассказывать, что раз Coffe (кофе) — это подтип Drink (Напитка), то мы должны или не должны наследовать одно от другого. Но в жизни никто НЕ моделирует реальность as-is. И это классическая и грубая ошибка новичка. Если ты делаешь класс для расчета нагрузки на балки, чаще всего тебе не надо моделировать саму балку, а просто запрограммировать функцию расчета в зависимости входных параметров.
> Да, а в чем проблема? Разве тим лид не должен быть более зрелым и опытным, чем остальные члены команды? Сначала он выслушает все мнения, но решение в итоге принимает он.
Одновременно разбираться во всем невозможно. Быть самым умным чуваком в команде можно только в том случае, если ты управляешь джунами-мидлами.
> Я вижу такой подход более эффективным, чем псевдодемократия.
В скраме нет задачи сделать всем хорошо, в скраме есть задача сделать качественный продукт за минимальное время.
Псевдодемократии — нет. При принятии рабочих решений есть критерий, который все знают, и которым руководствуются. Если критерий не срабатывают — идут к медиатору (и это совсем не обязательно начальник), который решает конфликт.
Демократия и обсуждения нужны для того, чтобы все понимали, что сейчас происходит. Эта прозрачность дает возможность всем принимать более качественные решения на местах.
> Так начальник в любом случае уволит того, кто его не устраивает. Но компетентный начальник будет больше оценивать профессиональные качества сотрудника, в то время как SCRUM-начальник может оценить только софт-скиллы (т.е., проще говоря, умение работать языком).
«Начальником», которые оценивает профессиональные качества сотрудником может быть функциональный руководитель — главный по фронту или главный по беку, который не входит в состав команды.
> Начальник и подчиненный изначально на разных ступенях, какой между ними может быть конфликт? Подчиненный говорит — начальник слушает. Начальник говорит — подчиненный выполняет. Не согласен с решением начальника? Выбор есть: смириться и делать, обращаться в высшие инстанции, увольняться, самому становиться руководителем.
Конфликт может быть любой — «Вася не нравится Пете-начальнику как человек, поэтому Пете Васе не дает премию». «Петя-начальник дает скучные и простые задаче Васе, Вася этим не доволен, но боится прийти к Пете, потому что его уволят». И т.д. и т.п.
Уход человека — это обычно самый плохой исход конфликта, потому что поиск нового человека и его адаптация — это очень затратно.
> Здесь интересно было бы послушать, как SCRUM мотивирует реально проявлять инициативу, а не радостно поддакивать на митингах и со всем соглашаться, оставаясь пассивным на деле. Как распределяется ответственность в команде, кто ее распределяет, и как применяется система поощрений и наказаний, если она вообще есть.
Скрам не призван решать эту проблему. Но в целом возможность брать на себя инициативу, определенная свобода в выборе технических решений и определении сроков, возможность видеть результаты своего труда вживую — это очень сильный мотиватор.
Скрам не решает проблему распределения отвтественности внутри команды. Считается, что люди сами между собой могут договорится. В целом у меня за несколько лет, в нескольких командах было не больше 5-6 конфликтов, когда люди не смогли договорится кто что делает и кто за что отвечает. И те решались на ретроспективе самостоятельно командой, либо между собой без эскалации наверх.
Система поощрений и наказаний тоже вне рамок скрама. Но обычно проста как палка — функциональный руководитель принимает решение о том поощрять человека или нет.
> Я допускаю, что если взять группу отборных высококвалифицированных японских трудоголиков, они могут показать очень высокий результат, работая по данной системе. Но это вовсе не означает, что эту методику можно перенести на всех остальных.
нельзя, поэтому главное требование к таким командам — это зрелость. Скрам не заработает в случае, если у нас склочная команда инфантильных разработчиков. Более того, в таких ситуациях скрам противопоказан.
> Т.е. если два фронтендера не могут определиться с выбором фреймворка, решающие голоса будут у девопса и бэкэндера?
Т.е. должен определять начальник (тим лид)? Т.е. он должен уметь разбираться прекрасно в бекенде, во фронтенде, в девопсе, в архитектуре и быть гуру разрешения конфликтов? Т.е. быть самым компетентным и самым лучшим во всем — как в софт-скиллах, так и в хард? Эх, если бы это было так — насколько лучше и спокойнее было бы в нашем мире.
> По факту, инакомыслящие и несогласные при такой методике из команды будут вынуждены уйти, не получив даже шанса на реализацию своих нестандартных или старомодных подходов. Останутся только приверженцы одинаковых взглядов и идей, одинаковых ценностей, как в какой-то тоталитарной секте.
Все так. Ровно так же как это происходит в случае начальника, который нанимает в команду только тех, кто ему нравится, с кем он может и хочет работать, и увольняет остальных. Т.е. вместо тоталитарный секты — авторитарная. Хотя какая разница какая секта, если работа сделана в срок? ;)
> Эх, если бы это было так — насколько лучше и спокойнее было бы в нашем мире.
А если конфликтов в команде много, то получается, что начальник по факту принимает все решения и чуть ли не один везет весь проект? В таком случае не проще ли научить команду саму принимать решения — дать критерии принятия решений, и помогать решать только важные и сложные конфликты?
Начальник — это очень часто ОДНА из сторон конфликта. И получается, что начальник должен разрешить конфликт, в котором он участвует. Совершенно очевидно, как будет конфликт решен и в чью пользу. И конфликты с начальником не будут разрешаться должным образом.
И по моему опыту проблема ровно обратная: конфликт разных инициатив встречается реже, чем отсутствие инициативы и проактивности со стороны разработчиков в принципе. Люди не хотят брать на себя ответственность, им проще, чтобы за них решил начальник.
выделенных тестировщиков — нет, но автотесты пишут разработчики, мы сознательно «убили» QA.
бизнес-аналитика в основном на плечах владельца продукта.
инжнерная часть — devops с настройкой пайпланов выкладки, мониторинг, алертинг все на стороне команды.
«Железная» часть — на стороне эксплуатации, которая не входит в команду.
Классический — это тот, который описан в статье винстона ройса, там одна итерация. Если говорить про массовое производство, то для снижения рисков тоже используются итерации/инкремент — НИОКР, прототипы и т.д. Только в массовом производстве нельзя сделать дешево инкремент — только отзыв партии в случае «бага», или нераспроданный товар на полках, в software дорабатывать инкрементам значительно дешевле. И надо этим пользоваться во всю.
На самом деле оценки в сторипоинтах — это траты. Результат планирования должен ответить на один простой вопрос «А сколько задач команда сможет сделать в текущем спринте? И каков план по достижению этой цели?». Сможешь это сделать без сторипоинтов — молодец, не сможешь — тоже молодец. No estimates, все дела.
> Классический waterfall, к слову, не так уж и плох для подавляющего большинства проектов с конечным сроком жизни.
для IT проектов waterfall не хорош примерно никогда. Главное преимущество итеративной и инкрементальной разработки не в точности оценок или плана, а в управлении рисками. Частые релизы снижают интеграционные и продуктовые риски. В классических waterfall проектах, все риски скопом ловишь в фазе интеграционного тестирования.
> Другими словами, руководство перекладывает часть своих обязанностей на команду? Логично, пусть «тыжпрограммисты» думают — они же в очках и умные. Но в чем тогда функция руководства? Увольнять и делить прибыль?
В скраме функция руководства, точнее того, что не отдано на откуп команде — это обеспечение ресурсами — рабочее место, сервера и т.д, плюс верхнеуровневое целеполагание, ну и увольнять и делить прибыль, как правильно замечено. «Перекладывание» ответственности — это просто необходимость, потому что в условиях высокой неопределенности централизация менеджмента становится крайне неэффективной.
> То есть тем, кто понаглее, и громче кричит? Кто и как определяет здравость этих идей? Каким-то общим голосованием? За кем последнее слово? Тут я серьезно спрашиваю, без сарказма.
У команд есть обычно командные правила относительно того, как принимаются решения. Это может быть консенсус — все должны быть согласны или не-против, большинство — мнение большинства, это может быть апрув самого важного по функциональной части. Или все три.
Предполагается, что люди в команде обычно взрослые и зрелые и могут договорится друг с другом. Если работать в команде кому-то не нравится, или команде не нравится, как кто-то работает, совершенно спокойно можно это обсудить, для этого в скраме есть специальная встреча — ретроспектива. И по результатам, либо меняются процессы, либо, например, человек может покинуть команду.
> Хотя если команда компетентна, регулярно повышает свой уровень компетентности, то зачем ей траты времени на всякие организационные мероприятия.
Команда подразумевает совместную работу над продуктом в скраме. Совместная работа предполагает необходимость договариваться, обсуждать и принимать решения. Собственно, все встречи в скраме так или иначе про это. И без этих встреч эффективность была бы хуже — лебедь, рак и щука тянули бы в разные стороны.
> Также, если на первое место выводится здравомыслие, навыки и опыт, то зачем нужна производственная иерархия
Скрам про организацию не любых работ или проектов, а только в применении к разработке продуктов в небольших (до 9 человек) кросс-функциональных командах
это и называется организовать работу ;) Собственно скрам, канбан и весь остальной аджайл вроде именно про то, как «наладить взаимодействие в команде». Подходят ли конкретные практики для компании и команды и как они «внедряются» — это конечно отдельный разговор.
pytest смотрели? Он конечно полон магии и колдунства, а в код внутри лучше не заглядывать, но после него на обычные xunit фреймворки смотреть не хочется.
Спасибо, поправил.
Конкретно этот принцип подходит и для структурного программирования, и для функционального, и для любых других. И в ООП у SRP ровно такие же проблемы, как и из примеров в статье, т.е. можно было бы вынести код не в функцию, а в классы и было бы то же самое.
Да, все так. Статья в большей степени про то, что наивное восприятие принципа SRP приводит к проблемам, особенно у молодого поколения. Так-то сам принцип по разному формулировался Мартином в разное время и начинался с относительного "наивного" определения и пришел по итогу к по сути к принципу loose coupling & high cohesion. И LCHC на мой личный взгляд является более объемлющим и более применимым в разработке на самом разных уровнях.
Да, все так, именно поэтому я и написал, что "может смотрит". Вообще говоря каков поп - таков приход, и руководитель подбирает людей обычно под себя, в том числе под свои недостатки, например, авторитарные нанимают сотрудников, которые будут подчиняться, а слишком свободолюбивых просто не возьмут.
Автор, конечно, молодец, также как и разработчики. Мне, конечно же, хотелось как минимум показать вид "сверху", как на тебя, как на разработчика может, и зачастую, смотрит руководитель. Этот взгляд может показаться неправильным, не справедливым, полным себялюбия и превосходства со стороны менеджера, но он позволяет лучше понять поведение "менеджера", и почему он принимает те или иные решения. Мне кажется, вне зависимости от того, считаешь ты своего руководителя упырем или нет, понимать логику его поведения - как минимум полезно.
Вы знаете, и примерял, и примеряю. И могу сказать, что и сейчас я замечаю в себе и ждуна, и обиженку, и звезду, но стараюсь не давать им мешать мне жить и действовать продуктивно.
Если эти сервисы-сущности используются только в микросервисе витрине, то зачем они вообще нужны? Не проще ли будет сразу ходить в БД?
Если используют другие сервисы, то там будут собираться методы, которые нужны разным бизнес-процессам. И чтобы сделать изменения в сервисе — надо все-равно ходить и смотреть как в других сервисах используется — какие на самом деле есть ограничения и инварианты на сущность.
Кроме того, если такой сервис используется во многих бизнес процессах, то его падение приводит к критичным последствиям, при этом нагрузка на него большая в плане RPS, и количество фич, которые все хотят добавить в этот сервис тоже большое. Что приводит к ненадежной и сильносвязанной архитектуре.
Если интересно, что по этому поводу считают люди в целом по индустрии, то Фаулер тоже считает сервис-сущность антипаттерном, например.
DDD — это лишь один из способов проектирования. Фактически любой код — это лишь человекочитаемый способ записи большого и сложного вычисления. Как минимум, он может быть организован не только с помощью абстракции ООП, но и функционального, логического и мета программирования и т.д. Кроме того, один тот же кусок кода может быть раздекомпозирован огромным количеством способов даже в рамках ООП.
Это на самом деле частая проблема обучающих статей про ООП. Когда пытаются рассказывать, что раз Coffe (кофе) — это подтип Drink (Напитка), то мы должны или не должны наследовать одно от другого. Но в жизни никто НЕ моделирует реальность as-is. И это классическая и грубая ошибка новичка. Если ты делаешь класс для расчета нагрузки на балки, чаще всего тебе не надо моделировать саму балку, а просто запрограммировать функцию расчета в зависимости входных параметров.
Одновременно разбираться во всем невозможно. Быть самым умным чуваком в команде можно только в том случае, если ты управляешь джунами-мидлами.
> Я вижу такой подход более эффективным, чем псевдодемократия.
В скраме нет задачи сделать всем хорошо, в скраме есть задача сделать качественный продукт за минимальное время.
Псевдодемократии — нет. При принятии рабочих решений есть критерий, который все знают, и которым руководствуются. Если критерий не срабатывают — идут к медиатору (и это совсем не обязательно начальник), который решает конфликт.
Демократия и обсуждения нужны для того, чтобы все понимали, что сейчас происходит. Эта прозрачность дает возможность всем принимать более качественные решения на местах.
> Так начальник в любом случае уволит того, кто его не устраивает. Но компетентный начальник будет больше оценивать профессиональные качества сотрудника, в то время как SCRUM-начальник может оценить только софт-скиллы (т.е., проще говоря, умение работать языком).
«Начальником», которые оценивает профессиональные качества сотрудником может быть функциональный руководитель — главный по фронту или главный по беку, который не входит в состав команды.
> Начальник и подчиненный изначально на разных ступенях, какой между ними может быть конфликт? Подчиненный говорит — начальник слушает. Начальник говорит — подчиненный выполняет. Не согласен с решением начальника? Выбор есть: смириться и делать, обращаться в высшие инстанции, увольняться, самому становиться руководителем.
Конфликт может быть любой — «Вася не нравится Пете-начальнику как человек, поэтому Пете Васе не дает премию». «Петя-начальник дает скучные и простые задаче Васе, Вася этим не доволен, но боится прийти к Пете, потому что его уволят». И т.д. и т.п.
Уход человека — это обычно самый плохой исход конфликта, потому что поиск нового человека и его адаптация — это очень затратно.
> Здесь интересно было бы послушать, как SCRUM мотивирует реально проявлять инициативу, а не радостно поддакивать на митингах и со всем соглашаться, оставаясь пассивным на деле. Как распределяется ответственность в команде, кто ее распределяет, и как применяется система поощрений и наказаний, если она вообще есть.
Скрам не призван решать эту проблему. Но в целом возможность брать на себя инициативу, определенная свобода в выборе технических решений и определении сроков, возможность видеть результаты своего труда вживую — это очень сильный мотиватор.
Скрам не решает проблему распределения отвтественности внутри команды. Считается, что люди сами между собой могут договорится. В целом у меня за несколько лет, в нескольких командах было не больше 5-6 конфликтов, когда люди не смогли договорится кто что делает и кто за что отвечает. И те решались на ретроспективе самостоятельно командой, либо между собой без эскалации наверх.
Система поощрений и наказаний тоже вне рамок скрама. Но обычно проста как палка — функциональный руководитель принимает решение о том поощрять человека или нет.
> Я допускаю, что если взять группу отборных высококвалифицированных японских трудоголиков, они могут показать очень высокий результат, работая по данной системе. Но это вовсе не означает, что эту методику можно перенести на всех остальных.
нельзя, поэтому главное требование к таким командам — это зрелость. Скрам не заработает в случае, если у нас склочная команда инфантильных разработчиков. Более того, в таких ситуациях скрам противопоказан.
Т.е. должен определять начальник (тим лид)? Т.е. он должен уметь разбираться прекрасно в бекенде, во фронтенде, в девопсе, в архитектуре и быть гуру разрешения конфликтов? Т.е. быть самым компетентным и самым лучшим во всем — как в софт-скиллах, так и в хард? Эх, если бы это было так — насколько лучше и спокойнее было бы в нашем мире.
> По факту, инакомыслящие и несогласные при такой методике из команды будут вынуждены уйти, не получив даже шанса на реализацию своих нестандартных или старомодных подходов. Останутся только приверженцы одинаковых взглядов и идей, одинаковых ценностей, как в какой-то тоталитарной секте.
Все так. Ровно так же как это происходит в случае начальника, который нанимает в команду только тех, кто ему нравится, с кем он может и хочет работать, и увольняет остальных. Т.е. вместо тоталитарный секты — авторитарная. Хотя какая разница какая секта, если работа сделана в срок? ;)
> Эх, если бы это было так — насколько лучше и спокойнее было бы в нашем мире.
А если конфликтов в команде много, то получается, что начальник по факту принимает все решения и чуть ли не один везет весь проект? В таком случае не проще ли научить команду саму принимать решения — дать критерии принятия решений, и помогать решать только важные и сложные конфликты?
Начальник — это очень часто ОДНА из сторон конфликта. И получается, что начальник должен разрешить конфликт, в котором он участвует. Совершенно очевидно, как будет конфликт решен и в чью пользу. И конфликты с начальником не будут разрешаться должным образом.
И по моему опыту проблема ровно обратная: конфликт разных инициатив встречается реже, чем отсутствие инициативы и проактивности со стороны разработчиков в принципе. Люди не хотят брать на себя ответственность, им проще, чтобы за них решил начальник.
выделенных тестировщиков — нет, но автотесты пишут разработчики, мы сознательно «убили» QA.
бизнес-аналитика в основном на плечах владельца продукта.
инжнерная часть — devops с настройкой пайпланов выкладки, мониторинг, алертинг все на стороне команды.
«Железная» часть — на стороне эксплуатации, которая не входит в команду.
для IT проектов waterfall не хорош примерно никогда. Главное преимущество итеративной и инкрементальной разработки не в точности оценок или плана, а в управлении рисками. Частые релизы снижают интеграционные и продуктовые риски. В классических waterfall проектах, все риски скопом ловишь в фазе интеграционного тестирования.
В скраме функция руководства, точнее того, что не отдано на откуп команде — это обеспечение ресурсами — рабочее место, сервера и т.д, плюс верхнеуровневое целеполагание, ну и увольнять и делить прибыль, как правильно замечено. «Перекладывание» ответственности — это просто необходимость, потому что в условиях высокой неопределенности централизация менеджмента становится крайне неэффективной.
> То есть тем, кто понаглее, и громче кричит? Кто и как определяет здравость этих идей? Каким-то общим голосованием? За кем последнее слово? Тут я серьезно спрашиваю, без сарказма.
У команд есть обычно командные правила относительно того, как принимаются решения. Это может быть консенсус — все должны быть согласны или не-против, большинство — мнение большинства, это может быть апрув самого важного по функциональной части. Или все три.
Предполагается, что люди в команде обычно взрослые и зрелые и могут договорится друг с другом. Если работать в команде кому-то не нравится, или команде не нравится, как кто-то работает, совершенно спокойно можно это обсудить, для этого в скраме есть специальная встреча — ретроспектива. И по результатам, либо меняются процессы, либо, например, человек может покинуть команду.
Команда подразумевает совместную работу над продуктом в скраме. Совместная работа предполагает необходимость договариваться, обсуждать и принимать решения. Собственно, все встречи в скраме так или иначе про это. И без этих встреч эффективность была бы хуже — лебедь, рак и щука тянули бы в разные стороны.
> Также, если на первое место выводится здравомыслие, навыки и опыт, то зачем нужна производственная иерархия
Скрам про организацию не любых работ или проектов, а только в применении к разработке продуктов в небольших (до 9 человек) кросс-функциональных командах
это и называется организовать работу ;) Собственно скрам, канбан и весь остальной аджайл вроде именно про то, как «наладить взаимодействие в команде». Подходят ли конкретные практики для компании и команды и как они «внедряются» — это конечно отдельный разговор.