Kuinka sovellusten luominen toimii alhaisen koodin alustalla

Sovellusten rakentaminen matalan koodin alustalla tarkoittaa liiketoimintasovelluksen kokoamista neljästä ydinkerroksesta – tietomalli, käyttöliittymä, liiketoimintalogiikka ja pääsynhallinta – sen sijaan, että jokainen koodirivi kirjoitettaisiin käsin. Esimerkiksi 4D-projekti toimitetaan käännettynä työpöytä-, asiakas-palvelin- tai verkkosovelluksena yhdestä koodikannasta, joten pienet IT-tiimit voivat siirtyä taulukkosuunnittelusta käyttöön otettuun sovellukseen viikoissa eikä vuosineljänneksissä.

• Kun pohditaan, miten sovellusten rakentaminen toimii, jokainen yrityssovellus, matalakoodi tai käsin koodattu, pelkistyy neljään tasoon: missä data on, miten käyttäjät näkevät ja muokkaavat sitä, mitkä säännöt siinä toimivat ja kuka saa koskea siihen.
• Tietomalli on päätös, joka vanhenee pahimmin, jos teet sen väärin – normalisoi ensin, denormalisoi tarkoituksella äläkä koskaan anna lomakkeen sanella taulukkorakennettasi.
• Arvoluettelot, valintakentät ja haut ovat halvin luotettavuusvoitto kaikissa sovelluksissa: ne pysäyttävät huonot tiedot syöttökohdassa sen sijaan, että ne puhdistaisivat niitä myöhemmin.
• Matalakoodialustat vaihtavat joustavuutta nopeuteen. Tiedä, mitkä sovelluksesi osat ovat aidosti mukautettuja, ennen kuin sitoudut, sillä katto on siellä.
• Käyttöönottomalli (työpöytä, asiakaspalvelin, verkko, mobiili) on suunnittelupäätös, ei jälkikäteen tehty päätös – se muuttaa tapaa, jolla käsittelet samanaikaisuutta, istuntoja ja offline-käyttöä.
• Toimiva sovellus voittaa täydellisen skeeman. Lähetä kapea ensimmäinen versio, katso, kuinka ihmiset todella käyttävät sitä, ja laajenna sitten.

Mitä “sovellusten rakentaminen” oikeastaan tarkoittaa

Sovellusten rakentamisen toiminnan ymmärtäminen on prosessi, jossa yritysongelma muuttuu ohjelmistoksi, jota ihmiset käyttävät päivittäin – ja ohjelmistoosa on yleensä työstä pienempi puoli. Suurempi osa on päättää, mitä sovelluksen on tehtävä, mitä sen on kieltäydyttävä tekemästä ja kuka omistaa kunkin päätöksen. Ryhmät, jotka ohittavat tämän vaiheen, päätyvät rakentamaan saman näytön uudelleen kolme kertaa, koska kukaan ei ole sopinut siitä, mikä “asiakas” on.

Matalakoodi- ja ei-koodityökalut muuttivat tämän työn taloudellisuutta. AppSheet, Base44, Figman tekoälysovellusten rakentaja ja Flutter hyökkäävät kaikki samaan ongelmaan eri näkökulmista: AppSheet nojaa jo olemassa oleviin laskentataulukoihin ja tietokantoihin, Flutter on suunnattu kehittäjille, jotka haluavat yhden koodikannan iOS:lle ja Androidille, ja 4D on keskellä – relaatiotietokantamoottori, jossa on visuaalisen lomakkeen suunnittelija ja täydellinen ohjelmointikieli. Oikea valinta riippuu vähemmän ominaisuuksista kuin siitä, missä tietosi sijaitsevat ja kuka ylläpitää sovellusta julkaisun jälkeen.

Minkä tahansa sovelluksen neljä kerrosta

Taso 1: Tietomalli

Kun harkitset sovellusten rakentamista, tietomalli on joukko taulukoita, kenttiä ja suhteita, jotka kuvaavat liiketoimintaasi. 4D:ssä määrität tämän rakenneeditorissa: jokainen taulukko saa kenttiä tyypeineen (teksti, kokonaisluku, todellinen, päivämäärä, aika, Boolean, kuva, BLOB, objekti) ja taulukoiden väliset suhteet on määritelty eksplisiittisesti, jotta tietokantamoottori pakottaa ne. Hyvin rakennettu malli tarkoittaa, että laskun riviä ei voi olla ilman laskua, eikä asiakasta voida poistaa tilauksissa viitattaessa siihen.

