För några dagar sedan skrev vi om hur du utvärderar kod i molnet, och nu är det dags att gå vidare och titta närmare på vilka typer av strategier för kodning och systemmodifikationer som kan göra systemet sårbart. Eftersom crm-system har krav som verkar utvecklas i all oändlighet, är det viktigt att använda varaktig kod som gör att sådana system håller över tid.

Innan vi startar vill vi dock nämna en viktig sak, nämligen att de exempel och villkor vi nämner i artikeln gäller för Salesforce.com-miljön. Andra applikationsmiljöer och plattform följer andra villkor.

Ytterligare en salesforce-guide hittar ni här: Så lägger du in databasen i molnet


Deklarativ utveckling och programmering
Molnbaserade applikationer är ofta baserade på det som leverantörerna kallar för deklarativ programmering, och det eftersom det är entydigt, lättare att lära och lättare att kontrollera i saas-miljöer. De flesta molnapplikationerna använder valideringsregler för fält, begränsningar för fält och tabeller, samt arbetsflöden för objekt. Det fungerar bra i början och erbjuder förvånansvärt mycket kraft och funktionalitet.

Problemen uppstår när du lägger till kod. När man utvecklar en ny trigger, klass eller ”lyssnartjänst”, kan det mycket väl vara så att programmeraren arbetar i en utvecklings- eller sandlådemiljö som inte är konfigurerad på samma sätt som produktionssystemet. När koden skickas ut i skarp version uppstår alla möjliga fel som kanske inte kan återskapas i utvecklingsmiljön. Dessvärre kan felmeddelandena vara rätt så svåra att tyda, både för användaren och den som ska lösa problemet.

Några tips:

1. Försäkra dig om att utvecklarna arbetar i en nyligen uppdaterad ”sandlåda” så att de inte överraskas av konfigurationen i produktionsmiljön.

2. Så långt det är möjligt bör du aktivera integrationsadaptrar och andra tillägg i sandlådan, så att utvecklarna kan se förgreningarna av alla tillståndsförändringar.

3. När du har börjat utveckla tillägg och funktionalitet runt ett objekt flyttar du alla valideringsregler och återimplementerar dem i din lågnivåkod så att du kan upptäcka och kontrollera olika fel.

4. På ett liknade sätt ersätter du eventuella arbetsflöden som gör fältuppdateringar med implementeringar av lågnivåkod.

5. Skapa en administrativ regel som gör det mycket svårt att skapa nya valideringsregler eller arbetsflödesdrivna fältuppdateringar.

6. Försäkra dig om att du lägger in kod som förhandskontrollerar värden och sätter stopp innan du passerar begränsningar hos fält eller tabeller.

7. Kontrollera att det inte finns några null-värden i fälten samt empty-värden i set, list eller map, och det innan du försöker använda dessa i någon typ av logik.

8. Skriv klasser som hanterar alla applikationsfel i realtid och skickar dessa som meddelanden till en centraliserad felhanteringstjänst på annan plats i molnet.