Czy należy oczekiwać, że programiści skompilują bibliotekę wewnętrzną przed właściwym programem?

10

Ostatnio starszy programista, z którym współpracuję, uzasadnił wymóg, aby programiści otrzymali najnowszą wersję i skompilowali w ramach swojego projektu dużą bibliotekę wewnętrzną. Stoi to w sprzeczności z argumentem licznika, że ​​zespoły projektowe powinny pracować nad stabilną wersją, którą otrzymują z wewnętrznego repozytorium Maven, do którego programista argumentował, że udostępnienie kodu źródłowego na komputerach programistów pozwala zaoszczędzić czas, ponieważ mogą czytać źródła bibliotek kod określający, czy wymagana funkcjonalność jest dostępna.

Czy starszy programista ma ważny argument? Czy też wymaganie od programistów czytania kodu źródłowego bibliotek jest sprzeczne z podstawową filozofią enkapsulacji, a nawet posiadania biblioteki na pierwszym miejscu?

rjzii
źródło

Odpowiedzi:

15

Argument tego starszego programisty nie ma dla mnie sensu.

Czy chcą dodać narzut związany z ciągłym wyszukiwaniem i kompilowaniem biblioteki wewnętrznej, aby deweloperzy mogli czasami odczytywać kod źródłowy? To zmarnuje o wiele więcej czasu niż to, że deweloperzy sprawdzają kod źródłowy tylko wtedy, gdy muszą sprawdzić, czy funkcja jest dostępna.

Jest to szczególnie zły pomysł, jeśli biblioteka i klienci są rozwijani przez różne grupy programistyczne, a biblioteka jest aktywnie rozwijana. Deweloperzy klientów nie będą mieli żadnej izolacji przed niestabilnością w bibliotece.

Nie rozumiem, dlaczego kod źródłowy nie może zostać udostępniony programistom bez zmuszania ich do włączenia ich do normalnej wersji.

17 z 26
źródło
Po drugie, powinieneś być w stanie łatwo pobrać źródło używanej wersji biblioteki. Dlaczego, u licha, potrzebujesz „ostatecznej najnowszej wersji” biblioteki? Po prostu dodaje potencjalną entropię do projektu.
jlemos
1
Zgadzam się tylko częściowo. IMHO zależy od polityki rozwoju dla biblioteki lib. Jeśli lib jest w trakcie aktywnego rozwoju drugiego zespołu, masz 100% racji. Jeśli lib może zostać zmieniony przez kogokolwiek z obecnego zespołu ORAZ, jeśli zasadą jest, że lib powinien być w jakikolwiek sposób kompatybilny wstecznie, wówczas używanie zawsze najnowszej wersji pomaga wcześniej zidentyfikować problemy z integracją, co jest dobre.
Doc Brown
Doc Brown - zgadzam się. Moja odpowiedź opierała się na fakcie, że pytanie zostało sformułowane w taki sposób, że jedynym powodem żądania get & compile było umożliwienie programistom odczytania kodu źródłowego.
17 z 26
4

Sugestia brzmi:

Możemy zaoszczędzić czas przez programistów po stronie klienta czytających kod źródłowy biblioteki, aby ustalić, czy wymagana funkcjonalność jest dostępna

Możesz zrobić alternatywną sugestię

Możemy zaoszczędzić czas przez osobę dokumentującą bibliotekę, aby wskazać, jaka funkcjonalność jest dostępna.

MarkJ
źródło
Próbowano tego i argument był taki, że programiści biblioteki byli zbyt zajęci dodawaniem nowych funkcji.
rjzii
2
Myślałem, że możesz tak powiedzieć. Przypuszczalnie biblioteka istnieje po to, aby pomóc programistom po stronie klienta i czy nie jest celem samym w sobie? Niemniej jednak doceniam to, że możesz nie mieć siły politycznej (wpływ na menedżerów, klientów lub starszych programistów), aby skłonić programistów biblioteki do zwiększenia swojej wagi. Być może programista po stronie klienta mógłby udokumentować bibliotekę? Uruchom wiki i buduj dokumentację według potrzeb? Może wymagać trochę odczytu kodu źródłowego, ale nie wymaga ciągłego kompilowania najnowszej wersji.
MarkJ
3