Kolme sääntöä kantavat suurimman osan painosta:

1. Yksi tosiasia, yksi paikka. Jos asiakkaan osoite on sekä Asiakkaat- että Laskut-taulukossa, he ovat eri mieltä kuukauden kuluessa.
2. Mallinnoi suhdetta, älä raporttia. Useita moneen -suhde (esimerkiksi tuotteet toimittajiin) tarvitsee liitostaulukon, vaikka ensimmäisessä raportissasi olisi vain yksi puoli.
3. Valitse avaimet tarkoituksella. Automaattinen kokonaislukujen lisääminen on nopeaa ja yksinkertaista; UUID:t selviävät tietokantojen yhdistämisestä. Valitse sen perusteella, yhdistätkö koskaan tietoja kahdesta järjestelmästä.

Relaatiosuunnittelu ei ole matalakoodin keksintö - se tulee E. F. Coddin relaatiomallista, ja normaalimuodot (1NF - 3NF) kuvaavat edelleen virhetiloja, joihin törmäät. Wikipedian artikkeli tietokannan normalisoinnista on kohtuullinen virkistys, jos viimeinen muodollinen altistuminen tapahtui vuosia sitten.

Aiheeseen liittyvä: Claris FileMaker Pro — Pitkäaikainen relaatiotietokanta-alusta tiimeille, jotka tarvitsevat mukautettuja sovelluksia työpöydälle, verkkoon ja mobiililaitteille yhdestä tiedostosta..

Taso 2: Käyttöliittymä

Käyttöliittymä on paikka, jossa tietomallisi kohtaa todelliset ihmiset, ja siellä useimmat sovellusprojektit onnistuvat tai epäonnistuvat. Lomake, joka pyytää kaksitoista kenttää, kun käyttäjä tietää, että kaksi, se hylätään. Luetteloa, jossa on 4 000 riviä ilman suodatinta, vieritetään kerran eikä sitä avata enää koskaan.

4D-projektissa lomakkeet suunnitellaan visuaalisesti ja sidotaan taulukoihin tai muuttujiin. Käytännön päätökset ovat:

• Syöte vs. näyttölomakkeet. Tietojen syöttölomakkeiden tulee olla kapeita ja peräkkäisiä; arvostelulomakkeet voivat olla tiheitä.
• Lista vs. yksityiskohdat. Anna käyttäjille haettavissa oleva luettelo ja sitten yksityiskohtainen näkymä – ei yhtä jättimäistä muokattavaa ruudukkoa.
• Oletusarvot kehotteiden sijaan. Esitäytä tämän päivän päivämäärä, nykyinen käyttäjä, viimeksi käytetty osasto. Jokainen asettamasi oletus on näppäinpainallus, jonka tallennat sata kertaa.
• Validointisijoittelu. Vahvista lomakkeella välitöntä palautetta varten ja uudelleen tietokerroksessa, jotta tuonti ja API-kutsut eivät voi ohittaa sitä.

Taso 3: Liiketoimintalogiikka

Liiketoimintalogiikka on joukko sääntöjä, jotka tekevät sovelluksestasi enemmän kuin tietojen syöttöruudun: kokonaissumman laskeminen, alennusten soveltaminen, asiakirjojen luominen, ilmoitusten lähettäminen, hyväksymisketjujen pakottaminen. Tässä matalan koodin alustat eroavat jyrkimmin.

Meidän valintamme: Airtable — Yksinkertainen laskentataulukkokäyttöliittymä, joka sijaitsee todellisen relaatiotietokannan päällä, jossa on automaatioita, näkymiä ja jaettavia käyttöliittymiä..

Taulukkolaskentatyökalu käsittelee logiikkaa kaavojen ja automaatioiden avulla. Visuaalinen rakentaja käsittelee sitä tapahtumakäsittelijöiden ja työnkulun vaiheiden kautta.

