Online-sovelluskehityskoodi: Käytännön opas

Verkkosovelluskehityskoodi on yhdistelmä visuaalisia määrityksiä, kaavoja ja valinnaisia ​​komentosarjoja, jotka muuttavat tietokantaskeeman toimivaksi liiketoimintasovellukseksi. Tyypillinen matalan koodin koontiversio kulkee neljän kerroksen läpi: tietomalli, käyttöliittymä, logiikka ja integraatiot, jotka kaikki paljastetaan selaimen kautta ilman paikallista asennusta. Kypsät tiimit yhdistävät luotua ja käsin kirjoitettua koodia käyttämällä visuaalisia työkaluja toistuvaan 80 %:iin ja lähdekoodiin todella ainutlaatuiseen 20 %:iin.

• Verkkosovelluskehityksen matalakoodi- ja koodittomat alustat korvaavat rutiinikoodin (reititys, todennus, CRUD-näytöt, käyttöönotto) konfiguroinnilla, mutta ne harvoin poistavat logiikkaa kokonaan: määrittelet silti säännöt, validoinnit ja laskelmat.
• Minkä tahansa sovelluksen neljä kerrosta (data, käyttöliittymä, logiikka, integraatiot) ovat oikea ajattelumalli päätettäessä, mitä konfiguroida tai mitä koodata.
• Luotua koodia ja käsin kirjoitettua koodia eivät ole vastakohtia; kypsät tiimit sekoittavat niitä käyttämällä visuaalisia työkaluja toistuvaan 80 %:iin ja lähdekoodiin todella ainutlaatuiseen 20 %:iin.
• Ensimmäisellä viikolla tehdyt datamallinnuspäätökset ovat vaikeimpia perua myöhemmin. Joten suunnittele taulukot ja suhteet ennen yhden lomakkeen luomista.
• Toimittajariippuvuus on todellinen kompromissi: mitä nopeammin toimitat pilvipalvelualustalla, sitä riippuvaisemmaksi olet kyseisen alustan vientivaihtoehdoista ja hinnoittelusta.
• 4D (4th Dimension) on pitkään vakiintunut vaihtoehto tällä alalla, jossa yhdistyvät relaatiotietokantamoottori, lomakesuunnittelija ja oma ohjelmointikieli yhdessä ympäristössä.

Mitä “Online-sovelluskehityskoodi” todellisuudessa tarkoittaa

Online-sovelluskehityskoodi kuvaa ohjeet, joita pilvipalvelussa isännöimä rakentaja käyttää sovelluksesi määrittämiseen – osan niistä olet kirjoittanut itse, ja suurin osa niistä on luotu alustalla määrityksistäsi. Ilmaus kattaa kolme eri asiaa, jotka aloittelijat usein yhdistävät: luomasi visuaaliset määritelmät (taulukot, kentät, lomakkeet, työnkulut), näihin määritelmiin kirjoittamasi lausekkeet ja kaavat sekä taustalla oleva lähdekoodi, jonka alusta tuottaa tai tulkitsee puolestasi.

On tärkeää ymmärtää, minkä näistä olet tekemisissä, koska se määrittää, kuinka kannettava työsi on. Selaimessa yhteen vedetty lomakeasettelu tallennetaan alustan metatietoina. sitä ei yleensä voi nostaa toiseen tuotteeseen. Tavallisella lausekekielellä kirjoittamasi kaava on periaatteessa kannettavampi, vaikka toteutukset vaihtelevat niin paljon, että käännös on harvoin automaattista. Itse kirjoittamasi lähdekoodi on kannettava ja kallein ylläpitää.

Käytännön seuraus: mitä enemmän sovelluksestasi on konfiguraatiossa, sitä nopeammin toimitat ja sitä vaikeampaa sinun on siirtyä. Tämä on kompromissi, joka tehdään tarkoituksella, ei vahingossa.

Ei koodia -sovelluskehitys vs. Low-Code vs. perinteinen koodaus

Kooditon verkkosovelluskehitys on suunnattu ihmisille, jotka eivät koskaan avaa editoria: tavoitteena on luoda valmiiksi määritetyistä komponenteista koottu täydellinen sovellus, jonka logiikka ilmaistaan pudotusvalikoilla, ehdoilla ja yksinkertaisilla kaavoilla. Matala koodi on yhden askeleen edellä: samat visuaaliset rakennuspalikat sekä varsinaisen koodin poistumisluukku, kun vaatimus ylittää komponenttien toimittaman. Perinteinen kehitys alkaa tyhjästä arkistosta ja puitteiden valinnasta.

