Затрудняюсь вести диалог, если вы даже абстрактного школьника со смартфоном первым же сообщением заклеймили.
Если вы выбрали кактус сферу, в которой в принципе нет адекватного менеджмента в части работы с ИТ (такое бывает), и не хотите её менять, потому что это кажется оверкиллом, то... это ведь просто ваш выбор, а не повод делать выводы про менеджмент вообще где бы то ни было?
Разумно. Если критично время, то вредно под запрос устанавливать соединение. (у нас один разработчик смог даже на REST Proxy каждый раз устанавливать соединение)
Кстати, а почему Kafka, если важно время? Она вроде сильно хуже RabbitMQ по таймингам?
Ну конечно же не надо всегда досконально разбираться чтобы чем-то управлять. Однако стоит разделять ситуации, когда допустимо чем-то управлять без досконального понимания, а когда нет.
Вот школьник управляет своим смартфоном - думаете он досконально разбирается? Как это обеспечили? Просто дали ему некие понятные правила и ограничения, в которых он управляет, чтобы в ногу себе не стрелял.
Отдельная история - страдания технических специалистов, продолжающих есть кактус работать с некачественным менеджментом. Я не понимаю, в мире нет менеджмента качественного? Или их туда не берут? Или им лень поискать нормальный менеджмент?
Один момент на мой взгляд есть значимый. Думаю, в РФ более развита техническая школа, чем менеджмент, из-за чего есть перекос. Но всё равно, каждый сам решает, либо страдать, либо пробиваться в компании с качественным менеджментом.
А откуда взялось утверждение, что менеджмент по этим метрикам собирался сравнивать несравнимые команды? Есть какой-то список команд хотя-бы, чтобы делать выводы об невозможности их сравнить? Или менеджмент априори дураки и будут одни и те же требования предъявлять к машинам для перевозки пассажиров и сжиженного газа?
А как Вы поняли основную мысль этого текста? У меня ощущение, что если тут и есть какая-то основная мысль, то это примерно "Менеджмент только вредит, программисты легко и правильней всё сами решат".
Заменить прямой учет багов на проде на какие-то метрики CI/CD - это конструктивная критика?
Или может предложение использовать GIT для регистрации дефектов вместо JIRA?
Или креативная идея обязательно применить Trunk Based работу с 1 веткой не вдаваясь в реалии конкретной команды, продукта и требований к нему - тоже конструктив? Остальные подходы ведь придумали злые эффективные менеджеры, даже Scaled Trunk-Based.
Исходная статья https://habr.com/ru/company/tinkoff/blog/684608/ и перечисленные в ней подходы вполне адекватны, чего не могу сказать об этой статье. CI/CD не является панацеей при тестировании. И конечно никто CI/CD сжигать не предлагал в оригинальной статье, там даже слова такого нет.
Берём людей, которые дежурили и примерно 15% времени тушили пожары.
Говорим им, что теперь они будут за эти деньги работать в обратной пропорции - 15% дежурство, остальное - тушим пожары. Понимая, что на рынке такой объем тушения пожаров стоит совершенно других денег.
То что вы сильно связываете два микросервиса внутри системы/подсистемы, создавая еще один уровень абстракции/управления между микросервисом и системой/подсистемой. В общем случае так делать плохо с архитектурной точки зрения.
Звучит опасно - сначала тестируем конкретную связку, а потом "разный деплой".
В целом я не к тому что это ужас-ужас так делать, но на мой взгляд это тревожный звонок, если приходится выделять какое-то подмножество микросервисов из подсистемы и отдельно с ним работать.
Затрудняюсь вести диалог, если вы даже абстрактного школьника со смартфоном первым же сообщением заклеймили.
Если вы выбрали
кактуссферу, в которой в принципе нет адекватного менеджмента в части работы с ИТ (такое бывает), и не хотите её менять, потому что это кажется оверкиллом, то... это ведь просто ваш выбор, а не повод делать выводы про менеджмент вообще где бы то ни было?Разумно. Если критично время, то вредно под запрос устанавливать соединение.
(у нас один разработчик смог даже на REST Proxy каждый раз устанавливать соединение)
Кстати, а почему Kafka, если важно время? Она вроде сильно хуже RabbitMQ по таймингам?
Согласен, эволюционирующий самолёт
Ну конечно же не надо всегда досконально разбираться чтобы чем-то управлять. Однако стоит разделять ситуации, когда допустимо чем-то управлять без досконального понимания, а когда нет.
Вот школьник управляет своим смартфоном - думаете он досконально разбирается? Как это обеспечили? Просто дали ему некие понятные правила и ограничения, в которых он управляет, чтобы в ногу себе не стрелял.
Отдельная история - страдания технических специалистов, продолжающих
есть кактусработать с некачественным менеджментом. Я не понимаю, в мире нет менеджмента качественного? Или их туда не берут? Или им лень поискать нормальный менеджмент?Один момент на мой взгляд есть значимый. Думаю, в РФ более развита техническая школа, чем менеджмент, из-за чего есть перекос. Но всё равно, каждый сам решает, либо страдать, либо пробиваться в компании с качественным менеджментом.
Тогда через законы Мёрфи легко доказать что <вставьте роль> априори дураки.
Вы не находите это неконструктивным?
А откуда взялось утверждение, что менеджмент по этим метрикам собирался сравнивать несравнимые команды? Есть какой-то список команд хотя-бы, чтобы делать выводы об невозможности их сравнить? Или менеджмент априори дураки и будут одни и те же требования предъявлять к машинам для перевозки пассажиров и сжиженного газа?
А как Вы поняли основную мысль этого текста? У меня ощущение, что если тут и есть какая-то основная мысль, то это примерно "Менеджмент только вредит, программисты легко и правильней всё сами решат".
На мой взгляд это не работает в данном случае, т.к. тут "один и тот же самолёт".
Заменить прямой учет багов на проде на какие-то метрики CI/CD - это конструктивная критика?
Или может предложение использовать GIT для регистрации дефектов вместо JIRA?
Или креативная идея обязательно применить Trunk Based работу с 1 веткой не вдаваясь в реалии конкретной команды, продукта и требований к нему - тоже конструктив? Остальные подходы ведь придумали злые эффективные менеджеры, даже Scaled Trunk-Based.
Баг на проде это не обязательно Error/Exception в логе.
Идея исследования, которое покажет, что горизонтальное представление более удобное:
Заменить джойстик на кнопки. Поместить на кнопки пальцы разных рук (без перекрещивания рук).
Размещать кнопки как числа - либо горизонтально, либо вертикально.
Исходная статья https://habr.com/ru/company/tinkoff/blog/684608/ и перечисленные в ней подходы вполне адекватны, чего не могу сказать об этой статье. CI/CD не является панацеей при тестировании. И конечно никто CI/CD сжигать не предлагал в оригинальной статье, там даже слова такого нет.
Так, погодите, я правильно понимаю?
Берём людей, которые дежурили и примерно 15% времени тушили пожары.
Говорим им, что теперь они будут за эти деньги работать в обратной пропорции - 15% дежурство, остальное - тушим пожары. Понимая, что на рынке такой объем тушения пожаров стоит совершенно других денег.
Удивляемся тому, что фокус сразу не удался.
То что вы сильно связываете два микросервиса внутри системы/подсистемы, создавая еще один уровень абстракции/управления между микросервисом и системой/подсистемой. В общем случае так делать плохо с архитектурной точки зрения.
Звучит опасно - сначала тестируем конкретную связку, а потом "разный деплой".
В целом я не к тому что это ужас-ужас так делать, но на мой взгляд это тревожный звонок, если приходится выделять какое-то подмножество микросервисов из подсистемы и отдельно с ним работать.
Если нужно тестировать два микросервиса в связке, но не систему/подсистему целиком, то может лучше было делать один микросервис?
Однако считать так и не научились...
Если из крипты выводить, то крипта снижаться должна, а не расти.
Странная терминология в этой 1С, правда так, а не наоборот?
Программисты 1С - редко программируют, воспринимают это как отпуск
Разработчики 1С - только программируют, = купили квартиру у моря
Позвольте предположить, что вы пишете хрупкие автотесты с дублированием кода.
По той же причине почему шуруповерт не вытеснил из продажи отвертки. У них разные задачи.