Czy znane są prawidłowe zastosowania SLOC do pomiaru wydajności?

55

Odbyłem niezwykłą, krótką rozmowę z bardzo starszym architektem na temat języków dynamicznych i statycznych. Powiedział, że dane firmy pokazują, że istnieją dowody na wyższą produktywność, gdy używane są języki statyczne. Uwaga, to duża firma z długą historią. Ku mojemu (i innym) zaskoczeniu metryką, której użył, były dodane wiersze kodu.

Szybko odrzucił obiekcje dotyczące metryki, mówiąc, że w tej samej firmie, z podobną kulturą, branżą i wystarczającą ilością danych, różnice (dotyczące unikalnych sytuacji i możliwości osób fizycznych) mieszają się na tyle, że metryka SLOC jest przydatna do porównania wydajności narzędzia i języki.

Chociaż nie sądzę, aby twierdzenie to było poparte rygorystyczną analizą statystyczną, czy istnieją jakieś dowody w branży, które popierałyby ten sposób myślenia?

sevo
źródło
25
Produktywność to zły termin. Termin ten jest definiowany jako ilość pracy wykonanej w określonym czasie, niezwiązanym z produkowanym kodem.
Frank Hileman,
25
Mądra osoba powiedziała, że ​​powinniśmy traktować wiersze kodu nie jako „wbudowane”, ale jako „wydane”; w inżynierii fizycznej, gdy weźmiemy pod uwagę liczbę części i długość BOM, im mniejsze, tym lepiej.
pjc50,
23
Porównywanie różnych języków (bez względu na to, czy są statyczne czy dynamiczne) przeczy założeniu „w tej samej firmie, z podobną kulturą, branżą”: różnice w językach sprawiają, że porównania SLOC nie mają znaczenia.
okradać
4
Ta metoda jest tragicznie wadliwa. Nawet dwóch różnych programistów w tej samej firmie korzystających z tego samego środowiska programistycznego często tworzy drastycznie różne SLOC, aby wdrożyć ten sam zestaw funkcji.
17 z 26
8
Używanie SLOC do mierzenia produktywności ma tyle samo sensu, co wykorzystywanie emitowanych zanieczyszczeń do mierzenia przebytej odległości, gdy najważniejsze jest oszczędność paliwa. Sposoby, w jakie jest to właściwe, są nadal błędne. Użyj tego .
candied_orange

Odpowiedzi:

66

Argument starszego architekta może oznaczać dwie rzeczy.

  1. Może to oznaczać, że przeciętny programista w firmie produkuje więcej wierszy kodu , używając języków statycznych niż dynamicznych. Na przykład, jeśli piętnastu programistów pracuje z Javą przez sześć miesięcy, napiszą 100 KLOC, a jeśli tych samych piętnastu programistów będzie pracować z Pythonem przez sześć miesięcy, napiszą tylko 50 KLOC.

    Nie ma tu korelacji między LOC a produktywnością. Co się stanie, jeśli potrzeba czterech razy więcej wierszy kodu w Javie, aby uzyskać tę samą funkcję niż w Pythonie? Jeśli to prawda, użycie Pythona spowodowałoby dwukrotność wydajności, w oparciu o powyższe wskaźniki KLOC.

  2. Może również oznaczać, że przeciętny programista w firmie produkuje mniej wierszy kodu , używając języków statycznych niż dynamicznych: piętnaście programistów napisałoby w ciągu sześciu miesięcy 100 KLOC w Javie lub 200 KLOC w Pythonie.

    Chociaż zwykle mniej wierszy kodu jest lepszych (mniej kodu do pisania, czytania i utrzymywania), nadal nie jest jasne, ile funkcji opracowali programiści Java w porównaniu do Pythona. Może napisali pół wiersza kodu w porównaniu do programistów Pythona, ale stworzyli także połowę liczby funkcji?

