Ma olen juba pikka aega tegelenud veebirakenduste arendamisega. Tõeliselt pikka aega. Oma esimesed veebirakendused lõin ma keskkonnas Lotus Domino , kui sõna «google» ei olnud veel tegusõna, ja internetis infokogumiseks kasutasid inimesed Yahoo! ja Ramblerit. Mina kasutasin Infoseek’i — neil oli kitsendav otsing ja vähem kaootiline kasutajaliides kui Yahoo-l.

Rakenduste arendamine, igasuguste rakenduste, mitte ainult veebirakenduste, on loominguline töö. Harva keegi vaidlustab selle väite. Kuid ilu loomingus, see on nagu praktika teaduslikus tunnetamises — tõe kriteerium. Kuid teaduslik praktika on objektiivne ja põhineb mõõtmistel, samas kui ilu on subjektiivne, sõltudes vaatajast. Nii ma küsisin endalt, mis on minu arvates ilus veebirakendus?

(Küpsenud, minu jaoks pole see esteetika, aga IMHO, naiselik vaade on sellel teemal kohasem, kui mehelik, sest see on — Küpsenud!)

Allpool jagan enda kriteeriume, mille alusel võib praegust veebirakendust pidada ilusaks. Väga subjektiivne esitlus, mis tuleneb minu isiklikust kogemusest. Võimalik, et mõnele tunduvad mu ilu kriteeriumid hoopis koleduse kriteeriumid. Ärge imestage, teie kogemus on lihtsalt erinev.

Ja kuna te juba allpool olete, siis palun olge kommentaarides ettevaatlikud. Kui te saate artikli lugemise lõpetada, kui selle sisu tundub teile kole või isegi vastik, siis mina, autori poole, pean lugema kõiki kommentaare.

Elukeskkond

Protokollid

Ma ei teagi, kas selle kriteeriumi eraldi välja toomine on vajalik. Veebirakendused elavad Internetis ja peavad vastama võrgu seadustele (protokollidele). Peamised protokollid Internetis on TCP ja IP. Nendele põhinevad paljud teised protokollid, kuid ma pean veebirakenduste jaoks kõige olulisemaks HTTP (või pigem selle laiendust HTTPS põhjal TLS). See tähendab, et ilus veebirakendus on saadaval HTTPS/TLS kaudu (võimalus — HTTP kaudu), kuid kõik teised protokollid (LDAP, RPC, IMAP4, POP3, SMTP, FTP, NNTP, …) muudavad selle vähem ilusaks iga uue toetatava protokolliga. Ise rakendus võib nende täiendavate protokollide abil kasutada väliseid ressursse.

Mis puudutab WebSocket, aga mul ei ole piisavalt kogemusi selle protokolli kasutamise osas veebirakendustes. See näeb välja ilus ja lubav, kuid kui stabiilne ja praktiline see on — seda ma ei oska öelda.

Brauserid

Veebirakendus toetab serveripoolt vaid ühe jalaga, teine ​​on kliendipool. Kliendipool on brauser. Kaasaegne brauser pakub palju erinevaid võimalusi,mida kaasaegne veebirakendus saab ja peab oma huvides kasutama. Kaunis veebirakendus kasutab kaasaegseid brauserite võimalusi ja ei pea töötama brauserites, mis neid ei toeta. Ma mõistan, et polyfillid on sunnitud lahendus, kuid see ei ole ilus. Lõppude lõpuks ei tohiks ainult arendajad kaasas käia kaasaegsete tehnoloogiatega, see puudutab ka kasutajaid ja äri.

KTP

Veebirakenduste loomiseks kasutatavate programmeerimiskeeltega on kõik väga keeruline. Veebirakenduste kliendipoolte jaoks on palju tehnoloogiaid, mis võimaldavad arendajal lihtsustada HTML/CSS/JS triadi loomist (kui need on kõik kaasaegsete brauserite arusaadavad). Kuid mina puutusin omal ajal tihedalt kokku GWT ja pean ilusaks, kui arendaja näeb brauseris algset koodi, mitte kompileerimise või transpileerimise tulemust. Seetõttu on webpack's ja sarnaste toodete kasutamine kliendikoodi genereerimiseks, IMHO, inetuks. Mida rohkem on brauseris täidetav kood sarnane arendaja loodud algkoodiga, seda parem. Ei usu? Proovi debugida tootmises GWT loodud koodi.

