Microsoft Power Apps mahdollistaa liiketoimintasovelluksien kehittämisen ns. low-code-periaatteella, tarkoituksena nopeuttaa ohjelmistokehitystä verrattuna perinteisempään koodaamiseen. Muutaman viikon takaisessa yksikkömme hackathon-tapahtumassa rakennetut täsmäsovellukset ovat hyviä esimerkkiä tuottavuudesta, jota Power Appsilla voidaan saavuttaa täsmätarpeisiin.
Vaikka Power Appsin avulla voi luoda nopeasti toiminnallisia sovelluksia, on tärkeää ottaa huomioon, että sovellukset kehitetään hyvien sovelluskehittämisen käytäntöjen mukaan. Tämä korostuu varsinkin, jos tavoitteena on toteuttaa tietoturvallisia tuotannollisia ratkaisuja, joita pitää jatkokehittää ja tukea.
Olemme käyneet organisaatiomme sisäisen Power Platform -osaamisen kehittämistä edistävän virtuaalitiimin sisällä keskustelua parhaista käytännöistä, jotta low-code-sovelluksien kehittämisessä yleiset sudenkuopat vältettäisiin ja niistä tulisi helpommin ylläpidettäviä.
Tässä kirjoituksessa olen nostanut osa-alueita, jotka on tärkeää huomioida, mutta jotka saattavat helpolla jäädä retuperälle, jos low-code-kehittämistä lähestytään ”kunhan vaan tehdään” -periaatteella.
1. Kehittäjätiimi
Yksikin kehittäjä voi luoda Power Appseja tehokkaasti, mutta on suositeltavaa, että ratkaisuja kehitetään useamman henkilön voimin, ellei sovelluksen laajuus ole hyvin rajallinen.
Näin vältetään tilanteet, joissa vain yksi kehittäjä tuntee toteutuksen. Henkilöriippuvuuden vähentäminen luo paremmat puitteet jatkokehittämiselle ja ylläpidolle.
Jos sovellukseen kohdistuu epätriviaaleja integraatiotarpeita, käyttöliittymä vaatii erityistä huomiota tai testitapausten määrä on iso, tarvitaan täydentäviä rooleja, kuten arkkitehti, integraatiokehittäjä, UX-suunnittelija, testauskonsultti, ja niin edelleen. Näin varmistetaan, että kaikki osa-alueet on huomioitu ja ratkaisu on suunniteltu laadukkaasti ja skaalautuvasti.
2. Suunnittelusprintti
Lähtökohtaisesti toteutuksien alussa olisi aina hyvä olla niin sanottu suunnittelusprintti, jossa on arkkitehti mukana. Suunnittelusprintti on hyvä tapa selvittää riittävällä tarkkuudella, mitä ratkaisun tulee tehdä ja mitä lisenssejä tarvitaan. Sprintin aikana voidaan esimerkiksi luoda käyttöliittymän rautalankamalli ja alustava ulkoasu, jonka avulla voidaan hahmottaa paremmin ratkaisun laajuus. Suunnittelusprintin aikana voidaan myös arvioida, onko Power Apps ylipäänsä oikea ratkaisu ja mikäli ei, suunnitellaan muita vaihtoehtoja.
3. Käyttäjäkokemuksen suunnittelu
Ennen sovelluksen toteutusta kannattaa varata aikaa käyttäjäkokemuksen ja käytettävyyden suunnitteluun. Sovelluksen käyttöliittymästä voidaan rakentaa rautalankamalli Power Appsilla itsellään tai vaihtoehtoisesti jollain UX-prototypointityökalulla. Projektin alkuun on hyvä tuoda käyttäjäkokemuksen suunnittelun ammattilainen, jotta Power Apps -sovellus on helppokäyttöinen ja tarjoaa erinomaisen käyttökokemuksen.
4. Yhteiset nimeämis- ja koodin kommentointikäytännöt
Organisaatioiden kannattaa ottaa käyttöön yhteiset nimeämis- ja koodin kommentointikäytännöt, joiden avulla sovelluksen koodi ja kontrollit (esimerkiksi tekstinsyöttökenttä) pysyvät selkeinä ja ymmärrettävinä. Näin vältetään turhaa konfigurointia ja koodin muuttamista, kun uusia käyttäjiä tulee mukaan projektiin.
Koodia kannattaa kommentoida aina, kun sovellukseen kehitetyn toiminnallisuuden kommentointi nopeuttaa toiminnallisuuden ymmärtämistä uudelle kehittäjälle. Kommentoinnin kieli kannattaa valita yhtenäiseksi läpi organisaation ja tyypillisesti paras kieli kommentointiin on englanti.
5. Dokumentaatio
Dokumentaatio pitää tehdä jokaisesta toteutuksesta. Dokumentaatioon kannattaa päättää minimivaatimukset ja yhteinen pohja, jotta dokumentaatioista tulee yhtenäisiä. Hyvä dokumentaatio on sellainen, että mahdollinen uusi tekijä saa toteutuksesta selkeän kuvan jo sen perusteella.
6. Testausvaihe
Testausvaiheessa tulee ottaa huomioon, että sovellus testataan perusteellisesti eikä sovellusta käytetä vain tyypillisimmällä tavalla. Power Appseja kehittäessä sovelluksia voi testata myös monitoroimalla niitä Monitor Sessionilla tai seuraamalla mahdollisia virheilmoituksia Power Platform Admin -portaalista. Ympäristöjä kannattaa olla aina ainakin kolme, tyypillisesti: Dev, Test ja Prod.
7. Uudelleen käytettävät komponentit
Sovelluksia kannattaa kehittää niin, että käytetään ympäristömuuttujia aina kun se on mahdollista. Näin säästetään aikaa ja vähennetään virheitä, kun manuaalisia muutoksia pitää tehdä vähemmän. Ympäristömuuttujia on mahdollista laittaa ratkaisupakettien sisälle, jolloin ratkaisupaketin siirto ympäristöjen välillä on suoraviivaisempaa.
Teemasta voi tehdä myös uudelleen käytettävän komponentin, mikäli useammalla sovelluksella on samankaltainen värimaailma ja peruspainikkeet, jolloin sovelluskehitys nopeutuu värien ja peruspainikkeiden asettelun osalta.
Yhteenveto
Yhteenvetona voidaan sanoa, että Power Apps-kehityksessä hyvien käytäntöjen noudattaminen auttaa liiketoimintaa hyödyntämään low-code alustan parhaita puolia ja varmistamaan, että ratkaisut ovat tehokkaita ja skaalautuvia. Sovelluksien suunnitteluun ja toteutukseen kannattaa panostaa ja varmistaa, että tarvittavat lisenssit on hankittu.
Koodin kommentointi- ja nimeämiskäytännöt ovat myös tärkeitä, eikä käyttöliittymän käytettävyyden hiomista tule unohtaa. Dokumentaation tulee olla yhtenäistä ja testausvaiheessa on syytä muistaa, että sovellusta tulee testata myös epätyypillisillä tavoilla. Näiden käytäntöjen noudattaminen varmistaa, että Power Apps -ratkaisut ovat laadukkaita, skaalautuvia ja ylläpidettäviä.