За какой код я должен отвечать?

Через коллег и выездные интервью я узнал, что в моей маленькой компании я «ответственен» за где-то в 3-10 раз больше кода, чем на другой работе. Я пытаюсь найти какую-то нечеткую метрику, которую я могу использовать, чтобы сравнить свою рабочую нагрузку с другими в моей области.

Под «ответственностью за код» я не имею в виду «я единственный, кто знает область X базы кода» (хотя, к сожалению, в среде запуска это часто так), а скорее ссылаюсь на число типа «code_base_size» / number_of_developers».

Есть ли какие-либо ресурсы, которые я могу использовать, чтобы помочь мне более точно измерить рабочую нагрузку, чем просто подсчет строк кода?

Единственная конкретная мера для занятого разработчика - это количество часов, потраченных на кодирование и исправление ошибок, и деньги, которые вам за это платят. Если вы остаетесь поздно ночью 6 дней в неделю за 50 000 долларов США в год, то у вас есть проблема. Независимо от того, сколько строк кода ваш босс хочет, чтобы вы отвечали, вы не будете обрабатывать больше, чем можете, учитывая, конечно, определенное качество кода. Разработка некачественного кода без юнит-тестов - хороший способ справиться с большим количеством кода, но компании придется заплатить цену большого технического долга .

В небольших компаниях разработчики, как правило, несут ответственность за гораздо больший объем кода, чем в крупных корпорациях. Фактор от 3 до 10, на который вы ссылаетесь, кажется мне реалистичным.

Я знал команду из трех человек, которая управляла 1,5 миллиона строк кода и не тонула в ней. Важным измерением является не количество кода, за который вы отвечаете, а количество кода, которое необходимо изменить за определенный промежуток времени.

Есть также угол оценки риска. Если вы единственный человек, который знает фрагмент кода, какова альтернативная стоимость, которая будет потеряна, если вы пойдете под автобус? Небольшие компании обычно не проводят такую ​​оценку рисков, но это означает, что дальнейший успех бизнеса оставлен на волю случая.

базовый размер кода / количество разработчиков не связано с рабочей нагрузкой. Если у вас огромная стабильная база кода, этот показатель будет высоким. Если у вас небольшая кодовая база, которая еще находится в разработке, этот показатель будет низким. Изменения количества линий в единицу времени на одного разработчика больше связаны с рабочей нагрузкой. Но даже тогда я потратил несколько дней, чтобы отследить тонкие ошибки, исправление которых было одной строкой ...

Код должен быть ответственностью группы, а не одного разработчика. Поддержка должна делегироваться справедливо каждую неделю, кажется глупым распределять ее любым другим способом. Если это не так, я предлагаю вам поговорить с вашим руководством.

В ситуации, когда вы описываете одного разработчика, возможно, не удается уложиться в сроки из-за огромного количества поддержки из одной области, где другие разработчики работают недостаточно. Это очень неэффективная структура управления.

Также я предлагаю вам отойти от измерения рабочей нагрузки в строках кода. Человеческие часы - единственная разумная метрика, о которой я могу думать

Измерение прогресса в программировании по строкам кода похоже на измерение прогресса в самолетостроении по весу - Билл Гейтс

NB. Я не говорю равных, я говорю честно. Также стоит отметить, что хорошо специализироваться на определенных аспектах кодовой базы, что происходит естественным образом. Проблема только в том, что никто не работает над этим кодом.

Например, если бы в Facebook было 2 программиста, они, очевидно, были бы перегружены работой - но как бы вы пришли к такому выводу? Это тип вопроса, который я собирался ответить.

Это не вопрос программирования, это вопрос управления.
Есть несколько простых вопросов, чтобы ответить на них, и они не имеют ничего общего с программным обеспечением.

1. Сколько часов ты работаешь?
2. Сколько часов вы должны работать?
3. Соблюдаются ли сроки?

Затем следуйте этой логике:

• Если 1> 2, вам нужно больше людей или менее агрессивные сроки.
• Если 1 <2, вам нужно меньше людей или больше инициатив.
• Если сроки не соблюдаются и 1> = 2, вам нужно больше людей.
• Если сроки не соблюдаются и 1 <2, вы должны кого-то уволить.

Это упрощение, которое имеет два явных недостатка.

• Люди не созданы равными.
• Есть способы сделать людей более производительными (обновить компьютер или что-то в этом роде).

Но Вы получаете идею.