W obu przypadkach LOC nie jest cenną miarą, ponieważ ta sama funkcja nie tłumaczyłaby tyle samo wierszy kodu w różnych językach . Niektóre języki są bardziej szczegółowe; inne - bardziej kompaktowe. Chociaż w niektórych przypadkach zwartość jest cenna, nie ma na to ogólnej zasady. Skrajnym przykładem byłby język Brainfuck, który ma ekstremalną zwartość, ale który nie jest popularny ze względu na czytelność. Porównywanie nawet podobnych języków może być trudne: na przykład, jeśli chodzi o nawiasy klamrowe, Java podąża za stylem K&R, podczas gdy w języku C # otwierający nawias klamrowy jest w swoim własnym stylu, w większości przypadków podążając za oficjalnym stylem, co prowadzi do sztucznego wzrost LOC dla C #. A co się stanie, gdy porówna się język proceduralny z językiem obiektowym lub językiem funkcjonalnym?

Zamiast korzystać ze wskaźników podatnych na błędy, starszy architekt może polegać na grupie wskaźników, które mierzą wydajność, gdy są używane razem: liczba funkcji opracowywanych miesięcznie, liczba błędów wprowadzonych do bazy kodu i czas spędzony na ich rozwiązywaniu , ewolucja długu technicznego itp. Porównanie to może być trudne na początku, ponieważ należy wziąć pod uwagę nieznajomość nowego języka przez zespół. Gdy zespół się z nim zaznajomi, wybór powinien opierać się na stabilnych wskaźnikach, a także w większości na preferencjach samych członków zespołu.

LOC ma wartość w niektórych wąskich sytuacjach. Na przykład może podpowiedzieć na temat wielkości projektu i jego części (i średnio koreluje z punktami funkcyjnymi, choć często jest łatwiejszy do zmierzenia) lub wskazać metody i klasy, które mogą wymagać dalszej uwagi, ponieważ ich dużego rozmiaru. LOC należy jednak stosować ostrożnie, ponieważ jest zbyt często wykorzystywany przez osoby, które wyobrażają sobie korelację między niepowiązanymi rzeczami. Najbardziej katastrofalnym wykorzystaniem LOC-ów była w przeszłości próba zmierzenia wydajności pojedynczego programisty na podstawie LOC-ów pisanych miesięcznie.

Arseni Mourzenko
źródło
8
Tak. Jedyną miarą, której ufam, jest liczba biletów (funkcji, błędów, badań itp.) Ukończonych na jednostkę czasu. Różni się w zależności od zespołu (inny zespół rozkłada bilety o różnej ziarnistości), ale w obrębie tego samego zespołu lub grupy zespołów pojawi się kultura, aby rozmiary biletów były dość dokładne (o ile nie porównasz ich spoza tej kultury)
slebetman,
10
Rzecz, którą lubię bardziej: „Nigdy nie polegaj tylko na jednej metodzie”
Chococroc,
30
@slebetman Jestem zazdrosny o precyzję / spójność osoby tworzącej bilety, ale muszę rozwiązać problemy, od „Napraw pisanie 2 słów” do „Dodaj funkcję X”. Metryka biletów jest dla mnie jeszcze mniej przydatna niż LOC. Zredukowany kod klasy o 20 LOC przynajmniej daje mi wyobrażenie o wykonanej pracy. Rozwiązanie 5 biletów może być godziną pracy, ale równie dobrze może to być tydzień.
R. Schmitz,
3
@ R.Schmitz To samo w mojej firmie, ale każdy bilet ma również skojarzony rozmiar, więc sumowanie przy rozmiarach biletów będzie działać.
Nico Burns,
1
Nawet próby użycia tych wskaźników mają problemy. Co jeśli dodane funkcje są złożone i trudne do wdrożenia? Może to być nawet sytuacja, w której określone funkcje są szczególnie łatwe lub trudne do wdrożenia dla języka, ale ogólnie język jest łatwiejszy / trudniejszy w obsłudze. Brak wydajności może być również spowodowany brakiem znajomości języka przez obecnych pracowników. Nie należy przede wszystkim polegać na wskaźnikach, aby określić, jakiego języka użyć.
John Smith,
26

O wydajności i SLOC

Problem z SLOC

