Kuinka selität huolenaiheiden erottamisen muille?

Kuvittele, että sinulla on ohjelma joka on vapautettu. Asiakas tulee mukaan ja tarjoaa maksaa sinulle yhden sen ominaisuuksista. Saadaksesi rahaa sinun on vaihdettava ohjelmasi lisäämään uusi ominaisuus. Jotkut asiat, jotka vaikuttavat voittomarginaaliisi, ovat:

1. kuinka paljon koodia sinun on vaihdettava
2. kuinka helppoa on tehdä muutoksia
3. kuinka todennäköinen olet rikkoa olemassa olevia ominaisuuksia, joita muut asiakkaat käyttävät
4. kuinka paljon voit käyttää olemassa olevaa mallia / arkkitehtuuria uudelleen

Huolenaiheiden erottaminen auttaa saat enemmän positiivisia vastauksia näihin kysymyksiin.

1. jos kaikki sovelluksen tietyn toiminnan koodit erotetaan toisistaan, sinun tarvitsee vaihtaa vain uuteen ominaisuuteen suoraan liitetty koodi . Minkä koodin pitäisi olla vähemmän muutettavissa.
2. jos sinua kiinnostava käyttäytyminen erotetaan siististi muusta sovelluksesta, on todennäköisempää, että voit vaihtaa uuden toteutuksen ilman, että sinun on ymmärrettävä täysin tai manipuloida muuta ohjelmaa. Pitäisi olla myös helpompaa selvittää muutettava koodi.
3. Koodi, jota sinun ei tarvitse muuttaa, hajoaa vähemmän kuin muuttamasi koodi. Joten huolenaiheiden jakaminen auttaa välttämään etuyhteydettömien ominaisuuksien rikkoutumisen estämällä sinua vaihtamasta koodia, johon he voivat soittaa. Jos ominaisuutesi sekoitetaan yhteen, voit muuttaa yhden käyttäytymistä vahingossa yrittäessäsi vaihtaa toista.
4. Jos arkkitehtuurisi on agnostinen teknisiin tai liiketoimintalogiikan yksityiskohtiin nähden, toteutuksen muutokset eivät todennäköisesti edellytä uudet arkkitehtoniset piirteet. Esimerkiksi, jos päätoimialueesi logiikka on tietokanta-agnostinen, uuden tietokannan tukemisen tulisi olla yhtä helppoa kuin vaihtaa pysyvyyskerroksen uusi toteutus.

kommentit

• Rakastan, että annoit vastauksen tiukasti ankkuroituna taloudelliseen todellisuuteen. Johtajilla ei ole tekosyitä olla huolimattomia ja jättää huomioimatta tämä peruskäsite.

Katso sairaalaa ja miettiä kaikkia erilaisia rooleja, jotka liittyvät potilaan hoidon tarjoamiseen: triagiahoitajat, lääkärit, lääkärien avustajat, teknikot, toimihenkilöstö, kahvilat jne.

Onko joku henkilö, joka tietää miten kaikki noista ihmisistä saavat työnsä päätökseen? Ei, koska se olisi ylivoimainen. Heidän on erotettava eri vastuualueet erillisiksi rooleiksi, ja näiden roolien väliset kosketuspisteet ovat hyvin tarkkoja.

Jos hän / hän työskentelee toimistossa, ota se esimerkkinä, selitä kunkin henkilöstön rooli kyseisessä toimistossa ja kysy tältä, mitä tapahtuisi, jos näitä henkilöstöjä ei jaettaisi työnsä mukaan?

Katsoisin, kuinka hän ei soveltanut SoC: ta koodissaan / suunnittelussaan, ja tekisin siitä reaalimaailman esimerkin, johon hän voi olla yhteydessä se ei tietenkään ole toivottavaa.

Esimerkiksi, jos hänellä on luokka, jossa asiakkaan on toimitettava useita tietoja, jotka eivät ole merkityksellisiä kyseisille asiakkaille, käytän analogiaa leipomoon, jossa sinulla on tuoda omat jyvät ja hiiva, jos haluat ostaa leipää.

Yksi esimerkki voi olla html-kehittäjä haluat erottaa html: n, css: n ja javascriptin erillisiksi te-tiedostot. Tällä tavoin voit muuttaa sanan ulkoasua ja tunnetta muuttamalla yksinkertaisesti css: tä tai käyttäytymistä muuttamalla erikseen ladattavaa javascript-tiedostoa. Jos sinulla on reagoiva tai mukautuva sivusto, tämä paradigma toimii hyvin, koska voit ladata erilaisia css: itä tai javascriptiä käyttäjän näkymästä tai käyttäjäagentista riippuen. Jos kuitenkin muokkaat html: ää tai mallia, on todennäköistä, että joko css tai javascript voivat rikkoutua. Nämä erilliset huolenaiheet voivat myös olla riippuvaisia.

Toinen tapa on niputtaa kaikki css javascript ja html komponenttien tai moduulien ryhmään. Tämä tarkoittaa, että voit tehdä muutoksia yhteen moduuliin, eikä se saisi vaikuttaa muihin sivun komponentteihin tai moduuleihin, joiden sivuilla se ei ole yhteydessä toisiinsa. Täällä css-, js- ja html-tiedostot yhdistetään yhdeksi komponentiksi, joka voidaan testata yksiköllä.Joten huolenaiheet erotetaan yksittäisten atomikomponenttien muodossa, jotka voidaan testata yksikköä sen sijaan, että erotettaisiin merkinnät, muotoilu ja käyttäytymisosat. Tämä toinen lähestymistapa soveltuu paremmin monimutkaisempien verkkosovellusten luomiseen.

muokkaa. Koska olen saanut negatiivisen vastauksen tähän kommenttiin, ajattelin, että palaan siihen uudelleen ja yritän pätevöittää joitain poviani. Valitettavasti mikään palaute ei ole erityisen rakentavaa, mutta näin muualla mielenkiintoisen keskustelun, jossa tarkastellaan Reactia, nykyistä verkkokehityksen kuumaa tekniikkaa, reaalimaailman esimerkkiä ja kysytään, rikkooko se huolenaiheita vai etenkin, jos se rikkoo yhden periaatteen ”s of Feather” SOLID-objektisuuntautunut suunnittelumenetelmä.

JavaScript-kehittäjien tekninen näkökulma

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-suunnittelijan näkökulma

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. 

Joukkueen näkökulma

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

Lisäksi sivulla on linkki mielenkiintoiseen esitykseen Pete Huntilta, Facebookista, jossa hän puhuu komponenteista, ei malleista, ja erottaa kielisovelluksessa olevat ongelmat kehyksen huolenaiheiden, eli mallien, css: n, javascriptin jne., erottaminen.

Huolenaiheiden erottamiseksi sovelluksesi kielellä tämä voi tarkoittaa useiden mallien käyttämistä koodin erottamiseksi tai irrottamiseksi moduulimuotoon joita voidaan testata yksiköillä jne.

Yhteenvetona voidaan siis erottaa huolenaiheet riippuen roolistasi tai näkökulmastasi, kuten muualla mainittiin.

Kommentit

• tämä ei ’ näytä tarjoavan mitään merkittävää aikaisemmin esitettyjen ja selitettyjen kohtien yli 7 vastausta
• Korostan vain, että huolenaiheiden erottaminen voi tapahtua eri tavoin kontekstista riippuen. Tämä on lähempänä todellista tilannetta ohjelmistotekniikan tiimeissä, ja korostan, että html-sivuilla työskennellessäsi on erilaisia lähestymistapoja, jotka saattavat aluksi tuntua ristiriitaisilta.