✅ WEB- ja WordPress -uutiset, -teemat, -laajennukset. Täällä jaamme vinkkejä ja parhaita verkkosivustoratkaisuja.

Projektin koko ja ”Keeping It Simple”

16

Jostain syystä on olemassa johdonmukainen jännite (ainakin minun mielestäni) jonkun jonkun rakentamisen hyödyllisyyden ja mainitun asian rakentamiseen kuluvan ajan välillä.

Tällä tarkoitan sitä, että mitä tulee WordPressiin, on suhteellisen helppoa rakentaa pieniä, yksinkertaisia ​​laajennuksia ja apuohjelmia muille, jotka eivät välttämättä noudata nykyajan parhaita käytäntöjä.

Ja mitä tulee tähän viestiin, sanoisin, että nykyaikaiset parhaat käytännöt ovat jotain tällaista:

  • palvelinpuolen paketinhallinta,
  • asiakaspuolen paketinhallinta,
  • asianmukainen yksikkötestaus,
  • hyvin suunnitellut tunnit,
  • dokumentoitu koodi,
  • ja niin edelleen.

Ja kaikki tämä on hienoa ja epäilemättä tarpeellista isommille projekteille (varsinkin koska ylläpito ja johdonmukainen kehitys tulevat olemaan niin merkittävässä roolissa).

Yksinkertaisena

Mutta entä pienemmät projektit, joissa olet enemmän tai vähemmän koodikannan ainoa ylläpitäjä? En väitä, etteikö hyviä käytäntöjä tulisi ottaa käyttöön. Mielestäni meidän pitäisi:

  • sinulla on hyvin dokumentoitu koodipohja,
  • toiminto- tai luokkasuunnittelu, joka palvelee tulevaa kehitystä,
  • sekä asiakas- että palvelinpuolen koodin optimointi

Mutta tarkoittaako tämä sitä, että näissä projekteissa on oltava suuria toimittajahakemistoja tai suuria node_modules -hakemistoja?

Kuva: Artur Pokusin Unsplashissa

Lyhyesti sanottuna, en usko. Luulen, että se liittyy ylisuunnitteluun.

Tee asioista mahdollisimman yksinkertaisia, mutta älä yksinkertaisempia.

Tämä ei tarkoita, että luopuisimme huolellisuudesta, jota tarvitaan laatukoodin kirjoittamiseen IDE-ympäristössämme.

Mahdolliset ohjeet

Mutta ehkä siihen se pysähtyy. Eli ehkä hyvä nyrkkisääntö on:

  • Jos projekti vaatii jatkuvaa integrointia, siinä tulee olla tarvittavat suojakaiteet laadun varmistamiseen sekä paikallisesti että lavastusympäristöissä ja jatkuvassa integraatioprosessissa.
  • Jos projekti rakennetaan ja sitten julkaistaan ​​(ja tehdään iteratiivisesti), suurin osa laadusta tulee mitata ja valvoa IDE:n kautta.

En tiedä, onko tämä paras tapa lähestyä sitä, mutta olen miettinyt sitä ja päädyn jatkuvasti edellä mainittuihin sananlaskuesteisiin.

Kirjoitan tällä hetkellä e-kirjaa (monenlaisen muun premium-sisällön ohella). Jos olet kiinnostunut, katso mitä saat.

Tämä verkkosivusto käyttää evästeitä parantaakseen käyttökokemustasi. Oletamme, että olet kunnossa, mutta voit halutessasi kieltäytyä. Hyväksyä Lisätietoja