Хорошая статья. Сам думал написать что-то такое, так как пришел к похожим выводам.
Диктатуру можно реализовать и по другому. Есть решения, которые просто делегируются вниз, команде, и, какое решение команда бы ни приняла, это не имеет стратегического значения или риска. Есть вопросы, по которым руководитель убежден в правильности определенного решения и ему тут демократия не нужна. Остальные вопросы (их большинство) можно принимать по схеме 3х этапов: первый этап обсуждение, в котором все имеют право высказывать мнение и все, высказавшие мнение получают искреннюю благодарность и (обязательно!) обратную связь - даже отрицательную, когда (и почему) предложение отклоняется; это позволяет людям учиться мыслить, отделять важное от неважного, видеть суть и не забывать про временнОе измерение - принимать решение надо так, чтобы не аукнулось в будущем; на втором этапе руководитель принимает решения на основе всего мозгового штурма, тут уже диктатура; на третьем этапе принятое решение реализуется без недовольства. Такое тоже работает, если у руководителя есть авторитет.
Ответственность за диктаторские решения — целиком на вас
Ответственность за любые решения на вас. Это важно понимать и помнить =)
Не указано, что делегирование позволяет команде расти. Для некоторых работников это очень ценно и значимо.
Микросервисы используются не потому, что они проще, тут не о чем спорить, микросервисы намного сложнее. Это очевидно. Они используются для изоляции, горизонтального масштабирования, устойчивости к частичным отказам (и вообще - к существованию такого явления) и т.д. и т.п.
В любом случае, статья не про микросервисы vs монолит, мы обсуждаем незначительную деталь. Есть ли смысл?
Свойство монолита (любого, не только моего) - если падает, то падает всё. Неотъемлемое свойство монолита. Речь была про это, возможно, выражено не полностью ясно.
Мне статья понравилась, но заголовочек бы изменить. "Переворачивает" слишком громкое слово, скорее видоизменяет или модифицирует. ИИ на удивление "переворачивает" очень мало что. Кто-то уже утверждает, что код комментировать не надо, так как ИИ его поймет и так, или ИИ можно попросить объяснить. Что ошибочно, ведь ИИ не телепат и комментарии даже ему полезны. Кто-то вот утверждает, что закон Конвея перевернут. Не надо так.
Возможно Вы правы, у меня там акаунт уже сто лет, жаль это слышать, так как из гитхаба Ваше расширение вряд ли получит популярность, а оно того стоит. Найдите кого-то за пределами санкционных стран, чтобы он создал акаунт и передал его Вам.
Поддерживаю, всё написано верно, хоть и психологическим языком)) Команды, в которых не построена культура "тупых вопросов не бывает", в среднем, гораздо хуже тех, где таковое практикуется всеми, и даже руководитель не боится ошибиться и признает свои ошибки.
Собственно, культура "тупых вопросов не бывает" это часть здоровых производственных процессов, не достаточная, но необходимая.
Дык, основная фича - в интеграции локальной LLM с IDE Visual Studio =) Если Вас устраивает Ваш консольный инструментарий - то это прекрасно, пользуйтесь на здоровье! =) Ну или попробуйте использовать описанное расширение и сделать уже практические\железобетонные выводы о переходе для себя.
Не я один построил свою систему-вспомогашку поверх гитлаба, приятно знать :) У нас всё с одной стороны похоже, а с другой - совсем не похоже, но суть 100% та же. Удачи в развитии проекта!
Отдельные камиты никак не мешают быстро получать обратную связь от юнит (и других) тестов. Просто упаковывайте в каждый камит не только код, но и тесты, что в общем, и рекомендуется. Подход проверялся на практике, работает. Программисты принимают его умеренно-позитивно, умеренно - те, кто не хочет осваивать в гите искуссиство слияния и разделения камитов, а позитивно - тем, кому это интересно освоить.
Хоть статья и рекламная, добавлю еще одно соображение: делить работу на N МРов обычно не работает, если приняты строгие стандарты оформления МР - просто слишком трудоемко и само собой эта практика сходит на нет, если, конечно, тимлид не зверь (а зверем быть не надо).
С другой стороны, и автор тут транслирует старую истину, большие МРы проверяют а) долго б) поверхностно.
Есть ли компромисс? Компромисс есть: надо создавать один МР, но в нем организовывать камиты так, чтобы каждый камит имел отдельный, четкий, понятный смысл, описанный в камит-мессадже.
Тогда ревьювер может не проверять весь МР, а проверять МР по камитам и делать между ревью паузу, осталяя в МР сообщения типа "камит 3 - ОК".
Это всё равно требует хлопот от автора МРа (двигать камиты, объединять камиты), но сие есть гораздо более реалистичный сценарий, чем 10 МРов на задачу.
Представляется, что предложенный подход всё же лучше, хотя бы тем, не нужно переписывать методы выше по стеку на использование указанного враппера.
Генератор - не мой, но у нас он покрыл все случаи, а таких методов было несколько сотен. Да, генератор не всесилен, но он достаточно хорош для решения обсуждаемой задачи.
Про деградацию склонен согласиться, может быть допустимо в каких-то случаях, но зачем, если можно без неё?
Если я правильно Вас понял, в кодовой базе есть два метода, один асинк, второй синк с обсолетом. Это не означает одного источника правды! Если исправляется баг в асинк методе, его же надо будет исправить и в синк, несмотря на обсолет.
В любом случае, Ваши сомнения понятны, но ценность данной заметки в том, чтобы поделиться опытом, предложенная миграция - это ретроспектива реального опыта, а не теоретическое предложение. Работает.
Хорошая статья. Сам думал написать что-то такое, так как пришел к похожим выводам.
Диктатуру можно реализовать и по другому. Есть решения, которые просто делегируются вниз, команде, и, какое решение команда бы ни приняла, это не имеет стратегического значения или риска. Есть вопросы, по которым руководитель убежден в правильности определенного решения и ему тут демократия не нужна. Остальные вопросы (их большинство) можно принимать по схеме 3х этапов: первый этап обсуждение, в котором все имеют право высказывать мнение и все, высказавшие мнение получают искреннюю благодарность и (обязательно!) обратную связь - даже отрицательную, когда (и почему) предложение отклоняется; это позволяет людям учиться мыслить, отделять важное от неважного, видеть суть и не забывать про временнОе измерение - принимать решение надо так, чтобы не аукнулось в будущем; на втором этапе руководитель принимает решения на основе всего мозгового штурма, тут уже диктатура; на третьем этапе принятое решение реализуется без недовольства. Такое тоже работает, если у руководителя есть авторитет.
Ответственность за любые решения на вас. Это важно понимать и помнить =)
Не указано, что делегирование позволяет команде расти. Для некоторых работников это очень ценно и значимо.
Спасибо за статью.
Статья совсем не о перехода на микросервисы. Но не будем спорить. Каждому своё. Удачи!
Микросервисы используются не потому, что они проще, тут не о чем спорить, микросервисы намного сложнее. Это очевидно. Они используются для изоляции, горизонтального масштабирования, устойчивости к частичным отказам (и вообще - к существованию такого явления) и т.д. и т.п.
В любом случае, статья не про микросервисы vs монолит, мы обсуждаем незначительную деталь. Есть ли смысл?
Свойство монолита (любого, не только моего) - если падает, то падает всё. Неотъемлемое свойство монолита. Речь была про это, возможно, выражено не полностью ясно.
не в бровь, а в вирус!
Мне статья понравилась, но заголовочек бы изменить. "Переворачивает" слишком громкое слово, скорее видоизменяет или модифицирует. ИИ на удивление "переворачивает" очень мало что. Кто-то уже утверждает, что код комментировать не надо, так как ИИ его поймет и так, или ИИ можно попросить объяснить. Что ошибочно, ведь ИИ не телепат и комментарии даже ему полезны. Кто-то вот утверждает, что закон Конвея перевернут. Не надо так.
Возможно Вы правы, у меня там акаунт уже сто лет, жаль это слышать, так как из гитхаба Ваше расширение вряд ли получит популярность, а оно того стоит. Найдите кого-то за пределами санкционных стран, чтобы он создал акаунт и передал его Вам.
Хорошая работа, желаю удачи.
@a-yumashin это расширение опубликовано в visual studio marketplace? был бы рад поставить 5 звезд там.
Поддерживаю, всё написано верно, хоть и психологическим языком)) Команды, в которых не построена культура "тупых вопросов не бывает", в среднем, гораздо хуже тех, где таковое практикуется всеми, и даже руководитель не боится ошибиться и признает свои ошибки.
Собственно, культура "тупых вопросов не бывает" это часть здоровых производственных процессов, не достаточная, но необходимая.
Дык, основная фича - в интеграции локальной LLM с IDE Visual Studio =) Если Вас устраивает Ваш консольный инструментарий - то это прекрасно, пользуйтесь на здоровье! =) Ну или попробуйте использовать описанное расширение и сделать уже практические\железобетонные выводы о переходе для себя.
Если Вам нужна независимость от IDE, тогда проект не для Вас и главной фичи нет.
Не я один построил свою систему-вспомогашку поверх гитлаба, приятно знать :) У нас всё с одной стороны похоже, а с другой - совсем не похоже, но суть 100% та же. Удачи в развитии проекта!
Отдельные камиты никак не мешают быстро получать обратную связь от юнит (и других) тестов. Просто упаковывайте в каждый камит не только код, но и тесты, что в общем, и рекомендуется. Подход проверялся на практике, работает. Программисты принимают его умеренно-позитивно, умеренно - те, кто не хочет осваивать в гите искуссиство слияния и разделения камитов, а позитивно - тем, кому это интересно освоить.
Удачи!
Хоть статья и рекламная, добавлю еще одно соображение: делить работу на N МРов обычно не работает, если приняты строгие стандарты оформления МР - просто слишком трудоемко и само собой эта практика сходит на нет, если, конечно, тимлид не зверь (а зверем быть не надо).
С другой стороны, и автор тут транслирует старую истину, большие МРы проверяют а) долго б) поверхностно.
Есть ли компромисс? Компромисс есть: надо создавать один МР, но в нем организовывать камиты так, чтобы каждый камит имел отдельный, четкий, понятный смысл, описанный в камит-мессадже.
Тогда ревьювер может не проверять весь МР, а проверять МР по камитам и делать между ревью паузу, осталяя в МР сообщения типа "камит 3 - ОК".
Это всё равно требует хлопот от автора МРа (двигать камиты, объединять камиты), но сие есть гораздо более реалистичный сценарий, чем 10 МРов на задачу.
Я не понял до конца Ваш комментарий, но методов несколько сотен. Основное - БД, есть также диск и сеть.
Представляется, что предложенный подход всё же лучше, хотя бы тем, не нужно переписывать методы выше по стеку на использование указанного враппера.
Генератор - не мой, но у нас он покрыл все случаи, а таких методов было несколько сотен. Да, генератор не всесилен, но он достаточно хорош для решения обсуждаемой задачи.
Про деградацию склонен согласиться, может быть допустимо в каких-то случаях, но зачем, если можно без неё?
Если я правильно Вас понял, в кодовой базе есть два метода, один асинк, второй синк с обсолетом. Это не означает одного источника правды! Если исправляется баг в асинк методе, его же надо будет исправить и в синк, несмотря на обсолет.
В любом случае, Ваши сомнения понятны, но ценность данной заметки в том, чтобы поделиться опытом, предложенная миграция - это ретроспектива реального опыта, а не теоретическое предложение. Работает.
Спасибо за мнение!
Вероятно, Вы неправильно поняли смысл статьи. Как раз микроменеджментом в классическом понимании тут и не пахнет.
да, я это указал.
если под этим мы понимаем количество МР в единицу времени, то нет, такого не наблюдается.
спасибо за комментарии!
конечно, не обладая ресурсами и властью, реализовать такие реформы не получится.
к счастью, не на бумаге =)
Полагаю, если бы это писала нейросеть, то было бы как раз ЗС =) Да, МР это запрос за слияние.