Alusta, jossa on oikea ohjelmointikieli – 4D käyttää omaa kieltään ja Flutter käyttää Dartia – antaa sinun kirjoittaa mielivaltaisen koodin, kun visuaalinen polku loppuu. Rehellinen kompromissi: visuaalinen logiikka on nopeampi rakentaa ja ei-ohjelmoijan helpompi ylläpitää, mutta sitä on vaikea lukea, kun säännössä on enemmän kuin kourallinen haaroja. Kun työnkulku vaatii kahdeksan ehtoa ja silmukan, koodi voittaa.

Taso 4: Kulunvalvonta ja käyttöönotto

Kulunvalvonta vastaa kahteen kysymykseen: kuka näkee mitkä tietueet ja kuka voi muuttaa niitä. Useimmat pienten tiimien sovellukset tarvitsevat vähintään kolme roolia - järjestelmänvalvojan, editorin, katsojan - ja usein neljännen, jotta “näkevät vain oman osastonsa tiedot”. Rivitason suodatus on se osa, jonka tiimit unohtavat, ja se on osa, joka aiheuttaa tietoturvapoikkeaman.

Käyttöönotto on viimeinen kerros. 4D-sovellus voi toimia yhden käyttäjän työpöytäsovelluksena, asiakas-palvelinjärjestelmänä, jossa useat käyttäjät jakavat yhden tietokannan, tai selaimille tarjottavana verkkosovelluksena. Jokainen valinta muuttaa samanaikaisuusmalliasi, varmuuskopiointistrategiaasi ja tapaa, jolla päivität. Asiakaspalvelin tarjoaa keskitettyjä tietoja ja todellisia tapahtumia; web-käyttöönotto tarjoaa käyttöösi ilman asentamista; työpöytäkäyttöönotto antaa sinulle yksinkertaisuuden koordinoinnin kustannuksella.

Alustan valitseminen: Kriteeriluettelo

Kriteeri	Mitä kysyä	Miksi sillä on merkitystä
Tietojen omistus	Missä tiedot fyysisesti sijaitsevat, ja voinko viedä ne vakiomuodossa?	Siirtokustannukset ovat todellinen lukitus, ei lisensointi
Logiikan katto	Voinko kirjoittaa mukautetun koodin, kun visuaaliset säännöt loppuvat?	Määrittää, kestääkö sovellus toisen vuoden
Käyttöönottovaihtoehdot	Työpöytä, asiakaspalvelin, verkko, mobiili – mitä tuetaan?	Käyttöönottomallin jälkiasentaminen on kallista
Offline-käyttäytyminen	Mitä tapahtuu, kun verkko katkeaa?	Kenttä- ja varastosovellukset epäonnistuvat ilman vastausta
Integrointi	REST, SQL, tiedostojen tuonti/vienti, webhookit?	Useimpien sovellusten on puhuttava jollekin muulle
Huoltomalli	Kuka korjaa sen, kun rakentaja lähtee?	Kansalaisten kehittämät sovellukset ylittävät usein tekijänsä toimikauden

Viimeinen rivi ansaitsee korostuksen pohdittaessa, miten sovellusten rakentaminen toimii. Kansalaiskehittäjä, joka rakentaa aidosti hyödyllisen sovelluksen, on luonut tuotantojärjestelmän, kutsui sitä kukaan sellaiseksi tai ei. Suunnittele luovutus heti ensimmäisestä päivästä lähtien: dokumentoi taulukot, nimeä asiat selkeästi ja pidä kirjallista luetteloa sovelluksen noudattamista säännöistä.

Käytännön rakennussarja sovellusten rakentamiseen

Vaihe 1 – Kirjoita ongelman kuvaus yhdellä lauseella. “Seuraa laitelainoja ja kenellä jokainen esine on” on rakennettava laajuus. “Paranna toimintaa” ei ole.

Aiheeseen liittyvä: Knack — Kooditon tietokannan rakentaja, joka on tarkoitettu portaaleihin, hakemistoihin ja sisäisiin työkaluihin – kiinteähintaisella hinnoittelulla käyttäjäkohtaisten maksujen sijaan..

Vaihe 2 – luettele substantiivit ja verbit. Substantiivit muuttuvat taulukoiksi; verbeistä tulee tekoja. Tämä on vanhanaikainen domeinimallinnus ja toimii edelleen.

Vaihe 3 – Piirrä kolme näyttöä, joita et voi toimittaa ilman. Yleensä luettelo, yksityiskohta/muokkauslomake ja haku tai kojelauta. Kaikki muu on versiota kaksi.

