Objektorienteeritud programmeerimine WordPressis: analüüs, 1. osa
Kui ma esimest korda sellel saidil liikmelisust pakkuma hakkasin, teadsin, et esimene asi, millega tahan tegeleda, oli tutvustus objektorienteeritud programmeerimisega.
See tundub olevat huvitav enamikule WordPressis töötavatest inimestest, kuid ilmneb probleem, mis kas tõrjub palju inimesi eemale või annab kehvad tulemused:
Objektorienteeritud programmeerimine võib kiiresti keeruliseks muutuda. Ja see muutub demotiveerivaks.
Pean silmas järgmist. Oletame, et olete WordPressi arendaja, kes hakkab uurima objektorienteeritud programmeerimist. See hakkab rääkima klassidest, konstruktoritest ja funktsioonidest ning kõik tundub hästi.
Kuid siis läheb see kiiresti:
- privaatsed ja kaitstud meetodid,
- pärand,
- polümorfism,
- disaini mustrid,
- sõltuvussüst,
- hoidlad,
- ja nii edasi.
Lumepalle sajab, kas pole? Ja see ei pea sugugi nii olema, kuid korralikku sissejuhatust on raske leida, välja arvatud mõned olemasolevad vahendid.
Kõike seda silmas pidades (ja olles taustaks sellele, kuhu ma suundun) tahtsin luua sisuseeria neile, kes:
- olete tõeliselt huvitatud objektorienteeritud programmeerimisest,
- pole kindel, kust alustada,
- soovivad oma oskusi arendada,
- tahan alustada nullist, ilma et see liiga kiiresti keerulisemaks materjaliks muutuks.
Ja sellega ma täna alustan ja esimeses tõsises plaanis liikmetele. Kui kõik see öeldud, alustame.
Täpsemalt, hakkame rääkima objektorienteeritud programmeerimisest, analüüsist, disainist ja sellest, miks ta peaks sellest alustama.
Objektorienteeritud programmeerimine: analüüs
Koodi kirjutamisel on praegu kolm populaarset viisi:
Kui töötame WordPressi koodiga ja seda loeme, loete protseduurikoodi ja objektorienteeritud koodi kombinatsiooni.
Sellel on mõned põhjused, kuid see jääb meie arutelust välja.
Selle põhjuseks on asjaolu, et WordPress on üles ehitatud mõlemaga ja WordPressi arenduse teatud aspekte saab kirjutada protseduurilise koodiga, nagu pistikprogrammid ja teemad, ning teised nõuavad objektorienteeritud arendust, nagu vidinad.
Analüüs ja disain
Nii sageli on esimene asi, mida me arendajatena teha tahame (nooruvad või mitte), hakata kohe koodi kirjutama. Ma saan ka. See on lõbus. Meil on idee, me tahame selle ellu viia, tahame seda kasutama hakata ja tahame seda teistele inimestele näidata.
Siin on aga selle tegemise probleem: me jätame sageli koodi kirjutamise vahele, et proovida panna projekti tegema seda, mida me tahame.
Kui see on lihtne (ja ma mõtlen väga lihtsat) projekt, siis pole see nii suur asi. Ausalt öeldes olen seda teinud (ja GitHub on selle tõestuseks). Aga mis puudutab tööd, mida me Pressware’is teeme ; see on hoopis teine lugu.
Selliste projektide puhul tahame enne koodi kirjutamist natuke analüüsi ja disaini teha.
Mis tõstatab küsimuse, mis on objektorienteeritud analüüs ja disain?
Analüüs
Lühidalt, mõelge sellele järgmiselt:
Analüüs on protsess, mille käigus võetakse ette idee, mis on kliendil või mis teil on, ja uuritakse välja, mis on tegelikult vaja ehitada.
See aitab teil kindlaks teha, mis on rakenduse varjatud ja mis pole rakenduse esimese versiooni jaoks vajalik. Mulle meeldib neid sildistada niipalju kui need, mis on kohustuslikud ja millised on need, mis on meeldivad.
Hea rusikareegel on järgmine:
- must have on asjad, mis on rakenduse keskmes ja peavad minema projekti esimesse iteratsiooni,
- kenad on asjad, mida saame lõpuks sellesse sisse ehitada
Lõppkokkuvõttes aitab see meil töötada kliendi jaoks tugeva esimese versiooni poole. Võib-olla on üks näide WordPressi jaoks:
- Kas WordPressi esimesel versioonil pidi olema pistikprogrammi API või pidi inimestel olema lihtsalt võimalus postitusi kirjutada ja neid veebis avaldada?
Kui loote ajaveebi platvormi, kas see peab olema esimesest versioonist alates laiendatav? See pole midagi muud kui näide, kuid saate aru.
Mis teeb analüüsi nii raskeks?
Ma arvan, et see on sageli seotud isikutega.
Näiteks meie kui programmeerijad arvame, et projekt peaks alati tegema seda, mida klient soovib. Tõde on see, et see pole alati nii.
Ma mõtlen, et lõpuks võib see nii olla, kuid projekti esimene versioon ei pea tingimata nii olema.
Lisaks on üks objektorienteeritud programmeerimise põhimõtetest, et me ei kirjuta palju dubleerivat koodi. Kuid seda võib olla väga raske teha, kui pole korralikult analüüsi tehtud.
Lõpuks ütlevad kogenumad, et hea tarkvara kasutab läbiproovitud ja tõelisi põhimõtteid – olgu see siis disainimustrid või mitte –, kuid seda saab aja jooksul hõlpsasti muuta. See kasvab teatud mõttes orgaaniliselt.
Mida me siis tegema peame?
Järgmises artiklis räägin kolmest asjast, mida saame arendajatena teha tagamaks, et tarkvara, mida me endale või teistele ehitame, viiks meid õiges suunas.
Ma ei ütle, et see on hõbekuul, sest ma ei usu, et see on olemas, aga ma ütlen, et see on üsna tugev lähenemine, mida olen leidnud, et teised ja enda jaoks sobivad ning mis viib päris heasse suunda. objektorienteeritud analüüsi osas.
See viib meid lõpuks disainini. Aga me pole veel kohal.