Käytännössä todella tärkeä ero ei ole etiketti, vaan se, missä katto sijaitsee. Kooditon työkalu runsaalla kaavakielellä ja API-liittimellä voi viedä pienyrityssovelluksen pitkälle. Matalakoodityökalu, jossa on heikko komentosarjataso, voi pysähtyä, kun tarvitset mukautetun laskelman yhdistetyille taulukoille.

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

Kolme kysymystä erottaa kategoriat hyödyllisesti:

1. Voitko ilmaista ehdollista logiikkaa? Jos alusta tukee vain lineaarisia “kun X, tee Y” -sääntöjä, monimutkaiset liiketoimintasäännöt rikkovat sen lopulta.
2. Saatko yhteyden ulkoiseen järjestelmään? REST-sovellusliittymät, webhookit ja tietokantaliittimet määrittävät, onko sovelluksesi saari.
3. Saatko tietosi ulos? CSV-vienti on perusedellytys; dokumentoitu API tai suora tietokantakäyttö suojaa sinua.

Alusta, joka vastaa kyllä ​​kaikkiin kolmeen kysymykseen, tekee suurimman osan siitä, mitä perinteinen pino tekee, paljon pienemmällä asennuksella. Alusta, joka vastaa ei kolmanteen, on riski, että sinun tulee hinnoitella ennen sitoutumista.

Minkä tahansa sovelluksen neljä kerrosta

Jokainen yrityssovellus, riippumatta siitä, miten se on rakennettu, koostuu samoista neljästä kerroksesta. Niiden erottaminen selventää, mitä määrität ja mitä kirjoitat.

Jos olet ostoksilla: Zoho Creator — Halpakoodisovellusten rakentaja, joka liitetään laajempaan Zoho-sviittiin ja hinnat käyttäjää kohti sovelluksen sijaan..

Taso 1: Tietomalli

Taulukot, kentät, tietotyypit, avaimet ja suhteet muodostavat perustan. Relaatioalustassa, kuten 4D:ssä, tämä edellyttää taulukoiden määrittelyä ensisijaisilla avaimilla, linkittämistä relaatioiden kautta ja kenttätyyppien huolellista valintaa: tekstikenttä, jonka olisi pitänyt olla numero, aiheuttaa myöhemmin lajittelu- ja laskentaongelmia. Laskentataulukkotyylisessä alustassa samat päätökset näkyvät saraketyypeinä ja linkitetyinä tietueina.

Tietomallinnus on se, missä kokemus kannattaa eniten. Normalisoimalla asiakkaan/tilauksen/rivikohteen rakenteen oikein alusta alkaen vältytään siirtoon liittyviltä haasteilta, jotka liittyvät paisuneen taulukon jakamiseen sen jälkeen, kun siihen on osoittanut 10 000 tietuetta ja kymmenkunta lomaketta.

Taso 2: Käyttöliittymä

Lomakkeet, luettelonäkymät, tietosivut ja kojelaudat muodostavat käyttöliittymäkerroksen. Visuaalisten suunnittelijoiden avulla voit sijoittaa kenttiä, sitoa ne tietolähteisiin ja määrittää vahvistussääntöjä kirjoittamatta merkintäkieltä. Tässä oleva koodi on deklaratiivinen: kuvailet mitä näytön pitäisi näyttää ja alusta tekee sen.

Käyttöliittymätyö on se, missä koodittomat työkalut loistavat eniten, koska toistuvat osat (sivutus, haku, reagoiva asettelu, tyhjät tilat) käsitellään puolestasi. Kompromissi on, että epätavalliset asettelut tai vahvasti tuotemerkit voivat saavuttaa suunnittelijan komponenttijoukon rajat.

Taso 3: Logiikka

Logiikka on paikka, jossa “sovelluskehityksen koodi” muuttuu kirjaimelliseksi. Laskelmat, vahvistukset, hyväksyntäreititys, ajoitetut työt ja tilasiirtymät tarvitsevat kaikki ohjeita. Alustat ilmaisevat nämä eri tavoilla:

• Kaavakentät laskevat arvon muista kentistä, jotka lasketaan uudelleen luettaessa tai kirjoitettaessa.
• Tapahtumankäsittelijät suoritetaan, kun tietue luodaan, päivitetään tai poistetaan.
• Työnkulkusäännöt ketjun ehdot ja toiminnot, usein visuaalisen rakentajan kanssa.
• Komentosarjakielet käsittelevät kaikkea, mitä yllä olevat eivät voi ilmaista.

