Здравствуйте, r0nd, Вы писали:
R>On Apr 23, 2024, 8:10 PM, alzt <59854@users.rsdn.org> wrote:
A>>2. Строк кода (в новом проекте и не очень)
R>100–150 строк кода в день для C++/Java соответствует синьору; если меньше — это мидл;
Наверное, я очень тупой тим лид — в день от силы 50 строк могу написать. Хотя зависит- может и 200 за час наизменяться переименованием . И ещё люто, яростно бью по рукам за копи-пасту в стиле
if()
a=b
else if
a=b
else if
a=b
else
a=b
Это реальный недавний пример пулреквеста от коллеги оверсииз.
A>>3. Количество закрытых тасков
Синьёрность зависит от сложности таски, которую можно поручить. Если тасков вагон и маленькая тележка в день — тогда это не сеньёр, а что-то в районе джуна.
On May 15, 2024, 12:58 AM, Артём <30761@users.rsdn.org> wrote: R>>100–150 строк кода в день для C++/Java соответствует синьору; если меньше — это мидл; Аё>Наверное, я очень тупой тим лид — в день от силы 50 строк могу написать.
Я думаю ответ здесь
⸻ ❧ “Goal setting is the secret to a compelling future.” — Tony Robbins
Мне пофиг на количество изменённых строк- много строк не говорит о производительности программиста в части правильной имплементации фич, только говорит о количестве перелопаченных строк.
On May 16, 2024, 7:59 AM, Артём <30761@users.rsdn.org> wrote:
Аё>Мне пофиг на количество изменённых строк- много строк не говорит о производительности программиста в части правильной имплементации фич, только говорит о количестве перелопаченных строк.
Это не график измененных строк, разве я где-небудь говорил про измененные строки? Нет. Но, этот график полностью подтверждает твою фразу почему ты "в день от силы 50 строк можешь написать".
⸻ ❧ “If you can’t yet do great things, do small things in a great way.” ― Napoleon Hill
Здравствуйте, alzt, Вы писали:
A>Какие показатели считаете хорошими, какие у вас есть/были, средние по команде и т.п.
Хорошесть метрики определяется его полезностью для целей проекта. Поэтому без цели довольно трудно ответить на этот вопрос.
Одна и та же метрика может принести пользу в одном проекте, и вред в другом.
1) Test coverage — необходим в критическом софте, но вреден в задачах прототипирования.
2) Cyclomatic complexity — будет вредна для legacy проекта в состоянии поддержки, так как отвлечет ресурсы на улучшение этой метрики. Также она будет вредна для модели разработки когда код пишется, например, математиком, а потом переписывается программистом.
3) Стори пойнты не работают в проектах с большой компонентой ресерча. Также они вредят в больших проектах с жесткими дедлайнами, так как команда за деревьями перестает видеть лес.
4) Количество строчек кода не работает в проектах, где большой разброс по сложности задач или команда состоит из специалистов очень разных компетенций. С другой стороны, если команда штампует типовые решения по образцу, то количество строчек кода может оказаться вполне себе полезной метрикой.
Список можно продолжать долго и метрик можно выдумать тоже много. Основная идея в том, что идти надо не от метрик, а от целей и задач. И думать о том, как метрики помогут с этим помочь и какую функцию они должны выполнять. Метрика может нужна, чтобы видеть прогресс, менять фокус команды, выявлять слабые места и так далее. Когда будут ответы на эти вопросы, то идеи метрик будут органично появляться сами. И очень может, что выработаете свои собственные.
Здравствуйте, Codealot, Вы писали:
C>Какие и зачем?
Зависит от продукта и целей.
В качестве самого типового примера — это UX оптимизация и метрики для оценки качества UX.
_>Метрики надо снимать с продукта. А не с программиста, потому что люди приходят и уходят, а продукт остается.
Боюсь, что когда будешь делать ремонт в своей квартире, то оценивать будешь не только качество ремонта, а и скорость и эффективность рабочих.
Хотя они приходят и уходят, а квартира остается надолго.
Здравствуйте, kov_serg, Вы писали:
_>Значит компания зарабатывает на чем-то другом. В общем случае это параметры модели, эволюционирование которой во времени может оценить последствия, разных воздействий. _>В простейшем случае анализ рисков. Что потеряете в случае гибели ухода конкретного человека и какова вероятность такого события.
В реальности получается заливание кучи ресурсов на оценку и анализ рисков, который устаревает уже через месяц. Поэтому я не видел сам и не слышал, чтобы кто-то такие риски считал. Как правило, в маленьких компаниях и так все на виду, а в больших работают другие инструменты и анализ рисков делается на более высоком уровне.
Здравствуйте, Codealot, Вы писали:
C>Для оценки качества. C>То есть кто-то сделал более качественную работу, а кто-то менее качественную.
Нет, в общем случае это неверно. И в целом это контрпродуктивное рассуждение.
UX который работал вчера, может перестать работать сегодня.
И нужно постоянно мониторить, насколько эффективно UX решает задачи пользователя.
Здравствуйте, Codealot, Вы писали:
MVK>>Нет, в общем случае это неверно. И в целом это контрпродуктивное рассуждение. C>Это рассуждение, которое совершенно точно кто-то сделает.
Зависит от культуры разработки в команде.
Но да, встречается довольно часто.
MVK>>И нужно постоянно мониторить, насколько эффективно UX решает задачи пользователя. C>И кто сделал эти изменения, верно?
Верно. Вопрос с какой целью и что из этого следует?
. И ещё люто, яростно бью по рукам за копи-пасту в стиле
