Большое спасибо за комментарий, хотелось бы уточнить несколько моментов))
Модель Kano — дешёвый способ отприоритезировать сотню-другую features
1. Моделей Кано по факту несколько, так уж вышло
2. дешёвый способ — я бы не сказал что дешевый, если подход подразумевает исследование целевой аудитории, то провести его так чтобы самому доверять своим результатам — обычно дорого и трудно
3. сотню-другую features — опять же, для исследования аудитории можно говорить о десятках фичей, но уж точно не о сотне. Найти аудиторию которая станет усердно заполнять опросник из нескольких сотен вопросов, это кажется нереально.
Как их потом отклассифицировать (смогут ли feature скопировать быстро конкуренты, насколько дёшево или дорого их сделать) — не проблема респондента, он этого не знает и знать не должен.
4. Как их потом отклассифицировать не проблема респондента — действительно, подразумевается что респондент выражает свое отношение к фиче (важна она ему, или нет), а классификация — вопрос дальнейшего анализа
5. смогут ли feature скопировать быстро конкуренты, насколько дёшево или дорого их сделать — эти вопросы в большой степени лежат за пределами модели, уж точно нет смысла спрашивать об этом клиентов, тут вы правы
Вообще то я не говорил что у нас есть собственное решение, Migrations штука вполне стандартная и общедоступная. Тем не менее, вы угадали. Мы отказались от Migrations в сторону своего решения.
Я планирую написать вторую статью в продолжение, если к этой будет интерес.
Опять же, в целом вы правильно мыслите, кроме стандартных команд Migrations (init, up, down, status) мы добавили: sign, snapshot, copy и diff. Кроме того, мы частично автоматизировали UNDO, так что проблем с несимметричностью изменений должно стать меньше. На систематизацию простых миграций данных тоже есть планы.
И теперь сравните это со state-driven deployment подходом
Подход интересный, но организационно сложнее.
(ссылка на Red Gate)
1. А как будет собираться состояние к релизу — из тех патчей/ченжей/миграций?
2. Тогда получается что либо перед либо после релиза нужно собрать финальное состояние и положить его в код? Вроде как лишний шаг.
Мне кажется что такой вариант идеально подошел ты тому, мифическому, Oracle DBA из начала статьи.
И конечно же основная проблема в любом подходе к database deployment — это сохранение и миграция данных.
Миграция данных куда хуже, полностью с вами согласен.
Даже просто откатить DROP TABLE уже непростая задача.
У меня статья короче чем ваш комментарий, ну, поехали.
У всех подобных решений (change-driven deployment)...
Люди приходят к change-driven deployment не на пустом месте, а потому что есть
состояние которое нельзя потерять. В случае с кодом, который вы конечно привели
для контраста, старое состояние кода не имеет ценности и всегда его можно заменить
полным новым состоянием кода. Исключения: erlang и хранимые процедуры.
У нас вот тоже «исторически» внедрён подобный подход
Да, реализация решения не слишком сложная и для большого проекта реализовать
собственный инструмент может быть лучшим решением чем брать готовое.
Но! Попробуйте с таким подходом создать схему с нуля
Вы правы, с этим есть проблемы. В лучшем случае это долго, в худшем — не работает.
За миграциями приходится следить. Мне приходилось несколько раз патчить их ретроспективно.
Кроме того, к сожалению, наивно надеяться на то, что патчи разработчики будут делать правильные
Увы, вы правы. Средненькое решение тут — тестировать, хорошее — генерировать UNDO автоматически.
Спасибо за комментарий :)
Да, есть некоторое разнообразие в терминологии, вероятно database deployment patch это один из вариантов. M.Fowler использует термины «database changes are migrations», тут единого
стандарта нет.
Migrations или нечто подобное… выглядит немного напыщенной, т.к. подобный решений существует не один десяток… вы правы, но я и не утверждаю что Migrations это
единственное решение в своем классе, как видите.
Большое спасибо за любопытную статью, было очень интересно читать.
У меня получилось 27 вопросов, если вы не против, я отправлю их вам в личку.
Любопытно узнать ваше мнение. Вот вы говорите что используете SAFe,
а SAFe это lean-agile. Так вот, не кажется ли вам некоторым лицемерием
тот факт что у методологии, одним из ключевых принципов которой является
«Люди важнее процессов», на первой странице сайта размещена дигарамма процессов
размером со стену. Не видите ли вы в этом какого то подвоха?
...
final Тип имяЗначения = вычислитьИмяЗначения(параметр1, параметр2, ...);
Это может быть вполне хорошим способом структурировать код,
однако:
1. Имя метода типично будет дублировать имя значения и не несет нового смысла.
2. Для того чтобы понять как вычисляется значение нужно будет перейти
в тело метода, посмотреть логику там, потом вернуться и продолжить читать
основной метод. Муторно для одноразового метода.
3. Если параметров для вычисления много, одноразовый метод становится
еще и громоздким. Нужно будет не только придумать имена для всех
параметров но и держать их в голове при чтении.
Либо:
final Тип имяЗначения = ((Supplier<Тип>)()->{ … }).get();
Хотя в нашем подходе нет ничего экстраординарного, он во многом отличается от того, как принято писать код на Java. Тем не менее, кто-то может найти нечто полезное в нашем подходе и для себя.
Обратите внимание, я нигде не утверждаю что приведенные мною техники написания кода
являются единственно правильными. Наоборот, я подчеркиваю что они скорее отличаются
от общепринятого подхода к написанию Java кода.
Каждый разработчик при написании кода использует определенные приемы,
и код написанный подобным образом ему, само собой, кажется простым и понятным.
Приведенные мною примеры не являются типичными, так что на первый взгляд может показаться что они хуже читаются.
Приведенные выше примеры позволяют сделать код чуть менее сложным и чуть более выразительным. По крайней мере, для нас они полезны.
Надеюсь что они окажутся полезны и для кого то еще.
Но для этого нужно изменить некоторые привычки написания и чтения кода.
Это сложно, и вообще говоря, не обязательно.
Мысль в том что Java разработчики не умею решать задачи управления ресурсами,
дело не в том что задача сложная, но в том что в Java с такой проблемой приходится
сталкиваться слишком редко. Необходимый навык не вырабатывается.
Уверен, пытливый читатель может найти ошибку в приведенном мною примере
за пять, максимум десять минут. А когда суть ошибки становится ясна,
возникают логичные вопросы. Почему вопиющая ошибка не была видна сразу?
Что сделать для того чтобы подобные ошибки не повторялись в дальнейшем?
Возможно вас путает пример с определением типа браузера, поскольку кажется что эта логика может быть переиспользована, подразумевается что это не так и код одноразовый. Возможно не слишком удачный пример.
Тем не менее, вы апеллируете к тому что нужно вынести метод, но пример про другое.
У вас есть переменная, для ее вычисления вам нужно определить несколько дополнительных переменных которые далее вам не нужны.
Можно просто написать вычисления в коде метода, тогда читая дальнейшую логику
вам придется иметь в виду что есть еще дополнительные переменные, а потом окажется
что для дальнейшей логики они не нужны.
Либо, можно спрятать такие вычисления в Supplier, и тем самым показать что
про все промежуточные переменные дальше можно забыть, не только компилятору,
но и тому кто читает код.
Спасибо за комментарий. Вот вы говорите «у меня нет успешного опыта работы по аджайл-методике…», а как вы представляете себе «аджайл-методику»? Что именно вы под этим подразумеваете?
Конечно может, и не только гибким но и хорошим.
Если 看板 для вас работает, это отлично.
На всякий случай, хочу порекомендовать вам пару книг:
Джеффри К. Лайкер, Дао Toyota и
Мэри и Том Попендик, Бережливое производство программного обеспечения (увлекательное чтение).
Тем не менее, Kanban это всего лишь способ _сокращения_ waste перепроизводства
за счет ограничения объема незавершенной работы. Суть, если у вас на команду
уже, скажем, 6 задач в работе, вы не можете взять седьмую пока не закончите
одну из уже начатых. Очень разумно. Тем не менее, есть тонкости.
Вообще говоря, с точки зрения Toyota, Kanban это _один из самых плохих_
способов организации работы, и то к чему нужно стремиться — организации
потока производства единичных изделий. То есть вообще не браться за
вторую задачу пока не сделана первая. Это идеал, он не всегда достижим.
Также, нет ничего плохого в тактических инструментах, наоборот, они важны и нужны.
Kanban это техника организации _процессов_, это важно, но это тактика.
Scrum «больше» Kanban, поскольку позволяет работать с проектами,
а с точки зрения организации проекты сложнее процессов.
И да, Kanban был придуман до Agile, вот уж не знаю когда он был адаптирован к разработке. Scrum тоже был придуман до Agile. А что было придумано после 2001?
— все приходит с опытом, чтобы что то уметь, сначала нужно этому научиться.
Хорошие инженеры в гробу видали методологии управления
— не совсем взрослая позиция, если человеку все равно как он работает, он получит то что получит.
вы на короткой ноге с её руководителем
— а если не на короткой ноге, а наоборот, вы первый месяц в компании. У вас свежий взгляд, проблемы к которым все привыкли для вас очевидно, но, видите ли, ноги оказываются недостаточно короткими чтобы быть услышанным. Такое бывает.
те, кому надо — просто придут и спросят
— такое тоже случается, но не всегда.
Для того, чтобы открыто говорить о проблемах никакой agile не нужен.
— вы правы, нужна культура допускающая такую возможность. Как она называется не суть важно.
1. Моделей Кано по факту несколько, так уж вышло
2. дешёвый способ — я бы не сказал что дешевый, если подход подразумевает исследование целевой аудитории, то провести его так чтобы самому доверять своим результатам — обычно дорого и трудно
3. сотню-другую features — опять же, для исследования аудитории можно говорить о десятках фичей, но уж точно не о сотне. Найти аудиторию которая станет усердно заполнять опросник из нескольких сотен вопросов, это кажется нереально.
4. Как их потом отклассифицировать не проблема респондента — действительно, подразумевается что респондент выражает свое отношение к фиче (важна она ему, или нет), а классификация — вопрос дальнейшего анализа
5. смогут ли feature скопировать быстро конкуренты, насколько дёшево или дорого их сделать — эти вопросы в большой степени лежат за пределами модели, уж точно нет смысла спрашивать об этом клиентов, тут вы правы
P.S. Спасибо за картинки))
Я планирую написать вторую статью в продолжение, если к этой будет интерес.
Опять же, в целом вы правильно мыслите, кроме стандартных команд Migrations (init, up, down, status) мы добавили: sign, snapshot, copy и diff. Кроме того, мы частично автоматизировали UNDO, так что проблем с несимметричностью изменений должно стать меньше. На систематизацию простых миграций данных тоже есть планы.
Подход интересный, но организационно сложнее.
(ссылка на Red Gate)
1. А как будет собираться состояние к релизу — из тех патчей/ченжей/миграций?
2. Тогда получается что либо перед либо после релиза нужно собрать финальное состояние и положить его в код? Вроде как лишний шаг.
Мне кажется что такой вариант идеально подошел ты тому, мифическому, Oracle DBA из начала статьи.
Миграция данных куда хуже, полностью с вами согласен.
Даже просто откатить DROP TABLE уже непростая задача.
Люди приходят к change-driven deployment не на пустом месте, а потому что есть
состояние которое нельзя потерять. В случае с кодом, который вы конечно привели
для контраста, старое состояние кода не имеет ценности и всегда его можно заменить
полным новым состоянием кода. Исключения: erlang и хранимые процедуры.
Да, реализация решения не слишком сложная и для большого проекта реализовать
собственный инструмент может быть лучшим решением чем брать готовое.
Вы правы, с этим есть проблемы. В лучшем случае это долго, в худшем — не работает.
За миграциями приходится следить. Мне приходилось несколько раз патчить их ретроспективно.
Увы, вы правы. Средненькое решение тут — тестировать, хорошее — генерировать UNDO автоматически.
(Вторая половина ответа в следующем комментарии).
Да, есть некоторое разнообразие в терминологии, вероятно database deployment patch это один из вариантов. M.Fowler использует термины «database changes are migrations», тут единого
стандарта нет.
Migrations или нечто подобное… выглядит немного напыщенной, т.к. подобный решений существует не один десяток… вы правы, но я и не утверждаю что Migrations это
единственное решение в своем классе, как видите.
У меня получилось 27 вопросов, если вы не против, я отправлю их вам в личку.
Любопытно узнать ваше мнение. Вот вы говорите что используете SAFe,
а SAFe это lean-agile. Так вот, не кажется ли вам некоторым лицемерием
тот факт что у методологии, одним из ключевых принципов которой является
«Люди важнее процессов», на первой странице сайта размещена дигарамма процессов
размером со стену. Не видите ли вы в этом какого то подвоха?
Это может быть вполне хорошим способом структурировать код,
однако:
1. Имя метода типично будет дублировать имя значения и не несет нового смысла.
2. Для того чтобы понять как вычисляется значение нужно будет перейти
в тело метода, посмотреть логику там, потом вернуться и продолжить читать
основной метод. Муторно для одноразового метода.
3. Если параметров для вычисления много, одноразовый метод становится
еще и громоздким. Нужно будет не только придумать имена для всех
параметров но и держать их в голове при чтении.
Либо:
Обратите внимание, я нигде не утверждаю что приведенные мною техники написания кода
являются единственно правильными. Наоборот, я подчеркиваю что они скорее отличаются
от общепринятого подхода к написанию Java кода.
Каждый разработчик при написании кода использует определенные приемы,
и код написанный подобным образом ему, само собой, кажется простым и понятным.
Приведенные мною примеры не являются типичными, так что на первый взгляд может
показаться что они хуже читаются.
Надеюсь что они окажутся полезны и для кого то еще.
Но для этого нужно изменить некоторые привычки написания и чтения кода.
Это сложно, и вообще говоря, не обязательно.
дело не в том что задача сложная, но в том что в Java с такой проблемой приходится
сталкиваться слишком редко. Необходимый навык не вырабатывается.
Уверен, пытливый читатель может найти ошибку в приведенном мною примере
за пять, максимум десять минут. А когда суть ошибки становится ясна,
возникают логичные вопросы. Почему вопиющая ошибка не была видна сразу?
Что сделать для того чтобы подобные ошибки не повторялись в дальнейшем?
Остальное есть в статье, не буду повторяться.
Тем не менее, вы апеллируете к тому что нужно вынести метод, но пример про другое.
У вас есть переменная, для ее вычисления вам нужно определить несколько дополнительных переменных которые далее вам не нужны.
Можно просто написать вычисления в коде метода, тогда читая дальнейшую логику
вам придется иметь в виду что есть еще дополнительные переменные, а потом окажется
что для дальнейшей логики они не нужны.
Либо, можно спрятать такие вычисления в Supplier, и тем самым показать что
про все промежуточные переменные дальше можно забыть, не только компилятору,
но и тому кто читает код.
Кортежи это хорошо, иногда, но в Java их нет.
Если 看板 для вас работает, это отлично.
На всякий случай, хочу порекомендовать вам пару книг:
Джеффри К. Лайкер, Дао Toyota и
Мэри и Том Попендик, Бережливое производство программного обеспечения (увлекательное чтение).
Тем не менее, Kanban это всего лишь способ _сокращения_ waste перепроизводства
за счет ограничения объема незавершенной работы. Суть, если у вас на команду
уже, скажем, 6 задач в работе, вы не можете взять седьмую пока не закончите
одну из уже начатых. Очень разумно. Тем не менее, есть тонкости.
Вообще говоря, с точки зрения Toyota, Kanban это _один из самых плохих_
способов организации работы, и то к чему нужно стремиться — организации
потока производства единичных изделий. То есть вообще не браться за
вторую задачу пока не сделана первая. Это идеал, он не всегда достижим.
Также, нет ничего плохого в тактических инструментах, наоборот, они важны и нужны.
Kanban это техника организации _процессов_, это важно, но это тактика.
Scrum «больше» Kanban, поскольку позволяет работать с проектами,
а с точки зрения организации проекты сложнее процессов.
И да, Kanban был придуман до Agile, вот уж не знаю когда он был адаптирован к разработке. Scrum тоже был придуман до Agile. А что было придумано после 2001?
— все приходит с опытом, чтобы что то уметь, сначала нужно этому научиться.
— не совсем взрослая позиция, если человеку все равно как он работает, он получит то что получит.
— а если не на короткой ноге, а наоборот, вы первый месяц в компании. У вас свежий взгляд, проблемы к которым все привыкли для вас очевидно, но, видите ли, ноги оказываются недостаточно короткими чтобы быть услышанным. Такое бывает.
— такое тоже случается, но не всегда.
— вы правы, нужна культура допускающая такую возможность. Как она называется не суть важно.