Hur förklarar du Separation of Concerns to others?

Tänk dig att du har ett program som har släppts. En kund kommer och erbjuder att betala dig för en förbättring av en av dess funktioner. För att få pengarna måste du ändra ditt program för att lägga till den nya funktionen. Några av de saker som kommer att påverka vad din vinstmarginal är är:

1. hur mycket kod du måste ändra
2. hur lätt det är att göra ändringarna
3. hur troligt att du bryter mot befintliga funktioner som används av andra kunder
4. hur mycket du kan återanvända din befintliga modell / arkitektur

Separation av bekymmer hjälper för att få mer positiva svar på dessa frågor.

1. om all kod för ett visst beteende för applikationen är åtskild, behöver du bara ändra kod direkt associerad med din nya funktion . Vilket bör vara mindre kod att ändra.
2. om beteenden du är intresserad av är snyggt åtskilda från resten av applikationen är det mer troligt att du kommer att kunna byta i en ny implementering utan att behöva förstå eller manipulera resten av programmet. Det borde också vara lättare att ta reda på vilken kod du behöver ändra.
3. Kod som du inte behöver ändra är mindre benägna att bryta än kod som du ändrar. Så att dela upp bekymmerna hjälper dig att undvika brott i orelaterade funktioner genom att hindra dig från att behöva ändra kod som de kan ringa. Om dina funktioner blandas ihop kan du ändra en beteende av misstag medan du försöker ändra en annan.
4. Om din arkitektur är agnostisk till teknisk eller affärslogisk detalj är det mindre troligt att ändringar i implementeringen kräver nya arkitektoniska detaljer. Till exempel, om din huvuddomänlogik är agnostisk databas bör det vara lika enkelt att stödja en ny databas som att byta in en ny implementering av uthållighetsskiktet.

Kommentarer

• Jag älskar att du gjorde svaret förankrad i den ekonomiska verkligheten. Chefer har ingen ursäkt för att vara slarviga och ignorera detta grundläggande koncept.

Titta på ett sjukhus och tänka på alla de olika roller som är involverade i att tillhandahålla vård till en patient: triagesjuksköterskor, läkare, medicinska assistenter, tekniker, kontorspersonal, cafeteria osv.

Finns det någon som vet hur alla dessa människor får sina jobb gjort? Nej, för det skulle vara överväldigande. De måste separera de olika ansvarsområdena i olika roller och beröringspunkterna mellan dessa roller är mycket specifika.

Om han / hon arbetar på ett kontor, ta det som ett exempel, förklara varje stabs roll på det kontoret och fråga honom, vad skulle hända om de inte är uppdelade efter deras jobb?

Jag skulle titta på hur han misslyckades med att tillämpa SoC i sin kod / design och göra det till ett verkligt exempel som han kan relatera till och det är uppenbarligen oönskat.

Till exempel, om han har en klass där kunden behöver tillhandahålla flera uppgifter som inte är relevanta för dessa kunder, skulle jag använda analogin med ett bageri där du har att ta med egna korn och jäst om du vill köpa ett bröd.

Ett exempel kan vara en html-utvecklare kan vill separera ut html, css och javascript till separa te filer. På det här sättet kan du ändra utseendet och känslan av något att säga genom att helt enkelt ändra css eller beteende hos något genom att ändra javascript-filen som laddas separat. Om du har en responsiv eller adaptiv webbplats fungerar detta paradigm bra eftersom du kan ladda olika css eller javascript beroende på användarens visningsport eller användaragent. Men om du ändrar html eller mall, är chansen att antingen css eller javascript kan gå sönder. Dessa separata problem kan också vara beroende.

Ett annat tillvägagångssätt är att samla alla dina CSS-javaskript och html i en grupp av komponenter eller moduler. Det betyder att du kan göra ändringar i en modul och det ska inte påverka andra komponenter eller moduler på sidan som den kör längs sidan som inte är relaterade. Här sammanfogas css-, js- och html-filerna till en enda komponent som kan testas enhet.Så skillnaden mellan oro kommer i form av enskilda atomkomponenter som kan enhetstestas snarare än separering av markering, styling och beteendeelement. Detta andra tillvägagångssätt är mer lämpligt för att skapa mer komplexa webbapplikationer.

redigera. Eftersom jag har fått ett negativt svar på den här kommentaren trodde jag att jag skulle besöka den igen och försöka kvalificera några av mina pov. Tyvärr är all feedback här inte särskilt konstruktiv men jag såg en intressant diskussion någon annanstans som tittar på React, den nuvarande heta teknologin inom webbutveckling, ett verkligt exempel på världen, och frågar om det bryter separationen av bekymmer eller i synnerhet om det bryter en av principen ”s of Feather”: s SOLID-objektorienterade designmetodik.

Det tekniska JavaScript-utvecklingsperspektivet

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. 

UX / UI Designer Perspective

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. 

Teamperspektivet

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

Också på sidan finns en länk till en intressant presentation från Pete Hunt, på Facebook, där han pratar om komponenter inte mallar, och separerar oro i språkapplikationen snarare än separera problem i ramverket, dvs mallar, css och javascript etc.

När det gäller att separera dina problem på språket i din applikation kan detta innebära att du använder olika mönster för att separera eller koppla bort din kod till modulär form som kan enhetstestas osv.

Så för att sammanfatta, kan det vara beroende av din roll eller synpunkt, som nämnts annars där, att separera problem.

Kommentarer

• detta verkar inte ’ inte erbjuder något väsentligt över poäng som har gjorts och förklarats tidigare 7 svar
• Jag påpekar bara att det att skilja mellan bekymmer kan ta olika tillvägagångssätt beroende på sammanhanget. Detta är närmare en verklig situation inom programvaruteknik och jag betonar att det finns olika tillvägagångssätt när du arbetar på html-sidor som till en början kan verka motstridiga.