Dlaczego zespół programistów miałby nalegać, aby stosowanie jednego rozwiązania dla wielu projektów w Visual Studio „zwiększało złożoność współzależności”?

26

Pomagam zarządzać zewnętrznym zespołem, który zaczyna opracowywać nowe wersje niektórych istniejących produktów. Historycznie, ten zespół zawsze używał modelu jednego projektu w jednym rozwiązaniu dla około 30 modułów w Visual Studio, które razem tworzą jedną możliwą do wdrożenia wersję.

Ma to szkodliwy wpływ na niezawodność i jakość kompilacji, ponieważ nie zawsze przesyłają nam najbardziej aktualny kod źródłowy. Staramy się je naciskać, aby ujednolicić wszystkie odwołania do kodu w jednym rozwiązaniu, ale otrzymujemy pewien opór - w szczególności rozmawiają o zwiększeniu zależności między modułami (czytaj „projekty” w Visual Studio), jeśli wszystko jest umieszczone w pojedynczy plik rozwiązania. Żaden kod w oddzielnych rozwiązaniach nie jest używany gdzie indziej.

Podkreślam, że to nonsens, a dobre wzorce rozwoju pozwolą uniknąć takiego problemu.

Zespół, o którym mowa, wykonuje również poprawki błędów i opracowuje nowe funkcje w istniejącym produkcie, którego doświadczenie było co najmniej uciążliwe i cierpi na dokładnie ten sam problem podziału na wiele rozwiązań. Odmówiono nam dostępu do ich kontroli źródła ( TFS ), a podejściem, które zastosowaliśmy w celu ujednolicenia bazy kodów, jest próba co najmniej zmniejszenia liczby brakujących aktualizacji i więcej niż sporadycznych regresji (tak, naprawione błędy pojawiają się ponownie - wprowadzono do produktu), mówiąc: „wyślij nam ZIP całego folderu rozwiązania, abyśmy mogli go rozpakować, otworzyć w Visual Studio i nacisnąćF5 do testowania ". Pod względem ogólnej struktury i jakości kod jest dość ubogi i trudny do obsługi. To doświadczenie sprawia, że ​​zamierzam zapewnić prawidłowe działanie procesów na jak najwcześniejszym etapie cyklu programowania.

Czy czegoś brakuje? Czy jest jakiś dobry powód, aby oddzielić cały ten kod? Dla moich pieniędzy musiałby to być tak przekonujący powód, że byłaby to powszechna wiedza, ale jestem bardziej niż skłonny przyznać, że nie wiem wszystkiego.

DrMistry
źródło
5
Jeśli zespół jest zewnętrzny, trudno będzie cokolwiek zmienić. Zamiast skupiać się na problemie, próbujesz wcielić swój pomysł w życie. Problem polega na tym, że „nie zawsze wysyłają nam aktualny kod”, czy rozwiązali ten problem w preferowany przez siebie sposób. Czy nie mogą dać ci dostępu do systemu kontroli wersji?
RMalke,
9
Brzmi jak nonsens. Projekty nie będą już ani zależne od siebie ani w jednym, ani w trzydziestu rozwiązaniach. Powodem przechowywania kodu w oddzielnych rozwiązaniach jest to, że wynikowa biblioteka jest używana przez wiele oddzielnych kompilacji do wdrożenia. To nie brzmi jak przypadek dla ciebie.
David Arno,
3
Wygląda na to, że masz wiele nietechnicznych problemów, które najlepiej rozwiązać, wprowadzając zmiany w umowie i oświadczeniach o pracy.
Ross Patterson,
9
Utworzenie jednego rozwiązania niekoniecznie oznacza, że ​​muszą porzucić poszczególne rozwiązania, ponieważ projekt może istnieć w więcej niż jednym rozwiązaniu.
Erik Eidt,
6
Nie jestem pewien, dlaczego zastanawiasz się nad rozwiązaniami technicznymi czegoś, co zasadniczo stanowi problem ludzi. Zwolnij tych ludzi i zatrudnij ludzi, którzy są powyżej przeciętnego poziomu kompetencji. Oznacza to, że zapłacisz więcej, ale zdecydowanie warto w IT pod względem obniżonego całkowitego kosztu posiadania. Im dłużej się trzymasz, tym więcej będziesz cierpieć.
Brad Thomas

Odpowiedzi:

54

Nie musisz mówić im, jak ustrukturyzować swoje projekty. Zamiast tego uczyń twardym wymogiem, że możesz zbudować system ze źródła, uruchamiając jeden skrypt, bez żadnych błędów. Jeśli w tych skryptach działa program Visual Studio, Msbuild lub inne narzędzia, a jeśli zostaną one wywołane raz, 50 lub 100 razy nie powinno mieć znaczenia.

W ten sposób otrzymujesz taki sam „test kompletności” kodu, jak w przypadku umieszczenia wszystkiego w jednym rozwiązaniu. Oczywiście, ten skrypt nie mówi ci, czy zespół naprawdę sprawdził najnowszą wersję ze swojej kontroli źródła, ale posiadanie całego kodu w jednym rozwiązaniu również by tego nie sprawdził.

