Kuidas hinnata Drupal-arendaja kompetentsi
🎧 Kuula kõiki artikleid järjest
Kui palkad Drupal-arendajat või vahetad hoolduspartnerit, ära küsi ainult portfooliot. Küsi, kuidas ta hoiab süsteemi uuendatava, testitava ja järgmisele arendajale arusaadavana.
- aastal ei piisa Drupal-arendaja hindamisel teadmisest, et ta on "Drupalit teinud".
Drupal on piisavalt lai platvorm, et sama nimetuse alla mahub väga erinevaid töid:
- sisutüüpide ja vaadete seadistamine;
- kohandatud moodulite arendus;
- migratsioonid;
- jõudluse parandamine;
- turvauuendused;
- ligipääsetavus;
- integratsioonid väliste süsteemidega.
Hea arendaja ei pea olema kõigis valdkondades võrdselt tugev. Küll aga peab ta oskama realistlikult hinnata, milles ta on tugev, kus vajab tuge ja kuidas töö käigus riske kontrolli all hoida.
Alusta sellest, millist kompetentsi tegelikult vajad
Drupal-arendaja kompetentsi ei saa hinnata ilma kontekstita.
Väike sisulehe muudatus ja mitmekeelse portaali migratsioon ei vaja sama profiiliga arendajat. Enne hindamist pane kirja, kas vajad eelkõige:
- hooldust ja turvauuendusi;
- uue funktsionaalsuse arendust;
- kohandatud moodulite arendust;
- Drupali versiooniuuendust või migratsiooni;
- e-poe või makselahenduse arendust;
- jõudluse ja vahemälu analüüsi;
- WCAG nõuete ja ligipääsetavuse tuge;
- projekti ülevõtmist teiselt arendajalt.
Kui vajadus ei ole veel selge, eelista arendajat, kes alustab olukorra kaardistamisest, mitte kohe hinnapakkumisest. Keerukama olemasoleva saidi puhul on sageli mõistlik alustada tehnilisest auditist, mitte suurest arendustellimusest.
Pädev arendaja küsib ebamugavalt täpseid küsimusi
Hea märk ei ole see, et arendaja lubab kõik kiiresti ära teha.
Parem märk on see, kui ta küsib enne töö alustamist:
- milline Drupali versioon on kasutusel;
- kas projekt kasutab Composerit;
- kus asub Git-repositoorium;
- kas konfiguratsioon on eksporditud koodi;
- kas olemas on testkeskkond;
- kuidas toimub juurutamine;
- kas on teada mittetoimivaid integratsioone;
- kes saab teha otsuseid sisu, disaini ja kasutajaõiguste kohta.
Need küsimused näitavad, et arendaja hindab süsteemi seisukorda tervikuna. Kui vastuseid ei ole, peaks järgmine samm olema tehniline ülevaatus, mitte pimesi arendamise alustamine.
Vaata, kuidas ta riskidest räägib
Nõrk vastus kõlab tavaliselt nii:
> "See on lihtne, teeme ära."
Tugevam vastus kirjeldab tingimusi:
> "Kui testkeskkond vastab tootmiskeskkonnale ja vajalikud ligipääsud on olemas, on see väike muudatus. Kui konfiguratsioon asub ainult andmebaasis, peame enne kontrollima, mida juurutamine võib üle kirjutada."
Drupali arenduses võivad riskid peituda kohtades, mida esmapilgul ei märka:
- kogukonna moodul võib olla hooldamata;
- kohandatud kood võib kasutada aegunud API-sid;
- vahemälu võib peita vea kuni järgmise tühjendamiseni;
- kasutajaõiguste muudatus võib teha sisu kättesaadavaks valele rollile;
- otse andmebaasis tehtud seadistus võib järgmise juurutamise käigus kaduda.
Kompetentne arendaja ei dramatiseeri neid riske, kuid oskab need välja tuua ja selgitada, kuidas neid maandada.
Töö peab olema jälgitav
Töö jälgitavus tähendab, et tagantjärele on võimalik aru saada:
- mida muudeti;
- millal muudeti;
- kes muudatuse tegi;
- miks muudatus tehti.
Hea märk on see, kui arendaja kasutab:
- Git-versioonihaldust;
- tööülesannete haldamise süsteemi;
- lühikesi ja arusaadavaid commit-sõnumeid;
- dokumenteeritud juurutamisprotsessi;
- vajaduse korral pull request'e ja koodiarvustust.
Kui kogu töö toimub ainult tootmisserveris ja muudatuste ajalugu puudub, ei ole probleem üksnes töökorralduses. Hiljem on keeruline kindlaks teha, mida muudeti, miks seda tehti ja kuidas vajaduse korral varasem seis taastada.
Composer ja konfiguratsioonihaldus ei ole luksus
Kaasaegne Drupal-projekt peaks kasutama Composerit sõltuvuste haldamiseks ning Giti koodimuudatuste jälgimiseks.
Composer aitab hallata:
- Drupal core'i;
- mooduleid;
- PHP teeke;
- versioonipiiranguid ja sõltuvusi.
Drupali konfiguratsioon peaks olema vähemalt eksporditav ja süsteemselt hallatav. Kui saidi oluline loogika asub ainult tootmiskeskkonna andmebaasis, muutuvad partnerivahetus ja turvaline juurutamine märksa keerulisemaks.
Kui mooduleid laaditakse serverisse käsitsi FTP kaudu, on see ohumärk. Selline tööviis muudab uuendamise, auditeerimise ja varasema versiooni taastamise ebakindlamaks.
Testkeskkond peab olema tööprotsessi osa
Iga olulisem muudatus peaks enne avalikku veebi jõudmist läbima testkeskkonna.
See kehtib eriti:
- turvauuenduste;
- mooduliuuenduste;
- vormide;
- integratsioonide;
- makselahenduste;
- kasutajarollide ja -õiguste muudatuste kohta.
Kui arendaja teeb muudatusi otse avalikus veebis, suureneb oht, et kasutajad puutuvad kokku katkise või valesti toimiva funktsionaalsusega.
Küsi:
- kas projektil on testkeskkond;
- kuidas muudatused sinna jõuavad;
- kes kontrollib muudatused enne avaldamist üle;
- kuidas taastatakse vajaduse korral varasem töötav versioon.
Keerukama projekti puhul tasub küsida ka automaattestide kohta. Kõiki vaateid ja funktsioone ei pea automaattestidega katma, kuid kriitilised kasutajateekonnad peaksid olema kontrollitavad. Nende hulka võivad kuuluda vormid, ostukorv, sisselogimine, maksmine, kasutajaõigused ja olulised integratsioonid. WebPro kasutab selleks muu hulgas automaattestimist.
Turvauuendused ei tohiks sõltuda kliendi meeldetuletusest
Hea Drupal-arendaja jälgib turvateateid ja rakendab vajalikud uuendused kokkulepitud protsessi alusel.
Küsi:
- millal tehti viimati turvauuendusi;
- kas uuendusi testitakse enne tootmiskeskkonda paigaldamist;
- kes otsustab, millal kriitiline uuendus paigaldatakse;
- kuidas klienti vajalikest uuendustest ja tehtud töödest teavitatakse.
Kui turvauuendusi tehakse ainult siis, kui klient neid eraldi küsib, ei ole tegemist süsteemse hooldusega.
Drupali turvateadete ametlik allikas on Drupal.org security advisories (avaneb uues aknas). Arendaja ei pea kliendile iga teadet eraldi vahendama, kuid ta peab oskama selgitada, kuidas turvateateid jälgitakse ja kuidas kriitilised uuendused tootmiskeskkonda jõuavad.
Kood peab olema teisele arendajale üleantav
Hea arendaja ei loo olukorda, kus ainult tema suudab süsteemi hallata.
Üleantav projekt tähendab, et olemas on vähemalt:
- lähtekood;
- Giti ajalugu;
- Composeri failid;
- vajalikud ligipääsud;
- dokumentatsioon;
- teave oluliste integratsioonide kohta.
Kui partnerivahetus tundub võimatu või ebamõistlikult kallis, võib süsteem olla liiga tugevalt seotud ühe inimese või teenusepakkujaga.
Portfoolio on kasulik, kuid sellest üksi ei piisa
Portfoolio näitab, millistes projektides arendaja on osalenud. See ei näita tingimata, milline oli tema tegelik vastutus.
Küsi mõne varasema projekti kohta täpsemalt:
- mille eest arendaja vastutas;
- milline oli kõige keerulisem tehniline otsus;
- kuidas korraldati juurutamine;
- kuidas lahendust testiti;
- mida teeks ta sama projekti puhul täna teisiti.
Vastus "tegin kogu Drupali" ei ütle kuigi palju. Sisukam vastus kirjeldab konkreetseid probleeme, tehtud kompromisse, valikute põhjuseid ja projektist saadud õppetunde.
Punased lipud
Mõned märgid võivad viidata sellele, et arendusprotsess ei ole piisavalt küps.
"Kõik on korras, pole vaja muretseda"
Ilma konkreetsete andmeteta ei ütle selline kinnitus kuigi palju.
Küsi:
- milline Drupali versioon töötab;
- millal süsteemi viimati uuendati;
- millised moodulid on kriitilised;
- kas kasutatav PHP versioon on endiselt toetatud.
Muudatused tehakse otse andmebaasis
Drupali konfiguratsioon peab olema hallatav ja vajaduse korral eksporditav.
Kui konfiguratsioonimuudatused jäävad ainult andmebaasi, võib järgmine juurutamine need üle kirjutada. Samuti muutub keerulisemaks arusaamine sellest, milline konfiguratsioon on tegelikult õige ja millised muudatused on eri keskkondades tehtud.
Auditit välditakse
Hea partner ei peaks sõltumatut tehnilist auditit kartma.
Audit ei ole süüdistus. See on viis kontrollida, kas süsteem on turvaline, hooldatav ja uuendatav ning millised tehnilised riskid vajavad tähelepanu.
Iga kuu on kriis
Kui peaaegu iga muudatus muutub kiireloomuliseks parandustööks, on probleem tõenäoliselt protsessis, mitte ainult üksikutes vigades.
Kvaliteetne arendusprotsess vähendab kriiside tõenäosust, mitte ei tekita neid regulaarselt juurde.
Praktiline kontrollnimekiri
Küsi arendajalt või arenduspartnerilt:
- Milline Drupali versioon on kasutusel?
- Millal lõpeb selle versiooni ametlik tugi?
- Kuidas tehakse turvauuendusi?
- Kas projekt kasutab Composerit?
- Kus asub Git-repositoorium?
- Kas kliendil on ligipääs lähtekoodile ja repositooriumile?
- Kas projektil on testkeskkond?
- Kas kasutatakse automaatteste?
- Kuidas tehakse varukoopiaid ja kuidas kontrollitakse nende taastatavust?
- Mis juhtub projekti ja ligipääsudega, kui koostöö lõpeb?
- Millised moodulid on projekti jaoks kriitilised?
- Kuidas dokumenteeritakse kohandatud loogikat?
Kui nendele küsimustele ei ole võimalik saada selgeid vastuseid, tasub projekti tehnilist seisukorda põhjalikumalt uurida.
Millal tellida sõltumatu audit?
Sõltumatu audit on mõistlik, kui:
- plaanid arenduspartnerit vahetada;
- saiti ei ole mitu aastat süsteemselt hooldatud;
- uuendused muutuvad järjest keerukamaks ja kallimaks;
- puudub ülevaade süsteemi tehnilisest seisukorrast;
- partneri vastused tehnilistele küsimustele jäävad ebamääraseks.
Audit võib anda ülevaate:
- turvauuenduste seisust;
- moodulite versioonidest ja hooldatavusest;
- kohandatud koodi kvaliteedist;
- jõudlusprobleemidest;
- ligipääsetavusega seotud riskidest;
- süsteemi üldisest hooldatavusest.
Kokkuvõte
Hea Drupal-arendaja teeb enamat kui kasutajale nähtava veebilehe.
Ta jätab endast maha süsteemi, mis on:
- jälgitav;
- testitav;
- uuendatav;
- dokumenteeritud;
- vajaduse korral teisele arendajale üleantav.
Klient ei pruugi tehnilist kvaliteeti otseselt näha, kuid seda saab hinnata arendusprotsessi kaudu. Git, Composer, testkeskkond, süsteemne turvauuenduste protsess, automaattestid ja selge üleandmine näitavad, et arendaja mõtleb lisaks tänase ülesande lahendamisele ka veebiplatvormi pikaajalisele elueale.
Kui soovid teada, millises seisus olemasolev Drupal-sait tegelikult on, aitab tehniline audit saada enne suuremate otsuste tegemist sõltumatu ülevaate.
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.