Jos sinulla on yritys, joka keskittyy sekä ratkaisujen kehittämiseen alusta alkaen että räätälöidyn ratkaisun toteuttamiseen jo olemassa olevien projektien yhteydessä (tai ehkä molemmissa), olet todennäköisesti – jossain vaiheessa – Perinyt WordPress-projekteja.
Projekteihin vastaaminen kummastakin kahvasta tuo mukanaan haasteita – useimmat niistä ovat tervetulleita – mutta näyttää olevan paljon yleisempi paikka, jossa ihmiset valittavat työskentelystä olemassa olevan koodikannan kanssa.
Kyse ei ole siitä, ettenkö ymmärtäisi sitä tunnetta, mutta mielestäni sen tekemisessä on jonkin verran kypsymättömyyttä. Toisaalta, kyllä, jotkut koodikannat ovat aivan kauheita. Mutta sitten jotkut koodikannat eivät ole niin huonoja. Itse asiassa väittäisin, että ne ovat vain hieman erilaisia kuin sinä kehität sen.
Tämä on tapaus, jossa standardit tulevat peliin, mutta poikkean tästä nyt.
Oletetaan siis, että perit WordPress-projekteja etkä ole erityisen innostunut koodikannasta, jonka kanssa työskentelet. Miten on mahdollista, että voit silti nauttia tekemästäsi työstä ilman, että sinun tarvitsee kritisoida kaikkia näkökohtia siitä, minkä kanssa olet tekemisissä?
WordPress-projektien periminen
Ensinnäkin tämä muiden ihmisten työstä valittaminen on sitä sananlaskua, jossa en halua tallata.
- En tiedä taustaa, joka johtaa siihen, että koodikanta on tilassaan,
- En tiedä miksi tietyt asiat on kehitetty sellaisina kuin ne olivat (aikarajoitukset, projektin tuntemattomuus jne.),
- Minun tehtäväni on tehdä jotain projektin puitteissa, joten miksi viettää aikaa keskittyen asioihin, jotka eivät kuulu minun vastuulleni?
Ymmärrän sen: On aikoja, jolloin kirjoittamamme koodin on kommunikoitava jo olemassa olevan koodin kanssa. Ja se voi olla vaikeaa. On suunnittelumalleja, jotka eivät ole erityisesti tätä tilannetta varten.
Mutta sen peittämisen sijaan ajattelin jakaa kolme asiaa, jotka mielestäni osoittavat kypsyyttä kehityksessä, kun perimme WordPress-projekteja, jotka voivat ärsyttää meitä.
1 Älä refaktoroi kaikkea
Kuten Martin Fowler totesi:
Bob-setä viittaa tähän opportunistiseen uudelleenjärjestelyyn partiopoikasäännön noudattamisena – jätä koodi aina paremmassa tilassa kuin sen löysit.
Yleisesti ottaen pidän tästä säännöstä, mutta projektin vaatimuksista riippuen tämä voi olla vastuumme ulkopuolella.
Joten aina kun törmäämme johonkin, jonka tiedämme tarvitsevan uudelleenkäsittelyä, mutta projekti etenee sujuvasti. Jos teet yhden muutoksen johonkin, koska luulet, että se on tehtävä, et tiedä, kuinka tämä ketjuttaa koko projektin.
Jos sinulla on aikaa tehdä täydellinen koodin tarkastus, se on yksi asia, mutta jos ei, sinun tehtäväsi on esitellä, mitä olet suostunut tekemään.
2 Keskity siihen, mitä olet suostunut tekemään
Ja se johtaa tähän pisteeseen: Kun perit WordPress-projekteja, sinun on tehtävä tietty määrä työtä etkä mitään muuta (siksi meillä on työselostus, eikö niin?).
Joten vaikka kuinka paljon haluat muuttaa ympäristöä, jossa olet, älä tee sitä. Keskity siihen, mitä voit tehdä, mitä vain sinä voit tehdä ja mitä olet suostunut tekemään.
Minusta on hyvä tehdä muistiinpanoja ongelmista, ja uskon, että tästä voi olla jopa hyötyä (ja puhun tästä hetken), mutta älä menetä keskittymistä siihen, mitä olet sopinut tekemään. Tekee kaikkea muuta kuin epäammattimaista.
3 Älä tuomitse edellistä kehittäjää
Toinen yleinen asia – varsinkin avoimessa lähdekoodissa – on arvioida kehittäjä, joka kirjoitti alkuperäisen koodisarjan, jota käytät.
Mikä tämä on? En koskaan kirjoittaisi noin.
Tarkoitan, kuinka monta kertaa olemme ajatellut sitä itseksemme? Emme kuitenkaan tiedä aikaa, rajoituksia, kokemusta tai kontekstia, jossa kehittäjä työskenteli.
Julkaisemme koodi ei välttämättä edusta taitotasoamme. Sen sanelevat usein kolmannen osapuolen muuttujat, joilla on vaikutusta tapaan, jolla toteutamme ratkaisun.
Ja me tiedämme millaista se on, eikö niin? Kuinka monta kertaa olemme halunneet tehdä jotain yhdellä tavalla, mutta rajoitukset ja aikataulu, jossa työskentelemme, sanelevat, mitä teemme?
Joten miksi odotamme näiden kehittäjien olevan erilaisia?
Valinnainen: Tarjoa tulevaa tukea
Kuten aiemmin mainittiin, jos törmäät koodikannan alueisiin, jotka ovat ongelmallisia, se ei tarkoita, että se olisi menetetty syy.
Sen sijaan, kun kohtaat tämän tyyppisiä ongelmia, mielestäni on hyvä idea:
- tee muistiinpanoja näkemistäsi asioista,
- huomauta, mitä tekisit korjataksesi sen ja miksi,
- keskustele asiakkaan kanssa näkemästäsi ja sen päivittämisen eduista.
Tämä tietysti johtaa tulevaan työhön, mutta ehkä sen lisäksi voit tarjota ratkaisuja parempien, paremmin suunniteltujen ohjelmistojen luomiseen ja sen avulla voit varmistaa, että teet internetistä paremman paikan niin suositulle sisällönhallintajärjestelmälle.
Ei, tätä työtä ei koskaan taata, mutta se on hyödyllistä.
Olen varma, että siellä on enemmän
Nämä ovat vain kolme vinkkiä, joita tarjoan perustuen kokemukseni, joka minulla on WordPress-projektien perimisestä. Sen ei ole tarkoitus olla kaiken kattava.
Sen sijaan se on tarkoitettu antamaan muutamia vinkkejä, joiden avulla voit olla huomioivampi toisten ihmisten työssä suhteessa omaan työhön, pohtia selkeämmin, mitä voit tehdä samankaltaisissa tilanteissa ja saada lisää työtä parantamalla olemassa olevaa ratkaisu mahdollisesti.
Mutta tiedän, että mainitsemani asiat ovat vain muutamia havaintojani. Onko sinulla omasi? Mainitse ne kommenteissa.