Problem z metryką SLOC polega na tym, że mierzy ona przybliżoną ilość napisanego kodu, nie biorąc pod uwagę:

  • jakość kodu (tj. co jeśli na każde 100 SLOC trzeba dodać kolejne 90 SLOC z powodu błędów, ale których nie znasz w momencie dostarczenia kodu?)
  • cele osiągnięte za pomocą kodu (tj. czy 10K SLOC obsługuje wszystkie oczekiwane przypadki użycia lub historie użytkowników? czy tylko niewielki podzbiór?)
  • łatwość konserwacji kodu (tj. czy będziesz musiał dodać 1% lub 50% więcej kodu w celu dostosowania kodu do oczekiwanych ewoluujących wymagań?).

W przeciwnym razie produkcja podatnego na błędy, niemożliwego do utrzymania kodu spaghetti z dużą ilością skopiowanych części zostanie uznana za bardziej produktywną niż starannie zaprojektowany kod wielokrotnego użytku.

Dlatego SLOC zdecydowanie nie jest najlepszym sposobem pomiaru wydajności.

Jaką produktywność rozważamy?

Wydajność jest mierzona dla procesu. Tak więc SLOC może być doskonale ważnym wskaźnikiem dla samego procesu kodowania.

Jeśli na przykład źle zrozumiesz słabe wymagania, poświęcisz pięć miesięcy na wyprodukowanie oprogramowania, pokażesz go użytkownikowi, odkryjesz, że jest po prostu źle i poświęcisz kolejne 5 miesięcy na przepisanie go na dobre od zera, będziesz mieć taką samą produktywność w SLOC / miesiąc, że zespół pisze kod po raz pierwszy, na przykład dlatego, że zastosował zwinny proces, który zmniejsza nieporozumienia poprzez częste informacje zwrotne. Ta pozorna równa wydajność kryje ogromne problemy.

Tak więc pomiar produktywności oprogramowania musi uwzględniać cały proces, w tym analizę wymagań, projektowanie kodu, kodowanie, testowanie, debugowanie i sprawdzanie, czy spełnione są oczekiwania użytkowników. Ponieważ wszystkie te czynności są bardzo różne, najlepszą rzeczą jest zmierzenie jedynej ważnej myśli: działającego oprogramowania, czyli tego, co wyprodukowane oprogramowanie oznacza dla użytkownika .

Jak mierzyć elementy oprogramowania?

Istnieje kilka podejść:

  • Typowym podejściem w klasycznej inżynierii oprogramowania są punkty funkcyjne (FP). Punkty funkcyjne są mierzone w oparciu o wymagania, które należy spełnić (np. Liczba formularzy, liczba pól w każdym formularzu itp.). Wydajność jest następnie mierzona w FP na jednostkę czasu i na osobę. Niektóre firmy dysponują nawet danymi określającymi, ile punktów funkcyjnych programista może wygenerować na jednostkę czasu w danym języku dla danej domeny. Problem z FP polega na tym, że wymaga on z góry bardzo szczegółowych wymagań i jest czasochłonny.
  • Bardziej nowoczesne i pragmatyczne podejście to punkty historii (SP). Służą one do oceny złożoności kodu, który ma zostać wygenerowany, i są rutynowo wykorzystywane do oceny szybkości pracy zespołów programistycznych. Jednak SP jest miarą szacunkową dla pracy wykonanej przed poznaniem wszystkich szczegółów. To nie jest ostateczna miara tego, co się naprawdę wydarzyło. Dlatego należy zachować ostrożność przy stosowaniu go jako miary wydajności, ponieważ może to mieć negatywny wpływ na proces szacowania .

O wydajności pisania statycznego vs. dynamicznego

Muszę wyznać, że osobiście jestem fanem statycznie pisanych języków, ponieważ w moim wnętrzu wiem, że jest bardziej niezawodny (lata kodowania mi to udowodniły).

Tak więc jedną rzeczą, którą z całą pewnością biorę pod uwagę, jest to, że język o typie statycznym jest w stanie zapobiec znacznie większej liczbie błędów / błędów w czasie kompilacji (np. Literówki, niedopasowanie w oczekiwanych typach itp.) Niż języki o typie niestatycznym. Ale z całą obiektywnością nie odważyłbym się obelżywie uogólnić to jako wyższą wydajność.

Czy twój architekt ma rację?

Może, może nie.

Ale jego argumenty nie wydają się słuszne: wzrost produktywności języka o typie statycznym wynika ze znacznej liczby błędów wykrytych z góry przez kompilator.