Vaihe 4 – Luo tietomalli ja lataa todellista näytedataa. Kymmenen realistista tietuetta paljastaa suunnitteluvirheitä, joita sata tyhjää riviä ei koskaan tule paljastamaan.

Lukijan suosikki: Microsoft Power Apps — Yritystason alhaisen koodin sovelluskehitys yhdistettynä Microsoft 365:een, Dataverseen ja Power Automateen..

Vaihe 5 – Yhdistä arvoluettelot ja haut. Valintakentät, avattavat valikot ja relaatiovalitsimet ovat arvokkain ja pienin vaiva ominaisuus koko sovelluksessa. Ne estävät kirjoitusvirheisiin perustuvat kaksoiskappaleet, jotka tekevät raportoinnista hyödytöntä.

Vaihe 6 – Lisää logiikka yksi sääntö kerrallaan ja testaa jokaisen jälkeen. Viiden säännön erärakentaminen ja sitten virheenkorjaus on hitaampaa kuin niiden peräkkäinen rakentaminen.

Vaihe 7 – Aseta roolit ja testaa jokaista roolia. Kirjaudu sisään rajoitettuna käyttäjänä ja varmista, että hän ei näe sitä, mitä heidän ei pitäisi.

Vaihe 8 – Ota käyttöön pienessä ryhmässä ja laajenna. Kolmen tai viiden hengen pilottiryhmä löytää puuttuvan kentän, jota et koskaan ajatellutkaan.

Yleisiä virheitä sovellusten rakentamisessa

Kun mietit, kuinka sovellusten luominen usein menee pieleen, vältä näitä sudenkuoppia:

Annetaan lomakkeen ohjata skeemaa. Jos näyttö tarvitsee kentän, se on käyttöliittymäongelma, ei automaattisesti taulukon muutos. Sarakkeiden lisääminen yhden asettelun tyydyttämiseksi on kuinka tietokannat mätänevät.

Ohitetaan poistosäännöt. Päätä, mitä tapahtuu, kun päätietue poistetaan. Kaskadi, rajoitus tai orpo – valitse yksi suhdetta kohden ja kirjoita se ylös.

Tarkistamista käsitellään valinnaisena. Jokainen tärkeä kenttä tarvitsee säännön. Vapaan tekstin “tila”-kentistä tulee kuusi samanarvoista kirjoitusasua neljänneksen sisällä.

Toisen käyttäjän huomiotta jättäminen. Yhden käyttäjän sovellus voi olla huolimaton samanaikaisuuden suhteen. Kun kaksi henkilöä muokkaa samaa tietuetta, tarvitset strategian – tietueiden lukitsemisen, optimistisia tarkistuksia tai tarkoituksella tehdyn viimeisen kirjoitusvoiton päätöksen.

Raportin laatiminen ennen dataa. Epäjohdonmukaisten tietojen pohjalta rakennetut hallintapaneelit opettavat ihmisiä epäluottamukseen sovellukseen, ja luottamusta on vaikea voittaa takaisin.

Kuinka sovellusten luominen eroaa eri alustoilla

Sovellusten rakentaminen taulukkolaskentatyökalulla on nopeinta, kun tietosi ovat jo laskentataulukossa ja säännöt ovat yksinkertaiset. Sovellusten rakentaminen Flutterin kaltaiselle kehittäjäkehykselle tarjoaa pikselitason hallinnan ja alkuperäisen suorituskyvyn jokaisen näytön koodin kirjoittamisen ja ylläpidon kustannuksella. Sovellusten rakentaminen tietokantakeskeiselle matalakoodialustalle, kuten 4D, on niiden välissä: saat todellisen relaatiomoottorin, visuaalisen suunnittelijan ja ohjelmointikielen sitä tarvitseville osille.

Ratkaiseva kysymys siitä, miten sovellusten rakentaminen eroaa, ei ole “kumpi on tehokkain”, vaan “mitä tämä sovellus tarvitsee 18 kuukauden kuluttua?” Jos vastaus koskee monimutkaisia ​​käyttöoikeuksia, usean taulukon tapahtumia tai integrointia olemassa olevaan ERP:hen, alusta, jonka alla on aito tietokanta, säästää uudelleenkirjoittamisen. Jos vastaus on “yksinkertainen lomake, joka lähettää PDF-tiedoston sähköpostitse”, melkein kaikki toimii, ja sinun tulee valita se, jota tiimisi voi ylläpitää.

