Zoptymalizuj obszary robocze

Czy chcesz upewnić się, że obszaru roboczego jest zoptymalizowany pod kątem pracę i skutecznie w swojej codebase?Jeśli tak, jesteś we właściwym miejscu.

Co chcesz zrobić?

• Optymalizacja nazwy folderów

• Optymalizacja mapowania folderu przy użyciu jawnych, niejawna, zamaskowane, a nie cykliczne obszaru roboczego

• Korzystanie z obszarów roboczych do izolowania i zarządzania nimi pracy między różnymi obszarami

Optymalizacja nazwy folderów

Podczas tworzenia projektów kodu w programie Visual Studio, domyślnie, umieszcza je w folderze Użytkownicy (na przykład: c:\users\myname\documents\visual studio 2012\Projects\SolutionName.Ale w większości przypadków najlepiej do używania danej ścieżki folderu krótkie i zrozumiałe, że pasuje do struktury projektu, takie jak c:\code\siteapp\Main\SolutionName\.

Wskazówki, nazwy folderów skuteczne:

• Zachowaj wszystkie folderu, podfolderów i krótkich nazw plików Aby uprościć swoją pracę i uniknąć potencjalnych problemów długie ścieżki, które mogą wystąpić z niektórymi typami projektów kodu.

• Jeśli chcesz, aby nieco łatwiejsze do wykonania operacji wiersza polecenia, należy unikać odstępy.

• Jeśli jeszcze nie używasz oddziałów, umieszczenia całego kodu w podfolderze o nazwie głównego (na przykład: $/SiteApp/Main/).W takim wypadku następnie będziesz gotowy gdy zespół powiększy się wystarczająco duży, aby wymagać od oddziałów do zarządzania swoimi codebase.

Optymalizacja mapowania folderu przy użyciu jawnych, niejawna, zamaskowane, a nie cykliczne obszaru roboczego

Jeśli Twój codebase jest duża, można uniknąć marnowania czasu, przepustowość sieci i miejsca na dysku lokalnym poprzez optymalizację mapowania folderu roboczego.

Zamapowanie folderu, upewnij się, aby wybrać folder wystarczająco wysoka, w drzewie kodu, że masz wszystkie pliki, należy utworzyć lokalne budować, ale na tyle niska, że nie są coraz większej liczby plików niż potrzeba.Umożliwia także niektóre narzędzia i bardziej szybkiego tworzenia można używać obszaru roboczego: jawne, niejawna, zamaskowane, i cykliczne nie mapowania folderów.

Jeśli spojrzeć na obszar roboczy Julia poniżej, można się zastanawiać do siebie: Dlaczego nie ona po prostu mapować $/SiteApp/ do c:\code\SiteApp\ i być z nim zrobić?Proste obszaru roboczego, tak by niejawnie mapować wszystkie foldery potrzebuje w $/SiteApp/Main/.

Głównym problemem z tym podejściem jest, że to również zapewnienie jej wiele plików ona nie potrzebujesz, a tym samym tracić czasu i zasobów.Tak więc Julia tworzy niektóre mapowania folderów dostosowane do potrzeb.

	Julia nie będzie rozwijać procesy budować dostosowane tak, aby nie potrzebuje $/SiteApp/BuildProcessTemplates.Czasem ona oczekuje codebase rośnie, a także nie chce do automatycznego pobierania co nieco nowego kodu dodane do $/SiteApp/Main/.Jak zespołom pracującym w innych folderach zmiany tych plików, gdy Julia pobiera najnowsze pliki z serwera, ona mogłoby spowodować duże opóźnienia czeka na pliki, które nie potrzebuje aktualizacji. Tworzenie jej kodu, Julia musi wszystkich projektów kodu, które składają się rozwiązania FabrikamFiber.A nie jawnie łącznie z każdego projektu kod (na przykład, $/SiteApp/Main/FabrikamFiber/FabrikamFiber.DAL) ona zamiast mapy $/SiteApp/Main/FabrikamFiber/, a tym samym ona niejawnie mapuje wszystkie podfoldery, zawierające projektów kodu potrzebuje.
	Julia nie wymaga plików w $/SiteApp/Main/FabrikamFiber/3DModels lub $/SiteApp/Main/FabrikamFiber/Docs, i dlatego są niejawnie mapowane przez, korzysta ona z dwóch zamaskowane mapowania, aby wykluczyć te foldery z jej obszaru roboczego.
	Julia i inne osoby w zespole jej utrzymanie i czasami poszerzyć zestaw niektórych podstawowych bibliotek.Ona potrzebuje prawie wszystkich bibliotek bieżącej, w tym folderze i oczekuje, że potrzebujesz bibliotek jej zespół dodaje w przyszłości, więc ona mapuje $/SiteApp/Main/libraries/Common.
	Julia potrzebuje tylko mały segment dużych folderów $/SiteApp/Main/libraries/Common/LibraryC, więc ona mapuje ją jako zamaskowane i jawnie mapy tylko podfolder, potrzebuje: $/SiteApp/Main/libraries/Common/LibraryC/Sub-Library1.
	Julia potrzebuje niektóre pliki natychmiast w ramach LibraryD, ale ona wymaga dużej zawartości jego podfoldery, więc ma ona zastosowanie cykliczne nie mapowania do tego folderu: $/SiteApp/Main/libraries/Specialized/LibraryD/*.

Korzystanie z obszarów roboczych do izolowania i zarządzania nimi pracy między różnymi obszarami

Jeśli firma korzysta z oddziałów do izolowania ryzyko w swojej codebase, następnie należy utworzyć oddzielny obszar roboczy dla każdego oddziału, pracujesz w.

Na przykład w Fabrikam Fiber kodu i personel wzrosła.Aby wyizolować ryzyka wśród ich wiele zespołów, one już rozgałęzionych ich codebase.Julia kontynuuje pracę w ramach jej małego zespołu, ale teraz używa kilku obszarów roboczych do zarządzania pracą, która robi teraz w wielu gałęzi.

	Opracowanie funkcji ona modyfikuje jej domyślnego obszaru roboczego do pracy w ekstranecie gałąź, w przypadku gdy ona uczestniczy w opracowywaniu witryny sieci Web klientów w tej dziedzinie.
	Integrowanie i stabilizacji ona powoduje utworzenie dwóch nowych obszarów roboczych do pracy w branżach Test i odchylenia standardowego, gdzie współpracuje z innymi programistami i testerami, jego praca się ustabilizuje kod podczas integracji.

Julia zarządza pracę w trzech obszarach roboczych, z których każda mapuje foldery z gałęzi na serwerze z folderami na komputerze jej odchylenia standardowego.

[!UWAGA]

Podręcznik rozgałęziania lub zawieszenia (lub półki) są preferowane sposoby izolowania innego wydziału walkę z tego samego kodu.Jednakże jeśli żadna z powyższych metod nie spełnia wymagań, można mapować tego samego folderu serwera w więcej niż jeden obszar roboczy.W większości przypadków nie należy w tym celu.Należy mapować tego samego folderu serwera w więcej niż jeden obszar roboczy, należy pamiętać, że można mieć odrębne i różne oczekujące zmiany do tego samego pliku przechowywanych w każdym obszarze roboczym.