Мы про исходный код говорим (про стиль его написания). На клиенте мы увидим продукт сборки в действии (про него мы не говорим)
И не про браузер речь, разумеется, а про "хрупкий" и "надёжный" код (как написанный человеком исходник). Если нужны такие вводные, пожалуйста - мы исходим из того, что транспайлер отработал как надо, код везде выполняется одинаково, говорим только об обработке ошибок входных данных и приведена аналогия "красных лампочек в интерфейсе" как хороший пример ориентира, какая часть системы отказала в данный момент (защитное программирование в действии, "хрупкий" код не даст такого эффекта).
Хотя, допускаю, Вы могли не понять аналогию, ну да ладно.
А здесь уже про разное. Ошибки должны быть обработаны независимо от браузера. Я про Защитное программирование - думаю за ним будущее ) вы когда-нибудь бывали на каком-нибудь военном командном пункте какой-нибудь абстрактной установке? Представьте что, для каждой неисправности есть красная лампочка и табличка (это удобно, потому что это стандарт вывода ошибки) - и это модульная система, где каждый модуль легко заменяем и быстро диагностируется
Не соглашусь с Вами. Я фронт, пишу в духе Защитного программирования, для меня важно иметь возможность быстро (asap) разобраться, что пошло не так (чтоб не ждать круговорот тикета через тестеров и искать причину по тексту ошибки из бандла). Я понимаю, у каждого своя практика, но исходя из моей практики, ошибку мало обнаружить, надо обработать - так ещё и корректно сообщить интерфейсу (а ещё лучше отправить лог в виде сформулированной проблемы) для возможности быстро разобраться в чем дело (не просто бросить в консоль). Не обязательно делать проверки в каждой функции, достаточно проверить входные данные (к примеру, получив ответ по апишке, можно сразу провалидировать ответ, получив на выходе интуитивно понятное `{ ok: boolean; message?: string; }` - и в случае !ok мы уже не работаем с "хрупкими функциями", а с человекочитаемым сообщением: `"Есть проблема! Некорректный формат ответа на запрос '/me' -> user.policyId (получено: undefined, ожидается: string)"`.
А если такой контракт ошибок принят во всем нашем коде как единый стандарт - то, если где-либо что-то пошло не так по итогам стандартной валидации (которая написана один раз и ожидает конфиг с описанием правил на входе), мы уже всегда имеем возможность отправить соответствующие логи, зная что в строке event.message все уже грамотно сформулировано. При этом проверки будут описаны максимально декларативно и без паранойи )
В общем, вкусовщина и полезные привычки (у каждого свои).
Как вариант, предположу, этому господину нужен широкий монитор, чтоб все колонки влезли (тогда не пришлось бы переносить блоки). Но: Это прокатило бы в случае если задачи действительно перемещались постепенно из одного столбика в другой как в классической канбан-доске. Но глядя на скрин, я все же в этом сомневаюсь, т.к. задачи просто делятся на группы: У автора названия блоков - это не стадии задач, а разные группы соответствия (все гораздо проще, чем канбан). Отсюда я делаю вывод, что с канбаном здесь мало общего.
Алгоритм довольно прозрачен и был однажды описан здесь: Теория вероятностей в действии 2.0 (суть алгоритма корректировки прогнозов разработчиков) https://habr.com/p/874226/
Как-то меня достали эти сторипоинты и я написал свою модель, опираясь исключительно на реальные даты, реальные ошибки в прогнозах и Теорию Вероятностей. Если интересно протестить - велкам https://gosuslugi.pravosleva.pro/dist.estimate-corrector-2024/
В таблице выше это была бы ещё одна колонка с тремя галочками и крестиком напротив сторипоинтов (польза от которых, кмк, стремится к нулю)
Есть в этом и подводные камни, например, вы завязываетесь на конкретной библиотеке-коннекторе к БД (которая добавляется в зависимости при создании проекта, в зависимости от конфигурации), разработанной определенной командой - со всеми ее возможностями, багами и проблемами (я надеюсь, сейчас их существенно меньше). Скорее всего СБ крупных неповоротливых компаний не дадут Вам такой свободы без подробного анализа на предмет потенциальной вредоносности каждой из них. Слежу за развитием Страпи более 5 лет и считаю это реально крутым проектом. Команда у них огонь, когда-то давно общался с ними в Слаке - охотно идут на контакт и отвечают на вопросы. Но вот ещё момент: миграции между мажорными версиями - это боль, которая (когда и если) придет без приглашения, поставив вас перед выбором - идти дальше по роадмапу разработки или брать таймаут на апдейт на какое-то время (если мы говорим про Ентерпрайз - Вы скорее всего выберете первый путь и останетесь в текущей мажорке до конца, т к. в другом случае это как-то придется объяснять бизнесу, который обычно ждать не любит).
Но, постойте. Есть ещё момент: Вы упомянули GraphQL - а Вы, уважаемый разработчик, готовы к тому, что не сможете оптимизировать эти запросы? То есть эта реализация остается под капотом Страпи (вернее, соответствующего плагина, разработанного соответствующей командой, предоставившей релиз этой либы - они прям альтруисты, наверное)) на Вашем доверии (на Ваш страх и риск).
Я делаю проект, который позволяет скорректировать прогноз планирования релиза/фичи на основании опыта предыдущих ошибок планирования. Данная версия исключительно для оффлайн (LocalStorage). Использую Веб-воркеры для разгрузки основного потока (летает как самолет).
Реализовано:
Создание задач с возможностью указать время старта, время прогноза, время фактического финиша, "субъективную сложность" фичи, назначенный исполнитель;
Задача, имеющая прогноз (при наличии завершенных задач конкретной сложности, назначенных на конкретного исполнителя) будет иметь прогрессбары для рассчитанного с использованием теории вероятностей "ощущаемого" и самого худшего сценариев;
Можно настроить варианты рабочих графиков для расчета рабочих часов на выполнение задачи (я использую для анализа эффективности промежутков работы между прерываниями на созвоны и коммуникации);
Для задачи можно назначить задачу-родителя (я использую для построения дерева задач);
Пока в работе, позже планирую добавить фичи:
Подключить сокет в отдельном потоке (поэкспериментировать с обратной связью от пользователя);
Функция "Поделиться ссылкой на дерево проектов" - Серверный кэш для хранения временных данных;
Я пришел к выводу, что "Менеджеры вынуждены контролировать работу специалистов", т.к. не знают их работу (как неспециалист не знает работу специалиста), и это единственный их вариант получить иллюзию ежедневного контроля. Управленцев, которые не знают матчасть сейчас сильно больше и на них идёт давление таких же менеджеров со стороны заказчика.
Поправка: (Вот более удачная версия статьи) Теория вероятностей в действии 2.0 (суть алгоритма корректировки прогнозов разработчиков) https://habr.com/p/874226/
Решаю практически эту же задачу длительное время. Думаю, финалом будет алгоритм, который распознает твою комфортную скорость работы. Подробнее описал здесь.
Но любую фичу разные люди делают за разное время. И оценивают по разному - для кого-то фича простая, для другого - несколько сложнее. Команда также может менять состав с течением времени. Как быть с этими фактами? Общая статистика здесь не прокатит, кмк
Интересная точка зрения. Согласен почти со всем кроме некоторых моментов:
Абсолютные оценки в часах не работают
Но постойте, как же Принцип Доказательного Планирования от Joel Spolsky? Я думаю, оценивать в реальных часах конкретными людьми для последующего анализа - это нормально. Подробнее изложил здесь, если интересно - там есть идеи как вычислить, насколько обманет конкретный разраб, который сказал "Это на пару часов".
С этим тоже не могу согласиться:
если за последние три месяца 80% задач размера M выполнялись в течение 5–7 дней, то с высокой вероятностью новая задача аналогичного размера займет примерно столько же времени.
А если процессы совершенствуются с течением времени? Мой контраргумент коротко: разные люди работают с разной комфортной скоростью, в любой момент времени статистика конкретного исполнителя может удивить - люди развиваются и деградируют, и это надо иметь ввиду.
Согласен с тем, что необходимо вводить абстрактные критерии оценки сложности фичи (попугаи, пятибалльная система, футболки и т.д.) - зачастую сложность определяет комфортную скорость работы.
Я как раз не сторонник раздувать код.
Если все делать правильно, не повторяя свой код, он и будет выглядеть и весить соответственно.
Не делайте 100 проверок, делайте одну стандартно.
Мы про исходный код говорим (про стиль его написания). На клиенте мы увидим продукт сборки в действии (про него мы не говорим)
И не про браузер речь, разумеется, а про "хрупкий" и "надёжный" код (как написанный человеком исходник). Если нужны такие вводные, пожалуйста - мы исходим из того, что транспайлер отработал как надо, код везде выполняется одинаково, говорим только об обработке ошибок входных данных и приведена аналогия "красных лампочек в интерфейсе" как хороший пример ориентира, какая часть системы отказала в данный момент (защитное программирование в действии, "хрупкий" код не даст такого эффекта).
Хотя, допускаю, Вы могли не понять аналогию, ну да ладно.
А здесь уже про разное. Ошибки должны быть обработаны независимо от браузера. Я про Защитное программирование - думаю за ним будущее ) вы когда-нибудь бывали на каком-нибудь военном командном пункте какой-нибудь абстрактной установке? Представьте что, для каждой неисправности есть красная лампочка и табличка (это удобно, потому что это стандарт вывода ошибки) - и это модульная система, где каждый модуль легко заменяем и быстро диагностируется
Не соглашусь с Вами. Я фронт, пишу в духе Защитного программирования, для меня важно иметь возможность быстро (asap) разобраться, что пошло не так (чтоб не ждать круговорот тикета через тестеров и искать причину по тексту ошибки из бандла). Я понимаю, у каждого своя практика, но исходя из моей практики, ошибку мало обнаружить, надо обработать - так ещё и корректно сообщить интерфейсу (а ещё лучше отправить лог в виде сформулированной проблемы) для возможности быстро разобраться в чем дело (не просто бросить в консоль). Не обязательно делать проверки в каждой функции, достаточно проверить входные данные (к примеру, получив ответ по апишке, можно сразу провалидировать ответ, получив на выходе интуитивно понятное `{ ok: boolean; message?: string; }` - и в случае
!okмы уже не работаем с "хрупкими функциями", а с человекочитаемым сообщением: `"Есть проблема! Некорректный формат ответа на запрос '/me' -> user.policyId (получено: undefined, ожидается: string)"`.А если такой контракт ошибок принят во всем нашем коде как единый стандарт - то, если где-либо что-то пошло не так по итогам стандартной валидации (которая написана один раз и ожидает конфиг с описанием правил на входе), мы уже всегда имеем возможность отправить соответствующие логи, зная что в строке
event.messageвсе уже грамотно сформулировано. При этом проверки будут описаны максимально декларативно и без паранойи )В общем, вкусовщина и полезные привычки (у каждого свои).
Есть еще незначительные мелочи: tsconfig надо дописать (настроить директорию сборки); установить директорию для скринов и т.д.
А так, идея интересная
Все верно. Узнаваемый стиль принятия законов "бешеным принтером" в контексте "опа, тут тоже можно постричь бабки" - ничего нового.
Как вариант, предположу, этому господину нужен широкий монитор, чтоб все колонки влезли (тогда не пришлось бы переносить блоки). Но: Это прокатило бы в случае если задачи действительно перемещались постепенно из одного столбика в другой как в классической канбан-доске. Но глядя на скрин, я все же в этом сомневаюсь, т.к. задачи просто делятся на группы: У автора названия блоков - это не стадии задач, а разные группы соответствия (все гораздо проще, чем канбан). Отсюда я делаю вывод, что с канбаном здесь мало общего.
Во всяком случае, прогнозы даёт реалистичные.
Алгоритм довольно прозрачен и был однажды описан здесь: Теория вероятностей в действии 2.0 (суть алгоритма корректировки прогнозов разработчиков) https://habr.com/p/874226/
Как-то меня достали эти сторипоинты и я написал свою модель, опираясь исключительно на реальные даты, реальные ошибки в прогнозах и Теорию Вероятностей. Если интересно протестить - велкам https://gosuslugi.pravosleva.pro/dist.estimate-corrector-2024/
В таблице выше это была бы ещё одна колонка с тремя галочками и крестиком напротив сторипоинтов (польза от которых, кмк, стремится к нулю)
Есть в этом и подводные камни, например, вы завязываетесь на конкретной библиотеке-коннекторе к БД (которая добавляется в зависимости при создании проекта, в зависимости от конфигурации), разработанной определенной командой - со всеми ее возможностями, багами и проблемами (я надеюсь, сейчас их существенно меньше). Скорее всего СБ крупных неповоротливых компаний не дадут Вам такой свободы без подробного анализа на предмет потенциальной вредоносности каждой из них. Слежу за развитием Страпи более 5 лет и считаю это реально крутым проектом. Команда у них огонь, когда-то давно общался с ними в Слаке - охотно идут на контакт и отвечают на вопросы. Но вот ещё момент: миграции между мажорными версиями - это боль, которая (когда и если) придет без приглашения, поставив вас перед выбором - идти дальше по роадмапу разработки или брать таймаут на апдейт на какое-то время (если мы говорим про Ентерпрайз - Вы скорее всего выберете первый путь и останетесь в текущей мажорке до конца, т к. в другом случае это как-то придется объяснять бизнесу, который обычно ждать не любит).
Но, постойте. Есть ещё момент: Вы упомянули GraphQL - а Вы, уважаемый разработчик, готовы к тому, что не сможете оптимизировать эти запросы? То есть эта реализация остается под капотом Страпи (вернее, соответствующего плагина, разработанного соответствующей командой, предоставившей релиз этой либы - они прям альтруисты, наверное)) на Вашем доверии (на Ваш страх и риск).
Я делаю проект, который позволяет скорректировать прогноз планирования релиза/фичи на основании опыта предыдущих ошибок планирования. Данная версия исключительно для оффлайн (LocalStorage). Использую Веб-воркеры для разгрузки основного потока (летает как самолет).
Реализовано:
Создание задач с возможностью указать время старта, время прогноза, время фактического финиша, "субъективную сложность" фичи, назначенный исполнитель;
Задача, имеющая прогноз (при наличии завершенных задач конкретной сложности, назначенных на конкретного исполнителя) будет иметь прогрессбары для рассчитанного с использованием теории вероятностей "ощущаемого" и самого худшего сценариев;
Можно настроить варианты рабочих графиков для расчета рабочих часов на выполнение задачи (я использую для анализа эффективности промежутков работы между прерываниями на созвоны и коммуникации);
Для задачи можно назначить задачу-родителя (я использую для построения дерева задач);
Пока в работе, позже планирую добавить фичи:
Подключить сокет в отдельном потоке (поэкспериментировать с обратной связью от пользователя);
Функция "Поделиться ссылкой на дерево проектов" - Серверный кэш для хранения временных данных;
Возможно что-то ещё...
https://pravosleva.pro/dist.estimate-corrector-2024
Проект живой (сам использую в работе), здесь пишу новости по обновлениям: https://t.me/bash_exp_ru/607
Я пришел к выводу, что "Менеджеры вынуждены контролировать работу специалистов", т.к. не знают их работу (как неспециалист не знает работу специалиста), и это единственный их вариант получить иллюзию ежедневного контроля. Управленцев, которые не знают матчасть сейчас сильно больше и на них идёт давление таких же менеджеров со стороны заказчика.
Поправка: (Вот более удачная версия статьи) Теория вероятностей в действии 2.0 (суть алгоритма корректировки прогнозов разработчиков) https://habr.com/p/874226/
А все потому что надо научиться отключать уведомления по умолчанию.
Вот же глюк... И не отредактировать уже, соррямба. https://habr.com/p/874226/
Решаю практически эту же задачу длительное время. Думаю, финалом будет алгоритм, который распознает твою комфортную скорость работы. Подробнее описал здесь.
И конечно же, многозадачность - вселенское зло )
Hours ∝ Story Points
Правильно, "живые" либы должны постоянно ломаться и ремонтироваться, как традиционные Жигули )
Но любую фичу разные люди делают за разное время. И оценивают по разному - для кого-то фича простая, для другого - несколько сложнее. Команда также может менять состав с течением времени. Как быть с этими фактами? Общая статистика здесь не прокатит, кмк
Интересная точка зрения. Согласен почти со всем кроме некоторых моментов:
Но постойте, как же Принцип Доказательного Планирования от Joel Spolsky? Я думаю, оценивать в реальных часах конкретными людьми для последующего анализа - это нормально. Подробнее изложил здесь, если интересно - там есть идеи как вычислить, насколько обманет конкретный разраб, который сказал "Это на пару часов".
С этим тоже не могу согласиться:
А если процессы совершенствуются с течением времени? Мой контраргумент коротко: разные люди работают с разной комфортной скоростью, в любой момент времени статистика конкретного исполнителя может удивить - люди развиваются и деградируют, и это надо иметь ввиду.
Согласен с тем, что необходимо вводить абстрактные критерии оценки сложности фичи (попугаи, пятибалльная система, футболки и т.д.) - зачастую сложность определяет комфортную скорость работы.