Hvordan forklarer du adskillelse af bekymringer til andre?

Forestil dig at du har et program som er frigivet. En kunde kommer og tilbyder at betale dig for en forbedring af en af dens funktioner. For at få pengene skal du ændre dit program for at tilføje den nye funktion. Nogle af de ting, der vil påvirke, hvad din fortjenstmargen er, er:

1. hvor meget kode du skal ændre
2. hvor let det er at foretage ændringerne
3. hvor sandsynligt du er for at bryde eksisterende funktioner, der bruges af andre kunder
4. hvor meget du kan genbruge din eksisterende model / arkitektur

Adskillelse af bekymringer hjælper dig for at få mere positive svar på disse spørgsmål.

1. hvis al koden for en bestemt opførsel af applikationen er adskilt, skal du kun ændre kode direkte tilknyttet din nye funktion . Hvilket skal være mindre kode at ændre.
2. hvis den adfærd, du er interesseret i, er pænt adskilt fra resten af applikationen, er det mere sandsynligt, at du vil kunne bytte i en ny implementering uden at skulle forstå eller manipuler resten af programmet. Det skal også være lettere at finde ud af, hvilken kode du skal ændre.
3. Kode, som du ikke behøver at ændre, er mindre tilbøjelig til at bryde end kode, som du ændrer. Så ved at opdele bekymringerne hjælper du dig med at undgå brud i ikke-relaterede funktioner ved at forhindre dig i at skulle ændre kode, som de kunne ringe til. Hvis dine funktioner blandes sammen, kan du ændre en adfærd ved et uheld, mens du prøver at ændre en anden.
4. Hvis din arkitektur er agnostisk til teknisk eller forretningslogisk detalje, er det mindre sandsynligt, at ændringer i implementeringen kræver nye arkitektoniske træk. For eksempel, hvis din hoveddomænelogik er database agnostisk, skal det være lige så let at støtte en ny database som at bytte ind i en ny implementering af persistenslaget.

Kommentarer

• Jeg elsker at du fik svaret fast forankret i den økonomiske virkelighed. Ledere har ingen undskyldning for at være sjusket og ignorere dette grundlæggende koncept.

Se på et hospital, og tænk på alle de forskellige roller, der er involveret i at yde pleje til en patient: triage-sygeplejersker, læger, medicinske assistenter, teknologer, kontoransatte, cafeteria osv.

Er der nogen, der ved hvordan alle disse mennesker får deres job udført? Nej, fordi det ville være overvældende. De er nødt til at adskille de forskellige ansvarsområder i forskellige roller, og berøringspunkterne mellem disse roller er meget specifikke.

Hvis han / hun arbejder på et kontor, tag det som et eksempel, forklar hver enkelt stabs rolle på dette kontor og spørg ham, hvad der ville ske, hvis disse stabe ikke er opdelt efter deres job?

Jeg ville se på, hvordan han ikke anvendte SoC i sin kode / design og gøre det til et eksempel på en reel verden, som han kan forholde sig til og det er åbenlyst uønsket.

For eksempel, hvis han har en klasse, hvor klienten har brug for at levere flere stykker information, der ikke er relevante for disse klienter, så bruger jeg analogien med et bageri, hvor du har at medbringe dine egne korn og gær, hvis du vil købe et brød.

Et eksempel kan være, at en html-udvikler måske ønsker at adskille html, css og javascript i separa te filer. På denne måde kan du ændre udseendet og følelsen af noget sige ved blot at ændre css eller adfærd for noget ved at ændre javascript-filen, der indlæses separat. Hvis du har et responsivt eller adaptivt sted, fungerer dette paradigme godt, da du kan indlæse forskellige css eller javascript afhængigt af brugernes visningsport eller brugeragent. Men hvis du ændrer html eller skabelon, er chancerne for, at enten css eller javascript kan gå i stykker. Disse separate bekymringer kan også være afhængige.

En anden tilgang er at samle alt dit css-javascript og html i en gruppe af komponenter eller moduler. Dette betyder, at du kan foretage ændringer i et modul, og det bør ikke påvirke andre komponenter eller moduler på siden, som det kører langs siden, der ikke er relateret. Her flettes css-, js- og html-filerne til en enkelt komponent, der kan testes enhed.Så adskillelsen af bekymringer kommer i form af individuelle atomkomponenter, der kan testes enhedstesten snarere end adskillelse af markering, styling og adfærdsmæssige elementer. Denne anden tilgang er mere velegnet til oprettelse af mere komplekse webapplikationer.

rediger. Da jeg har modtaget et negativt svar på denne kommentar, troede jeg, at jeg ville besøge den igen og forsøge at kvalificere nogle af mine synspunkter. Desværre er enhver feedback her ikke særlig konstruktiv, men jeg så en interessant diskussion andetsteds, der ser på React, den aktuelle hotteknologi inden for webudvikling, et eksempel på en reel verden og spørger, om det bryder adskillelse af bekymringer eller især om det bryder en af princippet “s of Feather” s SOLID objektorienterede designmetode.

Det tekniske JavaScript-udviklerperspektiv

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-designerperspektivet

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

Også på siden er der et link til en interessant præsentation fra Pete Hunt fra Facebook, hvor han taler om komponenter ikke skabeloner og adskiller bekymringerne i sprogapplikationen snarere end adskille bekymringer fra rammen, dvs. skabeloner, css og javascript osv.

Med hensyn til at adskille dine bekymringer på dit applikations sprog kan dette involvere brug af forskellige mønstre til at adskille eller afkoble din kode til modulær form der kan enhedstestes osv.

Så for at opsummere kan det at adskille bekymringer afhænge af din rolle eller dit synspunkt, som nævnt ellers hvor.

Kommentarer

• dette ser ikke ‘ ikke ud til at tilbyde noget væsentligt over punkter, der er fremsat og forklaret tidligere 7 svar
• Jeg påpeger bare, at adskillelse af bekymringer kan tage forskellige tilgange afhængigt af sammenhængen. Dette er tættere på en reel verdenssituation inden for software engineering, og jeg fremhæver, at der er forskellige tilgange, du kan tage, når du arbejder på html-sider, der i starten kan virke modstridende.