Optimalizace pracovního prostoru

Má váš tým rozsáhlý a komplexní základ kódu?Chcete, aby pracovní prostor obsahoval pouze soubory, které potřebujete pro zvýšení výkonu, snížení aktivity v síti a omezení místa na disku požadovaného ve vývojovém počítači?

• Optimalizace názvů složek

• Optimalizace pracovního prostoru pomocí explicitního, implicitního, skrytého a nerekurzivního mapování složek

• Izolace a řízení práce mezi různými větvemi pomocí pracovních prostorů

Optimalizace názvů složek

Pokud dosud nepoužíváte větve, měli byste na serveru ukládat veškerý kód do podsložky s názvem Main (například $/TFVCTeamProject/Main/).Pokud ano, pak budete připraveni na okamžik, kdy váš tým bude dostatečně velký, aby správa základu kódu vyžadovala větve.Ve vývojovém počítači byste měli používat krátkou a výstižnou cestu ke složce, která odpovídá struktuře projektu, například C:\Users\YourName\Source\Workspaces\TFVCTeamProject\Main\SolutionName\.

Několik dalších tipů pro efektivní názvy složek:

• Pro všechny složky, podsložky a soubory používejte krátké názvy, abyste si zjednodušili práci a vyhnuli se problémům s dlouhými cestami, které mohou nastat u některých typů projektů.

• Pokud si chcete usnadnit práci s příkazovým řádkem, nepoužívejte mezery.

Optimalizace pracovního prostoru pomocí explicitního, implicitního, skrytého a nerekurzivního mapování složek

Pokud máte rozsáhlý základ kódu, můžete optimalizací mapování složek pracovního prostoru zabránit plýtvání časem, šířkou pásma a místem na místním disku.

Při mapování složky zvolte složku dostatečně vysoko ve stromové struktuře kódu, abyste získali všechny soubory, které potřebujete k vytvoření místního sestavení, ale dostatečně nízko, abyste nezískali více souborů, než potřebujete.Můžete také použít některé nástroje, které vám umožní snadněji a rychleji vytvořit užitečný pracovní prostor: explicitní, implicitní, skryté a nerekurzivní mapování složek.

Při pohledu na níže zobrazený pracovní prostor fiktivní vývojářky Raisy se můžete divit: proč jednoduše nenamapovala pouze $/SiteApp/ na c:\code\SiteApp\ a nevystačila s tím?Jednoduchý pracovní prostor jako tento by implicitně mapoval všechny složky, které potřebuje v $/SiteApp/Main/.

Hlavní problém tohoto přístupu je, že by jí také mohl poskytnout velké množství nepotřebných souborů, takže by plýtvala časem a prostředky.Raisa si proto vytvoří mapování složek na míru.

	Raisa nevyvíjí vlastní procesy sestavení, takže nepotřebuje $/SiteApp/BuildProcessTemplates.Očekává, že základ kódu se časem rozroste, a nebude také chtít automaticky stahovat každý kousek nového kódu do $/SiteApp/Main/.Protože týmy pracující v těchto ostatních složkách tyto soubory mění, při získávání nejnovějších souborů ze serveru by Raisa musela dlouho čekat na aktualizace souborů, které nepotřebuje. Aby mohla Raisa psát kód, potřebuje všechny kódové projekty, ze kterých se skládá řešení FabrikamFiber.Místo explicitního zahrnutí každého kódového projektu (například $/SiteApp/Main/FabrikamFiber/FabrikamFiber.DAL) raději namapuje $/SiteApp/Main/FabrikamFiber/ a tím implicitně namapuje všechny podsložky, které obsahují potřebné kódové projekty.
	Raisa nepotřebuje soubory ve složkách $/SiteApp/Main/FabrikamFiber/3DModels ani $/SiteApp/Main/FabrikamFiber/Docs a protože jsou implicitně namapovány pomocí, používá dvě skrytá mapování, kterými tyto složky vyloučí ze svého pracovního prostoru.
	Raisa a další členové jejího týmu udržují a občas rozšiřují sadu některých základních knihoven.Potřebuje v této složce téměř všechny aktuální knihovny a očekává, že bude potřebovat knihovny, které její tým přidá v budoucnosti, proto namapuje $/SiteApp/Main/libraries/Common.
	Raisa potřebuje pouze malou část velké složky – $/SiteApp/Main/libraries/Common/LibraryC – proto ji namapuje jako skrytou a pak explicitně namapuje pouze podsložku, kterou potřebuje: $/SiteApp/Main/libraries/Common/LibraryC/Sub-Library1.
	Raisa potřebuje některé soubory přímo ve složce LibraryD, ale nepotřebuje rozsáhlý obsah jejích podsložek, takže na tuto složku použije nerekurzivní mapování: $/SiteApp/Main/libraries/Specialized/LibraryD/*.

Izolace a řízení práce mezi různými větvemi pomocí pracovních prostorů

Pokud vaše firma v základu kódu používá větve k izolaci rizika, pak byste měli vytvořit samostatný pracovní prostor pro každou větev, na které pracujete.

Například ve firmě Fabrikam Fiber se zvětšil základ kódu a počet zaměstnanců.Aby izolovali riziko mezi velkým počtem týmů, rozvětvili svůj základ kódu.Raisa pokračuje ve své práci v rámci svého malého týmu, ale používá několik pracovních prostorů ke správě své práce, kterou nyní dělá v několika větvích.

	Vývoj funkcí: Upraví svůj výchozí pracovní prostor tak, aby pracovala na větvi Extranet, kde se účastní vývoje webu orientovaného na zákazníka.
	Integrace a stabilizace: Vytvoří dva nové pracovní prostory pro práci na větvích Testování a Vývoj, kde spolupracuje s jinými vývojáři a testery na stabilizaci kódu během integrace.

Raisa pracuje ve třech pracovních prostorech, z nichž každý mapuje složky v určité větvi na serveru na složky v jejím vývojovém počítači.

[!POZNÁMKA]

Větvení a pozastavení (neboli odložení) jsou upřednostňované způsoby izolace různých pracovních výsledků vůči stejnému základu kódu.Pokud ale ani jeden z těchto přístupů nevyhovuje vašim potřebám, můžete stejné složky na serveru namapovat ve více než jednom pracovním prostoru.Ve většině případů to nebude zapotřebí.Uvědomte si, že pokud namapujete stejnou složku na serveru ve více než jednom pracovním prostoru, mohli byste mít v každém pracovním prostoru uloženy samostatné a odlišné nedokončené změny pro stejný soubor.