Jak utworzyć i obsługiwać bibliotekę wielokrotnego użytku?

Question

Próbuję skonfigurować repozytorium kodu wielokrotnego użytku. Myślałem o tym, że każdy moduł kodu wielokrotnego użytku ma pewien poziom "Poziomu dojrzałości". Ocena byłaby zdefiniowana jako poziom, na którym kod wielokrotnego użytku mieści się w określonym zestawie wymagań. Najwyższy poziom dojrzałości będzie najwyższym standardem w ramach wstępnie zdefiniowanego zestawu wymagań.

Na przykład:
Poziom; Wymagania; Opis
Poziom 0; Kod jest legalny; Czy kodeks jest legalny w branży komercyjnej/w ramach wielu umów/etc?
Poziom 1; Podstawowy kodek i spełnia wymagania poziomu 0; Kod prototypowy, narzędzia innych firm itp.
Poziom 2; Ma interfejs funkcji i komentarze oraz spełnia wymagania poziomu 1; Wystarczająca dokumentacja dla każdej klasy i funkcji; Potrafi określić funkcjonalność z komentarzy
Poziom 3; Dba o standardy kodowania i spełnia wymagania poziomu 2; Podąża za określonymi standardami kodowania i przechodzi testy kodu sprawdzające test użyteczności
Poziom 4; Obejmuje przypadki testowe i spełnia wymagania poziomu 3; Ma wystarczającą liczbę przypadków testowych do przetestowania wszystkich funkcji kodu:
Poziom 5; Zatwierdzony przez komisję ponownego wykorzystania i spełniający wymagania poziomu 4; Recenzowane przez ekspertów i współpracowników ds. Ponownego wykorzystania i potwierdzone, że spełnia wszystkie poziomy dojrzałości

Zastanawiam się, czy ten poziom dojrzałości powinien być strukturą hierarchiczną, gdzie aby przejść do następnego poziomu, należy spełnić wymagania wszystkich poprzednie poziomy (jak pokazałem powyżej)?

Lub czy powinien to być podzbiór wymagań, aby osiągnąć kolejny poziom?

Na przykład, spełniliśmy wymagania x z y, możemy przejść do następnego poziomu (wymagania byłyby takie same, jak wspomniano powyżej).

Level 0, spotyka 0 z 6 wymaganiami
Level 1, spełnia 1 z 6 wymaganiami
...

Problem widzę z podejściem podzbioru jest pewne wymagania powinny mieć silniejszą wagę, aw takie podejście, które nie będzie brane pod uwagę (chyba, że ​​zacznę się wyróżniać, spotyka się z b i x z y, itd.). Ale może zacząć się komplikować.

Czy ktoś zrobił to wcześniej, a jeśli tak, to jak skonfigurowałeś swoją bibliotekę? Czy masz poziom dojrzałości w ogóle lub w jakiejś innej strukturze? Wszelkie dane wejściowe będą bardzo mile widziane.

Answer 1

Konfigurowanie repozytorium ponownego użycia kodu jest trudnym zadaniem. Główna trudność polega nie na tym, jak ją skonfigurować, ale w , w jaki sposób komunikować istnienie różnych bibliotek w repozytorium. Ponownie korzystaj z bibliotek tylko dobrze, jeśli są one używane, i są używane tylko wtedy, gdy są znane i są szeroko stosowane tylko wtedy, gdy jakość kodu jest wysoka i spełnia wymagania użytkowników.

Podobają mi się pomysły na poziomy dojrzałości, ale jak napisali inni, prawdopodobnie jest sporo do zrobienia. Myślałem o podobnym podejściu do buildów aplikacji - nazwałem je poziomami zaufania. Na arenie budowania aplikacji budowanie o niskiej wiarygodności to taka, która nie przeszła testów jednostkowych; średnia pewność może obejmować zaliczenie testów jednostkowych, ale nie testy integracyjne i tak dalej. To był dobry mechanizm komunikacji z QA i użytkownikami, czego można się spodziewać. Podobny mechanizm może być odpowiedni dla bibliotek.

Komentarze do dokumentacji są koniecznością i muszą włożyć w nie tyle starań, ile włożysz w kod. Komentarze powinny określać, co, dlaczego, gdzie, kiedy, jak, które itp.Twój proces kompilacji powinien opublikować dokumentację w znanej lokalizacji (znowu kluczem jest komunikacja).

Wzdłuż linii komunikacji, nie zaszkodzi przedstawić od czasu do czasu, co tam jest. Jeszcze raz! komunikacja.

Więc przynajmniej twój build z każdej biblioteki powinny:

• publikować bibliotekę (może powiadomić abonentów)
• publikować dokumentację
• jednostka uruchomić testy
• opublikować poziom dojrzałości

