Kui juhite ettevõtet, mis keskendub nii lahenduste väljatöötamisele algusest peale kui ka kohandatud lahenduse rakendamisele juba olemasolevate projektide kontekstis (või võib-olla mõlemas), siis olete tõenäoliselt ühel hetkel WordPressi projektide pärimise olukorras.
Kummagi käepidemega projektidega tegelemine toob endaga kaasa oma väljakutsed – enamik neist on teretulnud –, kuid tundub, et see on palju tavalisem koht, kus inimesed kurdavad juba olemasoleva koodibaasiga töötamise üle.
Asi pole selles, et ma seda tunnet ei tunneks, aga ma arvan, et selle tegemisel on teatud määral ebaküpsus. Ühest küljest on jah, mõned koodibaasid on lausa kohutavad. Aga mõned koodibaasid polegi nii halvad. Tegelikult ma väidan, et need on veidi erinevad sellest, kuidas te seda arendaksite.
See on juhtum, kus mängu tulevad standardid, kuid praegu kaldun sellest kõrvale.
Oletame, et olete pärinud WordPressi projektid ja te ei ole eriti huvitatud koodibaasist, millega töötate. Kuidas on nii, et saate ikka veel nautida tööd, mida teete, ilma, et tunneksite, et peaksite kritiseerima kõiki selle aspekte, millega te tegelete?
WordPressi projektide pärimine
Esiteks on see arusaam teiste inimeste töö üle kaebamisest vanasõnavesi, milles mulle ei meeldi tallata.
- Ma ei tea tausta, mis viib koodibaasi olekusse,
- Ma ei tea, miks teatud asju arendati nii, nagu nad olid (ajapiirangud, projekti tundmise puudumine jne),
- Minu ülesandeks on projekti raames midagi ette võtta, nii et miks kulutada aega keskendudes asjadele, mis ei kuulu minu vastutusalasse?
Ma saan aru: on aegu, mil kirjutame koodi, mis peab suhtlema juba olemasoleva koodiga. Ja see võib olla raske. On disainimustreid, mis pole spetsiaalselt selle olukorra jaoks mõeldud.
Kuid selle katmise asemel mõtlesin, et jagan kolme asja, mis minu arvates näitavad WordPressi projektide pärimisel arendamise küpsust, mis võivad meid ärritada.
1 Ärge muutke kõike
Nagu Martin Fowler ütles:
Onu Bob viitab sellele oportunistlikule ümberkujundamisele kui skaudireegli järgimisele – jätke kood maha alati paremas olekus, kui selle leidsite.
Üldiselt mulle see reegel meeldib, kuid olenevalt projekti nõuetest võib see olla väljaspool meie kohustusi.
Nii et iga kord, kui puutume kokku millegagi, mille kohta teame, et see vajab ümberkujundamist, kuid projekt kulgeb sujuvalt. Kui teete milleski ühe muudatuse, sest arvate, et seda on vaja teha, ei tea te, kuidas see kogu projekti jooksul kaskaadi muutub.
Kui teil on aega koodi täielikuks auditeerimiseks, on see üks asi, aga kui mitte, siis on teie ülesanne tutvustada, mida olete kokku leppinud.
2 Keskenduge sellele, mida olete nõus tegema
Ja see viib selleni: WordPressi projektide pärimisel on teie ülesandeks teatud hulk tööd ja mitte midagi enamat (sellepärast on meil tööaruanne, eks?).
Nii et hoolimata sellest, kui palju soovite keskkonda, milles viibite, muuta, ärge seda tehke. Keskenduge sellele, mida saate teha, mida saate teha ainult teie ja mida olete kokku leppinud.
Ma arvan, et probleemide kohta märkmete tegemine on hea ja arvan, et sellest võib isegi kasu olla (ja ma räägin sellest kohe), kuid ärge kaotage keskendumist sellele, mida te tegema nõustusite. Teha kõike muud, kui see on ebaprofessionaalne.
3 Ärge mõistke kohut eelmise arendaja üle
Teine asi, mis on tavaline – eriti avatud lähtekoodiga puhul – on hinnata arendajat, kes kirjutas algse koodikogumi, millega te töötate.
Mis see on? Ma ei kirjutaks seda kunagi nii.
Ma mõtlen, mitu korda oleme seda endamisi mõelnud? Kuid me ei tea aega, piiranguid, kogemusi ega konteksti, milles arendaja töötas.
Välja antud kood ei pruugi tingimata meie oskuste taset esindada. Seda dikteerivad sageli kolmanda osapoole muutujad, mis mõjutavad lahenduse rakendamist.
Ja me teame, mis see on, eks? Kui palju kordi oleme tahtnud teha midagi ühel viisil, kuid piirangud ja ajakava, mille alusel töötame, määravad, mida me teeme?
Miks me siis eeldame, et need arendajad oleksid teistsugused?
Valikuline: pakkuge tulevast tuge
Nagu varem mainitud, ei tähenda see, et kui leiate koodibaasi probleemseid valdkondi, ei tähenda see, et see on kadunud.
Selle asemel, kui puutute kokku seda tüüpi probleemidega, on minu arvates hea mõte:
- märkige asju, mida olete näinud,
- märkige, mida teeksite selle parandamiseks ja miks,
- rääkige kliendiga sellest, mida olete näinud ja millised on selle värskendamise eelised.
See viib ilmselgelt edasise tööni, kuid võib-olla lisaks sellele võimaldab see pakkuda lahendusi parema ja paremini üles ehitatud tarkvara loomiseks ning võimaldab teil veenduda, et muudate Interneti nii populaarse CMS-i jaoks paremaks kohaks.
Ei, see töö ei ole kunagi garanteeritud, kuid see on kasulik.
Olen kindel, et seal on veel
Need on vaid kolm näpunäidet, mida ma WordPressi projektide pärimisel saadud kogemuste põhjal pakun. See ei ole mõeldud kõikehõlmavaks.
Selle asemel on selle eesmärk anda mõned näpunäited, mis võimaldavad teil oma tööga võrreldes teiste inimeste töö suhtes rohkem tähelepanelik olla, selgemalt mõelda, mida saate sarnastes olukordades ette võtta, ja koguda rohkem tööd, täiustades olemasolevat. lahendus potentsiaalselt.
Kuid ma tean, et asjad, mida ma mainisin, on vaid mõned minu tähelepanekud. Kas teil on oma? Mainige neid kommentaarides.