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”?

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.

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 .

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.

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!

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ń.