Jeśli chodzi o poziomy dojrzałości, zdefiniowałbym je za pomocą "nazwy poziomu" i opisu poziomu znaczy. Opublikuj kryteria określające, co oznacza przejście w górę lub w dół. Właściwie, teraz, gdy o tym myślę, być może potrzebujesz zestawu kryteriów ortogonalnych: poziomu kodu, poziomu dokumentacji, zasad użytkowania (tj. Musi mieć licencję na XYZ) i innych atrybutów. Zalecam jednak podejście to w małych odstępach. Koniec końców dostarczanie funkcjonalności użytkownikom końcowym ma znaczenie.

Musisz również przekazać sposób myślenia, w jaki sposób naturalnie wciskasz bity wielokrotnego użytku do repozytorium. Deweloperzy muszą mieć motywację, aby robić to zazwyczaj. Statyczne narzędzia do sprawdzania kodu, które szukają duplikatów i recenzji innych użytkowników, posuwają się tak daleko. Ktoś musi faktycznie wykonać pracę przenoszenia kodu do repozytorium.

Na koniec zalecam, aby używać jak największej liczby narzędzi do konfiguracji, budowy, konserwacji i komunikacji z repozytorium. W przeciwnym razie, jak każdy artefakt niekodujący kodu, napotkasz pewną ilość entropii, która obniży wartość, gdy artefakt bez kodu stanie się przestarzały.

Answer 2

Myślę, że za dużo nie myślisz.

Jak skonfigurowałeś moją bibliotekę? Łatwo, jeśli używasz tej samej (lub prawie takiej samej) metody w dwóch lub więcej projektach, przenieś ją do biblioteki.

Answer 3

Dla mojej biblioteki, po prostu wstawiłem kod, który napisałem, który może być używany w wielu aplikacjach. Jeśli kod jest specyficzny dla konkretnej aplikacji, nie trafia do biblioteki. Ponieważ używa go więcej aplikacji, błędy się sprawdzają, więc nie sądzę, że od razu będą wolne od błędów. Błędy będą nieustannie wykrywane i naprawiane, gdy twoja biblioteka dojrzewa i jest podkreślana przez różne aplikacje. To nigdy nie będzie wolne od błędów, ale z czasem zbliży się do niezawodności. Również, gdy zdaję sobie sprawę, że interfejs API dla niektórych rzeczy jest nieprawidłowy, nie martwię się o to i nie ograniczam interfejsu API tak szybko, jak to możliwe.

Oto moja biblioteka w C++
http://code.google.com/p/kgui/

Answer 4

myślę, że będzie trudno, aby zapewnić, że cały zespół rozwój następuje te wytyczne wystarczająco dokładnie. Zwłaszcza, gdy wytyczne mogą być interpretowane w ten czy inny sposób. Co więcej, będzie to ogromny problem, jeśli ktoś ulepszy fragment kodu, dodając testy i nagle musi przejść do innego projektu. Bardziej prawdopodobne jest, że taki kod pozostanie w projekcie, w którym został pierwotnie umieszczony, az czasem poziomy dojrzałości staną się bez znaczenia.

Jedno podejście widziałem działa dobrze w dużej firmie to:

• Wszystkie biblioteki stron trzecich są zobowiązani do specjalnego katalogu i zawsze zawierać numer wersji.
• Nasze własne wspólne biblioteki są podzielone w oparciu o referencje mają do innych rzeczy. Na przykład. jeśli kod narzędzia odwołuje się do biblioteki Infragistics, ten fragment kodu narzędziowego przechodzi do biblioteki InfragisticsUtils.
• Nasze własne wspólne biblioteki, które tworzą wyraźnie identyfikowalne "jednostki", przechodzą do oddzielnych bibliotek. Na przykład biblioteka kodu, która zajmuje się wyceną papierów wartościowych, jest osobnym projektem.
• Cały kod wielokrotnego użytku, który nie spełnia któregokolwiek z powyższych warunków, trafia do projektu typu catch-all Utilities.
• Nasze własne biblioteki są kompilowane i udostępniane we wspólnej lokalizacji, w której projekty mogą się do nich odwoływać. Zadaniem zespołu projektującego projekty jest decyzja, czy chcą odwołać się do skompilowanego pliku binarnego, czy tylko uwzględnić projekt narzędzia w swoim rozwiązaniu.

Oczywiście jakość kodu, który można znaleźć w bibliotece złapanych wszystkich Utilities może się znacznie różnić. Aby to złagodzić, po prostu upewniliśmy się, że dwie osoby z różnych zespołów programistycznych przeanalizowały wszystkie checkiny na Utilities. To eliminuje wiele rzeczy, które nie mają tam miejsca!

Answer 5

Uważa się, że dobrym pomysłem jest posiadanie własnej biblioteki, ale tysiące linii to jedna ruina!

Answer 6

Spójrz na "Spowiedzi sprzedawcy używanego programu Will'a Tracza", a także na temat ponownego wykorzystania przez HP Rabina, Martina Grissa.

Answer 7

Microsoft od lat był wielkim zwolennikiem tego, co znane jest jako software factories, którego znaczna część poświęcona jest rozwiązywaniu problemów związanych z ponownym wykorzystaniem.

