Во первых, нет: там тернарный оператор, который есть просто альтернативная форма записи if/then/else. Во-вторых, такое упрятывание условных ветвлений не улучшает, а ухудшает читаемость кода.
Напишите как вы видите более лучшую реализацию для конкретно этого случая
Я для всех случаев вижу, что каждое средство языка должно использоваться на своём месте, и не должно быть никаких религиозных догм типа полного отказа от if/switch – это приводит к ненужному усложнению кода.
Без условных операторов, серьёзно? Я в этом коде вижу как минимум три условия: isValid, isCurrentDayData(), orElse().
выбор конкретной реализации может быть передан «фабрике» — что избавляет нас от необходимости реализации проверок в основном коде.
Дженерики использовать не судьба? Паттерн матчинг, в конце концов?
Зачем вообще всё это? Отказ от if/switch – это религия какая-то? В некоторых случаях это действительно приводит к трудночитаемому коду, но приведённые примеры к таковым не относятся.
P.S. Использование скриншотов вместо вставок кода – плохая практика, затрудняет цитирование.
Если вам не нравится Agile, значит вы готовите его неправильно. Это логическая уловка, известная как "Ни один истинный шотландец".
Нет, не уловка – это действительно так. Ловушка тут в том, что весь смысл эджайла в повышении гибкости процессов разработки, мгновенной реакции на изменение внешних факторов. Бизнес аналитик ошибся в постановке задачи? Не беда, это выявится в конце короткой итерации и будет исправлено в следующей. Баг, который выявляется только на ограниченном подмножестве юзеров на проде? То же самое. И так далее. И тут возникает некий абсурд: гибкость пытаются получить, навязывая жесточайшим образом прописанные методологии (привет, SCRUM): шаг вправо, шаг влево, прыжок на месте.... ну, вы знаете. Так оно проще, да: думать не надо, кто-то за вас уже подумал и расписал, как надо, по пунктам. На самом деле каждая компания и каждый проект имеет индивидуальные черты, игнорирование которых приводит к снижению эффективности. "Правильно приготовленный" эджайл сохраняет гибкость и скорость реакции в условиях конкретной компании/проекта. Для чего его надо именно что "приготовить": взять наиболее подходящую методологию и адаптировать её под себя.
Вероятно, это то, с чем столкнулся автор, и к его чести, попытался найти собственное решение. Но сейчас он делает ту же самую ошибку, пропагандируя его как единственно верное. Это не говоря уж о том, что в статье полно ругани по адресу других методологий (иногда обоснованной, иногда не очень), а вот предлагаемое решение описано на уровне "подписывайтесь на мой канал, там всё узнаете". Нет, это так не работает. Возможно, у автора есть идеи, которые можно было бы позаимствовать – но для этого их нужно внятно изложить. Пока не получилось. Единственное, что понятно – это тот же эджайл, но реализованный по-своему. Поэтому критика эджайла в целом, как проектной философии, тоже выглядит несколько неуместной.
Чем это лучше доступа к user.name, проверяемого при компиляции?
Эмм, благородный дон точно не ошибся дверью? 🙂 Я, собственно, именно это тут и пытался выяснить. Безуспешно – чему, впрочем, ничуть не удивлён, ибо таки хуже.
Вы совсем не понимаете, как работает эджайл. Очевидно, это вина тех "эффективных менеджеров", которые внедряли модные технологии, совершенно не разобравшись в их сути, и в результате испортили им репутацию у множества разработчиков. В настоящем эджайле нет буквально ничего из Вами описанного, это совсем иначе работает.
Не скрою, когда году в 2002 один заказчик (друган аж самого Кента Бека) принёс нам на хвосте хР, тоже сначала подумал: что за дичь такая. Но вскоре проникся – ибо результаты говорили сами за себя, нужно было быть дураком, чтобы не увидеть преимуществ. С тех пор сам несколько раз сам организовывал такую трансфомацию – и всегда это приводило к улучшениям. В том числе и к повышению удовлетворённости разработчиков. Например, сейчас у меня в команде средний период трудоустройства превышает 10 лет. Было бы такое возможно при наличии всех описанных Вами ужасов? Согласитесь, вряд ли.
Просто хорошо помню как оно раньше было, м.б. и не так все приятно и понятно для менеджмента, но разработчику было намного комфортнее работать, как по мне.
Жизнь тогда была совсем другая. Прежде всего – темп жизни. Эджайл – ответ именно на это, сейчас невозможно пилить систему годами до её выхода в продакшн – обязательно найдётся кто-то другой, кто сделает раньше и снимет все сливки. Именно с этой точки зрения жизнь была более комфортной (не только у разработчиков) – не было этой непрекращающейся гонки. Вообще конкуренции как таковой не было – каждый проект делала одна конкретная организация. Зато и прогресс сейчас идёт гораздо быстрее – что, разумеется, хорошо, но тоже в каком-то смысле добавляет дискомфорта, ибо и самому нужно за ним успевать.
Мне эджайл нравится, уже 20 с лишним лет по-другому не работаю. Но у меня он без фанатизма: беру только то, что на самом деле помогает конкретно в моём случае. Одно неизменно: короткие итерации и непрерывная обратная связь. Это действительно помогает раннему выводу продукта и внесению корректив в разумные сроки. Коммуникации по необходимости, обязательных встреч всего две: по пятницам внутрикомандные, подбить результаты прошедшей недели, и по понедельникам общая, с обзором состояния в целом по проекту и корректировкой приоритетов. Нам достаточно для того, чтобы все были в курсе происходящего и видели своё место в общей картине.
вы отлично иллюстрируете один из типов менеджеров "мне неизвестны детали, и вникать я не буду, лучше поосуждаю"
Почему же неизвестны-то? Я опытный менеджер, и вполне могу обсуждать утверждения, какие именно задачи для менеджеров приоритетны. И считаю, что если менеджер озабочен(а) по большей части тем, чтобы не мешать – это означает, что свои прямые менеджерские обязанности он(а) не выполняет, или что эта должность вовсе не нужна.
А обсуждаю я ровно то, что Вы написали – ни больше, ни меньше. На продолжении дискуссии не настаиваю, разумеется.
команда у меня работает сильно иначе, чем обычно принято
В том смысле, что у вас там полно нижне-средних менеджеров, которые постоянно лезут не в своё дело, мешая другим работать? Сочувствую, но не стоит экстраполировать этот свой опыт на весь остальной мир. Тем более, сознавая, что оно у вас работает "иначе, чем обычно принято".
При больших объёмах работы и на большом отрезке времени это уже не так просто держать все в голове
Если объём превышает возможности одного человека, то пора дробить команду на более мелкие, и делегировать контроль низовым менеджерам. А больших отрезков при грамотной декомпозиции задач и вовсе быть не должно.
Встречал и такие реализации – очень плохо, и в целом свидетельствует о непонимании сути технологии. SCRUM в чистом виде никогда не использовал, но смысл любой эджайл технологии именно в повышении степени информированности и вовлечённости исполнителей – когда они понимают конечную задачу и стремятся её реализовать максимально эффективно. Это прямо в манифесте записано, и всё, что этому противоречит, есть ересь.
С этой точки зрения каскадная модель (тебе написали ТЗ и сиди, выполняй в строгом соответствии с написанным) гораздо ближе к конвейеру. Только он очень медленный.
Раньше тебе давали какую-то задачу, срок на ее выполнение, причем сроки там нарезались не часами а неделями, а то и месяцами
Скорее всего, там были проблемы с проектированием. При грамотно проведённой декомпозиции задач такой длительности просто не должно быть. По крайней мере, как системы – какие-то редкие исключения возможны.
А "все эти скрамы" отнюдь не предписывают поминутный учёт времени. Сам работаю в режиме недельных итераций, и тайм-трекинг не использую. Зато имею уверенность, что каждая из выполняемых в данный момент задач действительно актуальна для бизнеса, и даже если потом окажется, что идея была ошибочной – потеряю всего неделю, а не месяцы.
Во-первых ты понимаешь реальную скорость работы человека
Я и без этого понимаю. Для этого всего-то и нужно, что следить за выполнямыми командой задачами. Имея при этом в голове некоторое понимание сложности каждой, и при случае не стесняясь спросить исполнителя, в чём у него затык и нужна ли помощь.
Во первых, нет: там тернарный оператор, который есть просто альтернативная форма записи
if/then/else. Во-вторых, такое упрятывание условных ветвлений не улучшает, а ухудшает читаемость кода.Вы предлагаете мне переписать всю статью?
Нет, на такое нет. Желания тоже – я просто не понимаю причин искать способы полного отказа от условных операторов.
Я для всех случаев вижу, что каждое средство языка должно использоваться на своём месте, и не должно быть никаких религиозных догм типа полного отказа от
if/switch– это приводит к ненужному усложнению кода.Без условных операторов, серьёзно? Я в этом коде вижу как минимум три условия:
isValid,isCurrentDayData(),orElse().Дженерики использовать не судьба? Паттерн матчинг, в конце концов?
Зачем вообще всё это? Отказ от
if/switch– это религия какая-то? В некоторых случаях это действительно приводит к трудночитаемому коду, но приведённые примеры к таковым не относятся.P.S. Использование скриншотов вместо вставок кода – плохая практика, затрудняет цитирование.
Нет, не уловка – это действительно так. Ловушка тут в том, что весь смысл эджайла в повышении гибкости процессов разработки, мгновенной реакции на изменение внешних факторов. Бизнес аналитик ошибся в постановке задачи? Не беда, это выявится в конце короткой итерации и будет исправлено в следующей. Баг, который выявляется только на ограниченном подмножестве юзеров на проде? То же самое. И так далее. И тут возникает некий абсурд: гибкость пытаются получить, навязывая жесточайшим образом прописанные методологии (привет, SCRUM): шаг вправо, шаг влево, прыжок на месте.... ну, вы знаете. Так оно проще, да: думать не надо, кто-то за вас уже подумал и расписал, как надо, по пунктам. На самом деле каждая компания и каждый проект имеет индивидуальные черты, игнорирование которых приводит к снижению эффективности. "Правильно приготовленный" эджайл сохраняет гибкость и скорость реакции в условиях конкретной компании/проекта. Для чего его надо именно что "приготовить": взять наиболее подходящую методологию и адаптировать её под себя.
Вероятно, это то, с чем столкнулся автор, и к его чести, попытался найти собственное решение. Но сейчас он делает ту же самую ошибку, пропагандируя его как единственно верное. Это не говоря уж о том, что в статье полно ругани по адресу других методологий (иногда обоснованной, иногда не очень), а вот предлагаемое решение описано на уровне "подписывайтесь на мой канал, там всё узнаете". Нет, это так не работает. Возможно, у автора есть идеи, которые можно было бы позаимствовать – но для этого их нужно внятно изложить. Пока не получилось. Единственное, что понятно – это тот же эджайл, но реализованный по-своему. Поэтому критика эджайла в целом, как проектной философии, тоже выглядит несколько неуместной.
А раньше вы этого не делали, что ли? Мне сложно представить себе компанию, которая вкладывается в разработку продукта, вообще не заглянув на рынок.
Эмм, благородный дон точно не ошибся дверью? 🙂 Я, собственно, именно это тут и пытался выяснить. Безуспешно – чему, впрочем, ничуть не удивлён, ибо таки хуже.
Вы совсем не понимаете, как работает эджайл. Очевидно, это вина тех "эффективных менеджеров", которые внедряли модные технологии, совершенно не разобравшись в их сути, и в результате испортили им репутацию у множества разработчиков. В настоящем эджайле нет буквально ничего из Вами описанного, это совсем иначе работает.
Не скрою, когда году в 2002 один заказчик (друган аж самого Кента Бека) принёс нам на хвосте хР, тоже сначала подумал: что за дичь такая. Но вскоре проникся – ибо результаты говорили сами за себя, нужно было быть дураком, чтобы не увидеть преимуществ. С тех пор сам несколько раз сам организовывал такую трансфомацию – и всегда это приводило к улучшениям. В том числе и к повышению удовлетворённости разработчиков. Например, сейчас у меня в команде средний период трудоустройства превышает 10 лет. Было бы такое возможно при наличии всех описанных Вами ужасов? Согласитесь, вряд ли.
Можно уточнить, в чём разница между
и
Я её не вижу, ИМХО то же самое. Только последовательность в первом варианте несколько перепутана:
Таки лучше наоборот: тестируй, внедряй, «допиливай»
Жизнь тогда была совсем другая. Прежде всего – темп жизни. Эджайл – ответ именно на это, сейчас невозможно пилить систему годами до её выхода в продакшн – обязательно найдётся кто-то другой, кто сделает раньше и снимет все сливки. Именно с этой точки зрения жизнь была более комфортной (не только у разработчиков) – не было этой непрекращающейся гонки. Вообще конкуренции как таковой не было – каждый проект делала одна конкретная организация. Зато и прогресс сейчас идёт гораздо быстрее – что, разумеется, хорошо, но тоже в каком-то смысле добавляет дискомфорта, ибо и самому нужно за ним успевать.
Мне эджайл нравится, уже 20 с лишним лет по-другому не работаю. Но у меня он без фанатизма: беру только то, что на самом деле помогает конкретно в моём случае. Одно неизменно: короткие итерации и непрерывная обратная связь. Это действительно помогает раннему выводу продукта и внесению корректив в разумные сроки. Коммуникации по необходимости, обязательных встреч всего две: по пятницам внутрикомандные, подбить результаты прошедшей недели, и по понедельникам общая, с обзором состояния в целом по проекту и корректировкой приоритетов. Нам достаточно для того, чтобы все были в курсе происходящего и видели своё место в общей картине.
Почему же неизвестны-то? Я опытный менеджер, и вполне могу обсуждать утверждения, какие именно задачи для менеджеров приоритетны. И считаю, что если менеджер озабочен(а) по большей части тем, чтобы не мешать – это означает, что свои прямые менеджерские обязанности он(а) не выполняет, или что эта должность вовсе не нужна.
А обсуждаю я ровно то, что Вы написали – ни больше, ни меньше. На продолжении дискуссии не настаиваю, разумеется.
В том смысле, что у вас там полно нижне-средних менеджеров, которые постоянно лезут не в своё дело, мешая другим работать? Сочувствую, но не стоит экстраполировать этот свой опыт на весь остальной мир. Тем более, сознавая, что оно у вас работает "иначе, чем обычно принято".
Менеджер, безусловно. Но не один из – ибо задачи у меня совсем иные, под описание никак не подхожу.
И видите свою задачу в том, чтобы не мешать? Гм.
Первая – она же, вероятно, и основная? Во всяком случае, я так услышал. Если да, то не согласен, и написал, почему.
Тут есть два варианта:
Вам сильно не повезло.
Вы на своей позиции не видите, в чём ценность деятельности менеджеров. Как в политике: "Очень жаль, что все, кто умеет руководить государством, уже работают таксистами и парикмахерами".
Если объём превышает возможности одного человека, то пора дробить команду на более мелкие, и делегировать контроль низовым менеджерам. А больших отрезков при грамотной декомпозиции задач и вовсе быть не должно.
Мысль-то понял – а вот её связь с моим комментарием нет.
Встречал и такие реализации – очень плохо, и в целом свидетельствует о непонимании сути технологии. SCRUM в чистом виде никогда не использовал, но смысл любой эджайл технологии именно в повышении степени информированности и вовлечённости исполнителей – когда они понимают конечную задачу и стремятся её реализовать максимально эффективно. Это прямо в манифесте записано, и всё, что этому противоречит, есть ересь.
С этой точки зрения каскадная модель (тебе написали ТЗ и сиди, выполняй в строгом соответствии с написанным) гораздо ближе к конвейеру. Только он очень медленный.
Польщён. Это какой-то прям запредельный уровень эмпатии. Вот если человек слушает, но не слышит – тогда дело действительно плохо.
Скорее всего, там были проблемы с проектированием. При грамотно проведённой декомпозиции задач такой длительности просто не должно быть. По крайней мере, как системы – какие-то редкие исключения возможны.
А "все эти скрамы" отнюдь не предписывают поминутный учёт времени. Сам работаю в режиме недельных итераций, и тайм-трекинг не использую. Зато имею уверенность, что каждая из выполняемых в данный момент задач действительно актуальна для бизнеса, и даже если потом окажется, что идея была ошибочной – потеряю всего неделю, а не месяцы.
Я и без этого понимаю. Для этого всего-то и нужно, что следить за выполнямыми командой задачами. Имея при этом в голове некоторое понимание сложности каждой, и при случае не стесняясь спросить исполнителя, в чём у него затык и нужна ли помощь.