Jak vysvětlíte Oddělení obav ostatním?

Představte si, že máte program který byl propuštěn. Přijde zákazník a nabídne vám, že vám zaplatí za vylepšení jedné z jeho funkcí. Chcete-li získat peníze, budete muset změnit svůj program a přidat novou funkci. Některé z věcí, které ovlivní vaši ziskovou marži, jsou:

1. kolik kódu musíte změnit
2. jak snadné je provést změny
3. jak je pravděpodobné, že prolomíte stávající funkce, které využívají ostatní zákazníci,
4. jak moc můžete znovu použít stávající model / architekturu,

oddělení obav pomáhá získáte na tyto otázky pozitivnější odpovědi.

1. pokud je celý kód pro konkrétní chování aplikace oddělen, pak budete muset změnit pouze kód přímo spojený s vaší novou funkcí . Což by mělo být méně kódu na změnu.
2. Pokud jsou chování, která vás zajímají, úhledně oddělena od zbytku aplikace, je pravděpodobnější, že budete moci vyměnit novou implementaci, aniž byste museli plně rozumět nebo manipulovat se zbytkem programu. Mělo by také být snazší zjistit, který kód musíte změnit.
3. Kód, který nemusíte měnit, je méně pravděpodobné, že se rozbije, než kód, který změníte. Takže rozdělení problémů vám pomůže vyhnout se rozbití nesouvisejících funkcí tím, že vám zabrání ve změně kódu, který by mohli volat. Pokud jsou vaše funkce smíchány dohromady, můžete náhodou změnit chování jednoho, zatímco se pokusíte změnit jiný.
4. Pokud je vaše architektura agnostická k technickým detailům nebo detailům obchodní logiky, pak je méně pravděpodobné, že změny implementace budou vyžadovat nové architektonické prvky. Například pokud je vaše hlavní doménová logika databázová agnostika, měla by být podpora nové databáze stejně snadná jako výměna v nové implementaci vrstvy perzistence.

Komentáře

• Líbí se mi, že jste odpověď pevně zakotvili ve finanční realitě. Manažeři nemají žádnou výmluvu, aby byli nedbalí, a ignorují tento základní koncept.

Podívejte se na nemocnici a přemýšlejte o všech různých rolích, které se podílejí na poskytování péče o pacienta: třídění zdravotních sester, lékařů, lékařských asistentů, techniků, administrativního personálu, jídelny atd.

Existuje někdo, kdo ví jak všichni z těchto lidí dostanou práci? Ne, protože by to bylo ohromující. Musí rozdělit různé odpovědnosti do odlišných rolí a styčné body mezi těmito rolemi jsou velmi specifické.

Pokud / pracuje v kanceláři, vezměte si to jako příklad, vysvětlete roli každého štábu v této kanceláři a zeptejte se ho, co by se stalo, kdyby tyto štáby nebyly rozděleny podle jejich zaměstnání?

Podíval bych se na to, jak se mu nepodařilo aplikovat SoC ve svém kódu / designu, a proměnit to ve skutečný příklad, se kterým se může spojit a to je zjevně nežádoucí.

Například pokud má třídu, kde klient potřebuje poskytnout několik informací, které nejsou pro tyto klienty relevantní, použil bych analogii pekárny, kde máte přinést si vlastní obilí a droždí, pokud si chcete koupit chléb.

Jedním příkladem může být vývojář html chcete oddělit html, css a javascript na separa te soubory. Tímto způsobem můžete změnit vzhled a chování něčeho, co říkáte, jednoduše změnou css nebo chováním něčeho změnou souboru javascript, který je načten samostatně. Pokud máte responzivní nebo adaptivní web, toto paradigma funguje dobře, protože můžete načíst jiný css nebo javascript v závislosti na výřezu uživatele nebo uživatelském agentovi. Pokud však upravíte html nebo šablonu, je pravděpodobné, že by se mohl poškodit buď css nebo javascript. Tyto samostatné obavy mohou také záviset.

Dalším přístupem je seskupit všechny vaše CSS javascript a html do skupiny komponent nebo modulů. To znamená, že můžete provést změny v jednom modulu a nemělo by to mít vliv na ostatní komponenty nebo moduly na stránce, na které běží, které spolu nesouvisí. Zde jsou soubory css, js a html sloučeny do jedné komponenty, kterou lze testovat na jednotku.Oddělení obav tedy přichází ve formě jednotlivých atomových složek, které lze testovat na jednotce, spíše než oddělování značek, stylů a prvků chování. Tento druhý přístup je vhodnější pro vytváření složitějších webových aplikací.

Upravit. Vzhledem k tomu, že jsem obdržel negativní odpověď na tento komentář, myslel jsem si, že to znovu navštívím a pokusím se kvalifikovat některé z mých pov. Bohužel jakákoli zpětná vazba zde není nijak zvlášť konstruktivní, ale viděl jsem zajímavou diskusi jinde, která se zaměřuje na React, současnou horkou technologii ve vývoji webových aplikací, příklad z reálného světa a ptá se, zda to rozbíjí oddělení obav nebo zvláště jestli rozbíjí jednu z princip metodiky návrhu „of Feather“ SOLID objektově orientovaného návrhu.

Technická perspektiva vývojáře JavaScriptu

NO, because JSX is a view language. That"s one responsibility. BUT, this implies that the JS developer is self-enforcing SoC/SRP on his own architecture by not mixing ViewModel concerns in his JSX. This type of vigilance "in the wild" is highly suspect because JSX involves the full JavaScript dialect. 

Perspektiva návrháře UX / UI

YES, because JSX mixes Semantic Content (Model) with Behavior (Controller) YES, because the intrusion, specifically of JavaScript, into the Semantic Model makes it difficult or impossible for me to play my role and leverage my expertese and skills. 

Perspektiva týmu

NO, if both... Separate files are used for the View (JSX) and ViewModel (JS). Either there aren"t UI/UX/Designers involved, or they are productive working directly with JSX (not very common). YES, if either... Everything is in the same file, causing problems for version control or productive use of modern editors. Members of the team who are comfortable with HTML/CSS but less capable with JavaScript are excluded because of mixture or roles. 

https://hashnode.com/post/does-react-really-violate-separation-of-concern-by-putting-html-and-js-in-a-single-file-cil3bn5hj0011a65347rsdut0

Na stránce je také odkaz na zajímavou prezentaci Peteho Hunta z Facebooku, kde hovoří o komponentách, nikoli o šablonách, a odděluje obavy v jazykové aplikaci spíše než oddělení problémů rámce, tj. šablon, css a javascript atd.

Pokud jde o oddělení problémů v jazyce vaší aplikace, mohlo by to zahrnovat použití různých vzorů k oddělení nebo oddělení kódu do modulární podoby které lze testovat na jednotce atd.

Abychom to shrnuli, oddělení problémů může záviset na vaší roli nebo úhlu pohledu, jak je uvedeno jinde.

Komentáře

• Zdá se, že to ‚ nenabízí nic podstatného nad body a vysvětleno v předchozích 7 odpovědí
• Jen poukazuji na to, že oddělení problémů může vyžadovat různé přístupy v závislosti na kontextu. To se blíží situaci v reálném světě v oblasti softwarového inženýrství a já zdůrazňuji, že při práci na html stránkách můžete zvolit různé přístupy, které se na první pohled mohou zdát protichůdné.