Nie kupiłbym argumentu, że możliwość lokalnego przeglądania źródła jest zaletą, ale jeśli biblioteka jest w fazie aktywnego rozwoju (być może w celu dodania wsparcia dla potrzeb twojego projektu), to nie sądzę, aby wymaganie od programistów często pobieraj aktualizacje (prawdopodobnie kilka razy dziennie). Wydaje mi się, że lepiej jest udostępnić skompilowany (i przetestowany jednostkowo) plik binarny zamiast wymagać od programistów kompilacji ze źródła.

Czy masz możliwość skonfigurowania w swoim projekcie pewnego rodzaju wspólnego repozytorium, w którym dostępna byłaby najnowsza skompilowana wersja? Idealnie byłoby, gdybyś potrzebował serwera CI, który pobierał i budował zgodnie z harmonogramem, ale nawet jeśli jest to tylko zasób sieciowy, który jeden z kierowników zespołu jest odpowiedzialny za okresową aktualizację, może to pomóc. Oczywiście powinno to znajdować się na tabliczce zespołu bibliotecznego, ale oczywiście nie są zainteresowani, więc musisz podnieść luz.

TMN
źródło
1

Pracowałem dla dużej firmy programistycznej, która stale „karmiła” swoim własnym oprogramowaniem wewnętrznymi systemami biznesowymi.

Postrzegali to jako kolejny poziom testowania.

Z czym się zgadzam, dla firmy, to dobra rzecz.

Myślę, że zmuszanie cię do pobrania i skompilowania najnowszej wersji jest krokiem za daleko, chyba że krok kompilacji jest ważną częścią Twojej firmy oferującej sprzedaż lub nawet outsourcing biblioteki.

ozz
źródło
Jest wdrażany jako część produktów; jednak staram się rozwiązać ten problem z dwóch stron: programiści pracują na swoich komputerach i serwery ciągłej integracji.
rjzii
1

Chociaż dostępność kodu źródłowego może być korzystna, jeśli masz agenta kompilacji CI monitorującego repozytorium, rozsądniej jest, aby agent ten skompilował tę bibliotekę i skopiował ją do zależnych projektów jako zewnętrzną, niż wymagać od programistów uruchom dwa różne kroki kompilacji podczas budowania ich kopii.

Obecnie pracuję nad projektem, który nie jest podłączony do agenta kompilacji, który wymaga zbudowania podaplikacji przed zbudowaniem głównej aplikacji. To poważny ból w moim odcinku tylnym; aby dokonać zmiany w pod-aplikacji, muszę najpierw skompilować cały projekt, a następnie przejść do folderu pod-kompilacji, pobrać z niego skompilowany produkt i skopiować go do innego podfolderu przed zbudowaniem całego projektu PONOWNIE aby upewnić się, że najnowsza wersja podaplikacji jest uwzględniona w kompilacji głównej aplikacji. To NIE jest tak, jak należy to zrobić; przynajmniej powinien istnieć skrypt MSBuild, który zautomatyzuje ten proces, i wolałbym, aby agent kompilacji aktualizował zewnętrzne, ilekroć nowy kod jest przypisany do pnia.

KeithS
źródło
1

