Olio-ohjelmointi WordPressissä: analyysi, osa 1

Kun aloin tarjota jäsenyyksiä tällä sivustolla, tiesin, että ensimmäinen asia, jonka halusin käsitellä, oli johdatus olio-ohjelmointiin.

Se näyttää kiinnostavan useimmille WordPressillä työskenteleville ihmisille, mutta ongelmana on, että se joko käännyttää monet ihmiset pois tai tuottaa huonoja tuloksia:

Olio-ohjelmointi voi monimutkaista nopeasti. Ja tämä demotivoi.

Tarkoitan seuraavaa: Oletetaan, että olet WordPress-kehittäjä, joka alkaa tutkia olio-ohjelmointia. Se alkaa puhua luokista, rakentajista ja funktioista, ja kaikki näyttää hyvältä.

Mutta sitten se menee nopeasti:

• yksityiset ja suojatut menetelmät,
• perintö,
• polymorfismi,
• suunnittelumalleja,
• riippuvuusruiske,
• arkistot,
• ja niin edelleen.

Lumipalloja, eikö niin? Eikä niin sen todellakaan tarvitse olla, mutta kunnollista esittelyä on vaikea löytää muutamaa resurssia lukuun ottamatta .

Kaiken tämän jälkeen (ja toimii taustana matkalleni), halusin luoda sarjan sisältöä niille, jotka:

• olet aidosti kiinnostunut olio-ohjelmoinnista,
• en ole varma mistä aloittaa,
• haluavat kehittää taitojaan,
• haluat aloittaa nollasta ilman, että se laajenee liian nopeasti monimutkaisempaan materiaaliin.

Ja siitä aloitan tänään ja ensimmäisessä jäsenille suunnatussa vakavassa suunnitelmassa. Kaiken tämän jälkeen aloitetaan.

Tarkemmin sanottuna, aloitetaan puhua olio-ohjelmoinnista, analysoinnista, suunnittelusta ja siitä, miksi hänen pitäisi aloittaa siitä.

Olio-ohjelmointi: Analyysi

Mitä tulee koodin kirjoittamiseen, tällä hetkellä on kolme suosittua tapaa tehdä se:

• toimiva ,
• menettelyllinen ,
• oliosuuntautunut.

Aina kun työskentelemme ja luemme WordPress-koodia, luet prosessikoodin ja oliokoodin yhdistelmää.

Tähän on joitakin syitä, mutta se ei kuulu keskustelumme piiriin.

Tämä johtuu siitä, että WordPress on rakennettu molemmilla ja koska tietyt WordPress-kehityksen osat voidaan kirjoittaa prosessikoodilla, kuten laajennukset ja teemat, ja toiset vaativat olio-kehitystä, kuten widgetejä.

Analyysi ja suunnittelu

Niin usein ensimmäinen asia, jonka haluamme tehdä kehittäjinä (aloittavina tai ei), on ryhtyä välittömästi koodin kirjoittamiseen. Minäkin saan. Se on hauskaa. Meillä on idea, haluamme herättää sen henkiin, haluamme alkaa käyttää sitä ja haluamme näyttää sen muille ihmisille.

Tässä on kuitenkin ongelma sen tekemisessä: Usein ohitamme koodin kirjoittamisen yrittääksemme saada projektin tekemään mitä haluamme sen tekevän.

Jos tämä on yksinkertainen (ja tarkoitan todella yksinkertaista) projektia, se ei ole niin iso juttu. Rehellisesti sanottuna olen tehnyt sen (ja GitHub on todiste siitä). Mutta mitä tulee Presswaren työhön ; se on eri tarina.

Kun kyse on tällaisista projekteista, haluamme tehdä hieman analyysiä ja suunnittelua ennen koodin kirjoittamista.

Mikä herättää kysymyksen, mitä on olioanalyysi ja suunnittelu?

Analyysi

Lyhyesti sanottuna, ajattele asiaa näin:

Analyysi on prosessi, jossa otetaan idea, joka asiakkaalla on tai sinulla on, ja kaivataan, mitä todella tarvitsee rakentaa.

Tämä voi auttaa sinua määrittämään, mikä on sovelluksen salaisuus ja mikä ei ole välttämätöntä sovelluksen ensimmäisessä versiossa. Tykkään merkitä nämä niin pitkälle kuin "pakolliset" ja mitkä ovat "kiva-to-have".

Hyvä nyrkkisääntö on tämä:

• must-have ovat asioita, jotka ovat sovelluksen ydin, ja niiden on mentävä projektin ensimmäiseen iteraatioon,
• mukavat tavarat ovat asioita, joita voimme lopulta rakentaa siihen

Viime kädessä tämä auttaa meitä työskentelemään kohti vahvaa ensimmäistä versiota asiakkaalle. Ehkä yksi esimerkki on WordPressille:

• Tarviiko WordPressin ensimmäisessä versiossa liitännäissovellusliittymä vai tarvittiinko siinä vain ihmisten mahdollisuus kirjoittaa viestejä ja julkaista niitä verkossa?

Jos olet rakentamassa alustaa bloggaamiseen, täytyykö sen olla laajennettavissa ensimmäisestä versiosta lähtien? Tämä ei ole muuta kuin esimerkki, mutta ymmärrätte idean.

Mikä tekee analyysistä niin vaikeaa?

Luulen, että se liittyy usein henkilöihin.

Esimerkiksi me ohjelmoijat ajattelemme, että projektin tulee aina tehdä mitä asiakas haluaa. Totuus on, että näin ei aina ole.

Tarkoitan, että se saattaa lopulta olla, mutta projektin ensimmäisen version ei välttämättä tarvitse olla sellainen.

Lisäksi yksi olio-ohjelmoinnin periaatteista on, että emme kirjoita paljon päällekkäistä koodia. Mutta se voi olla erittäin vaikeaa tehdä, jos analyysiä ei ole tehty kunnolla.

Lopuksi kokeneemmat sanovat, että hyvässä ohjelmistossa käytetään hyväksi todettuja ja oikeita periaatteita – olipa kyseessä suunnittelumalleja tai ei – mutta että sitä on helppo muuttaa ajan myötä. Se tietyssä mielessä kasvaa orgaanisesti.

Mitä meidän on tehtävä?

Seuraavassa artikkelissa aion puhua kolmesta asiasta, joita voimme tehdä kehittäjinä varmistaaksemme, että itsellemme tai muille rakentamamme ohjelmisto vie meidät oikeaan suuntaan.

En sano, että se on hopealuodi, koska en usko sen olevan olemassa, mutta sanon, että se on melko vahva lähestymistapa, jota olen löytänyt muiden käytettäväksi ja itselleni ja joka johtaa melko hyvään suuntaan. olio-analyysin kannalta.

Tämä vie meidät lopulta suunnitteluun. Mutta emme ole vielä siellä.