Hyödyllinen nyrkkisääntö: jos liiketoimintasääntö voidaan ilmaista yhdellä lauseella ilman poikkeuksia, visuaalinen sääntö käsittelee sen. Jos se tarvitsee kappaleen, jossa on kolme “ellei”-lausetta, haluat komentosarjakerroksen.

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..

Taso 4: Integraatiot

Integraatiot yhdistävät sovelluksesi sähköpostiin, maksuprosessoreihin, kirjanpitojärjestelmiin ja muihin tietokantoihin. Useimmat alustat tarjoavat valmiiksi rakennetut liittimet yleisille palveluille ja yleisen HTTP-pyyntötoiminnon kaikkeen muuhun. Todennus – API-avaimet, OAuth-tunnukset – on yleensä alustan hallinnassa, mikä poistaa aidosti vaivalloisen työn.

Integroinnin luotettavuus ansaitsee huomiota. Hiljaisesti vikaantuva liitin on huonompi kuin ei liitintä, joten etsi uudelleenyrityslogiikka, virheloki ja tapa toistaa epäonnistuneet työt.

Missä koodi todella elää

Koodi matalan koodin sovelluksessa näkyy neljässä paikassa, ja niiden tunteminen auttaa sinua arvioimaan rehellisesti verkkosovellusten kehityskoodin vaivaa.

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

Lausekkeet ja kaavat ovat yleisimpiä. Kaava, joka laskee laskun loppusumman rivikohdista, soveltaa alennustasoa ja pyöristää kahteen desimaaliin, on oikea logiikka, vaikka se syötettäisiin yksiriviseen kenttään.

Tapahtumakoodit suoritetaan tietueiden elinkaaritapahtumissa. 4D:ssä tämä on sen sisäänrakennetun ohjelmointikielen toimialue, joka voidaan liittää lomaketapahtumiin, triggereihin ja menetelmiin. Selainpohjaisilla alustoilla vastaava on yleensä JavaScript-katkelma tai palvelinpuolen toiminto.

API- ja webhook-hyötykuormat ovat koodia, jota kirjoitat siinä mielessä, että rakennat JSON-muodon, yhdistät kenttiä ja käsittelet vastauksia. Tässä integraatiotyöstä tulee ohjelmointia.

Muokatut komponentit ja laajennukset ovat syvin taso: uudelleenkäytettävän widgetin tai alustan kutsuman palvelinpuolen toiminnon kirjoittaminen. Harvat kansalaiskehittäjät menevät sinne, ja harvat tarvitsevat.

Rehellinen kehystys: No-code poistaa tarpeen kirjoittaa web-palvelinta, kirjautumisjärjestelmää tai tietokantaohjainta. Tämä ei poista tarvetta ajatella tarkasti sääntöjä ja tietoja. Tarkkuus on todellinen taito, ja se siirtyy alustojen välillä.

Alustan valinta: Kriteerien tarkistuslista

Useimmat projektit onnistuvat tai epäonnistuvat alustan valinnassa, ja markkinointisivut ovat harvoin hyödyllisiä. Arvioi ehdokkaita näiden kriteerien mukaan ja painota heidät tilanteesi mukaan.

Kriteeri	Mitä tarkistaa	Miksi sillä on merkitystä
Tietomallin syvyys	Relaatiotaulukot avaimilla ja suhteilla vai tasaiset luettelot?	Määrittää, pysyvätkö monimutkaiset tiedot hallittavissa
Logiikka katto	Kaavakieli, tapahtumakäsittelijät, komentosarjojen pakoluukku	Asettaa pisteen, jossa sinun on rakennettava uudelleen muualla
Integrointivaihtoehdot	Natiiviliittimet, yleinen HTTP, webhookit, todennusten käsittely	Päättää, yhdistääkö vai eristääkö sovellus
Tiedon siirrettävyys	Dokumentoitu API, CSV-vienti, suora pääsy tietokantaan	Poistumisreittisi, jos alusta muuttuu
Isännöintimalli	Toimittajapilvi, itseisännöity tai paikan päällä	Vaatimustenmukaisuus ja valvonta
Hinnoittelumuoto	per käyttäjä, per tietue, per sovellus tai taso	Ennustettavuus käytön kasvaessa
Oppimiskäyrä	Ei-ohjelmoijan aika lähettää ensimmäinen työlomake	Voiko tiimisi todella ottaa sen käyttöön

