Начало любой задачи начинается с поиска уже имеющейся реализации. Даже поиск слова “bonus” по проекту от корня найдёт все связанное. Если разработчик это не сделал или не смог разобраться и реализовал своё, хотя уже было, то это джун. Архитектура от джунов не поможет.
Код дублируется... Либо запутывается от сервиса к сервису...
SOA тоже надо уметь использовать.
Если дублируется, то разработчик не нашёл уже имеющуюся реализацию , это к пункту 1, это не к архитектуре.
Если запутывается в инжекте, то нужно общее правило написать в ридми в корне репы - бизнес логику функционала расширять внутри сервиса, а не снаружи (это про S из солида, и агрегаты из DDD).
Вот эти три пункта, без тд, что у вас, я сразу считаю в часах, плюс резерв, и тогда бизнес может посчитать конкретный дедлайн. А у меня всегда явная оценка времени на которую я могу ориентироваться в успеваемости.
В целом легче посчитать в часах и вести оценку эпика в человека/часах. Прозрачно и все знают как с этим работать, особенно все менеджеры и бизнес в целом.
Код в котором в каждом методе не будет проброса ошибки в разы проще воспринимать и расширять. Буквально на прошлой неделе приводил подобное на ревью, потом с разрабом на 121 смотрел до и после, результат на порядок лучше, и, что интересно, меньше.
Я не очень много писал на go. Но всю дорогу так и не смог привыкнуть к обязательному пробросу ошибок. Как и не смог найти минус в отсутствии такой обязательной необходимости в PHP. Хотя 2 года писал параллельно на обоих.
Ошибка в логе из исключения с полным трейсом. Везде скрипт, функция/метод и номер строки. Этого всегда достаточно, что бы 100% разобрать весь путь, понять логику и исправить. Намного проще чем кастомно это запихивать в одну ошибку по месту.
С исключениями всегда проще, просто кидай и все, кому надо, тот обработает. Это проще, чем усложнять функцию/метод и придумывать разный ответ в случае ошибки и добавлять обязательную обработку ошибки. В одном эндпоинте может быть парочка и больше классов в которых не надо обрабатывать ошибки, но на уровне предметной логики перехватить обязательно.
Меньше логики: проще писать, проще читать, проще понимать, проще дебажить, проще расширять (меньше - это разумеется без фанатизма).
Не понимаю про магию, можете детальней раскрыть мысль?
Исключения хороши тем, что вызывающий код может не заботится о проверке и обязательно не возвращать ошибку. Но на несколько уровней выше может быть обработка исключения. В go придётся вручную вести ошибку во всех функциях, это намного-намного менее удобней исключений.
Не равнозначное сравнение. Любой сервис web приложения и Linux kernel это абсолютно разные уровни, в частоте решения задач, в скорости разработки, удобстве разработки, в частоте расширения, в количестве миддл участников.
И вот напробовав разных этих плясок с бубном с SP вернулся к часам по уже полностью готовому бизнес и тех требованиям и все взлетело, по оценке успеваем, готовность спринта 80-90%, всем сразу все понятно как оценивается.
У сеньера за спринт выходит 10 СП, у мида 7, у джуна 5, хотя в днях у всех 14.
Вот этот расчет очень сложный. Был в проектах с такой практикой. Но последние 3 расчет в часах, работает очень легко, понятно и просто.
В такой логике лиду в принципе довольно удобно будет рассчитывать срок выполнения задачи и назначить исполнителя. Оценили задачу в 5 СП, сдать нужно за неделю, понятно что назначить ее можно только на сеньера, только у него в неделю выйдет 5 СП сделать.
У меня не выходит примерить это на свое управление. Обычно считаю сколько влазит часов на исполнителя в часах за спринт, и по ним распределяется.
@DenSigma Очень хорошее описание. Именно такой лаконичный и зрелый текст рассчитывал встретить в тексте на тему этой статьи.
Запутывается... Нужен эксперт...
Начало любой задачи начинается с поиска уже имеющейся реализации. Даже поиск слова “bonus” по проекту от корня найдёт все связанное. Если разработчик это не сделал или не смог разобраться и реализовал своё, хотя уже было, то это джун. Архитектура от джунов не поможет.
Код дублируется... Либо запутывается от сервиса к сервису...
SOA тоже надо уметь использовать.
Если дублируется, то разработчик не нашёл уже имеющуюся реализацию , это к пункту 1, это не к архитектуре.
Если запутывается в инжекте, то нужно общее правило написать в ридми в корне репы - бизнес логику функционала расширять внутри сервиса, а не снаружи (это про S из солида, и агрегаты из DDD).
Хорошая статья. Понятно даже не знающему эту кухню. Большая благодарность за примеры.
Вот эти три пункта, без тд, что у вас, я сразу считаю в часах, плюс резерв, и тогда бизнес может посчитать конкретный дедлайн. А у меня всегда явная оценка времени на которую я могу ориентироваться в успеваемости.
Мне необходимо получить точный расчёт когда задача будет готова. Поэтому нужны часы. Поэтому SP это прослойка которую можно убрать.
Бизнес не интересует трудоемкость (я назвал это сложностью). Бизнес интересует когда будет сделано, сколько будет стоит и качество.
В целом легче посчитать в часах и вести оценку эпика в человека/часах. Прозрачно и все знают как с этим работать, особенно все менеджеры и бизнес в целом.
Везде в проектах перешёл на часы. Это сразу решило все вопросы. Все знают как с этим работать, менеджеры, бизнес и сама разработка. Просто и понятно.
В SP необходимо оценивать сложность. Поэтому разница во времени реализации вполне может быть.
SP это метрика сложности, а не времени.
И на практике это не погрешность.
У меня два твёрдых синьера, но один подключился недавно и на незнакомый функционал добавляется ознакомление и погружение и, иногда, это много времени.
А разница между этими двумя и одним из мидлов ещё более ощутимая.
Кратко, ясно, без воды. Хорошая водная статья. Благодарю тебя автор.
Код в котором в каждом методе не будет проброса ошибки в разы проще воспринимать и расширять. Буквально на прошлой неделе приводил подобное на ревью, потом с разрабом на 121 смотрел до и после, результат на порядок лучше, и, что интересно, меньше.
Я не очень много писал на go. Но всю дорогу так и не смог привыкнуть к обязательному пробросу ошибок. Как и не смог найти минус в отсутствии такой обязательной необходимости в PHP. Хотя 2 года писал параллельно на обоих.
Ошибка в логе из исключения с полным трейсом. Везде скрипт, функция/метод и номер строки. Этого всегда достаточно, что бы 100% разобрать весь путь, понять логику и исправить. Намного проще чем кастомно это запихивать в одну ошибку по месту.
С исключениями всегда проще, просто кидай и все, кому надо, тот обработает. Это проще, чем усложнять функцию/метод и придумывать разный ответ в случае ошибки и добавлять обязательную обработку ошибки. В одном эндпоинте может быть парочка и больше классов в которых не надо обрабатывать ошибки, но на уровне предметной логики перехватить обязательно.
Меньше логики: проще писать, проще читать, проще понимать, проще дебажить, проще расширять (меньше - это разумеется без фанатизма).
Не понимаю про магию, можете детальней раскрыть мысль?
Исключения хороши тем, что вызывающий код может не заботится о проверке и обязательно не возвращать ошибку. Но на несколько уровней выше может быть обработка исключения. В go придётся вручную вести ошибку во всех функциях, это намного-намного менее удобней исключений.
Нейронка так не переведёт. Текст немного лучше чистого джипити.
Не равнозначное сравнение. Любой сервис web приложения и Linux kernel это абсолютно разные уровни, в частоте решения задач, в скорости разработки, удобстве разработки, в частоте расширения, в количестве миддл участников.
Статья больше вводная и больше для не инженеров или начинающих.
И вот напробовав разных этих плясок с бубном с SP вернулся к часам по уже полностью готовому бизнес и тех требованиям и все взлетело, по оценке успеваем, готовность спринта 80-90%, всем сразу все понятно как оценивается.
Вот этот расчет очень сложный. Был в проектах с такой практикой. Но последние 3 расчет в часах, работает очень легко, понятно и просто.
У меня не выходит примерить это на свое управление. Обычно считаю сколько влазит часов на исполнителя в часах за спринт, и по ним распределяется.