W związku z tym nie można dowiedzieć się o tym „wyższym” wzroście produktywności, patrząc tylko na SLOC, bez analizowania poprawek wymaganych dla dynamicznie typowanych języków. Więc jego porównanie nie może być uczciwe.

Argument porównywalnych okoliczności również nie ma miejsca. Niektóre języki o typie dynamicznym pozwalają na konstrukcje wyższego poziomu, które wymagają mniej kodu niż robienie tego samego w jednym z klasycznych języków o typie statycznym. Możesz więc potrzebować mniej czasu, pisać mniej kodu, ale dodać te same koszty analizy, testowania i weryfikacji. Zatem pomiar wydajności przez SLOC osłabiłby potencjalny wzrost wydajności, tworząc w ten sposób uprzedzenie względem dynamicznie typowanego języka.

Jakieś badania na poparcie tego twierdzenia?

Istnieje kilka najnowszych badań akademickich na ten temat. Chociaż niektóre z nich widzą zaletę pisania statycznego, generalnie są ograniczone do określonego celu (dokumentacja, ponowne użycie źle udokumentowanego kodu lub API itp.). Rozsądne sformułowanie jest również stosowane, ponieważ współczesne IDE znacznie zmniejszyło ryzyko związane z dynamicznym pisaniem:

Christophe
źródło
3
Wasze uwagi krytykowe zostały już poruszone w pytaniu: „ w tej samej firmie, z podobną kulturą, branżą i wystarczającą ilością danych, różnice (w odniesieniu do unikalnych sytuacji i możliwości osób fizycznych) mieszają się na tyle, aby wskaźnik SLOC był użyteczny ”. Tj. Argument był taki, że w tej skali wszystkie bazy kodu byłyby porównywalnej jakości. Chociaż osobiście bardzo wątpię, że to prawda.
amon
Używamy gitprime ( gitprime.com ) do konkretnych pomiarów, a jedną z rzeczy jest śledzenie, ile razy programista zapisuje te same wiersze kodu. Więc jeśli napiszesz jakiś kod, otrzymasz raport o błędzie i ponownie go napiszesz, faktycznie mierzy on twoją wydajność i zgłasza produktywność netto. Krótko mówiąc, nie sądzę, aby twoje komentarze były nieodłącznymi problemami w stosowaniu SLoC jako miary wydajności. Myślę raczej, że twoje skargi dotyczą systemów, które nie mierzą SLoC „prawidłowo”.
Conor Mancone,
8
@ ConorMancone Nikt nie zarabia na pisanie kodu. Zarabiają na tworzeniu rozwiązań. Analogią byłoby zmierzenie stolarza na podstawie liczby zużytych gwoździ i desek. Klaun, który tnie deski na krótko i zgina więcej gwoździ, które jedzie do domu, przy tej metodzie będzie bardziej produktywny niż mistrz stolarski.
JimmyJames,
1
@Christophe Eksperymentowałem z pomiarem wyników do produkcji jako głównej miary wydajności. Jedyną trudną częścią jest to, że niektóre rzeczy mogą być bardziej pracochłonne niż inne, ale z tego, co mogę powiedzieć, z czasem rzeczy zmierzają w kierunku dość (statystycznie) spójnej wydajności w oparciu o wielkość zespołu i skład. Oczywiście wiele się w tym dzieje, więc atrybucja może być wyzwaniem, ale stanowi podstawę wszelkich innych pomiarów wydajności programistycznej.
JimmyJames,
2
Wiele lat temu w co najmniej jednym sklepie programistycznym niektórzy pisali diagramy logiczne, a inni przekształcali je w kod kompilowalny. W istocie kompilator tego sklepu miał ludzkich preprocesorów. Sprawiedliwe byłoby stosowanie SLoC / miesiąc do mierzenia wydajności jednego z tych ludzkich preprocesorów; jest to analogiczne do liczby śrub, które pracownik linii montażowej może zamontować w otworach, do których inżynierowie powinni się udać. Inżynier, który określa 100 śrub, gdy 15 jest tym, czego wymaga praca, obniża produktywność firmy. (Podobnie, jeśli określą 5 śrub!)
David K
7