Lähteet ja lisälukemista

• Low-code-kehitysalusta — Wikipedia: Low-code-kehitysalusta (LCDP) tarjoaa ohjelmistokehitysympäristön – tyypillisesti graafisen käyttöliittymän (GUI) –, joka vaatii vähän tai ei ollenkaan kirjoittamista…

Usein kysyttyjä kysymyksiä

Kuinka kauan sovellusten luominen yleensä kestää?

Keskittynyt sisäinen sovellus – yksi ydintaulukkosarja, muutama lomake, perusroolit – kestää tavallisesti päivistä muutamaan viikkoon alhaisen koodin alustalla riippuen siitä, kuinka paljon liiketoimintalogiikkaa siihen liittyy. Tietomalli ja säännöt vievät kauemmin kuin näytöt. Sovellukset, jotka integroituvat ulkoisiin järjestelmiin tai tarvitsevat offline-tuen, vievät huomattavasti kauemmin, koska ne vaativat todellista suunnittelua konfiguroinnin sijaan.

Pitääkö minun osata ohjelmoida rakentaakseni sovelluksen?

Ei, suurelle sisäisille työkaluille. Visuaaliset lomakkeiden suunnittelijat, arvoluettelot ja työnkulun rakentajat kattavat tietojen syöttämisen, haut ja yksinkertaiset hyväksynnät ilman koodia. Ohjelmointi on tarpeen, kun tarvitset mukautettuja laskelmia, monimutkaista ehdollista logiikkaa, API-integraatioita tai suurten tietojoukkojen suorituskyvyn viritystä. Monet menestyvät sovellukset sisältävät 90 % määrityksiä ja 10 % koodia.

Mitä eroa on low-code- ja no-code-työkalujen välillä?

Koodittomat työkalut olettavat, että rakentaja ei koskaan kirjoita koodia ja rajoittavat mahdollisuuksia pitääkseen tämän lupauksen. Low-code-työkalut tarjoavat visuaalisia rakennuspalikoita, mutta paljastavat komentosarja- tai ohjelmointikerroksen, kun visuaalinen polku loppuu. Käytännön ero näkyy toisessa vuodessa: koodittomat sovellukset osuvat kattoon ja ne vaihdetaan, kun taas low-code-sovellukset laajenevat.

Pitäisikö minun rakentaa mukautettu sovellus vai käyttää valmiita tuotteita?

Mukautetut sovellukset voittavat, kun prosessisi on aidosti erottuva tai kun tietojen on säilyttävä omassa tietokannassasi. Valmiit tuotteet voittavat, kun prosessisi on vakio – kirjanpito, sähköposti, projektien seuranta – koska perit niiden ylläpidon ja vaatimustenmukaisuustyön. Kallis keskitie on ostaa tuote ja sitten räätälöidä sitä niin voimakkaasti, että omistat ylläpidon joka tapauksessa.

Mikä on tärkein vaihe sovellusten rakentamisessa?

Oikean tietomallin luominen on vaikuttavin vaihe, koska jokainen lomake, raportti ja sääntö on rakennettu sen päälle. Hyvä malli omaksuu uudet vaatimukset sulavasti; huono pakottaa kiertotapoja, jotka lisääntyvät. Käytä ylimääräinen päivä taulukoiden normalisoimiseen ja suhteiden määrittämiseen ennen kuin suunnittelet yhden näytön.

Voiko pieni IT-tiimi ylläpitää mukautettua sovellusta pitkällä aikavälillä?

Kyllä, jos sovellus on dokumentoitu ja alusta on sellainen, jolle tiimi löytää osaajia. Pidä kirjallista tietosanakirjaa (data dictionary), nimeä taulukoita ja kenttiä johdonmukaisesti ja vältä yhden henkilön tietosiilot. Riski ei ole koodissa oleva tekninen velka, vaan sen rakentaneen henkilön poistuminen, minkä vuoksi luovutusdokumentaatio on pienten tiimien ympäristöissä tärkeämpää kuin tyylikäs koodi.