Co sprawia, że ​​projekt jest duży? [Zamknięte]

32

Z ciekawości, jaka jest różnica między małym, średnim i dużym projektem? Czy mierzy się to liniami kodu lub złożonością?

Buduję system barterowy i do tej pory mam około 1000 linii kodu do logowania / rejestracji. Mimo że jest dużo LOC, nie uważałbym go za duży projekt, ponieważ nie jest tak skomplikowany, choć jest to mój pierwszy projekt, więc nie jestem pewien. Jak to jest mierzone?

Jonathan
źródło
2
Tak ............ Większa złożoność oznacza więcej linii kodu.
Robert Harvey
3
Pierwszy KLOC jest najtrudniejszy ...
Następnie musisz zapytać: „Co sprawia, że ​​projekt jest złożony? Linie kodu? Warstwy abstrakcji?”
Steven Evers,
Wspominasz 1000 wierszy kodu jako „dużo”. To naprawdę nic nie znaczy bez kontekstu. Pracowałem nad kilkoma projektami, które zawierały ponad milion linii kodu. Pracowałem również nad tak zwanymi „małymi” projektami, które mają tylko około 50 000 wierszy, ale ze względu na złożoność nie będą uważane za „małe” ze względu na ilość zasobów wymaganych do zaprojektowania, kodowania, i przetestuj. Ale z własnego doświadczenia nie mogę wymyślić żadnego przypadku, w którym uważałbym, że 1000 linii to dużo. Wspominam tylko o tym, aby zapewnić pewną perspektywę dla twojego pierwszego projektu. Powodzenia!
TMarshall
Powiedziałbym, że „bezczelność” projektu zależy od więcej niż 1 czynnika ...
kiwixz

Odpowiedzi:

20

Złożoność.

Im większa złożoność, tym trudniej jest nauczyć się wszystkiego w projekcie.


źródło
5
To jest podobne do imo tautologii. Złożony system jest synonimem dużego systemu; chyba że mówimy o złożoności kodu, a wtedy może być tak, że wszystko jest dobrze oddzielone i ma jedną odpowiedzialność, w takim przypadku złożoność kodu może być w rzeczywistości mniejsza dla dużych projektów. Dlatego powiedzenie, że złożoność oznacza, że ​​projekt jest duży, naprawdę nic nie mówi.
Henrik
... lub oczywiście każda inna miara złożoności.
Henrik
@Henrik, „złożony system” nie jest równoważny z „dużym systemem”.
1
Nie, to synonim.
Henrik
@Henrik, nie zgadzam się. System może być duży, ale regularny - tzn. Wiele rzeczy rozwiązuje się prawie w ten sam sposób, dzięki czemu można przewidzieć, jak to się robi na podstawie doświadczenia z resztą systemu - a system może być mały, ale wciąż bardzo złożony.
34

Z grubsza, jak bym zgodził się - pamiętaj, że jest to mniej więcej arbitralne. „Rozmiar” projektu składa się z innych czynników, takich jak złożoność, wiersze kodu źródłowego, liczba funkcji / wartość biznesowa itp. Bardzo mały produkt może zapewnić dużą wartość itp. Mówiąc to:

  • 2m + sloc to duży do dużego projekt. Są one na ogół tak skomplikowane, że niewielu, jeśli w ogóle, ludzie są „biegli” w całym systemie; raczej odpowiedzialność jest zmodularyzowana wzdłuż struktury kodu. Projekty te często zapewniają ogromną wartość biznesową i mogą mieć kluczowe znaczenie dla misji. Czasem są też pod dużym obciążeniem technicznym i mają inne obawy.

  • Sloc 100k - 2m to projekt średniej wielkości. To jest moja podstawa: projekt jest na tyle skomplikowany, że wymaga pewnej wiedzy eksperckiej i prawdopodobnie narodził się do pewnego stopnia techniczny dług; prawdopodobnie zapewnia również pewną wartość biznesową.

  • 10–100 tys. To niewielki projekt, ale niezbyt mały, aby mieć wystarczającą złożoność, którą będziesz potrzebować od eksperta; jeśli jesteś open source, zastanów się, czy nie zaufać zaufanym osobom w celu sprawdzenia swoich zobowiązań.

  • Wszystko mniej niż 10 tys. Sloców jest naprawdę małe. To nie znaczy, że w ogóle nie może dostarczyć żadnej wartości, a wiele bardzo interesujących projektów ma bardzo mały ślad (np. Camping, którego źródłem jest ~ 2 kb (!)). Osoby niebędące ekspertami mogą generalnie wzbudzać obawy dotyczące wartości - naprawiać błędy i dodawać funkcje - bez konieczności posiadania zbyt dużej wiedzy na temat domeny.