Ponieważ tak wiele osób odpowiedziało, że nie ma sensu, aby wszyscy budowali bibliotekę wewnętrzną, przedstawię przeciwny punkt widzenia, który mógłby uzasadnić powody:

  1. Często korzystasz z biblioteki i nie ma dokumentacji. Więc każdy powinien mieć źródło w celach informacyjnych. Jeśli jest to biblioteka, która jest bardzo często używana, przydatne może być posiadanie podręcznego podręcznika

    • Jasne, można powiedzieć, że powinni pracować nad dokumentacją i bardziej niż prawdopodobne, że starszy programista jest tego świadomy. Ale spójrzmy prawdzie w oczy, wiele razy zespoły programistów mają mnóstwo nieudokumentowanego kodu, więc kiedy musisz wiedzieć, jak to działa, idź do źródła. Nie powinieneś tego robić, ale w krótkim okresie jest to najlepsza alternatywa.
    • Zwykle najlepszymi ludźmi do wprowadzenia dokumentacji są ci, którzy najlepiej znają bibliotekę. Niestety są to te same osoby, które zazwyczaj są najbardziej zajęte, więc często nie jest im łatwo rzucić wszystko i rozpocząć dokumentację.
  2. Kiedy ludzie zaczynają pisać własny kod, który zależy od biblioteki i coś w bibliotece nie działa, zamiast wyrzucać ręce w powietrze, jeśli biblioteka jest budowana lokalnie, bardzo łatwo jest wejść bezpośrednio do kodu biblioteki

    • Może się to zdarzyć, ponieważ wiele bibliotek jest daleka od doskonałości i chociaż wszyscy chcemy pracować z wersją „stabilną”, nadal mogą występować problemy.
    • Być może otrzymujesz złe wyniki z powodu nieporozumienia, w jaki sposób należy używać interfejsu API. Nawet przy dokumentacji ludzie często przyjmują błędne założenia
    • Twój starszy facet jest prawdopodobnie zmęczony nowymi ludźmi (a czasem jest o wiele więcej nowych osób niż ci, którzy znają projekt od wewnątrz i na zewnątrz), rzucając rękami w powietrze, gdy katastrofa / jakiś inny błąd wydaje się pochodzić z kodu biblioteki. Zamiast więc podejść do maszyny, a następnie do faceta siedzącego obok ciebie, chcą opcji odpowiedzi na następujące pytania: 1) gdzie dokładnie jest awaria? jaki moduł / plik / linia? 2) czy debugowałeś to? co znalazłeś
    • Twoi starsi faceci pracowali z tą bazą kodu (aplikacją i główną biblioteką) wystarczająco długo i być może zauważył, że kiedy kod jest już na komputerze i jest gotowy do debugowania i przejścia, to ułatwia mu życie i przyciąga ludzi aby szybciej nauczyć się podstawy kodu. Z tego powodu zmusza cię do podjęcia wstępnych kosztów budowy biblioteki na komputerze.

Nie twierdzę, że jego decyzja jest uzasadniona, po prostu wskazuję, że a) pytanie zadało jedną stronę historii ib) mogły istnieć prawdopodobne motywy.

DXM
źródło
1

Tego rodzaju testy byłyby rzeczywiście lepsze. Rzecz w tym, że powinni to robić testerzy, a nie programiści . W tym sensie nie jest to ani praca twoich, ani twórców bibliotek.

Z tego, co opisujesz, wygląda na to, że w projekcie nie ma testerów - jeśli tak jest, to jest to problem zarządzania i dość poważny.

... oszczędza czas, ponieważ mogą odczytać kod źródłowy bibliotek w celu ustalenia, czy wymagana funkcjonalność jest dostępna

Dość kiepskie rozumowanie. Kiedy najnowsza wersja biblioteki nie może się skompilować z najnowszym projektem wersji, może to być wiele różnych przyczyn - po prostu wczytywanie kodu źródłowego lib może być stratą czasu.

  • Co zrobić, jeśli biblioteka działa poprawnie, a błąd kompilacji został spowodowany błędem w kodzie projektu? Lub co jeśli niepowodzenie kompilacji zostało spowodowane tymczasową niezgodną zmianą, która powinna zostać poprawiona dzień lub dwa później? Co jeśli niepowodzenie kompilacji wskazuje na skomplikowany problem z integracją, który zajmie tydzień lub miesiąc? Czy w przypadku problemu z integracją korzystanie z biblioteki wcześniejszej wersji może to obejść?
     
    Niezależnie od przyczyny, wstępna analiza awarii oznaczałaby marnowanie czasu programisty na pracę, która powinna zostać wykonana przez testerów.

Kolejną rzeczą nad brakami w rozumowaniu są nieuniknione (i dość bolesne z mojego doświadczenia) straty produktywności, które następują, gdy trzeba przerwać przepływ , przełączając się między działaniami rozwojowymi a kontrolą jakości.


