Na ogół kiepskim pomysłem jest nazywanie swojego szefa idiotą, więc moje sugestie zaczynają się od zrozumienia i omówienia wskaźników, a nie ich odrzucenia.
Niektóre osoby, które tak naprawdę nie są uważane za idiotów, korzystały z danych opartych na wierszach kodu. Używali ich Fred Brooks, Barry Boehm, Capers Jones, Watts Humphries, Michael Fagan i Steve McConnell. Prawdopodobnie z nich korzystałeś, nawet jeśli tylko powiedzieć koledze, ten moduł Boga ma 4000 linii, należy go podzielić na mniejsze klasy.
Istnieją konkretne dane związane z tym pytaniem ze źródła, które wielu z nas szanuje.
http://www.codinghorror.com/blog/2006/07/diseconomies-of-scale-and-lines-of-code.html
http://www.codinghorror.com/blog/2005/08/are-all-programming-languages-the-same.html
http://discuss.joelonsoftware.com/default.asp?joel.3.286106.22
Podejrzewam, że najlepszym zastosowaniem wiersza kodu na godzinę programisty jest pokazanie, że w trakcie trwania projektu wartość ta zacznie się dość wysoko, ale w miarę wykrycia i naprawienia defektów zostaną dodane nowe wiersze kodu w celu rozwiązania problemów, które nie były częścią pierwotnych szacunków, a wiersze kodu usunięte w celu wyeliminowania powielania i poprawy wydajności pokażą, że LOC / hr wskazuje na rzeczy inne niż produktywność.
- Gdy kod zostanie napisany szybko, niechlujnie, nadęty i bez jakiejkolwiek próby refaktoryzacji, pozorna wydajność będzie najwyższa. Morał będzie polegał na tym, że musisz uważać na to, co mierzysz.
- W przypadku konkretnego programisty, jeśli w tym tygodniu dodają lub dotykają dużej ilości kodu, w przyszłym tygodniu może wystąpić techniczny dług związany z przeglądem kodu, testem, debugowaniem i przeróbką.
- Niektórzy programiści będą pracować z bardziej spójną wydajnością niż inni. Może się okazać, że spędzają najwięcej czasu na tworzeniu dobrych historii użytkowników, bardzo szybko się odwracają i przeprowadzają odpowiednie testy jednostkowe, a następnie odwracają się i szybko tworzą kod, który koncentruje się tylko na historiach użytkowników. Problem polega na tym, że metodyczni programiści prawdopodobnie szybko się odwrócą, napiszą kompaktowy kod i będą mieli niewielkie poprawki, ponieważ bardzo dobrze rozumieją problem i rozwiązanie, zanim zaczną kodować. Wydaje się rozsądne, że kodują mniej, ponieważ kodują dopiero po przemyśleniu, zamiast przed i po.
- Gdy kod jest oceniany pod kątem gęstości defektów, okaże się, że jest mniej niż jednolity. Niektóre kody odpowiadają za większość problemów i wad. Będzie kandydatem do przepisania. Kiedy tak się stanie, stanie się najdroższym kodem, ponieważ dzięki temu wysoki stopień przeróbki. Będzie miał najwyższą liczbę wierszy kodu brutto (dodaną, usuniętą, zmodyfikowaną, jak można zgłaszać z narzędzia takiego jak CVS lub SVN), ale najniższą zainwestowaną linię netto kodu na godzinę. Może to być kombinacja kodu albo implementującego najbardziej złożony problem, albo najbardziej skomplikowane rozwiązanie.
Niezależnie od tego, jak okaże się debata na temat produktywności programisty w liniach kodu, przekonasz się, że potrzebujesz więcej siły roboczej, niż możesz sobie pozwolić, a system nigdy nie zostanie ukończony na czas. Wasze prawdziwe narzędzia nie są miernikami. Używają najlepszej metodologii, najlepszych programistów, których możesz zatrudnić lub szkolić, a także kontroli zakresu i ryzyka (prawdopodobnie metodami zwinnymi).