Millal Drupal vajab refaktoreerimist, mitte ainult uuendust?

🎧 Kuula kõiki artikleid järjest

Drupal-i uuendamine parandab turvalisust ja pikendab platvormi eluiga, kuid see ei lahenda automaatselt halvasti kujundatud andmemudeleid, keerulist custom-koodi ega ebaefektiivseid töövooge.

Paljud organisatsioonid jõuavad olukorda, kus Drupal-sait on tehniliselt küll töökorras, kuid iga järgmine arendus muutub ebaproportsionaalselt keeruliseks. Sellisel juhul ei pruugi probleem olla Drupal-i versioonis, vaid süsteemi ülesehituses.

Refaktoreerimine tähendab olemasoleva lahenduse sisemise struktuuri parandamist nii, et kasutaja jaoks jääb funktsionaalsus üldiselt samaks, kuid süsteem muutub lihtsamini hallatavaks, arendatavaks ja testitavaks.

Uuendus ja refaktoreerimine ei ole sama asi

Drupal-i versiooniuuendus viib platvormi uuemale tehnoloogilisele alusele.

Näiteks:

• Drupal 9 → Drupal 10;
• Drupal 10 → Drupal 11.

Selle käigus uuendatakse Drupal Core'i, mooduleid, sõltuvusi ja vajadusel PHP versiooni.

Refaktoreerimine keskendub aga süsteemi sisemisele kvaliteedile:

• andmemudelile;
• custom-koodile;
• integratsioonidele;
• töövoogudele;
• arhitektuurilistele otsustele.

Sageli tehakse neid tegevusi paralleelselt. Uuele Drupal-versioonile üleminek võib olla hea hetk ka vanade tehniliste probleemide lahendamiseks.

Märgid, et refaktoreerimine on vajalik

Iga muudatus tekitab uusi probleeme

Kui näiliselt lihtsad muudatused põhjustavad ootamatuid kõrvalmõjusid, on see tavaliselt märk liiga tihedalt seotud süsteemist.

Näiteks:

• vormimuudatus lõhub teise funktsionaalsuse;
• turvauuendus põhjustab veateateid;
• uue välja lisamine mõjutab olemasolevaid vaateid;
• väike muudatus nõuab suure hulga failide muutmist.

Selline olukord muudab arenduse aeglaseks ja riskantseks.

Custom-kood on raskesti mõistetav

Aastate jooksul kogunenud custom-kood võib muutuda keeruliseks isegi algsetele arendajatele.

Hoiatusmärgid on näiteks:

• väga pikad klassid või failid;
• sama loogika kordumine mitmes kohas;
• dokumentatsiooni puudumine;
• äriloogika segunemine kujundus- või andmekihiga;
• raskesti jälgitavad sõltuvused.

Kui arendajad kardavad olemasolevat koodi muuta, on refaktoreerimine tavaliselt põhjendatud.

Sisutüübid ja väljad on dubleerunud

Paljud Drupal-saidid kasvavad järk-järgult.

Aastate jooksul võivad tekkida:

• mitu peaaegu identset sisutüüpi;
• dubleerivad väljad;
• erinevad lahendused sama probleemi jaoks;
• segased sisuhaldusprotsessid.

Tulemus on olukord, kus toimetajad ei ole enam kindlad, millist sisutüüpi või välja kasutada.

See on sageli märk, et andmemudel vajab korrastamist.

Toimetajad kasutavad süsteemist möödahiilimist

Kui kasutajad on loonud oma töövõtted süsteemi piirangute ületamiseks, viitab see sageli halvasti sobivale andmemudelile.

Näiteks:

• märkuste välju kasutatakse tegelikult kategooriatena;
• HTML-i kirjutatakse sinna, kus peaks olema eraldi väli;
• infot dubleeritakse käsitsi mitmes kohas;
• sisu kopeeritakse ühest kirjest teise.

Kui süsteem sunnib kasutajaid pidevalt ümbernurga lahendusi kasutama, ei vasta arhitektuur enam tegelikele vajadustele.