Gdy w zespole są testerzy, takie rzeczy są naprawdę proste i można z nimi łatwiej sobie poradzić. To, co rzucił na ciebie „starszy” programista, jest w zasadzie wymogiem testowania.

Po każdej zmianie dokonanej w projekcie lub bibliotece upewnij się, że kompilacja się powiodła.

Kroki, które należy wykonać, to typowe działania związane z kontrolą jakości: wyjaśnienie szczegółów wymagań, zaprojektowanie sformalizowanego scenariusza testowego, negocjowanie sposobu postępowania w przypadku niepowodzenia testów.

  • Z punktu widzenia SQA jest to dość rutynowe zadanie polegające na zaprojektowaniu, skonfigurowaniu i utrzymaniu dość prostej procedury testowania regresji , która mogłaby być wysoce zautomatyzowana - prawdopodobnie do tego stopnia, że ​​jedynie ręczne działanie polegałoby na tworzeniu i utrzymywaniu biletów w narzędziu do śledzenia problemów i weryfikacji poprawki
komar
źródło
0

To, co sugeruje Sr Dev, nie ma dla mnie żadnego sensu. Miło jest móc przeglądać źródła, ale są na to lepsze sposoby.

Z jakiego repozytorium artefaktów korzystasz? Powinieneś być w stanie wdrożyć jar jar dla każdej wersji, aby żyć obok skompilowanej biblioteki. Większość IDE pozwoli ci wtedy dołączyć to do skompilowanej biblioteki do przeglądania źródeł. Eclipse z wtyczką Maven zrobi to automatycznie.

Jeśli potrzebujesz najnowszego kodu, możesz po prostu wdrożyć migawki wersji.

smp7d
źródło
Maven jest używane jako repozytoria, a większość projektu używa tego lub Ivy do zarządzania zależnościami.
rjzii
@ RobZ nie używasz centralnego repozytorium artefaktów, takiego jak Artifactory lub Nexus?
smp7d
Korzystamy z Archiva.
rjzii
@RobZ ok, prawdopodobnie możesz skonfigurować swoje poms, aby wdrożyć jar src i dołączyć do biblioteki w IDE, jeśli nie zrobi to automatycznie. Zobacz maven.apache.org/plugins/maven-source-plugin
smp7d
0

Powinno to po prostu nastąpić w skrypcie kompilacji:

  1. sprawdź, czy dostępna jest nowa wersja. pomiń 2 w przeciwnym razie.
  2. pobierz go i skompiluj, a następnie uruchom dowolne narzędzia do wygenerowania odwołania API na podstawie kodu źródłowego lokalnie. pokaż dziennik zmian.
  3. zbuduj swoją aplikację

Nie rozumiem, dlaczego i jak to jest problem. Również gdy czegoś brakuje w referencji, możesz dodać to do źródeł i wcisnąć zmiany. Oczywiście może wydawać się trochę przerażające, że biblioteka może zmienić się tuż pod twoimi stopami, ale jeśli opiekunowie biblioteki wykonują swoją pracę właściwie, to dobrze.

back2dos
źródło
Z punktu widzenia serwerów ciągłej integracji sama biblioteka nie jest mała i zajmuje kilka minut.
rjzii
@RobZ: Więc? Dopóki biblioteka się nie zmienia, nie musisz jej odbudowywać, prawda?
back2dos
W tej chwili jest nadal w fazie aktywnego rozwoju.
rjzii
@RobZ: Tak, to może tak, ale jeśli zespół biblioteczny taguje wersję co 10 minut, to robi to źle. Ciągła integracja jest dobrą rzeczą, ale wydanie powinno obejmować pewien test użyteczności. W przypadku biblioteki jest to przegląd kodu. Nie można tego zautomatyzować. Jednak proces uzyskiwania ostatniej sprawdzonej i oznaczonej wersji można zautomatyzować, a jeśli recenzje zostaną wykonane poprawnie, a oznaczenie zostanie wykonane odpowiedzialnie, to nie widzę problemu, ale w rzeczywistości ulepszenie.
back2dos