Из всех скрам-церемоний я на самом деле положительно отношусь к дейликам и, как ни странно, к ретро. Сейчас и так все на удалёнке, никто никого не видит, общение, хотя бы по звонку, полезно. С Ретро то же самое.
Груминги постановок с командой, общекомандные демо - тоже полезные практики, но прибито ли это гвоздями к пресловутому "скрам-процессу"?
Спринты, с моей точки зрения, имеют смысл только тогда, когда они привязаны к релизам. На этапах R&D, MVP это просто бесполезная церемония.
Оценки не имеют смысла никогда. Будучи тим-лидом я мог оценить скорость доставки фичи плюс-минус палец без всяких циферок, просто понимая степень проработанности постановки, сложность открытых вопросов и валовой объём работы. Гадание на сторипойнтах точности не прибавит. И я совершенно согласен с посылом автора, что вся эта скрам-история - это создание иллюзии контроля для менеджеров среднего звена и красивых отчётиков для бизнеса.
Когда-то занимался схожим проектом - портирование COBOL-портянок на C#. Первый вопрос, который у меня возник - как вы собирались проверять корректность работы программы? Но в комментах я уже увидел ответ - через сравнение с образцами. У нас был такой же подход.
Второй момент, который у меня вызывает вопросы - а зачем вообще потребовалась трансляция именно на Java? Уже есть немало проектов, позволяющих приложениям COBOL уйти c мейнфреймов. В первую очередь GnuCobol. NetCobol ещё был, не знаю на сколько он сейчас жив.
Главной особенностью этих интструментов было то, что они не стремились конвертировать код COBOL во что-то красивое. GnuCobol транслировал в C, чтобы потом скормить эти файлы gcc. NetCobol, по-моему, прямо в IL фигачил. Т.е., платформа менялась, а код оставался на COBOL. Ну и в ходе работы над своим проектом я понял, почему так происходит. Слишком большое расстояние между COBOL и современными языками. Древовидные структуры, сплошные процедуры, произвольные переходы - всё это только в goto разворачивать и в state-машину с кучей флагов. Т.е., как ни крутись, красивый код из COBOL в общем случае не получишь, хоть на Java, хоть на C#. А вот научиться получать бинарники, совместимые с современными архитектурами - задача намного проще. Но она уже решена.
Я так и не понял, почему вам для задач по расписанию не использовать Quartz, а для задач из Кафки - решение для Кафки. Зачем вам нужно было "бескомпромиссное решение"?
Тестировщика овнер с PM первого задушат. Тестировщик воспринимается как самая низкая единица в _иерархии_, а тоже куда-то _лезет_. Быстро его поломают, особенно, если он будет один в окружении таскодробителей и KPI-достигателей. Наблюдал уже такое.
Всех этих "носителей плохих вестей" начальство воспринимает как экстремистов, которые покушаются на их "компетенции", а точнее, на место, занятое ими в феодальной IT-иерархии. Если выбор стоит между пользой продукту и личными интересами, то вопрос всегда будет решаться в пользу личных интересов. А связь личного интереса с пользой продукту в компаниях скорее исключение, а не правило.
Автор объясняет суть атомарности и объясняет правильно, вы же просто докапываетесь до мышей или до блох. Разумеется, в транзакции "ошибка" а-ля исключение, может быть перехвачена, а rollback может быть вызван без исключения-ошибки, на основе проверки бизнес-условий. Понятно почему автор не стал останавливаться на таких тривиальностях. Непонятно почему вы преподносите эти тривиальности с таким апломбом.
В структурах есть ссылочные типы, такие как String.
А почему не надо заменять классы структурами, если в структуре есть ссылочные типы? Что плохого случится, если я заменю record User(string Name, int Age) на readonly record struct User(string Name, int Age) ?
>Итак, предположим, у нас есть класс с массивами и структура с массивами . В первом случае массивы будут храниться в оперативной памяти нашего приложения, а во втором — в кэше процессора (с учетом некоторых особенностей сборки мусора, которые мы обсудим ниже).
Судя по примерам ниже, у вас речь не про классы/структуры с массивами, а про массивы классов и структур. Так дальнейшие рассуждения приобретают рамки хоть какого-то смысла. Т.е., становится понятно, что хотел сказать автор, но смысла в сказанном всё равно остаётся не много.
1. Структуры не хранятся в оперативной памяти? 2. Структуры гарантированно находятся в кэше процессора? 3. Классы не могут помещаться в кэш процессора?
А вот shrplab для обоих ваших вариантов с обходом цикла - и для "плохого" (где numbers[i]*numbers[i]) и для "хорошего" (где num*num) выдаёт одинаковый Asm Code. Выходит, компилятор запросто справляется с такого рода оптимизациями...
Продукт-менеджер ставит продуктовые задачи, а её декомпозицию на задачи разработчиков осуществляет тимлид. Вот он и должен принимать MR. Если на одного человека оказывается много нагрузки, а в команде достаточно сеньоров, то обязанности можно делить и тогда каждый сеньор будет "тимлидом" для своей _продуктовой_ задачи. Главное тут чтобы тот, кто проверяет MR, был глубоко погружён в проблематику общей (продуктовой) задачи, это лекарство от формальных ревью. И обычно этот человек тот, кто осуществил декомпозицию.
"А с майонезом огуречный"а со скрамом всё это сразу взлетит!Из всех скрам-церемоний я на самом деле положительно отношусь к дейликам и, как ни странно, к ретро. Сейчас и так все на удалёнке, никто никого не видит, общение, хотя бы по звонку, полезно. С Ретро то же самое.
Груминги постановок с командой, общекомандные демо - тоже полезные практики, но прибито ли это гвоздями к пресловутому "скрам-процессу"?
Спринты, с моей точки зрения, имеют смысл только тогда, когда они привязаны к релизам. На этапах R&D, MVP это просто бесполезная церемония.
Оценки не имеют смысла никогда. Будучи тим-лидом я мог оценить скорость доставки фичи плюс-минус палец без всяких циферок, просто понимая степень проработанности постановки, сложность открытых вопросов и валовой объём работы. Гадание на сторипойнтах точности не прибавит. И я совершенно согласен с посылом автора, что вся эта скрам-история - это создание иллюзии контроля для менеджеров среднего звена и красивых отчётиков для бизнеса.
Добавить в этот коктейль скрам-токсичности, как же ещё?
Т.е., скрам помогает так же редко, как ремень безопасности? А если помогает, то прям точно помогает?
Когда-то занимался схожим проектом - портирование COBOL-портянок на C#. Первый вопрос, который у меня возник - как вы собирались проверять корректность работы программы? Но в комментах я уже увидел ответ - через сравнение с образцами. У нас был такой же подход.
Второй момент, который у меня вызывает вопросы - а зачем вообще потребовалась трансляция именно на Java? Уже есть немало проектов, позволяющих приложениям COBOL уйти c мейнфреймов. В первую очередь GnuCobol. NetCobol ещё был, не знаю на сколько он сейчас жив.
Главной особенностью этих интструментов было то, что они не стремились конвертировать код COBOL во что-то красивое. GnuCobol транслировал в C, чтобы потом скормить эти файлы gcc. NetCobol, по-моему, прямо в IL фигачил. Т.е., платформа менялась, а код оставался на COBOL. Ну и в ходе работы над своим проектом я понял, почему так происходит. Слишком большое расстояние между COBOL и современными языками. Древовидные структуры, сплошные процедуры, произвольные переходы - всё это только в goto разворачивать и в state-машину с кучей флагов. Т.е., как ни крутись, красивый код из COBOL в общем случае не получишь, хоть на Java, хоть на C#. А вот научиться получать бинарники, совместимые с современными архитектурами - задача намного проще. Но она уже решена.
Мы так же делали, когда занимались транслированием COBOL на C#.
Я так и не понял, почему вам для задач по расписанию не использовать Quartz, а для задач из Кафки - решение для Кафки. Зачем вам нужно было "бескомпромиссное решение"?
В списке многовато "глыб" и "легенд". Да и "глыбовость" некоторых имён, мягко говоря, не бесспорна.
Тестировщика овнер с PM первого задушат. Тестировщик воспринимается как самая низкая единица в _иерархии_, а тоже куда-то _лезет_. Быстро его поломают, особенно, если он будет один в окружении таскодробителей и KPI-достигателей. Наблюдал уже такое.
Всех этих "носителей плохих вестей" начальство воспринимает как экстремистов, которые покушаются на их "компетенции", а точнее, на место, занятое ими в феодальной IT-иерархии. Если выбор стоит между пользой продукту и личными интересами, то вопрос всегда будет решаться в пользу личных интересов. А связь личного интереса с пользой продукту в компаниях скорее исключение, а не правило.
А как всё это хозяйство дебажить?
Автор объясняет суть атомарности и объясняет правильно, вы же просто докапываетесь до мышей или до блох. Разумеется, в транзакции "ошибка" а-ля исключение, может быть перехвачена, а rollback может быть вызван без исключения-ошибки, на основе проверки бизнес-условий. Понятно почему автор не стал останавливаться на таких тривиальностях. Непонятно почему вы преподносите эти тривиальности с таким апломбом.
Вот эти реальные вопросы на самом деле важны, а не бесконечное пережёвывание определения REST'а по Филдингу.
А вот при неполучении результата кэшируется исключение, так что с этим паттерном надо быть осмотрительным.
Когда не следует заменять классы структурами:
В структурах есть ссылочные типы, такие как String.
А почему не надо заменять классы структурами, если в структуре есть ссылочные типы? Что плохого случится, если я заменю
record User(string Name, int Age)наreadonly record struct User(string Name, int Age)?>Итак, предположим, у нас есть класс с массивами и структура с массивами . В первом случае массивы будут храниться в оперативной памяти нашего приложения, а во втором — в кэше процессора (с учетом некоторых особенностей сборки мусора, которые мы обсудим ниже).
Судя по примерам ниже, у вас речь не про классы/структуры с массивами, а про массивы классов и структур. Так дальнейшие рассуждения приобретают рамки хоть какого-то смысла. Т.е., становится понятно, что хотел сказать автор, но смысла в сказанном всё равно остаётся не много.
1. Структуры не хранятся в оперативной памяти?
2. Структуры гарантированно находятся в кэше процессора?
3. Классы не могут помещаться в кэш процессора?
Вопросы-вопросы...
Про TryGetValue автор статьи, взявшийся писать про оптимизацию использования CPU в C# не знает?
if(cache.ContainsKey(input)) {returncache[input]; }А вот shrplab для обоих ваших вариантов с обходом цикла - и для "плохого" (где numbers[i]*numbers[i]) и для "хорошего" (где num*num) выдаёт одинаковый Asm Code.
Выходит, компилятор запросто справляется с такого рода оптимизациями...
https://sharplab.io/#v2:C4LghgzgtgPgAgJgIwFgBQcDMACR2DC2A3utmbjgJYB2w2AskgBQ3ADaAuttQK5QBGAUwBOEAJTFS5aa2wQ+2ALzYADAG50U6WQBmAe2HYWtbJSWq1p7AB5ufIaIB0AGUHUA5sAAWlygGo/CRI0bVC5BT9lXgERCDZKLgAqOxjReI4NELCAXy1tPOk4AHZwqEzpXKyyPKxTE3oEY3YuaIdxSSrtWXkoc3VNTul9QyarZXUrW1bYlzdPH1MAoIKw2WjzabSE8rDpHuxIlOxk6J3Qyt2VsmLSs+xK7KA==
Подушню: а вариант "писать меньше логов" вам не подошёл?
Обратная совместимость сломается (кто знает, какую логику вы накрутили на Add в своей реализации ILIst).
Продукт-менеджер ставит продуктовые задачи, а её декомпозицию на задачи разработчиков осуществляет тимлид. Вот он и должен принимать MR. Если на одного человека оказывается много нагрузки, а в команде достаточно сеньоров, то обязанности можно делить и тогда каждый сеньор будет "тимлидом" для своей _продуктовой_ задачи. Главное тут чтобы тот, кто проверяет MR, был глубоко погружён в проблематику общей (продуктовой) задачи, это лекарство от формальных ревью. И обычно этот человек тот, кто осуществил декомпозицию.