Oto kontrprzykład dla twojego starszego architekta: Załóżmy, że chcę napisać hierarchię trzech klas, z których dwie wywodzą się z trzeciej, implementując niektóre funkcje wirtualne zdefiniowane przez klasę podstawową.

Jeśli napiszę te trzy klasy w C ++, to całkiem proste. Deklaruję zajęcia, używam wirtualnych w odpowiednich miejscach i gotowe.

Jeśli napiszę te trzy klasy w C, muszę dodać sporo kodu: muszę zdefiniować structs dla tabel v, muszę dodać wskaźnik tabeli v do klasy podstawowej, muszę dodać kod do konstruktorów, aby faktycznie ustawić wskaźniki tabeli v, muszę dodać kod konstruktorów, aby faktycznie wywołać konstruktor klasy podstawowej, muszę dodać kod, aby jawnie wykonać alokację pamięci przed wywołaniem konstruktora (co C ++ newrobi w jednym kroku ), podobnie, muszę oddzielić zniszczenie od kolejnego free()wezwania, i tak dalej, i tak dalej.

Chodzi o to, że wszystkie te dodatkowe rzeczy są dość bezmyślne. Mogę zrobić to bardzo szybko. Więc napisanie wersji C nie zajmie mi więcej czasu niż napisanie wersji C ++. Niemniej jednak stworzyłem o wiele więcej wierszy kodu C niż kod C ++. Tak bardzo, że wydaje się, że byłem bardziej produktywny w C pod względem SLOC.

Każdy język, który wymaga pewnej ilości kodu wzorcowego, będzie wydawał się bardziej produktywny pod względem SLOC niż język, który nie wymaga takiej samej ilości kodu wzorcowego.

Widzisz, argument SLOC jest tak zasadniczo wadliwy, że faktycznie widziałbym to na odwrót: przyjąłbym stwierdzenie „programiści zwykle produkują więcej SLOC w językach statycznych”, co oznacza: „języki statyczne wydają się wymagać więcej kod płyty grzewczej, a tym samym zmniejszyć wydajność ”.

cmaster
źródło
1
Podoba mi się twoje ostatnie zdanie.
Peter - przywróć Monikę
1
„wydaje się, że języki statyczne wymagają więcej kodu podstawowego, a tym samym zmniejszają wydajność”: to ponownie pokazuje, jak błędne są wskaźniki SLOC. Ostateczna liczba wierszy nie uwzględnia (1) ile razy trzeba było przepisać kod przed uzyskaniem ostatecznego rozwiązania (2) ile dodatkowych wierszy kodu w postaci testów jednostkowych (języki dynamicznie typowane wymagają średnio więcej testy jednostkowe, aby mieć porównywalne zaufanie do poprawności kodu produkcyjnego). Wskaźnik SLOC jest zdecydowanie wadliwy.
Giorgio
6

Będę contrarian.

Śledzimy SLoC w naszej pracy (chociaż nie używamy go bezpośrednio w decyzjach dotyczących personelu) i kazałem ludziom spierać się na to, co większość ludzi mówi w swoich odpowiedziach. W efekcie „LoC nie ma znaczenia, ponieważ technologia X pozwala nam robić więcej przy mniejszym kodzie” lub „Lepsi programiści piszą lepszy, krótszy kod, więc nie piszą więcej niż ktokolwiek inny”. Z mojego doświadczenia (chociaż nie mam twardych liczb, które mogłyby poprzeć te rzeczy), te obiekcje są po prostu nieprawidłowe. W swoim czasie widziałem wyraźną korelację zarówno szybkości, jak i jakości produkcji kodu dla naszych programistów, w porównaniu z wszystkimi innymi znaczącymi pomiarami ich ogólnej „kompetencji” jako inżyniera. Aby podać kilka kontrprzykładów do argumentów przedstawionych powyżej:

  1. Tak, niektóre języki mogą więcej z mniejszym kodem. W rzeczywistości mamy cały szkielet, który zbudowaliśmy, który „automatyzuje” duże części rozwoju naszych konkretnych problemów biznesowych (tylko back-end). Wynikiem tego wszystkiego nie jest to, że ludzie piszą mniej kodu, ale po prostu, że mamy więcej czasu na napisanie kodu. W rezultacie w naszej firmie ogólny wskaźnik pisania kodu jest dość stały we wszystkich technologiach i zależy przede wszystkim od poziomu kompetencji inżyniera.
  2. Pomysł, że lepszy programista będzie produkował mniej kodu, ponieważ piszą mądrzej, zdecydowanie nie jest prawdą. Tak, lepiej zaprojektowany program może zajmować mniej wierszy kodu. Jednak osobiście przekonałem się, że „lepsi” programiści piszący bardziej efektywny kod nie potrzebują więcej czasu, aby go zaplanować, niż bardziej młodsi programiści piszący na dłuższą metę. W rezultacie bardziej zaawansowani programiści szybciej wykonają swoje zadania kodowania i przejdą do pisania innego kodu z tą samą wysoką szybkością.

