Hvordan forklarer du Separasjon av bekymringer for andre?

Se for deg at du har et program som er utgitt. En kunde kommer og tilbyr å betale deg for en forbedring av en av funksjonene. For å få pengene, må du endre programmet for å legge til den nye funksjonen. Noen av tingene som vil påvirke fortjenestemarginen din er:

1. hvor mye kode du må endre
2. hvor enkelt det er å gjøre endringene
3. hvor sannsynlig det er at du bryter eksisterende funksjoner som brukes av andre kunder
4. hvor mye du kan gjenbruke eksisterende modell / arkitektur

Separasjon av bekymringer hjelper for å få mer positive svar på disse spørsmålene.

1. hvis all koden for en bestemt oppførsel i applikasjonen er skilt ut, trenger du bare å endre koden som er direkte tilknyttet den nye funksjonen din. . Som burde være mindre kode å endre.
2. hvis atferdene du er interessert i er pent skilt fra resten av applikasjonen, er det mer sannsynlig at du vil kunne bytte til en ny implementering uten å måtte forstå eller manipulere resten av programmet. Det skal også være lettere å finne ut hvilken kode du trenger å endre.
3. Kode som du ikke trenger å endre, er mindre sannsynlig å bryte enn kode som du endrer. Så å dele opp bekymringene hjelper deg med å unngå brudd i ikke-relaterte funksjoner ved å forhindre at du må endre kode som de kan ringe. Hvis funksjonene dine er blandet sammen, kan du endre oppførselen til en ved et uhell mens du prøver å endre en annen.
4. Hvis arkitekturen din er agnostisk til tekniske eller forretningslogiske detaljer, er det mindre sannsynlig at endringer i implementeringen krever nye arkitektoniske trekk. For eksempel, hvis hoveddomenelogikken din er database-agnostisk, bør det være like enkelt å støtte en ny database som å bytte inn en ny implementering av utholdenhetslaget.

Kommentarer

• Jeg elsker at du gjorde svaret fast forankret i den økonomiske virkeligheten. Ledere har ingen unnskyldning for å være slurvete og ignorere dette grunnleggende konseptet.

Se på et sykehus, og tenk på alle de forskjellige rollene som er involvert i å gi pasienter omsorg: triagesykepleiere, leger, medisinske assistenter, tekniske fagpersoner, kontorpersoner, kafeteria osv.

Er det noen som vet hvordan alle disse menneskene får jobben gjort? Nei, for det ville være overveldende. De må skille ut de ulike ansvarsoppgavene i forskjellige roller, og berøringspunktene mellom disse rollene er veldig spesifikke.

Hvis han / hun jobber på et kontor, ta det som et eksempel, forklar hvilken rolle hver stab har på det kontoret, og spør ham, hva ville skje hvis de ikke er delt i henhold til jobbene sine?

Jeg vil se på hvordan han ikke klarte å bruke SoC i sin kode / design og gjøre det om til et eksempel fra den virkelige verden som han kan forholde seg til og det er åpenbart uønsket.

Hvis han for eksempel har en klasse der klienten trenger å levere flere opplysninger som ikke er relevante for disse klientene, så vil jeg bruke analogien til et bakeri der du har å ta med egne korn og gjær hvis du vil kjøpe et brød.

Et eksempel kan være at en html-utvikler kanskje ønsker å skille ut html, css og javascript i separa te filer. På denne måten kan du endre utseendet på noe si ved å bare endre css eller oppførselen til noe ved å endre javascript-filen som lastes inn separat. Hvis du har et responsivt eller adaptivt nettsted, fungerer dette paradigmet bra, ettersom du kan laste inn forskjellige css eller javascript, avhengig av brukernes synsfelt eller brukeragent. Men hvis du endrer html eller mal, er sjansen stor for at enten css eller javascript kan gå i stykker. Disse separate bekymringene kan også være avhengige.

En annen tilnærming er å pakke hele CSS-javaskriptet og HTML-en din i en gruppe komponenter eller moduler. Dette betyr at du kan gjøre endringer i en modul, og det skal ikke påvirke andre komponenter eller moduler på siden den kjører langs siden som ikke er relatert. Her flettes css-, js- og html-filene til en enkelt komponent som kan enhetstestes.Så skillet mellom bekymringer kommer i form av individuelle atomkomponenter som kan enhetstestes i stedet for separasjon av markering, styling og atferdselementer. Denne andre tilnærmingen er mer egnet for å lage mer komplekse webapplikasjoner.

rediger. Siden jeg har fått negativt svar på denne kommentaren, trodde jeg at jeg ville gå tilbake til den og prøve å kvalifisere noen av mine pov. Dessverre er ingen tilbakemeldinger her spesielt konstruktive, men jeg så en interessant diskusjon andre steder som ser på React, den nåværende hotteknologien innen nettutvikling, et eksempel fra den virkelige verden, og spør om det bryter skillet mellom bekymringer eller spesielt om det bryter en av prinsippet «s of Feather» er SOLID objektorientert designmetodikk.

Det tekniske JavaScript-utviklerperspektivet

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

Også på siden er det en lenke til en interessant presentasjon fra Pete Hunt, på Facebook, der han snakker om komponenter ikke maler, og skiller ut bekymringene i språkapplikasjonen snarere enn skille ut bekymringer i rammeverket, dvs. maler, css og javascript osv. som kan enhetstestes osv.

Så for å oppsummere, kan det å skille ut bekymringer avhenge av din rolle eller synspunkt, som nevnt ellers hvor.

Kommentarer

• dette ser ikke ‘ ut til å tilby noe vesentlig over poengene som ble gjort og forklart tidligere 7 svar
• Jeg påpeker bare at det å skille ut bekymringer kan ta forskjellige tilnærminger avhengig av konteksten. Dette er nærmere en reell situasjon i programvareteknikk, og jeg fremhever at det er forskjellige tilnærminger du kan ta når du arbeider med html-sider som i utgangspunktet kan virke motstridende.