Ile kodu powinienem być odpowiedzialny?

Dzięki kolegom i wywiadom wyjściowym słyszałem, że w mojej małej firmie jestem „odpowiedzialny” za 3–10 razy więcej kodów niż w innym miejscu pracy. Próbuję poszukać pewnego rodzaju rozmytych danych, których mogę użyć do porównania obciążenia pracą z innymi w mojej dziedzinie.

Przez „odpowiedzialność za kod” nie mam na myśli „jestem jedynym, który zna obszar X podstawy kodu” (choć niestety często tak jest w środowisku startowym), ale raczej odnoszę się do liczby takiej jak „code_base_size / number_of_developers ".

Czy są jakieś zasoby, których mogę użyć, aby pomóc mi dokładniej zmierzyć obciążenie pracą niż tylko zliczanie linii kodu?

Jedynym konkretnym miernikiem dla zatrudnionego programisty jest liczba godzin spędzonych na kodowaniu i naprawianiu błędów oraz pieniądze, które otrzymasz za to. Jeśli spóźnisz się na noc 6 dni w tygodniu za 50 000 USD rocznie, masz problem. Bez względu na to, ile wierszy kodu chcesz, abyś był odpowiedzialny, nie poradzisz sobie więcej niż możesz, biorąc pod uwagę pewną jakość kodu. Opracowanie słabej jakości kodu bez testów jednostkowych to dobry sposób na obsługę znacznie większej liczby kodów, ale firma będzie musiała zapłacić cenę dużego długu technicznego .

W małych firmach programiści są zwykle odpowiedzialni za znacznie więcej kodu niż w dużych korporacjach. Współczynnik od 3 do 10, o którym mówisz, wydaje mi się realistyczny.

Znałem trzyosobowy zespół, który zarządzał bazą kodu 1,5 miliona linii i nie utonął w nim. Ważnym pomiarem nie jest to, za ile kodu jesteś odpowiedzialny, ale raczej, ile kodu musisz zmienić w określonym przedziale czasu.

Istnieje również kąt oceny ryzyka. Jeśli jesteś jedyną osobą, która zna kawałek kodu, jaki jest koszt alternatywny, który zostałby utracony, gdybyś wszedł pod autobus? Małe firmy zwykle nie przeprowadzają takiej oceny ryzyka, ale oznacza to, że dalszy sukces firmy jest pozostawiony przypadkowi.

rozmiar bazy kodu / liczba programistów nie jest związana z obciążeniem. Jeśli masz ogromną stabilną bazę kodu, ta metryka będzie wysoka. Jeśli wciąż masz małą bazę kodu w fazie opracowywania, wskaźnik ten będzie niski. zmiany linii na jednostkę czasu na programistę są bardziej związane z obciążeniem. Ale nawet wtedy spędziłem dni na śledzeniu subtelnych błędów, których poprawka dotyczyła jednej linii ...

Kod powinien być obowiązkiem grupy, a nie jednego programisty. Wsparcie należy delegować co tydzień, głupotą wydaje się przydzielanie go w jakikolwiek inny sposób. Jeśli tak nie jest, proponuję porozmawiać z kierownictwem.

W sytuacji, gdy opisujesz jednego programistę, możesz mieć trudności z dotrzymaniem terminów z powodu ogromnego wsparcia z jednego obszaru, w którym inni programiści są niedostatecznie pracowani. Jest to bardzo nieefektywna struktura zarządzania.

Sugeruję również odejście od mierzenia obciążenia w liniach kodu. Roboczogodziny to jedyny rozsądny wskaźnik, jaki mogę wymyślić

Mierzenie postępu programowania liniami kodu jest jak mierzenie postępu budowy samolotu według wagi - Bill Gates

NB Nie mówię równo, mówię uczciwie. Warto również zauważyć, że dobrze jest specjalizować się w niektórych aspektach bazy kodu, co dzieje się naturalnie. Jest to tylko problem, jeśli nikt inny nie pracuje nad tym kodem.

Na przykład, gdyby Facebook miał 2 programistów, byliby oczywiście przepracowani - ale JAK doszedłbyś do tego wniosku? Tego rodzaju pytania szukałem.

To nie jest pytanie programistyczne, to pytanie zarządcze.
Istnieje kilka prostych pytań, na które można odpowiedzieć i nie mają one nic wspólnego z oprogramowaniem.

1. Ile godzin pracujesz?
2. Ile godzin powinieneś pracować?
3. Czy terminy są dotrzymywane?

Następnie postępuj zgodnie z tą logiką:

• Jeśli 1> 2, potrzebujesz więcej osób lub mniej agresywnych terminów.
• Jeśli 1 <2, potrzebujesz mniej osób lub więcej inicjatyw.
• Jeśli terminy nie są dotrzymywane, a 1> = 2, potrzebujesz więcej osób.
• Jeśli terminy nie zostaną dotrzymane i 1 <2, powinieneś kogoś zwolnić.

Jest to nadmierne uproszczenie, które ma dwie rażące wady.

• Ludzie nie są równi.
• Istnieją sposoby na zwiększenie produktywności ludzi (ulepszenie komputera lub coś takiego).

Ale masz pomysł.