Kaksi kriteeriä ansaitsevat lisäpainoa pienten tiimien IT-rakentajille. Tietojen siirrettävyys suojaa sinua siltä, ​​että toimittaja muuttaa tuotettaan tai nostaa hintojaan. Logiikkakatto määrittää, onko tällä vuosineljänneksellä rakentamasi sovellus sopiva ensi vuonna.

Tiimille, joilla on olemassa olevaa relaatiodataa ja jotka haluavat käyttää itsepalvelua, 4D:llä on tietty markkinarako: tietokantamoottori, lomakesuunnittelija ja ohjelmointikieli yhdessä tuotteessa, jolla on pitkä historia vertikaalisten yritysohjelmistojen alalla. Tiimille, jotka haluavat vain selainkäyttökokemuksen verkkosovellusten kehittämiseen eikä palvelinta hallintaan, isännöidyt alustat, kuten Bubble- tai Airtable-tyyliset työkalut, jotka vaativat vähemmän koodia, sopivat paremmin. Kumpikaan ei ole universaalisti oikea.

Realistinen rakennussarja

Käyttöliittymästä aloittaminen on aloittelijan yleisin virhe, koska se näyttää edistymiseltä. Parempi sarja:

1. Lista kokonaisuudet. Kirjoita muistiin nimet, joita yrityksesi käsittelee (asiakkaat, työt, laskut, osat) ja niiden väliset suhteet.
2. Määrittele taulukot ja avaimet. Määritä jokaiselle taulukolle ensisijainen avain ja päätä, miten tietueet liittyvät toisiinsa. Tee tämä ennen kuin lomake on olemassa.
3. Luo luettelonäkymä ja yksityiskohtalomake entiteettiä kohden. Tee CRUD-perussilmukka toimimaan päästä päähän.
4. Lisää arvoluetteloita ja validointi. Hakutaulukkoon liittyvät pudotusvalikot estävät huonot tiedot lähteellä, mikä on paljon halvempaa kuin niiden puhdistaminen myöhemmin.
5. Looginen kerros. Lisää laskelmat, sitten tapahtumakäsittelijät, sitten työnkulkusäännöt ja testaa jokaista erikseen.
6. Kytke integraatiot viimeiseksi. Ulkoiset järjestelmät ovat vähiten ennakoitavissa oleva osa; niiden lisääminen vakaaseen ytimeen on helpompi korjata.
7. Ajoita vienti. Varmista, että voit purkaa tietosi käyttökelpoiseen muotoon, ennen kuin sinulla on tuhansia tietueita, joita et voi jättää taaksesi.

Ensimmäisessä ja toisessa vaiheessa tietokannan kehittäjän vaistot kannattavat ja kansalaiset kehittäjät hyötyvät eniten toisesta mielipiteestä. Piirustuksen 30 minuutin tarkistus voi säästää viikkoja muokkauksesta.

Yleiset virheet ja niiden välttäminen

Koonna lomakkeet ennen taulukoita. Lomakkeet ovat edullisia rakentaa uudelleen; kaaviot eivät ole. Jaksolla on väliä.

Alustan oletusarvojen käsittely vaatimuksina. Oletuskenttätyypit, oletusoikeudet ja oletusnimeämiskäytännöt ovat lähtökohtia. Tarkista ne.

Lupamallin huomiotta jättäminen. Kuka voi nähdä, mitkä tietueet ovat suunnittelupäätös, ei lopuksi määritettävä asetus. Erityisesti rivitason suojausta on vaikea päivittää.

Oletetaan, että koodittomuus ei tarkoita ylläpitoa. Sovellukset tarvitsevat päivityksiä, kun integraatiot muuttuvat, kun liiketoimintasäännöt muuttuvat ja kun alusta toimittaa rikkovan muutoksen. Budjetti sille.

Ohita testivienti. Suorita täydellinen vienti ensimmäisen viikon aikana. Jos tämä tuottaa jotain käyttökelvotonta, olet oppinut tärkeimmän tosiasian alustastasi, vaikka se on vielä edullista.

Lähteet ja lisälukemista

• Mobiilisovelluskehitys – Wikipedia: Mobiilisovelluskehitys on toimenpide tai prosessi, jolla mobiilisovellus kehitetään yhdelle tai useammalle mobiililaitteelle, johon voi sisältyä kämmentietokoneita…

Usein kysyttyjä kysymyksiä

Pitääkö minun osata koodata voidakseni rakentaa sovelluksen verkossa?

