В Amazon таких нет, представляете? Есть много команд, пилящих инфраструктуру (для пайплайнов в том числе). Но каждая сервисная команда сата содержит свои пайплайны — DevOps
"не дали времени на..." — это проблема либо моя (плохо сигнализирую "красные флаги"), но чаще — менеджмента с "датой наперед" в голове плюс с пресловутым "и так сойдет".
It depends. Иными словами, не все. Наша основная проблема в том, что многие утверждают "задача выполнена", когда на деле — нет. классическая такая "Developer calls it done".
Лично меня разбирает сарказм, когда в попытке угодить менеджменту и срокам сверху разработчики упускают слишком много дефектов.
Я борюсь за Scrum's "done-done-done". Чаще всего, это требует замедления команды. И как правило, это воспринимают это как элементарное "сделать как можно меньше и получить за это как можно больше", а не как профессионализм и борьбу за Качество.
Это ее перефразирование, поскольку утрачен исходный смысл. Я вижу большую разницу между "планы бесполезны, но важны" и "планы ничего не стоят, но планирование это всё".
Так или иначе, моя мысль была о том, что планы ценны даже если и не соблюдаются и на 50%. Спасибо, что дали подсказку про первоисточник.
Да, планы как правило не выполняются. Это совсем не значит, что они бесполезны. Максимум, план может иметь ограниченную полезность для конкретного применения (равно как и любой другой инструмент).
План это модель прогресса проекта.
All models are wrong but some are useful — George E. P. Box
"Количество полезности" плана, риски (стоимость) игнориования/фиксации плана, и многое другое определяют степень его важности.
Про 95% — чистая правда, но не все это понимают. Недавно пересаживал одну команду с архаики SVN на Git. БОльшая часть команды осваивала постепенно с базовых 5 команд к чему-то поумнее, типа cherry-pick, rebase [-i], и так далее. Но были и люди, которые привыкли учить что-либо "наскоком и целиком", как по учебнику. Вот они страдали больше, потому что learning curve выглядел для них хуже...
Спасибо за комментарий по существу вместо балабольства о жигулях vs мерседесах!
Можете привести пример того, когда важно знать, в какой ветке родился commit? С Git это и правда не определить. Так что, например, после cherry-pick так сразу и не скажешь, что откуда пришло (но мне и не приходилось задаваться вопросом).
Насколько можно доверять вашим замерам? Полноценный бенчмаркинг дело нелегкое, люди обычно пишут используют фреймворки, чтобы замеры были как можно более чистыми. По типу https://github.com/dotnet/BenchmarkDotNet для .NET
Если я правильно понимаю, то библиотека собирает из оригинальных бенчмарков другие бинарные артефакты, которые используются непосредственно в рантайме для оценки времени исполнения. А как дебажить это дело, если, брейкпойнты привязаны к оригинальному коду и ничего их волшебно не отображает на правильные места в новых бинарниках?
В Amazon таких нет, представляете? Есть много команд, пилящих инфраструктуру (для пайплайнов в том числе). Но каждая сервисная команда сата содержит свои пайплайны — DevOps
паубивав бы за такие грязные хаки!
"Pipeline сломат" — это моя проблема.
"QA несогласны" — это моя проблема.
"performance просел" — это моя проблема.
"не дали времени на..." — это проблема либо моя (плохо сигнализирую "красные флаги"), но чаще — менеджмента с "датой наперед" в голове плюс с пресловутым "и так сойдет".
It depends. Иными словами, не все. Наша основная проблема в том, что многие утверждают "задача выполнена", когда на деле — нет. классическая такая "Developer calls it done".
Лично меня разбирает сарказм, когда в попытке угодить менеджменту и срокам сверху разработчики упускают слишком много дефектов.
Я борюсь за Scrum's "done-done-done". Чаще всего, это требует замедления команды. И как правило, это воспринимают это как элементарное "сделать как можно меньше и получить за это как можно больше", а не как профессионализм и борьбу за Качество.
Так яснее?
O'RLY? Смею предположить, что это, мягко говоря, не так. Особенно если в вашей компании толковые разработчики.
"Bother to explain"?
Link please?
Это ее перефразирование, поскольку утрачен исходный смысл. Я вижу большую разницу между "планы бесполезны, но важны" и "планы ничего не стоят, но планирование это всё".
Так или иначе, моя мысль была о том, что планы ценны даже если и не соблюдаются и на 50%. Спасибо, что дали подсказку про первоисточник.
Что бы это значило? Это шутка такая?
Да, планы как правило не выполняются. Это совсем не значит, что они бесполезны. Максимум, план может иметь ограниченную полезность для конкретного применения (равно как и любой другой инструмент).
План это модель прогресса проекта.
"Количество полезности" плана, риски (стоимость) игнориования/фиксации плана, и многое другое определяют степень его важности.
Про 95% — чистая правда, но не все это понимают. Недавно пересаживал одну команду с архаики SVN на Git. БОльшая часть команды осваивала постепенно с базовых 5 команд к чему-то поумнее, типа cherry-pick, rebase [-i], и так далее. Но были и люди, которые привыкли учить что-либо "наскоком и целиком", как по учебнику. Вот они страдали больше, потому что learning curve выглядел для них хуже...
Привязка к корп серверу и интернету вообще большое зло. Автономность с Hg/Git/… даёт большой выйгрыш при "переключении контекста".
Спасибо за комментарий по существу вместо балабольства о жигулях vs мерседесах!
Можете привести пример того, когда важно знать, в какой ветке родился commit? С Git это и правда не определить. Так что, например, после cherry-pick так сразу и не скажешь, что откуда пришло (но мне и не приходилось задаваться вопросом).
Really?
https://www.quora.com/How-did-prehistoric-humans-kill-mammoths
Насколько можно доверять вашим замерам? Полноценный бенчмаркинг дело нелегкое, люди обычно пишут используют фреймворки, чтобы замеры были как можно более чистыми. По типу https://github.com/dotnet/BenchmarkDotNet для .NET
Как я вас понимаю!
дальше читать не стал.
sorttest.zip
во времена GitHub :(И дальше идет пример параноидального программирования. Это совсем не то же самое, что и защитное программирование.
«защитное программирование» это не есть «стелить солому везде, где только можно»