Ta ostatnia część to moje ogólne podsumowanie, BTW. Odkryłem, że niezależnie od stosu technologicznego lub rodzaju projektu, większość programistów ma swoje własne tempo, w którym działają. Jeśli język ma wiele funkcji, które zwiększają efektywność kodu programistów, jest to duży zysk dla firmy, ale to nie znaczy, że w rezultacie będą pisać mniej kodu. Zamiast tego szybciej wykonują funkcje i szybko przechodzą do nowego kodu. Ponownie, końcowym rezultatem jest to, że szybkość, z jaką kodują, zależy przede wszystkim od ich umiejętności, a mniej od ich stosu technologii. W rzeczywistości z tego powodu ogólnie spodziewałbym się, że stos technologii będzie miał większy wpływ na szybkość opracowywania biletów i funkcji niż na szybkość kodowania przez ludzi.

To powiedziawszy, ani szybkość pisania kodu, ani szybkość zamykania biletów nie jest doskonałą miarą wydajności, dlatego nie podejmujemy bezpośrednio decyzji personalnych na podstawie SLoC. Zamiast tego jest to część procesu, a oceny pracowników są przeprowadzane przy użyciu jak największej liczby punktów danych. Powiedziałbym jednak, że twój architekt z pewnością nie jest szalony.

Jeden wyjątek

Jedynym wyjątkiem, z którym się zgadzam, jest możliwość podania kodu kotła. Jeśli wiele klas kopiowania i wklejania dzieje się z jednej klasy (lub czegokolwiek) do drugiej, aby ją uruchomić, to oczywiście zniekształci wskaźniki. Dotyczy to również narzędzi, które mogą automatycznie generować duże ilości kodu. Myślę jednak, że często będą to raczej wyjątek niż reguła. Jeśli programiści poświęcają trochę czasu na kopiowanie kodu płyty kotła, aby rozpocząć, to używasz niewłaściwego zestawu technologii. Jeśli faktycznie piszą kod, nawet jeśli jest dość powtarzalny, spodziewam się, że to wypaczy wszelkie pomiary tylko w niewielkim stopniu: podczas pisania kodu, przez większość czasu jesteśmy ograniczeni przez to, jak szybko potrafimy przemyśleć problem niż jak szybko możemy pisać. Nawet podczas pisania stosunkowo powtarzalnego kodu,

Oczywiście wszystko powyżej opiera się na moich osobistych doświadczeniach. Twój przebieg może się różnić i oczywiście jestem w mniejszości. Możesz się nie zgodzić. Podsumowując:

Uważam, że szybkość kodowania zależy bardziej od tego, jak szybko możesz przemyśleć swoje problemy, niż cokolwiek innego. W rezultacie odkryłem, że szybkość kodowania jest przyzwoitą miarą wydajności, nawet w zestawach technicznych, z kilkoma możliwymi wyjątkami.