Ei, suurelle joukolle sisäisiä yrityssovelluksia. Koodittomat alustat käsittelevät tietojen tallennusta, lomakkeita ja yksinkertaisia ​​sääntöjä ilman ohjelmointia. Sinun on ajateltava jäsennellyin, sääntöihin perustuvin termein, mikä on toisiinsa liittyvä, mutta erilainen taito. Kun tarpeisiisi sisältyy monimutkaisia ​​laskelmia useiden taulukoiden tai epätavallisten integraatioiden välillä, komentosarjatasosta tulee arvokas.

Mitä eroa on no-codella ja low-codella?

No-code tähtää täydelliseen sovellukseen ilman rakentajan kirjoittamaa lähdekoodia käyttämällä visuaalisia komponentteja ja yksinkertaisia ​​kaavoja. Low-code tarjoaa samat visuaaliset rakennuspalikat sekä pakoluukun todelliseen koodiin vaatimuksia varten, joita komponentit eivät voi ilmaista. Käytännön ero on katossa: low-code-sovellukset voivat kasvaa entisestään ennen kuin niitä on siirrettävä perinteiseen pinoon.

Voinko viedä sovellukseni ja datani, jos vaihdan alustaa?

Tietojen vienti on yleensä mahdollista CSV:n tai dokumentoidun API:n kautta, mutta sovelluslogiikka siirtyy harvoin. Lomakeasettelut, työnkulkusäännöt ja kaavat tallennetaan alustakohtaisina metatietoina. Ennen sitoutumista vahvista vientimuoto ja testaa sitä. Käsittele tietoja siirrettävinä, mutta sovelluksen määritelmää ei.

Kuinka kauan toimivan yrityssovelluksen rakentaminen kestää?

Yksittäiseen entiteettiin perustuva sovellus, jossa on luettelonäkymä, yksityiskohtalomake ja perusvalidointi, voi olla käynnissä iltapäivällä useimmilla alustoilla. Usean taulukon sovellus, jossa on suhteita, roolipohjaisia ​​käyttöoikeuksia ja yksi tai kaksi integraatiota, on tyypillisesti usean viikon projekti. Monimutkaisuus johtuu tietomallista ja säännöistä, ei näyttöjen määrästä.

Onko low-code tarpeeksi turvallinen yritysdatalle?

Suojaus riippuu alustan lupamallista, isännöintijärjestelyistä ja omista asetuksistasi. Hyvämaineiset toimittajat hoitavat salauksen, todennuksen ja infrastruktuurin korjauksen. Sinun vastuullasi on rivitason käyttöoikeussäännöt, roolimääritykset ja se, ettet paljasta tietoja integraatioiden kautta. Tarkista säänneltyjen tietojen osalta toimittajan vaatimustenmukaisuusdokumentaatio ja isännöintivaihtoehdot ennen aloittamista.

Mitä minun pitäisi oppia ensin, jos haluan rakentaa sovelluksia tällä tavalla?

Opi ensin datamallinnus – taulukot, avaimet, suhteet ja normalisointi. Se on se kerros, jota on vaikein muuttaa ja se, joka vaikuttaa eniten kaikkeen sen yläpuolelle. Käyttöliittymän rakentaminen ja kaavojen kirjoittaminen on helpompi omaksua asteittain. Relaatiotietokantojen tausta siirtyy suoraan kaikkiin kohtaamiisi low-code-alustoihin.

Minne mennä seuraavaksi

Nopein tapa oppia verkkosovellusten kehitystä on rakentaa yksi pieni, todellinen sovellus – jotain sinä tai kollegasi todella tarvitset – ja käydä läpi kaikki neljä tasoa. Aloita skeemasta, saat luettelo- ja yksityiskohtanäkymän toimimaan, lisää yksi laskutoimitus ja yhdistä sitten yksi ulkoinen palvelu. Tuo yksittäinen passi opettaa enemmän kuin mikään vertailuartikkeli, koska se pakottaa sinut kohtaamaan kompromissit omassa kontekstissasi.

Relaatiotietokantoihin jo valmiiksi tottuneille kehittäjille sellaisen alustan tutkiminen, joka paljastaa sekä visuaalisen suunnittelijan että täyden ohjelmointikielen – 4D on pitkäaikainen esimerkki – on hyödyllinen harjoitus nähdäkseen, missä konfigurointi päättyy ja koodi alkaa. Kaikille muille on lähtökohtana yllä oleva kriteeritaulukko: arvioi rehellisesti kaksi tai kolme ehdokasta, testaa vienti ja valitse se, jonka katto on korkeammalla kuin missä toivot olevasi kahden vuoden kuluttua.