Jakie są problemy z ponownym użyciem? Przede wszystkim jest to trudne. Trudno wymyślić bibliotekę i API, które będą służyć poza bezpośrednimi potrzebami projektu. Jak przewidujesz przyszłość? Również problem scentralizowanego repozytorium, który służy zarówno jako baza wiedzy, jak i dynamiczna wspólnota praktyki, jest bardzo trudnym zadaniem. Jak stworzyć coś, co jest jednocześnie bardzo elastyczne, a jednocześnie łatwe w użyciu? Wielu próbowało i nie udało się. Zarówno software factories, jak i software product lines próbują rozwiązać te problemy.

Powodzenia!

Answer 8

Myślę, że świetne repozytorium kodu zawiera narzędzie CM i narzędzie Wiki. Narzędzie CM powinno być ustrukturyzowane za pomocą idei poziomu (zgodnie z propozycją), ponieważ strukturyfikuje kod według jakości. Wiki powinno działać jako "reklama" tego, co oprogramowanie może zrobić i jak może ci pomóc. Ta wiki może również przechowywać informacje takie jak, które projekty używają kodu, ocena tego, jak to jest możliwe do wykorzystania i przykłady, jak z niego korzystać. Jeśli ktokolwiek martwi się o zespół programistów, który postępuje zgodnie ze wskazówkami poziomu, należy wskazać, w jaki sposób działa samoobsługa i podać przykład, jak dobrze działa z wiki.

Teraz istotne jest ustrukturyzowanie narzędzia CM. Został zaprojektowany w celu przekazywania jakości kodu, dzięki czemu wiesz, co dostajesz, gdy go używasz. Na przykład, jeśli napiszesz prostą klasę z prawie żadnymi komentarzami i nie zachowa ona standardów kodowania (być może prototypu), wówczas zostanie wprowadzona do \ sw_repository \ level0 \ ExamplePrototype.

Może ktoś wtedy wziął ten fragment kodu i dodał komentarze i podniósł go do standardów. Wtedy ta osoba umieści go w \ sw_repository \ level1 \ ExamplePrototype.

Następnie ta sama osoba, chwilę później, tworzy testy jednostkowe dla ExamplePrototype. To by następnie przejść do poziomu 2 i tak dalej.

Określenie poziomów powinno zająć trochę czasu. Naprawdę powinny być nieco sekwencyjne i nawet gdyby na przykład napisano testy jednostkowe dla kodu prototypowego, ale nie spełniały one wymagań i standardu kodowania, to i tak jest on umieszczany w poziomie0. Łatwo byłoby jednak przejść na poziom 2, gdyby te uwagi i standardy zostały spełnione.

Answer 9

Zestaw wymieniony najważniejszy problem: ponowne użycie. Reszta pomysłu jest przyjemna, ale nie jest to tylko detal.

to znaczy, sam mam problem z utrzymaniem mojej własnej biblioteki wielokrotnego użytku. czasami robię implementację, która jest bardzo specyficzna dla projektu, lub robię n-ty prototyp dla jakiegoś pomysłu i żaden z tych nigdy nie wchodzi do mojej biblioteki.

jeśli naprawdę uda ci się mieć bibliotekę wielokrotnego użytku, która jest używana i utrzymywana przez wielu programistów w zdyscyplinowany sposób, niż zwycięstwo. potrzebujesz systemu kontroli wersji i modułu do śledzenia błędów, który jest używany zarówno przez właścicieli projektu, jak i użytkowników. potrzebujesz komunikacji i środków do wniesienia. posiadanie garstki programistów wykorzystujących projekt znacznie poprawia jego jakość. wdrożenie staje się lepsze. dokumentacja jest tworzona. API i projektowanie funkcji są na znacznie wyższym poziomie. komisja to dobra rzecz, ale nie może zdecydować, jak dobry jest dany kod, bez faktycznego korzystania z niego. może zdecydować, czy kod spełnia określone standardy, ale spełnienie standardów nie jest wystarczające dla dobrych bibliotek.

musisz zrobić co w twojej mocy, aby się upewnić, że nie masz wielu unoszących się fragmentów kodu, z których każdy może mniej więcej coś zrobić. OK, każda decyzja projektowa ma swoje wady i zalety, ale wydaje mi się, że lepiej zacząć od JEDNEGO projektu dla danego zadania i rozgałęzić go, jeśli jest to naprawdę konieczne, ale utrzymywać żywą komunikację między zespołami projektowymi i rozważyć (częściowe) scalenie plecy.

nie przejmuj się zbytnio kategoryzowaniem jakości różnych projektów. jeśli projekt jest zły, użytkownicy/deweloperzy popchną go na wyższy poziom. większość ludzi jest na tyle sprytna, by zobaczyć, kiedy biblioteka jest dobra, a kiedy nie. naprawdę musisz umieścić swoją energię w tych symbiotycznych efektach, zamiast próbować obciążać uczestników ścisłymi zasadami.

tylko moje 2 centy ...;)