Tämän sarjan ensimmäisessä viestissä puhuin kaikesta siitä, kuinka halusin käsitellä johdatusta olio-ohjelmointiin WordPressin yhteydessä.
Olio-ohjelmointiin on hienoja resursseja, mutta ne voivat käyttää keksittyjä esimerkkejä tai ne voivat liikkua liian nopeasti niille, jotka vain haluavat aloittaa.
Jotta näin ei tapahdu, uskon, että OOP:sta puhuminen WordPressissä ankkuroi meidät vahvalle pohjalle ja käytännön esimerkkien käyttäminen on aina parempi vaihtoehto kuin yleisten esimerkkien käyttäminen, jota on vaikea kääntää toimialueelle, jossa työskentelemme.
Niille, jotka eivät ole vielä liittyneet tai jotka eivät ole vielä liittyneet, ensimmäinen viesti osuu seuraaviin aiheisiin:
- Olio-analyysi,
- Pakollisten kohteiden ja mukavien hankintojen määrittäminen,
- Ja miksi se on vaikeaa?
Ja sieltä tämä postaus tulee.
Olio-ohjelmointi: Lisää analyysia
Tiedän: Mitä tulee koodin kirjoittamiseen, ensimmäinen asia, jonka haluamme tehdä, on istua alas ja alkaa kirjoittaa koodia. Mikä sen parempaa kuin saada jotain tapahtumaan ruudulla?
Ja kun teet tämän itsellesi, se ei ole niin iso juttu, mutta kun kirjoitat koodia, se on:
- jota ylläpitää joukko ihmisiä,
- Myytävänä,
- tai kaikki edellä mainitut
Se tekee eron. Koska hyvä analyysi voi johtaa hyvään organisointiin, joka voi johtaa hyvään ylläpidettävyyteen.
Muuten mukulat jotain lähetettäväksi, eikä se skaalaudu hyvin tulevien versioiden kanssa. Ja tämä on asia, josta puhumme syvällisesti koko sarjan ajan.
Mutta mikä on hyvä tapa tiivistää hyvän analyysin tekeminen kolmessa helpossa vaiheessa? Tämä ei välttämättä ole luodinkestävä vastaus, mutta sitä yritämme tehdä aina, kun työskentelemme projekteissa:
- Varmista, että koodi tekee mitä asiakas haluaa,
- Käytä hyviä oliokeskeisiä käytäntöjä,
- Tavoittele ylläpidettävä muotoilu.
Kaikki tämä kuulostaa teoriassa hyvältä, mutta ilman sukeltamista syvemmälle jokaiseen, mistä tiedämme, teemmekö tämän oikein? Toisin sanoen täältä löydämme usein kirjoja, resursseja ja muita apuohjelmia, jotka tekevät paremmaksi olio-ohjelmoijaksi tulemisen vaikeaksi.
Juuri tätä haluan välttää, joten aion kaivaa jokaiseen kohtaan hieman syvemmälle.
1 Mitä asiakas haluaa
Tämä voi olla yksi koko projektin haastavimmista kohdista, koska me kehittäjinä puhumme eri kieltä asiakkaan kanssa.
He eivät ainoastaan käytä usein terminologiaa, jota emme käyttäisi, vaan he usein ajattelevat, että se, mitä he haluavat näytöllä, on paras tapa toimia. Tämä kuulostaa todella alentuvalta ja väärältä yrittää korjata niitä, eikö niin?
Tarkoitan, että yrität kertoa jollekulle, jonka tiedät, mitä haluat, ja hän korjaa sinua. Tämän huolellinen käsittely voi saavuttaa suurta suhteellista tasapuolisuutta, mutta kestää jonkin aikaa "kaivaamaan", mitä he todella haluavat, verrattuna siihen, mitä he sanovat haluavansa.
Ja aiomme sukeltaa tähän enemmän tulevassa postauksessa.
2 Oliolähtöistä käytäntöä
Ilmeisesti tämä johtuu siitä, että tiedän, mitkä hyvät oliokäytännöt ovat, ja aion kattaa sen.
Monet ihmiset sanovat asioita käyttämällä esimerkiksi seuraavia asioita:
- SOLID-periaatteet,
- perintö,
- DRY koodi,
- riippuvuusruiske,
- ja niin edelleen
Ovat kaikki tärkeitä hyvien olio-käytäntöjen noudattamiselle.
Ja ehkä tämä ei ole suosittu sanonta, mutta olen sitä mieltä, että kaikkien asioiden jatkuva käyttäminen ei ole aina hyvä idea. Eli et todellakaan halua koodin toistuvan koko koodikannassasi, mutta onko sinulla oltava perintöä koodikannassasi?
Ei.
On aikoja, jolloin periaatteita tulee soveltaa ja jolloin ne voidaan jättää huomiotta. Mutta niiden tunteminen, milloin niitä käytetään parhaiten ja milloin niitä tulee käyttää, on avainasemassa mainittujen käytäntöjen oikean käytön kannalta.
3 Ylläpidettävä muotoilu
Yksinkertaisesti sanottuna, mallien ja periaatteiden soveltaminen ohjelmistoosi sitä kirjoitettaessa tekee siitä paljon helpompaa käyttää ja ylläpitää tulevaisuudessa.
Mutta jälleen kerran, tämä riippuu:
- ymmärtää täysin mitä asiakas haluaa,
- tietää, mitä käytäntöjä on olemassa, milloin niitä tulee soveltaa ja milloin niitä tulee välttää.
Ja tehdäksemme kaiken yllä olevan, meidän on tarkasteltava jokaista kohtaa sen kontekstissa ennen kuin otamme askeleen taaksepäin katsoaksemme isompaa kuvaa.
Mitä Asiakas haluaa?
On selvää, että edellä mainittujen kolmen kohdan osalta on paljon tehtävää. Mutta jos haluat kirjoittaa hyviä, ylläpidettäviä ohjelmistoja WordPress-taloudessa, on tärkeää ymmärtää, kuinka tämä kaikki sopii yhteen.
Joten sen sijaan, että hyppäämme eteenpäin koodin kirjoittamiseen tai projektin parissa työskentelemiseen, seuraavaksi tutkimme, kuinka ottaa asiakkaan haluama ja sitten tulkita se vaatimuksiksi, joiden avulla voimme luoda työselostus.
Tällä tavalla meillä on lopulta työasiakirja siitä, mitä asiakas haluaa ja mitä aiomme rakentaa, ja olemme kaikki samalla sivulla.