Joseph Weissman
źródło
4
Głosowałbym za tym dwa razy, gdybym mógł. Liczby są oczywiście dowolne, ale myślę, że opisy tego, co oznaczają różne stopnie „bezczelności”, są trafne.
Eric Anderson
1
@EricAnderson Zdecydowanie łatwiej jest myśleć o tym w kategoriach opisów niż o miarach sloc. Program Erlang o wielkości 100 tys. Sloców jest z łatwością o rząd wielkości „większy” niż program C ++ o wielkości 100 tys. Sloców, oparty po prostu na tym, co robi, niezależnie od tego, jak łatwo można odczytać kod na wyższym poziomie. W pewnym momencie czytanie kodu nie jest tak trudne, jak zapamiętanie, co dzieje się w systemie na wysokim poziomie, ponieważ jest tak wiele funkcji i centrów logicznych.
zxq9,
@ zxq9 Nie zgadzam się. To prawda, że ​​oznacza to, że wybór języka może zmniejszyć duży projekt. To, co przyzwyczaiło się do dużych komputerów, jest teraz zbyt wolne, a to, co przyzwyczaiło się do dużych projektów oprogramowania, może być obecnie banalne. Niezmienny jest koszt / złożoność projektu. Chociaż SLOC nie jest idealnym pomiarem, nadal jest ściśle związany z kosztami i złożonością projektu oprogramowania. Podobnie jak duże maszyny niekoniecznie są lepsze, tak samo duże projekty oprogramowania nie są. Jeśli to możliwe, podziel projekt na niezależne komponenty i wybierz odpowiednie technologie, aby uczynić je jeszcze mniejszymi.
Yongwei Wu
14

Wielkość projektu mierzy się stopniem niemożności utrzymania.

mojuba
źródło
2
To pesymistyczne: D
Henrik
.... a ten pomiar jest?
Casey Patton,
1
@Casey Patton pomiar jest dosłownie kosztem utrzymania.
mojuba
12

Złożoność, którą można oszacować na kilka sposobów:

  1. Budżet. Projekt z budżetem w wysokości 10 000 000 USD prawdopodobnie różni się znacznie od projektu na przykład poniżej 10 000 USD. Może to obejmować robociznę, oprogramowanie, sprzęt i inne koszty poniesione przy realizacji projektu.
  2. Godziny pracy osoby na ukończenie projektu. Czy zajmie to milion godzin czy coś jeszcze? Można to również postrzegać jako czynnik osi czasu, w którym niektóre projekty mogą potrwać lata, które, jak powiedziałbym, były duże w porównaniu do innych, które mogą potrwać krócej niż tydzień. Zauważ, że godziny pracy osoby mogą być mylące, jak ktoś może pomyśleć, podwajając personel, dzięki czemu nad projektem pracuje dwa razy więcej, a następnie harmonogram można skrócić o połowę, co rzadko by mi się wydawało.
  3. Ilość sprzętu, innych systemów i osób korzystających z tego, co buduje projekt. Jeśli coś wiąże się ze 101 systemami, może być bardziej skomplikowane, że jeśli jest samodzielne i nie wiąże się z niczym innym.

Chociaż wymagania mogą brzmieć jak dobry sposób na zmierzenie tego, często jest więcej wymagań, które zostaną znalezione, gdy projekt zostanie zrealizowany przy założeniu, że metodologia inna niż Waterfall.

JB King
źródło
11

Rozmiar projektu prawdopodobnie najlepiej mierzy się liczbą wymagań systemu, w przypadku których wymagań nie można dalej zmniejszać.

Oczywiście, więcej wymagań w większości oznacza większą złożoność, ale nie zawsze tak jest.

David_001
źródło
1
Może to nie być dobrym miernikiem: wymagania dotyczące kompilatorów i jąder systemu operacyjnego mogą być nieproporcjonalnie duże w porównaniu do innych rodzajów produktów.
mojuba,
2
@mojuba: „Duży” jest dość szerokim pojęciem, wyobrażam sobie, że napisanie kompilatora lub systemu operacyjnego byłoby „dużym” projektem
David_001,
@ David_001: weźmy kompilator Turbo Pascal, np. Którego rozmiar binarny w jednym punkcie wynosił 70 kilobajtów, a mimo to TP był pełnoprawnym obiektowym językiem programowania. Nigdy nie widzieliśmy źródeł, ale plik wykonywalny o wielkości 70 KB nie może być dużym projektem.
mojuba,
@ David_001: nie dlatego, że całkowicie się z tobą nie zgadzam. Każda definicja „dużego” projektu będzie tak niejasna, jak samo słowo „duży”.
mojuba,
@mojuba: Kiedy korzystałem z Turbo Pascal, wcale nie był obiektowy.
David Thornley,
4

Zmierzyłbym rozmiar projektu na podstawie tego, jak trudno jest postrzegać cały projekt jako pojedynczy duży obraz. Na przykład mam bazę kodu do eksploracji / prototypowania dotyczącą problemu uczenia maszynowego, nad którym pracuję. To tylko 5 000 wierszy kodu, ale wydaje się, że to ogromny projekt. Istnieje mnóstwo opcji konfiguracji, które działają w nieprzewidywalny sposób. Gdzieś w bazie kodu można znaleźć prawie każdy wzorzec projektowy znany człowiekowi, aby zarządzać całą tą złożonością. Projekt jest często nieoptymalny, ponieważ ewolucja bardzo wzrosła i nie jest refaktoryzowana tak często, jak powinna. Jestem jedynym, który działa na tej bazie kodu, ale często jestem zaskoczony tym, jak rzeczy się oddziałują.

