Verkkoarkkitehtuurit

Tämä sivu on osa valekoodarin käsikirjaa, joka opastaa miten huijaat työhaastattelijan uskomaan, että ymmärrät oikeasti jotain ohjelmoinnista.

Millainen on hyvä verkkoarkkitehtuuri?

Tämä on hyvin hankala kysymys varsinkin jos se esitetään kylmiltään kertomatta mitään taustoja järjestelmästä mihin se liittyy. Nouse kuitenkin itsevarmasti ylös, etsi lähin tussitaulu ja piirrä siihen seuraavanlainen kuva:

Piirrettyäsi kuvan voit alkaa selittämään sen eri osia haastattelijalle. Muista myös mainita, että kyseessä on pelkistetty yleiskuva, jota täytyy aina muokata tapauskohtaisesti. Aloita kertomalla palvelinosasta ja sen tekniikoista seuraavaa; tällä hetkellä suosituin tekniikka palvelinpuolen toteuttamiseksi on Microsoftin MVC-kirjasto. Tämän lisäksi on myös muita vaihtoehtoja riippuen siitä kuinka paljon halutussa järjestelmässä halutaan painottaa sujuvaa käyttäjäkokemusta. Tässä kohtaa voi kerätä lisäpisteen mainitsemalla esimerkkinä node.js:n uusista ja jännittävistä tavoista toteuttaa palvelinpuoli kevyesti. Jos haastattelija alkaa kysymään tarkentavia kysymyksiä joita et ymmärrä voit ohjata hänet takaisin isoon kuvaan toteamalla palvelinpuolen toteutustekniikan olevan vähäpätöinen yksityiskohta.

Seuraavaksi ala kertomaan selaimen pään toteutustekniikoista. Tällä hetkellä on vallalla trendi, jossa liiketoimintalogiikkaa siirtyy yhä enemmän pois palvelimelta käyttäjän selaimeen. Tällä saavutetaan parempi käyttäjäkokemus, koska sivu reagoi käyttäjän toimiin huomattavasti nopeammin kuin sovellus joka on toteutettu puhtaasti palvelimen päähän. Tähän kohtaan voit kertoa, että suosittuja kirjastoja selainpään toteuttamiseksi ovat tällähetkellä knockout.js ja AngularJS. Lisäpisteen voit kalastella paheksumalla sitä, että vielä julkaisematon AngularJS 2.0 on nimetty AngularJS:ksi kun kyseessä on täysin erilainen ja uusi kirjasto, joka ei ole taaksepäin yhteensopiva. Tässä kohtaa on myös hyvä todeta, että lähes poikkeuksetta selainpään perusarkkitehtuurimallina käytetään tällähetkellä MVVM:ää ja sen eri muunnelmia. 

Tietokantakerroksesta voit kertoa, että se ei ole kovin mielenkiintoinen, koska se piilotetaan kuitenkin oliomapperillä kuten EntityFramework tai NHibernate. Tietokantapalvelin voi olla oikeastaan melkein mikä vain, mutta toki kun toimitaan Microsoftin alustalla niin SQL Server tai Azure SQL on melko luonnollinen valinta. Voit taas kerätä lisäpisteitä mainitsemalla ohimennen, että modernissa verkko-ohjelmistossa voitaisiin tehokkuussyistä dokumenttitietokantaa kuten RavenDB, Azure DocumentDB tai MongoDB SQL:n sijasta.

Jos haastattelija ei ole vielä tässä vaiheessa kysynyt kohteliaasti palkkatoivettasi ja ohjannut sinua ulko-ovelle olet voitolla. Onnistuit selittämään verkkoarkkitehtuurin yleiskuvan ja vaikuttamaan uskottavalta. Vaikein on kuitenkin edessä, koska et saa sekoittaa ulkoaopettelemiasi asioita kun tarkentavat kysymykset alkavat.

Vastauksia tarkentaviin kysymyksiin löytyy seuraavien linkkien takaa: [Ei vielä kirjoitettu 12.9.2015]

• Mihin sijoittaisit liiketoimintalogiikan?
• Miten estetään se, että koodia ei tarvitse kirjoittaa kahteen kertaan; ensin palvelimelle ja sitten selaimeen?
• Miten testattavissa asiat ovat piirtämässäsi mallissa?
• Millainen on hyvä ketterä arkkitehtuuri ja miten se eroaa tavallisesta arkkitehtuurista?
• Mitä eroa on WebAPI:n REST-palveluilla ja WCF-palveluilla?
  • Milloin WCF on hyvä ratkaisu ja milloin huono?
  • Milloin REST on hyvä ratkaisu ja milloin huono?
• Miten valitaan parhaiten käyttötapaukseen sopiva suunnittelumalli? MVVM, MVC, MVP
  • Miten mallit eroavat toisistaan ja miksi?
  • Mihin käyttötapaukseen mikäkin malli sopii ja miksi?
  • Miten paljon eri malleista on testattavissa automaattisesti?