Conor Mancone
źródło
4
Jest jeszcze jeden wyjątek: poszukiwanie błędów. Poszukiwanie błędów w przypadku szczególnie paskudnych błędów może zająć dużo czasu, ale zwykle skutkuje zmianą jednej linii kodu.
Nathan Merrill,
@NathanMerrill To dobrze, że chociaż mniej istotne dla OP: debugowanie jest debugowaniem we wszystkich językach i (z góry mojej głowy), nie widzę powodu, dla którego byłoby to znacznie łatwiejsze lub trudniejsze z jednego stosu technologii na inny. To powiedziawszy, dlatego jest to powód, dla którego ogólnie rzecz biorąc, nie można oceniać produktywności wyłącznie na podstawie napisanego kodu, bardziej niż na innych metrykach.
Conor Mancone,
Używamy gitprime ( gitprime.com ) w naszej firmie i jako menedżer i inżynier uważam, że jest to najlepsza rzecz na świecie. Ponownie, jest to tylko część obrazu dla nas, ale była bardzo pomocna w identyfikowaniu potencjalnych problemów z inżynierami na długo przed faktycznym problemem. Przejrzystość jest niesamowita, a wszystko, co robią, ostatecznie sprowadza się do SLoC. Biorąc pod uwagę wartość i wgląd, jaki dodaje, zawsze bardzo wątpię w tendencję niektórych inżynierów do odrzucania SLoC pod kontrolą. Wszyscy są mile widziani, ale to zdecydowanie działa
Conor Mancone,
Pytanie brzmi, czy LoC można wykorzystać do porównywania narzędzi i języków, w kontekście wyższego dewelopera, który twierdzi, że wykazuje wyższą wydajność w językach „statycznych”. Wydaje się, że odpowiadasz na inne pytanie - LoC może być używany do porównywania programistów, ale nadal zgadzasz się, że nie można go używać do porównywania języków, ponieważ dany programista pisze taką samą liczbę LoC niezależnie od narzędzia / języka? Mówisz, że jesteś sprzeczny z innymi odpowiedziami tutaj, ale wydaje się, że zgadzasz się?
TessellatingHeckler
Jako programista wielokrotnie myślę o tym, że wziąłem garść kodu innego niż DRY i zastąpiłem go niewielkim zestawem funkcji wielokrotnego użytku. Następnie dodałem znaczną liczbę nowych funkcji. Zmniejszenie ilości kodu przy jednoczesnym dodaniu wielokrotności rzeczywistej wartości to dobra rzecz w mojej książce. Z mojego doświadczenia wynika, że ​​najlepsi inżynierowie piszą najmniej wierszy kodu, a najgorzej piszą najwięcej.
JimmyJames,
6

Chociaż wskakuję na modę. Myślę, że należy podkreślić wpływ na zachowanie programistów.

Używanie SLOC jako miernika produktywności ma toksyczny wpływ na morale programistów. W momencie, gdy jakikolwiek inżynier w twoim zespole / firmie zda sobie sprawę, że są mierzone na SLOC, dzieje się kilka rzeczy:

  1. Zaczynają pisać znacznie dłuższy kod, aby wykonać tę samą funkcję
  2. mniej dbają o jakość swojego kodu
  3. przestaną robić inne rzeczy, które pomogą Twojemu zespołowi (rekrutacja, debugowanie, pomaganie młodszym)
  4. będą nienawidzić swojej pracy i prawdopodobnie odejdą

Nie mogę wystarczająco mocno podkreślić, jak korozyjnie jest wpływać na morale, ponieważ widziałem to dwa razy w 2 różnych firmach. Niezależnie od tego, jak pozornie ważne są przypadki użycia, twierdzę, że nie jest to warte wpływu na Twój zespół / firmę, nawet jeśli istnieje tylko niewielka szansa, że ​​zostanie ono odkryte. Chociaż w niektórych przypadkach może istnieć korelacja między liczbą zapisanych wierszy a ilością przydatnych funkcji, zachęca to wszystkich niewłaściwych zachowań u programistów i wysyła komunikat, że jakość nie jest ważna.

