За скільки код я повинен відповідати?

Через колег та інтерв'ю з виїздом я чув, що в моїй невеликій компанії я "відповідальний" за десь у 3-10 разів більше коду, ніж був би на іншій роботі. Я намагаюся шукати якусь нечітку метрику, яку я можу використати для порівняння моєї роботи з іншими в моїй галузі.

Під "кодовою відповідальністю" я не маю на увазі "я єдиний, хто знає область X бази коду" (хоча, на жаль, це часто вірно в середовищі запуску), а скоріше я маю на увазі таке число, як "code_base_size / number_of_developers ".

Чи є ресурси, які я можу використати, щоб допомогти точніше виміряти моє робоче навантаження, ніж просто підрахунок рядків коду?

Єдиний конкретний захід для зайнятого розробника - кількість годин, витрачених на кодування та виправлення помилок, і гроші, які ви отримуєте за це. Якщо ви залишаєтесь пізно вночі 6 днів на тиждень за 50 тис. Доларів США на рік, тоді у вас є проблеми. Незалежно від того, за скільки рядків коду хочете, щоб ваш начальник відповідав, ви не впораєтеся більше, ніж можете, зважаючи на певну якість коду, звичайно. Розробка неякісного коду без одиничних тестів - хороший спосіб впоратися зі значно більшим кодом, але компанії доведеться заплатити ціну великого технічного боргу .

У невеликих компаніях розробники, як правило, відповідають за набагато більше коду, ніж у великих корпорацій. Коефіцієнт від 3 до 10, на який ви посилаєтесь, мені здається реалістичним.

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

Існує також кут оцінки ризику. Якщо ви єдина людина, яка знає фрагмент коду, яка можлива вартість, яку ви втратите, якщо ходити під автобусом? Малі компанії зазвичай не роблять такої оцінки ризику, але це означає, що постійний успіх бізнесу залишається випадковості.

розмір / кількість розробників коду не пов'язаний з навантаженням. Якщо у вас є величезна стабільна база коду, показник буде високим. Якщо у вас ще є невелика база коду, яка ще знаходиться в розробці, ця метрика буде низькою. Зміна ліній в одиницю часу на розробника більше пов'язана з навантаженням. Але навіть тоді я витратив дні на відстеження тонких помилок, виправлення яких було одним рядком ...

Код повинен відповідати групі, а не одному розробнику. Підтримку слід делегувати справедливо щотижня, здається, дурно виділяти її будь-яким іншим способом. Якщо це не так, я пропоную вам поговорити зі своїм керівництвом.

У ситуації, коли ви описуєте одного розробника, можливо, намагаєтесь дотриматись термінів через величезну підтримку з однієї області, де працюють інші розробники. Це дуже неефективна структура управління.

Також я пропоную вам відійти від вимірювання навантаження в рядках коду. Людські години - це єдиний розумний показник, про який я можу придумати

Вимірювання прогресу програмування за допомогою рядків коду подібно вимірюванню прогресу будівництва літака за вагою - Білл Гейтс

NB. Я не кажу рівним, кажу справедливо. Також варто відзначити, що штрафом спеціалізується на певних аспектах кодової бази, що відбувається природно. Єдина його проблема, якщо ніхто більше ніколи не працює над цим кодом.

Наприклад, якби у Facebook було 2 програмісти, вони, очевидно, були б перевантажені роботою - але ЯК би ти дійшов такого висновку? Це тип питання, над яким я йшов.

Це не питання програмування, це питання управління.
На це можна відповісти кілька простих питань, і вони не мають нічого спільного з програмним забезпеченням.

1. Скільки годин ви працюєте?
2. Скільки годин ви повинні працювати?
3. Чи дотримуються терміни?

Тоді дотримуйтесь цієї логіки:

• Якщо 1> 2, вам потрібно більше людей або менш агресивні терміни.
• Якщо 1 <2, вам потрібно менше людей або більше ініціатив.
• Якщо терміни не дотримані і 1> = 2, вам потрібно більше людей.
• Якщо терміни не дотримані та 1 <2, ви повинні когось звільнити.

Це надмірне спрощення, яке має два яскраві недоліки.

• Люди не створені рівними.
• Існують способи зробити людину більше виробництвом (оновити комп’ютер чи щось таке).

Але ви отримуєте ідею.