W odpowiedzi na „zwiększenie współzależności między modułami, jeśli wszystko jest umieszczone w jednym pliku rozwiązania” - jest to możliwy do udowodnienia nonsens, ponieważ dodanie projektów do rozwiązania nie zmienia żadnej zależności między projektami, zależności są wynikiem jednego projektu plik odwołujący się do innego, który jest całkowicie niezależny od tego, które rozwiązanie odwołuje się do pliku projektu. Nikt nie zatrzymuje tego zespołu od posiadania jednego - jednego rozwiązania, które odnosi się do wszystkich projektów, a także indywidualnych rozwiązań, z których każde odnosi się tylko do jednego projektu.

Niemniej jednak sugerowałbym dodanie skryptu kompilacji. Ma to zalety, nawet jeśli istnieje tylko jeden plik rozwiązania. Na przykład pozwala na uruchomienie kompilacji VS z preferowaną konfiguracją, pozwala skopiować pliki końcowe do wdrożenia (i nic więcej) do folderu „wdrożyć”, a także może uruchomić inne narzędzia i kroki, aby kompilacja została ukończona. Zobacz także F5 nie jest procesem kompilacji! oraz Test Joela .

Doktor Brown
źródło
Tak Zgadzam się, że F5 nie jest procesem kompilacji, ale chcemy przetestować jego kod w zespole deweloperskim przed przekazaniem go do naszego procesu kontroli jakości w celu przeprowadzenia kompleksowych testów z powodu regresji i błędów aktualizacji. Jak powiedziałem, nie mamy dostępu do ich TFS, więc musimy zaimportować ich zmiany do naszej własnej bazy kodów, a następnie sprawdzić je w TFS. W tej chwili proces ten jest tak słaby, że uruchomienie autobuilda przy zameldowaniu to całkowita strata czasu! Mamy resztę z reszty naszej oferty produktów i to naprawdę działa bardzo dobrze dla nas.
DrMistry
Chciałem tylko dodać, że „Test Joela” jest doskonały i polecam dobrze się przyjrzeć. Dziękuję bardzo!
DrMistry,
3

Zależy to od tego, ile skompilowanych zestawów zostanie ponownie wykorzystanych. Jeśli nie ma możliwości ponownego użycia zestawów, nie ma prawdziwego powodu, aby oddzielać „moduły”. W rzeczywistości z mojego doświadczenia jest to bardziej przeszkodą.

W zespole programistycznym należę do niezależnych bibliotek, które napisaliśmy, które są używane w wielu produktach jako osobne rozwiązanie, co w tym przypadku ma sens, inaczej musielibyśmy skompilować aplikację A, aby aktualizować aplikację B, które mogą być wymagane do aktualizacji Aplikacji C.

Każdy produkt jest przechowywany we własnym rozwiązaniu, nawet jeśli produkt składa się z wielu projektów. W ten sposób musimy tylko zbudować rozwiązanie biblioteczne, aby utrzymać współdzielony kod na bieżąco we wszystkich opracowanych produktach.

KeithN
źródło
Żaden z rozdzielonych projektów nie jest używany nigdzie indziej, to jest frustrujące. Wszystkie są używane w jednym produkcie i nigdzie indziej!
DrMistry,
1

Każda firma programowa, w której kiedykolwiek pracowałem, miała podstawowy zespół programistów, który zapewniał główny oddział zajmujący się podstawowymi przypadkami użycia produktów firmy.

Deweloperzy oddziałów korzystający z głównego repozytorium są odpowiedzialni za wykrywanie ulepszeń i przesyłanie żądań ściągania do oddziału głównego w celu przejrzenia. Zwykle staje się to głównym programistą, pokazując, że można wnieść lepszy wkład niż tylko rozpalanie płomieni konfliktu architektonicznego.

Jest prawdopodobne, że Twoja firma po prostu nie ma zasobów, aby natychmiast „ujednolicić wszystkie kody odniesienia w jednym rozwiązaniu”. Sugerowanie, aby zrobili to bez zrozumienia swoich ograniczeń budżetowych, może (przynajmniej) uniemożliwić zostanie inżynierem głównym.

Sformułuj więc swoją wielką wizję na kilka niszczących próśb o pociągnięcie do rdzenia i przygotuj się do obrony w recenzji!

Dominic Cerisano
źródło
0

Jądro prawdy znajduje się w stwierdzeniu „Korzystanie z jednego rozwiązania dla wielu projektów zwiększa złożoność współzależności”.

Jedno rozwiązanie ułatwia odniesienie do projektu z innego projektu (tj. Ponowne użycie kodu projektu, zwanego również „wprowadzaniem złożoności współzależności”):

  • zamiast przeglądać całą pamięć podręczną systemu plików / globalnego zestawu montażowego w poszukiwaniu zestawu, do którego istnieje odniesienie, możesz wybrać projekt z ograniczonego zestawu odpowiednich projektów w rozwiązaniu; i,
  • podczas czytania kodu źródłowego znacznie łatwiej jest przeskoczyć do projektu, do którego istnieje odniesienie w rozwiązaniu, niż do dowolnego zestawu (binarnego).

Tak więc w rękach niezdyscyplinowanego zespołu korzystającego z wielu projektów w jednym rozwiązaniu może prowadzić do wielu niedbale wprowadzonych zależności. Zespół może jednak lepiej nauczyć się niezbędnej dyscypliny, aby ostrożnie zarządzać zależnościami, a następnie skorzystać z łatwości ponownego użycia oferowanej za pomocą rozwiązań.

Kasper van den Berg
źródło