Serveripoolsetes rakendustes on rohkem vabadust (Java, PHP, Perl, Python, C#, Ruby jne), kuid mulle tundub ilusam, kui serveripoolses ja brauseris kasutatakse üht programmeerimiskeelt — JavaScripti. Lõppude lõpuks keel määrab mõtlemise, ja sarnaste mõtteviisidega meeskonnad on produktiivsemad.

Inimlikkus

Kaunis veebirakendus peab olema kasulik. Eelkõige peab see olema kasulik inimesele, kui lõppkasutajale. Seetõttu ei saa ma nimetada kauniks veebirakenduseks veebiteenuseid. Tüüpilisel inimesel (mitte veebi arendajal) on nende kasutamine keeruline. Veebiteenused on ilusad omal moel,

Kaunis veebirakendus peab omama intuitiivselt arusaadavat liidest. Võib vaielda, UI' kas see on päris subjektiivne asi. Kuid UX on palju lihtsam, kui kasutaja ei saa rakendust kasutada ilma ihaldatud RTFM — halb UX, inetuks veebirakenduseks. Kõige ilusamad veebirakendused selle kriteeriumi suhtes saavad lastega, kes ei oska veel lugeda, kergesti hakkama.

Tagasiulatuvus

Kaua aega tagasi oli programme võimalik kanda disketidel, nüüd - mälupulkadel või laadida otse Internetist. Tavalise rakenduse kopeerimine ja selle käivitamine teisel masinal on triviaalne ülesanne. Veebirakenduste puhul on olukord aga veidi eriline. Võrk on globaalne keskkond, kus pole vaja omada ühe ja sama veebirakenduse kloone. Internetis piisab ühest Facebookist, Twitterist, Instagramist, Mail.ru või Yandexist. Samas teemas võib olla erinevaid veebirakendusi, kuid erinevate sihtrühmadega (näiteks Facebook ja Vkontakte, Mail.ru ja Gmail, Google Maps ja Azure Maps). Nende veebirakenduste globaalsete kättesaadavuse tagamiseks on vajalikud, ütleme nii, mitte triviaalne.

Ma ei ole kunagi töötanud veebirakendustega sellisel tasemel arendajana ja ei kujuta ette, kuidas need seestpoolt toimivad. Nende veebirakenduste toimimise tagamiseks on vajalikud vastava ala spetsialistide meeskonnad ning eraldi andmekeskused. Mind imetleb inimeste võime koostööd teha sellisel skaalal ja selliste toodete loomine, kuid minu iluideaal on veebirakendus, mida saab käivitada eraldi sülearvutis.

Kaunis veebirakendus ei skaala mitte ainult ülespoole ja laiali (kasutajate jaoks), vaid ka allapoole ja sissepoole (arendajate jaoks).

„Amfiibsus“

Kaasaegsete veebirakenduste kasutamiseks kasutatakse kahte tüüpi seadmeid:

• arvutid (sülearvutid, lauaarvutid);
• mobiilsed seadmed (nutitelefonid ja tahvelarvutid);

Kusagil horisondi taga kumab veel „asjade Internet“, aga praegu on see nii.

Arvutid erinevad mobiilseadmetest sama palju kui maismaaolendid vees elavatest olenditest. Need on erinevad keskkonnad ja need seavad neis elavatele olenditele (programmidele) erinevad nõudmised. Kaunid veebirakendused ei ole need, mis sarnanevad amfiibidega, vaid need, mis vees - nagu kalad, maal - nagu loomad, ja õhus (SEO) - nagu linnud.

Ma pean 'amfiibsust' inetu, see on nagu proovida istuda kahel (SEO puhul - kolmel) toolil. Parem olla nagu Fiona Shrekist - päeva jooksul üks, öösel teine. Jah, see on kallim. Aga parem.

Cross-sharing

Olen juba maininud jaotises „Tagasiulatuv skaleeritavus“, et võrgu globaalsus võimaldab luua ühte veebirakendust kõigile. Seetõttu peaks iga veebirakendus mõnevõrra erinema teistest, et tagada oma ellujäämine. Sellegipoolest ütleb minu aastatepikkune kogemus Magento (e-kaubanduse jaoks mõeldud raamistik), et erinevate veebirakenduste vahel võib olla rohkem ühist, kui erinevusi. Kaunis veebirakendus ei peaks mitte ainult olema modulaarne, vaid ka jagama oma mooduleid teiste veebirakendustega. Teatud määral peegeldab seda ideed spetsifikatsioonidest JSR 168 ja JSR 286 ning sellised raamistikud nagu WordPress, Django ja sama Magento. Mida rohkem mooduleid veebirakenduses kasutatakse, seda ilusam see minu jaoks on. Ristjagamine võimaldab luua kvaliteetsemaid mooduleid ja seega stabiilsemaid veebirakendusi.

Moodulina ei mõtle ma sellistele teekidele nagu jQuery või RequireJS — pigem suurematele struktuuridele, nagu pluginad WordPress ja Django. Kuid ka teekide puhul kehtib väide, et teegi laialdane levik võimaldab selle kvaliteeti ja vastupidavust suurendada.

Harvardi arhitektuur

Harvardi arhitektuur, erinevalt praegusest valitsevast Princetoni arhitektuurist, eeldab koodi ja andmete lahusust. Arhitektuur ei saanud tuule tiibadesse, kuid idee iseenesest tundub mulle ilus. Eriti veebirakenduste jaoks. Iga staatika (HTML/CSS/JS/Pildid/…) on kood. Seda saab ja tuleb vahemälustada nii serveripoolselt kui ka kliendipoolselt. Andmed on REST/JSON (ilus) või SOAP/filestream (veidi vähem ilus). Või WebSockets/JSON (võib-olla parim variant, kuid ma pole proovinud).

Lokaliseerimine

On kaks asja, mis mind veebirakenduste arendamisel eriti muretsema panevad — see on mitmekeelne liides ja ajavööndid. Olen ise Lätist, meil on kasutusel kolm keelt: LV, RU, EN. Kaunis veebirakendus peaks võimaldama mitte ainult kasutada mitmeid keeli rakenduses, vaid ka laiendama kasutatavate keelte arvu väliste ressursside abil, nagu Crowdin. See kehtib ka moodulite kohta, millest veebirakendus on kokku pandud.

Kellaegade on lihtsad: kõik, mis asub serveris, lahkub serverist ja naaseb serverisse — UTC, kõik, mis kuvatakse kliendile — vastavalt kasutaja profiili ajavööndile. See on ilus.

Seppade töötoad asemel "Surma Tähed"

Amorani kord, igas suurimas linnas oli oma sepikoja. Võib-olla isegi mitmeid. Mõned paremad, mõned halvemad. Oli sepikoja meistreid, kes olid tuntud kogu maailmas, ja oli ka selliseid, kelle juurde mindi sunniviisiliselt. Läbisid sõjad, epideemiad, loodusõnnetused. Mõned linnad kadusid koos rahvaga. Kuid sepatööd elas edasi. Kadunud linnade asemele ehitati uusi, kuhu ilmusid samuti sepikojad.

Ja nüüd vaadake sellist teenust nagu DNS. Kui juurdeteenused kukuvad kokku, kõik maailm kannatab.

Minu arvates ei saa ilus veebirakendus olla sama suur kui Facebook või Mail.ru. See läheneb juba "Surma Tähele" nii ehitamiseks vajalike ressursside kui ka nende säilitamiseks vajalike ressursside osas. Jah, kui Facebook hävitatakse, ei kao inimkond, selle funktsioonid võtavad kiiresti üle teised rakendused (näiteks VK Venemaa ja lähiriikide territooriumil, Instagram, Twitter jne). Siiski, olulise osa inimkonna seottamine ühte rakendusse — see ei ole ilus. Veelgi enam, kui olemas on palju stabiilsemaid alternatiive (näiteks torrents).

Elulookirjeldus

Kui olete lõpuni lugenud ja tunnete segadust — "mida see oli?", siis väljendan teile oma siirat kaastunnet. Ma ei sundinud teid seda lugema. Ma lihtsalt proovisin oma mõtteid sõnadesse panna, et leida neid, kes mõtleksid samamoodi. Võib-olla suudan arutada nendega mõningaid aspekte ilusate veebirakenduste loomisel ja leida vastuseid oma küsimustele. Ja neid mul on palju.

Aitäh lugemise eest.

Allikas: habr.com