Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Utvärdera och beskriva möjligheterna att bedriva utveckling i applikationsramverket “Open ePlatform” Open ePlatform för en tredje part

  • Att förstå förutsättningar för att säkerställa kontinuitet vid en krishändelse hos befintlig leverantör (Nordic Peak) som en uppföljning av tidigare genomförd analys 2019:

...

Detta demo-projekt ser vid en första anblick ut att vara en referensimplementation/instans av Open ePlatform. En beskrivning av hur man kommer igång finns att läsa i dokumentet “Open ePlatform – Dokument för utvecklare”.

I texten nedan återges upplevelser och erfarenheter kring arbetet med att sätta upp demo-projektet. Både vad avser själva miljökonfigurationen, men även intryck av kod, struktur, ramverk, etc. i Open ePlatform.

Det är möjligt att vissa saker som tas upp i texten innehåller felaktigheter, att det finns kod som inte har setts eller att arbetet med att sätta upp demo-projektet inte är helt korrekt utfört. Dokumentet “Open ePlatform – Dokument för utvecklare” har dock följts så långt det bara är möjligt och nedan återges erfarenheterna utifrån det.

...

För att få igång detta är man dock varit tvungen att importera följande projekt (bild från utvecklingsmiljö) Bild-3.

Utvärderarenhar aldrig varit med om att en webbapplikation kräver denna mängd av Eclipse-projekt för att fungera. Det känns faktiskt helt bisarrt och man kan inte sluta förundras över valet att inte gå över till Maven, Gradle eller liknande verktyg. Inte ens i utvärderarens dagliga arbete med utveckling av microtjänster (som över tid kan bli många till antalet) har utvecklingsmiljön haft detta utseende.

...

  • Blandning av presentationslogik och affärslogik. Bilder, HTML-sidor, css-filer, etc. ligger blandat med Javakod (se: bild-1)

  • SQL (för databas-operationer) ligger inbäddat i javakoden. Det har länge varit praxis att istället använda persistence-API:er, t.ex. JPA. (se: bild-2)

Eftersom det är lätt att låta sig färgas av sina egna bestämda uppfattningar och åsikter när kodkvalitét skall bedömas, valdes att öka objektiviteten genom att låta utföra en kodanalys med verktyget SonarLint. Detta verktyg analyserar koden och rapporterar “code smells”, sårbarheter, buggar och övriga avsteg från god programmeringssed.

...

Resultatet får tala för sig självt och finns att ta del av i bifogad Excel-fil: sonar-issues.xlsx.

Tester

Även om det givetvis går att arbeta med kodstandard av lägre kvalitét upptäcktes saker som är mer besvärande. Den viktigaste av dessa upptäckter är att inbyggda enhets- och applikationstester helt saknas (utifrån vad som går att se). Detta gör att man funderar över följande:

...