Nath
źródło
Rzeczywiście ... każda metryka, która zniechęca kogoś do usuwania zbędnego kodu („w tym tygodniu miałeś negatywną charakterystykę SLoC!” Jest błędna, po prostu błędna!
Andrew
1

Na ogół nie jest uważany za prawidłowy sposób pomiaru wydajności. Mniejszy kod jest zwykle lepszy niż większy, więc bardziej produktywny programista zwykle wytwarza mniej kodu. Wydajność ma największy hit w debugowaniu; wydajni programiści poświęcają niewiele czasu na debugowanie.

Języki o typie statycznym są bardziej wydajne (jeśli kontrolujesz wszystkie inne różnice między językami), ponieważ gdy są używane mądrze, skracają czas debugowania, wychwytując błędy w fazie kompilacji, gdzie są szybsze do naprawienia.

Frank Hileman
źródło
1
To może być słuszny punkt, jeśli porównamy wydajność poszczególnych programistów. Pytanie dotyczy jednak porównania między językami, więc kontekst jest zupełnie inny. Oznacza to również na przykład, że mniejszy kod nie jest lepszy ani gorszy niż większy kod; porównaj LOC kodu napisanego w Brainfuck z kodem napisanym np. w Ruby.
Arseni Mourzenko
1
@ArseniMourzenko Oprócz żartów takich jak Brainfuck, dobrze zaprojektowane języki są w rzeczywistości porównywane na podstawie ilości kodu potrzebnego do rozwiązania zadania. Zwykle takie porównanie nazywa się ekspresyjnością. To prawda, mówiłem o LOC w jednym języku, a nie w różnych językach. Wydajność jest na ogół definiowana jako czas potrzebny do wykonania zadania; to nie jest specyficzne dla programowania.
Frank Hileman,
0

Jedyną miarą, której można użyć do porównania wydajności dla programistów między językami, jest metryka, która nie porównuje kodu między językami. Niektóre języki są notorycznie gadatliwe (COBOL za starsze zwycięstwo), a inne wymagają kilku kroków, aby zrobić coś, co możesz zrobić w jednym wierszu kodu (asemblowanie vs. wszystko inne). Nawet jeśli porównasz tylko aktywne linie kodu (tj. Nie liczą deklaracji i liczą tylko kod, który wiąże się z pewną akcją), nadal możesz wypaczać swoje wyniki.

Być może będziesz w stanie argumentować za szybkościami zmian. Tzn. Dodano linie kodu, porównując nachylenie wydajności w tym samym okresie. Nie uwzględnia to jednak negatywnych zmian w wierszach kodu. Na przykład dziedziczysz projekt, który wszędzie kopiuje i wkleja kod. Wykonujesz szybkie i łatwe refaktoryzacje, aby zmniejszyć liczbę powtarzających się bloków kodu - z definicji masz ujemne nachylenie.

Z całą powagą porównanie wydajności zespołów / języków jest bez znaczenia, ponieważ istnieje tak wiele dodatkowych czynników, które wpływają na wydajność zespołu, że nie można z niego wyciągnąć znaczących wniosków.

Pracowałem nad projektem, w którym infrastruktura była bardzo delikatna, a narzędzia były przestarzałe. Projekt został zbudowany na Javie z dołączoną do niego aplikacją Single Page, ale był hostowany w kontenerze portletu bez widocznych korzyści. Czas potrzebny nawet na proste zmiany był absurdalnie długi. Jeśli oprzesz wszystkie swoje wnioski na tym konkretnym projekcie, możesz dojść do wniosku, że Java była zła lub aplikacje Single Page były złe. Żadne nie są prawdziwe. System, który brzydki projekt miał zastąpić, został zbudowany na C # i WebForms. Kiedy przedstawiliśmy uzasadnienie biznesowe rozszerzenia istniejącej aplikacji w celu zaspokojenia potrzeb klientów, nasza produktywność gwałtownie wzrosła. Czy to oznacza, że ​​ściśle powiązana aplikacja WebForms jest lepsza? Można wyciągnąć taki wniosek tylko w tym konkretnym przypadkui nie obejmuje całego świata. Ma to sens tylko dlatego, że istniała aplikacja o wystarczającej dojrzałości do rozszerzenia.

Nawet porównywanie wskaźników rozwiązywania problemów w systemie śledzenia problemów jest wadliwe w tym sensie, że porównujesz między sobą kompletną infrastrukturę projektu. Użyte biblioteki i frameworki mogą przyspieszyć lub spowolnić postęp. Możesz być w fazie rozruchu z bardzo małą bezwładnością do pokonania, gdzie projekt, w którym jesteś „lepszy niż”, znajduje się w fazie konserwacji, w której liczba nowych biletów jest stosunkowo niska. Nigdy nie chodzi o porównywanie podobnych rzeczy.

Berin Loritsch
źródło