Optymalizacja obszaru roboczego

Czy zespół ma dużą i złożoną bazę kodu?Czy chcesz, aby twój obszar roboczy zawierał tylko pliki, które są potrzebne do zwiększenia wydajności, ograniczenia ruchu w sieci i zmniejszenia miejsca na dysku wymaganego na komputerze deweloperskim?

• Zoptymalizuj nazwy folderów

• Zoptymalizuj obszar roboczy za pomocą jawnych, niejawnych, zamaskowanych i niecyklicznych mapowań folderów

• Używaj obszarów roboczych do izolowania pracy i zarządzania nią w różnych gałęziach

Zoptymalizuj nazwy folderów

Jeśli jeszcze nie używasz gałęzi, umieść cały kod na serwerze w podfolderze o nazwie Main (na przykład: $/TFVCTeamProject/Main/).Jeśli używasz gałęzi, wszystko będzie gotowe, gdy zespół powiększy się na tyle, aby wymagać gałęzi do zarządzania bazą kodu.Na komputerze deweloperskim należy użyć krótkiej i zrozumiałej ścieżki folderu, która pasuje do struktury projektu, takiej jak C:\Users\YourName\Source\Workspaces\TFVCTeamProject\Main\SolutionName\.

Kilka dodatkowych porad na temat efektywnych nazw folderów:

• Wszystkie nazwy folderów, podfolderów i plików powinny być krótkie. To upraszcza pracę i pozwala unikać potencjalnych problemów długiej ścieżki, które występują w niektórych typach projektów kodu.

• W nazwach nie używaj spacji, jeśli chcesz, aby realizacja operacji wiersza polecenia była nieco łatwiejsza.

Zoptymalizuj obszar roboczy za pomocą jawnych, niejawnych, zamaskowanych i niecyklicznych mapowań folderów

Jeśli baza kodu jest duża, możesz uniknąć marnowania czasu, przepustowości sieci oraz miejsca na dysku lokalnym, optymalizując mapowania folderów obszaru roboczego.

Podczas mapowania folderu upewnij się, że wybrany folder jest wystarczająco wysoko w drzewie kodu, aby można było uzyskać wszystkie pliki potrzebne do utworzenia lokalnej kompilacji, ale na tyle nisko, aby nie było to więcej plików niż potrzeba.Możesz także używać pewnych narzędzi w celu prostszego i szybszego utworzenia praktycznego obszaru roboczego: jawnego, niejawnego, zamaskowanego i niecyklicznego mapowania folderów.

Jeśli spojrzeć na obszar roboczy fikcyjnego dewelopera, Raisy, można by się zastanawiać: dlaczego po prostu nie zmapowała $/SiteApp/ do c:\code\SiteApp\ i na tym nie poprzestała?Taki prosty obszar roboczy będzie niejawnie mapował wszystkie foldery potrzebne w $/SiteApp/Main/.

Główny problem tego podejścia polega na tym, że dostarczyłoby to jej wiele niepotrzebnych plików, a tym samym traciłaby czas i zasoby.Tak więc Raisa tworzy niektóre dostosowane mapowania folderów.

	Raisa nie pracuje nad procesami niestandardowej kompilacji, więc nie potrzebuje $/SiteApp/BuildProcessTemplates.Wie, że z czasem baza kodów się rozrośnie. Nie chce również automatycznie pobierać każdego nowego fragmentu kodu dodanego do $/SiteApp/Main/.Ponieważ zespoły pracujące w innych folderach zmieniają te pliki, podczas gdy Raisa pobiera najnowsze pliki z serwera, mogłaby ona tracić dużo czasu, czekając na aktualizację plików, których nie potrzebuje. Aby pracować nad kodem, Raisa potrzebuje wszystkich projektów kodu, które składają się na rozwiązanie FabrikamFiber.Zamiast jawnie dołączać każdy projekt kodu (na przykład $/SiteApp/Main/FabrikamFiber/FabrikamFiber.DAL), Raisa mapuje $/SiteApp/Main/FabrikamFiber/, a tym samym niejawnie mapuje wszystkie podfoldery zawierające projekty kodu, których potrzebuje.
	Raisa nie potrzebuje plików w $/SiteApp/Main/FabrikamFiber/3DModels ani $/SiteApp/Main/FabrikamFiber/Docs, a ponieważ są one niejawnie mapowane przez, korzysta ona z dwóch zamaskowanych mapowań, aby wykluczyć te foldery z jej obszaru roboczego.
	Raisa i inne osoby w jej zespole utrzymują i czasami powiększają zbiór niektórych podstawowych bibliotek.Potrzebuje prawie wszystkich aktualnych bibliotek w tym folderze i wie, że będzie potrzebowała bibliotek, które jej zespół doda tam w przyszłości, więc mapuje $/SiteApp/Main/libraries/Common.
	Raisa potrzebuje tylko małej części dużego folderu $/SiteApp/Main/libraries/Common/LibraryC, więc mapuje go jako zamaskowany, a następnie jawnie mapuje tylko podfolder, którego potrzebuje: $/SiteApp/Main/libraries/Common/LibraryC/Sub-Library1.
	Raisa potrzebuje niektórych plików bezpośrednio w LibraryD, ale nie potrzebuje rozbudowanej zawartości jego podfolderów. Dlatego stosuje niecykliczne mapowanie do tego folderu: $/SiteApp/Main/libraries/Specialized/LibraryD/*.

Używaj obszarów roboczych do izolowania pracy i zarządzania nią w różnych gałęziach

Jeśli firma korzysta z gałęzi do izolowania ryzyka w bazie kodu, należy utworzyć oddzielny obszar roboczy dla każdej gałęzi, w której się pracuje.

Na przykład, w firmie Fabrikam Fiber rozrosła się baza kodu i zwiększyła liczba pracowników.Aby wyizolować ryzyko w wielu zespołach, rozgałęziono bazę kodu.Raisa kontynuuje pracę w małym zespole, ale teraz używa kilku obszarów roboczych do zarządzania pracą, którą obecnie wykonuje w wielu gałęziach.

	Opracowywanie funkcji Modyfikuje ona domyślny obszar roboczy do pracy w gałęzi Ekstranetu, gdzie uczestniczy w opracowywaniu witryny sieci Web do bezpośredniej obsługi klienta w tej gałęzi.
	Integrowanie i stabilizacja Tworzy dwa nowe obszary robocze do pracy w gałęziach testowych i deweloperskich, gdzie współpracuje z innymi programistami i testerami w celu stabilizacji kodu podczas integracji.

Raisa zarządza swoją pracą w trzech obszarach roboczych, z których każdy mapuje foldery w gałęzi na serwerze z folderami na komputerze deweloperskim.

[!UWAGA]

Rozgałęzianie lub zawieszanie (lub odkładanie) to preferowane sposoby izolowania pracy z tą samą bazą kodu.Jednak jeśli żadna z tych metod nie spełnia wymagań użytkownika, można mapować ten sam folder serwera w więcej niż jednym obszarze roboczym.W większości przypadków nie trzeba tego robić.Jeśli zmapowano ten sam folder serwera w więcej niż jednym obszarze roboczym, należy pamiętać, że można mieć odrębne i różne oczekujące zmiany tego samego pliku przechowywane w każdym obszarze roboczym.