Definiera en QA-process för nya plugins

[viktor-sarge]

Vi har diskuterat plugins med Erika och beslutat att tredjepartsplugins kan vara en god idé att använda när det gäller större generella funktioner där det är onödigt att uppfinna hjulet på nytt. Innan andras kod tas in i stacken i form av tredjepartsplugins så behöver de dock granskas och hur den granskningen skall göras behöver definieras.

Specialiserade funktioner och mindre omfattande behov kan ofta vara snabbare och lämpligare att lösa med egen kod.

På möte som Erika kallade till den 9 jan 19 ombads jag att ta kontakt med Sebastian i Helsingborg.

[viktor-sarge]

Jag tog kontakt med Sebastian Thulin vars arbete i Helsingborg har gott renommé. Mitt brev:

Jag jobbar i teamet i Region Halland som bygger vår nya Wordpress-baserade infrastruktur för webb och hör mycket gott om dig och det arbete som ert team gör. En sak som vi klurar på just nu är vilka krav vi skall ställa på tredjeparts WP-plugins som vi tar in. De som träffat er nämner att ni är ganska hårda med vad ni plockar in och nu är jag nyfiken på om ni har en färdig kravlista någonstans som jag kunde låna goda tankar av?

[viktor-sarge]

Sebastians svar:

Vad trevligt att det talas gott om oss och vårt arbete. Det stämmer att vi är ganska hårda med vilka plugin som vi tar in och vår review-process tar ungefär fyra timmar att göra på ett normaltstort plugin. Det finns egentligen inga riktlinjer, utan vi letar generellt dåliga tillämpningar och säkerhetshål. Om pluginet är välanvänt täpper vi till, eller rapporterar felet till utvecklaren så att vi eventuellt kan använda det i framtiden.

Vi tar gärna fram en QA mall / process i samråd med er som båda kan applicera i sin process. Några delar som vi kollar på är:

Om pluginet … är objektorienterat. tillämpar namespaces har en rimlig naming-convention har en god struktur kör databasanrop utanför wpdb gör externa anrop (phone-home funktioner?) förvaltas aktivt vilka tekniker som används (appliceras ett onödigt ramverk?) identifiering av långsamma processer (många faller här, allt är inte gjort för webbplatser med 3000 sidor)

Vi testar också av att pluginet fungerar i vår plattform.

Saker som vi inte tittar på: Hur välanvänt pluginet är (många välanvända plugin håller dålig funktionalitet). Är ett dåligt mätvärde.

Vi tar även in generella erfarenheter som vi har samlat på oss med åren. Det kan vara generell kunskap om specifika åtgärder i WordPress som är ineffektiva och dylikt.

[viktor-sarge]

Mitt svar:

Tack snälla för snabbt och informativt svar! Det var många kloka tankar. Jag jobbar parallellt just nu med vår prestandabudget och sneglar en hel del på det som VGRegion gjorde och det som webperf utvecklade utifrån den. Det vi ändrar där blir främst att gradera överordnade mål och delmål som stöttar leveransen av huvudmålet men som inte är hårda i sig så länge huvudmålet är ok. Jag gissar att vi kanske kan hitta ett annat liknande upplägg här - typ att phone home med känslig data eller långsamma processer kan vara ett kritiskt fel medan t.ex. tveksam namngivning blir mer av en bedömningsfråga.

Mäter ni hur mycket overhead som nya plugins genererar i svarstiderna?

Jag tänker att jag skall diskutera med övriga teamet under nästa vecka och sedan skriva ihop någon form av dokument som jag kan dela till dig också så kanske vi kan hjälpa varandra att tweaka ytterligare.

[viktor-sarge]

Fr Sebastian:

Låter bra! Det finns en rimlighet att gradera de punkter man slår ner på och kanske till och med skapa någon form av värde som är mätbart båda på delmål och huvudmål. Precis så som du säger är huvudmålet mätpunkt för release, men delmålen blir förbättringsområde.

Som det ser ut i dagsläget ger våra metoder en mycket individuell bedömning som nästan vilar lite på om utvecklaren i fråga tycker att det är en värdefull funktion. Där finns mycket att vinna på att ta fram en ”regelbok”.

Gällande prestanda och mätverktyg: Vi mäter hela våra webbplatser med NewRelic. Där kan man gå ner på djupet och verkligen se vilka specifika metoder i plugin som man bör lägga kraften på att förbättra. Vi tittar inte alls på hur mycket svarstid ett specifikt plugin adderar på laddtiden, utan går direkt ner på metodnivå. NewRelic kostar en peng, men det går att motivera med att man slipper lägga onödig tid på att leta fel och insparade driftskostnader (om priset beror på belastning).

Återkom gärna när du vet mer, så kikar jag gärna på det.

[viktor-sarge]

Input från Roland: Bra om metodnamn är tillräckligt unika för att inte krocka med andra.

[JohannaOlin]

@regionhallandviktor Använd Classic editor och Classic table (dubbelkolla namnet med Roland) som test.

[viktor-sarge]

Tar mig friheten att flytta tillbaka den här till vanliga backlogen. Den kommer inte bli gjord just nu.