Jinak původní otázka co jsem pochopil nebyla ohledně toho jak to řídit, ale ohledně designu. Čas x návrh jdou obvykle proti sobě a proto je třeba hledat kompromisy, to je to čím tyto věci souvisí. Přijde manažer a řekne: "Trochu ten kód pročistěte a zavřete to, musíme to doručit už zítra!" a pak v kódu zůstanou prasárny kvůli kterým v budoucnu přibude práce, protože kód bude hůře udržovatelný.
Ale - u velkých projektů je významné procento kódu, na který se sáhne třeba jednou za dva roky. Kvalitní design dělá kód složitější, protože klade větší nároky na opici (pardón, na toho kdo to udržuje...) která nemusí vědět ani nic o tom že je dobré snažit se o znovuvyužití existujícího kódu. V praxi stejně můžete narazit na plánování typu "Tak zkopírujeme zdroják téhle obrazovky a trochu to změníme...".
Z hlediska byznysu není důležité jestli je kód čistý, ale že ona nová obrazovka dá v čas vědět že se třeba něco nemá vyrábět a tím že se výroba včas zastaví se ušetří značné prostředky, případně že nová funkcionalita umožní vyrobit co nejmíň v rámci legálních a smluvních limitů a tak uspokojit co největší počet zákazníků továrny, případně naopak pokud má továrna málo objednávek tak vyrábět co nejvíc v rámci existujících objednávek aby se maximalizoval zisk. A nejlépe mezi těmi dvěma situacemi dynamicky přecházet v závislosti na aktuální situaci která se třeba během roku mění...
U designu platí, že čím větší abstrakce, tím je může být pro ostatní složitější pochopit o co jde. Ale ani v případě relativně jednoduché abstrakce není zajištěno že nedojde k duplikaci kódu. A tak i když má třída reprezentující množinu řádků v databázi metodu na hledání záznamů podle hodnoty v nějakých sloupečcích, tak stejně se vždycky najde někdo kdo o tom neví a udělá si vlastní hledání, obvykle for přes prvky kolekce pomocí iterátoru. To se děje ve starých projektech kde podobné featury nebyly součástí jazyka a tak někdo naprogramoval vlastní framework ale neudělal k němu programovou dokumentaci bo na to nebyl čas ani peníze a nově příchozí pak nehledali, jestli tam na to něco není. Zvláště pak pokud nestandardní konstrukce v headeru zabily IntelliSense které se ani nedostalo k definici třídy a manažeři nedovolili refaktorovat několik stovek souborů protože to přece není bug nahlášený zákazníkem...
No každopádně u velkého projektu je klíčové rozdělit jej na několik modulů a definovat mezi nimi rozhraní, pak na modulech může pracovat vícero týmu relativně nezávisle na sobě. Je dobré pokud je nějaký modul do něhož se nacpe obecná programová funkcionalita nesouvisející s byznysem (helper classy v C#, generické algoritmy, perzistence č atp.) a ostatní moduly se pak zabývají jen svojí doménou. V takovém modulu pak je třeba implementován "kalendář s vodotryskem a splachovadlem", ten se pak nakonfiguje v byznys modulu aby u objednávek zobrazoval "blikající vodotrysk bez splachovadla" a skladníkovi co řídí nakládání zboží na kamiony "malý agregovaný vodotrysk co blikne jen při použití splachovadla". V byznys modulech se pak řeší jen byznys-logika, tudíž co udělat když si zákazník továrny v půli výroby uprdne, nikoliv už jak to zobrazit či pořešit technicky. Oddělení byznys logiky je kapitola sama pro sebe, je dobré vyvarovat se tomu aby taková logika byla v grafických komonentách...
No a hodně dalších věcí. V praxi stejně přijde někdo kdo to nedodrží a opice se na to vyserou, zvláště pokud je moc neplatí tak udělají jen tolik aby to fungovalo...