Testimine toimub ainult käsitsi

Kaasaegne Drupal-arendus eeldab vähemalt mingil tasemel automatiseeritud testimist.

Kui iga muudatus kontrollitakse ainult käsitsi:

• suureneb vigade oht;
• väljalasked aeglustuvad;
• arenduskulud kasvavad;
• kvaliteet sõltub üksikute inimeste teadmistest.

Refaktoreerimine loob sageli võimaluse lisada automaatteste ja muuta arendusprotsess usaldusväärsemaks.

Süsteemi mõistab ainult üks inimene

Üks kõige olulisemaid riske on teadmiste koondumine ühe inimese kätte.

Kui ainult üks arendaja:

• teab süsteemi arhitektuuri;
• oskab parandada vigu;
• mõistab integratsioone;
• julgeb muudatusi teha,

siis on organisatsioon tehniliselt haavatavas olukorras.

Hästi refaktoreeritud süsteem peaks olema arusaadav ka uuele arendajale.

Mida refaktoreerimine tavaliselt hõlmab?

Refaktoreerimise ulatus sõltub probleemidest, kuid enamasti sisaldab see järgmisi tegevusi.

Andmemudeli korrastamine

• sisutüüpide ühendamine;
• dubleerivate väljade eemaldamine;
• sisustruktuuri lihtsustamine;
• taksonoomiate korrastamine.

Koodi arhitektuuri parandamine

• äriloogika eraldamine esitlusloogikast;
• teenusepõhise arhitektuuri kasutamine;
• sõltuvuste vähendamine;
• korduva koodi eemaldamine.

Testide lisamine

Enne suuremaid muudatusi tasub luua kaitsevõrk.

See võib sisaldada:

• automaatteste;
• integratsiooniteste;
• regressiooniteste.

Dokumentatsiooni loomine

Dokumentatsioon aitab vähendada sõltuvust konkreetsetest arendajatest ning lihtsustab tulevasi muudatusi.

Millal refaktoreerimine ei ole mõistlik?

Refaktoreerimine ei ole alati õige lahendus.

Mõnikord on süsteem nii tugevalt aegunud või keeruliseks muutunud, et selle parandamine maksab rohkem kui uue lahenduse loomine.

Näiteks kui:

• arhitektuur on põhimõtteliselt vale;
• suur osa custom-koodist tuleb niikuinii ümber kirjutada;
• olemasolevad äriprotsessid on täielikult muutunud;
• tehniline võlg on kogunenud aastate jooksul kontrollimatult.

Sellisel juhul võib migratsioon või osaline ümberarendus olla majanduslikult mõistlikum valik.

Samuti ei ole refaktoreerimine eesmärk omaette. Koodi ei tasu ümber kirjutada ainult selleks, et see oleks „ilusam“. Refaktoreerimine peaks lahendama konkreetse ärilise või tehnilise probleemi.

Kuidas hinnata olukorda?

Väljastpoolt ei ole alati lihtne aru saada, kas probleem peitub Drupal-i versioonis või süsteemi arhitektuuris.

Seetõttu on mõistlik alustada tehnilisest auditist, mis aitab hinnata:

• koodi kvaliteeti;
• andmemudeli ülesehitust;
• moodulite ja integratsioonide seisukorda;
• tehnilise võla ulatust;
• võimalikke riske järgmiste uuenduste jaoks.

Tehniline audit aitab kaardistada probleemid prioriteetide järgi ning eristada, mis vajab refaktoreerimist ja mis vajab lihtsalt tavapärast uuendamist.

Kui kahtlustad, et sinu Drupal-sait on jõudnud keerukuse piirini, kus iga muudatus muutub ebaproportsionaalselt kalliks või riskantseks, siis võta ühendust ja vaatame olukorra koos üle.

WebPro Company OÜ Tehniline juht: Kaido Toomingas

Vajad Drupal abi?

Kui artikkel puudutab sinu olukorda, ei pea kõike lõpuni lugema. Sinuga suhtleb päris inimene ja aitab järgmise sammuni jõuda.

Võta ühendust