A kevés kódolást igénylő program a fejlesztőknek is szól: Itt jön a következő programozási forradalom
Nagy változás zajlik az alkalmazások fejlesztésében és használatában, és a kevés kódolás kulcsfontosságú jellemző lesz.
Annak ellenére, hogy a modern eszközök és szolgáltatások produktívabbá teszik a fejlesztőket, még mindig van egy "alkalmazáshiány". Ez a kód és az érdekelt felek által kívánt kód közötti szakadék. A fejlesztőcsapatok túlterheltek, és rangsorolniuk kell munkájukat, az alapvető üzleti rendszerekre és a velük való együttműködéshez szükséges eszközökre összpontosítva.
Nem meglepő tehát, hogy a kevés kódolást igénylő eszközök népszerűvé váltak. Ismerős fogalmakra építenek, hogy a végfelhasználóknak olyan eszközkészletet biztosítsanak, amely segít a szükséges alkalmazások létrehozásában és megosztásában. Az Excel és az Access logikai utódai, olyan játszóterek, amelyek megnyitják az adatokhoz való hozzáférést, és lehetőséget biztosítanak az alkalmazások és szolgáltatások összekapcsolására, miközben egyszerű felhasználói élményt építenek a közös építőelemekből. Úgy gondolhat rájuk, mint modern folyamatautomatizálási eszközökre, amelyek képesek munkafolyamatokat kinyerni a műveletekből, és ezeket a rögzített műveleteket kóddá alakítani.
Az olyan kevés kódolást igénylő eszközöket, mint a Zapier és a Microsoft Power Platformja, gyakran úgy tekintik, mint a fejlesztési igények csökkentésének módját, lehetővé téve a felhasználók számára, hogy akkor készítsék el a szükséges alkalmazásokat, amikor szükségük van rájuk. Bármennyire is jó az alkalmazáshiány csökkentésének módja, vannak jelentős korlátok, amelyek lehetetlenné teszik a kevés kódolást igénylő eszközök elszigetelt vizsgálatát.
API-k kezelése
Amit gyakran elfelejtenek a kevés kódolás felé való rohanásban, az az, hogy ez a lényeg egy munkafolyamat és integrációs technológia, és ez a végpontok létrehozását és kezelését jelenti. Itt elengedhetetlenné válnak a meglévő fejlesztőcsapatok, mivel feladatuknak kell lenniük a meglévő alkalmazások és szolgáltatások felügyelt API-inak biztosításával. Míg a legtöbb kevés kódolást igénylő eszköz által használt REST-alapú API-modellek viszonylag könnyen megvalósíthatók és támogathatók, ez a folyamat új problémákat vet fel: ki férhet hozzá ezekhez az API-khoz, és mennyit férhetnek hozzá rajtuk keresztül?
A meglévő identitásplatformhoz kötött API-kezelés nélkül nem valósíthat meg kevés kódolást igénylő megoldásokat. Az adatbiztonság és az integritás biztosításához szerepköralapú hozzáférés-vezérlésre és felügyelt szabályozásra lesz szükség. Biztosnak kell lennie abban, hogy a védett adatokhoz csak azok férhetnek hozzá, akiknek szükségük van rájuk, és hogy a túl sok felhasználó nem befolyásolja az üzletági rendszerek működését. Ha az API-kezelést a kevés kódolást igénylő csomag részévé teszi, az API-khoz hozzáférésre szoruló felhasználók egyszerű önkiszolgáló folyamatokkal építhetők ki, és az adatvesztés elkerülése érdekében a nem használt fiókok kiüríthetők.
Csapatmunka
Aztán ott van a kevés kódolás problémája, amelyet elszigetelten fejlesztenek. Túl gyakran hoznak létre eszközöket többször, így lemaradnak a kód újrafelhasználásának és hordozhatóságának előnyeiről. A probléma egy része az, hogy sok alacsony kódolást fejlesztenek szabadalmaztatott környezetekben, nem integrálva a forrásvezérlő rendszerekkel vagy a közösségi kódolási környezetekkel, például a GitHubgal. Még az eredeti alacsony kódolású környezet, az Excel is eltávolodik a szabadalmaztatott modelltől, az új LAMBDA funkcióval, amely lehetővé teszi a kódblokkok megosztását a különböző projektek között.
Egyértelmű, hogy a kevés kódolás kód, még akkor is, ha vizuális, fogd és vidd vásznon generálják. Ugyanúgy kell kezelnünk, mint a kódot a mainstream vállalati fejlesztéseinkben, biztosítva, hogy biztonságos és megbízható legyen, és ahol lehetséges, az alkalmazások létrehozásához használt tudás ne vesszen el, és megosztható legyen más csapatokkal.
A korai kevés kódolást igénylő eszközök sok mindent átugortak abból, ami ehhez elengedhetetlen volt. Igen, építhetne köré folyamatokat, fejlesztői véleményekkel és egyéb mérföldkövekkel, de ez a megközelítés akadályozza a kevés kódolást igénylő nyilvánvaló előnyöket, akadályokat gördítve az olyan alkalmazások gyors fejlesztésének útjába, amelyek esetleg csak néhány hónapig tervezik az élettartamot.
A kis kódolású nagyszabású fejlesztői eszközökbe való beépítése lehetővé teszi, hogy kihasználja a szervezet különböző részeinek készségeit, és kiépítse az úgynevezett "fúziós csapatokat", ahol a különböző csoportok együtt dolgoznak egy olyan alkalmazás vagy szolgáltatás létrehozásán, amely konkrét problémákat old meg. A fúziós csapat minden tagjának más felelőssége lesz: az egyik lehet a végfelhasználó, a másik egy kevés kódolást igénylő fejlesztő, a másik pedig a szolgáltatás API-k kezelése. Egy ilyen csapatnak nincs fix struktúrája; egy adott feladathoz szükséges emberekből áll. Még csak nem is kell találkozniuk - a projekt Slack- vagy Teams-csatornája elegendő lehet a leggyakoribb interakciókhoz.
Kevés kódolás kódként
Az újabb eszközök elkezdték megváltoztatni ezt, új kezelési koncepciókat és új kódmegosztási módszereket hoztak létre. Az egyik legfontosabb fejlemény a pusztán grafikus eszközöktől való elmozdulás, olyan új nyelvek kifejlesztésével, amelyek magukba foglalják a grafikus eszközökkel megvalósítható dolgok nagy részét, és lehetővé teszik számunkra, hogy alacsony kódolású fejlesztésünket CI/CD-folyamatokba és közösségi kódolási eszközökbe, például GitHubba építsük.
Ezek az új nyelvek jobban megfelelnek a kevés kódolást igénylő környezeteknek, és olyan fogalmakra épülnek, mint az SQL-lekérdezések és az Excel-képletek. Gyorsan megértik, deklaratív és funkcionális programozási koncepciók keverékét használják. A felhasználók továbbra is dolgozhatnak a megszokott grafikus fejlesztői környezetükben, és az eredményül kapott kódot automatikusan elmenthetik a git-tárolóikba. Eközben a fejlesztők gyorsan áttekinthetik ezt a kódot az IDE-jükben vagy a kódszerkesztőikben. Nincs váltási kontextus, és mindenki megkapja azokat az eszközöket, amelyekre szüksége van a szükséges munkák elvégzéséhez. A fejlesztők ezután CI/CD-folyamatok segítségével gyorsan tesztelhetik a kódot a kiadás előtt, és kereshetik a showstoppereket és más kritikus hibákat.
LÁSD: Webfejlesztő vagy CTO, mely technológiai munkákban a leggyorsabban nő a fizetés?
A kevés kódolást kódoló kódolás lehetővé teszi a gépi tanuláson alapuló kódolási asszisztensek új generációjának előnyeinek kihasználását. Az olyan technológiák, mint az OpenAI Codex modellje, képesek azonosítani a kód gyakori mintáit, és javaslatokat tenni annak alapján, hogy más alkalmazások hogyan oldják meg a hasonló problémákat. Ha például egy kevés kódolást igénylő alkalmazásnak szüksége van egy ERP-rendszerhez csatlakoztatott rácsvezérlésre, javaslatokat tehet a megfelelő kapcsolati karakterláncok felépítésére vagy a lekérdezés legjobb formázására.
Ez egy olyan megközelítés, amely még mindig a kezdeti időkben jár, de ígéretesnek tűnik. Nem annyira arról van szó, hogy egy mesterséges intelligencia kódot ír neked, hanem arról, hogy egy mesterséges intelligencia alapú páros programozó javaslatokat tesz a kód javítására. Ahogy megtanulja, hogyan hozhat létre kevés kódolást igénylő alkalmazásokat, ez egy olyan gyakorlókerék, amelyet lassan elindulhat, csökkentve a mesterséges intelligenciától és a fejlesztői erőforrásoktól való függőséget.
Láthatjuk, hogyan végződik ez, mivel az alapvető rendszerfejlesztők API-kat építenek, a mesterséges intelligenciák finomítják ezek használatát, a felhasználók pedig gyorsan követik javaslataikat, hogy kiváló minőségű alkalmazásokat készítsenek, amelyek jól működnek és nem zavarják a többi felhasználót.
Az alkalmazások fejlesztésében és használatában bekövetkezett nagy változás kezdetén vagyunk, és a kevés kódolást igénylő erőforrás lesz az új forradalom fő mozgatórugója. A kevés kódolást igénylő és a mainstream alkalmazásfejlesztés közötti kapcsolatnak szorosnak kell lennie. Mivel azonban a kevés kódolást a fejlesztési erőforrások hiányára való reagálás egyik módjaként tekintik, ez egy olyan kapcsolat, amelyet óvatosan kell kezelni. Ezért jó látni, hogy a szervezetek elismerik a hatékony API-kezelés, a kódmegosztást javító eszközök használata, a szervezeti határokon átívelő új csapatstruktúrák és végül a gépi tanulás használatának fontosságát a kockázatok csökkentése és a termelékenység növelése érdekében.