Z drugiej strony, jeden z moich projektów hobby ma około 3-4 razy więcej kodu, a jednak wydaje się o wiele mniejszy, ponieważ jest to w zasadzie biblioteka funkcji matematycznych, które są do siebie w większości ortogonalne. Rzeczy nie wchodzą w interakcje w skomplikowany sposób i całkiem łatwo jest zrozumieć każdą funkcję osobno. Łatwo jest zobaczyć duży obraz w takim stopniu, w jakim jest jeden, ponieważ nie ma zbyt wiele jednego do zobaczenia.

dsimcha
źródło
3

Arbitralna odpowiedź: jak duży jest projekt, jak bardzo chciałbyś, abyś zrobił go od samego początku z pozyskiwaniem zdarzeń i SOA. Albo że autorzy systemu przeczytali książkę Evana „DDD: Tackling Complexity in the Heart of Software”;)

Henrik
źródło
2

Współdziałanie i zakres

Uważam, że złożoność i zakres decydują o tym, jak duży jest projekt. Istnieje jednak kilka wartości niematerialnych, które mogą również wpływać na wielkość projektu.

Wymagania

Największym problemem, z jakim się spotkałem, był brak wymagań. W mojej szczególnej sytuacji kierownik sprzedaży ustalał wymagania. Skupił się na sprzedaży ... muszę dostać sprzedaż. Jego zdaniem to, o co prosił klient, nie wydawało się aż tak skomplikowane, ponieważ zbudowaliśmy coś podobnego. Niejasne wymagania prowadzą do niedocenianych miejsc pracy i przekraczają oczekiwania.

Brak CCMU

CCMU nazywam „ Coo Ca Moo ” (Clear Complete Mutual Understanding). Musisz mieć CCMU ze swoim klientem.

Jeśli masz mały projekt ze słabym CCMU, możesz zakończyć projekt 2,3,4 lub więcej razy. Zatem prosta 20-godzinna praca zamienia się w 60-godzinny projekt ze zestresowanym personelem i bardzo niezadowolonym klientem.

Zakres pełzania

Zdarza się to częściej niż myślisz. Klient decyduje, że skoro już robisz A, B i C, dodanie D lub nawet F. nie powinno być trudne. Jeśli to zachowanie nie zostanie sprawdzone, może również przekształcić mały projekt w projekt średniej wielkości. W zależności od sposobu, w jaki kierownik sprzedaży sprzedał zlecenie, te oczekiwania dotyczące zakresu mogą wydawać się „BEZPŁATNE” dla klienta.

Michael Riley - AKA Gunny
źródło
1

Dziwne, czytając wiele z tych odpowiedzi, widzę, że wielkość projektu widzę zupełnie inaczej. Być może to moja praca w dużej korporacji, ale tendencję do postrzegania wielkości projektu jako raczej skali jego widoczności / pożądania dla klientów (w zależności od obszaru pracy mogą to być współpracownicy lub faktycznie płacący klienci).

Kavet Kerek
źródło
1

Złożoność jest właściwą odpowiedzią, ale jak ją oszacować?

Czynniki to:

  1. Punkty rozszerzenia liczą się
  2. Liczba warstw modułów (funkcje, klasy, systemy klas, biblioteki, biblioteki współdzielone, aplikacje, aplikacje sieciowe itp.)
  3. Liczba zależności (w tym platformy)
  4. Funkcje liczenia współzależności.
  5. Niezbędne zasoby inne niż kod (w tym grafika / grafika, skrypty sterujące - takie jak skrypty projektowania poziomów - i inne zasoby wymagane do ukończenia wersji aplikacji).

Im więcej ich masz, tym bardziej złożony jest projekt.

Klaim
źródło
0

LOC jest notorycznie niedokładny w przypadku wielu pomiarów, ale myślę, że próbujesz zmierzyć coś, czego tak naprawdę nie ma dokładnego sposobu pomiaru. Być może alternatywą może być cykliczność .

Ostatecznie jednak uważam, że „bezczelność” projektu jest trudna do oszacowania. To prawie jak pytanie, jak ustalić, czy pies jest duży, czy nie. Nie tylko istnieje wiele sposobów jej pomiaru (masa, objętość itp.), Ale osobiście nie uważam tego za bardzo przydatne. Rzeczywistość jest taka, że ​​moje kryteria będą prawdopodobnie takie jak: „Jak prawdopodobne jest, że ucieknę od tego psa, jeśli zobaczę go w ciemnej uliczce?”

Dla przypomnienia, generalnie nie uważam, że 1k linii kodu to za dużo. Byłby to spory fragment kodu, ale w wielkim schemacie rzeczy nie byłoby tak wiele. Oczywiście przypuszczam, że to zależy od języka. Na przykład 1k wierszy kodu to znacznie mniej kodu w języku takim jak C niż w języku takim jak Pyhon.

Jason Baker
źródło