1980-luvulla helpoin tapa aloittaa nörtti-taistelu oli julistaa, että suosikki ohjelmointikielesi oli paras. C, Pascal, Lisp, Fortran? Ohjelmoijat selittivät tuntikausia tarkalleen, miksi heidän erityinen tapansa luoda jos-sitten-muu-lauseke oli parempi kuin sinun.
Se oli silloin. Nykyään syntaksia ja rakennetta sisältävät taistelut ovat suurelta osin ohi, koska maailma on lähentynyt muutaman yksinkertaisen standardin mukaan. C-, Java- ja JavaScripti-, kihara- ja sulkujen sekä vastaavan väliset erot ovat vähäisiä. Mielenkiintoisia keskusteluja konekirjoituksesta ja sulkemisista on edelleen olemassa, mutta suurin osa niistä on kiistanalaisia, koska automaatio sulkee aukon. Jos et pidä tietotyypin määrittämisestä, tietokoneella on hyvät mahdollisuudet päättää tarkalleen mitä tarkoitit. Jos pomosi haluaa JavaScriptiä, mutta pidät Javaista, ristikääntäjä muuntaa kaikki staattisesti kirjoitetut Java-tiedostosi pienennettyyn JavaScriptiin, joka on valmis suoritettavaksi selaimessa. Miksi taistella, kun tekniikalla on selkämme?
Nykyään mielenkiintoinen toiminta on kehyksissä. Kun istuin muiden Johns Hopkinsin yliopiston tiedekunnan jäsenten kanssa suunnitelemaan uutta kurssia, kehykset hallitsivat keskustelua. Onko kulmikas parempi kuin Ember? Onko Node.js kaikki?
Suunnittelimme kyselykurssin, joka tutkii tärkeimpien Internetin perustana olevien ohjelmistopakettien arkkitehtuuria. Tämä oli toiminnan keskipiste, joka ansaitsi kyselykurssin, jossa tutkitaan tärkeimpien nykypäivän Internetiä ympäröivien ohjelmistopakettien arkkitehtuuria.
Tässä mielessä kehykset ovat uusia ohjelmointikieliä. Niistä löytyy nykypäivän koodauksen uusimmat ideat, filosofiat ja käytännön käytännöt. Jotkut syttyvät, mutta monista on tulossa ohjelmoinnin uusi peruselementti. Tässä on seitsemän puolta, jotka ruokkivat kehyssuuntausta - ja tekevät kehyksistä uuden suosikkipesäkkeen nerd-taisteluille.
Suurin osa koodauksesta merkitsee yhteen API: ta
Oli aika, jolloin ohjelmiston kirjoittaminen tarkoitti kaiken ohjelmointikielen tuntemuksen hyödyntämistä puristaaksesi koodista kaiken irti. Oli järkevää hallita osoittimien, toimintojen ja laajuuden monimutkaisuus - koodin laatu riippui oikeasta toiminnasta. Nykyään automaatio hoitaa suuren osan tästä. Jos jätät arvottomia lauseita koodiin, älä huoli. Kääntäjä poistaa kuolleen koodin. Jos jätät viitteitä roikkumaan, roskien keräilijä todennäköisesti selvittää sen.
Lisäksi koodauksen käytäntö on erilainen nyt. Suurin osa koodista on nyt pitkä API-puheluiden rivi. Tietojen muotoilua tapahtuu ajoittain API-puhelujen välillä, mutta jopa nämä työtehtävät hoitavat yleensä muut API: t. Muutama onnekas saa kirjoittaa älykkään, bittimäisen, osoittimella jongleerauskoodin koneidemme suolille, mutta useimmat meistä työskentelevät ylempien kerrosten kanssa. Suoritamme yksinkertaisesti putkia API: n välillä.
Tämän vuoksi on tärkeämpää ymmärtää, miten API toimii ja mitä se voi tehdä. Mitä tietorakenteita se hyväksyy? Kuinka algoritmit käyttäytyvät, kun tietojoukko kasvaa? Tällaiset kysymykset ovat nykypäivän ohjelmoinnissa keskeisempiä kuin syntaksia tai kieltä koskevat kysymykset. Itse asiassa on olemassa joukko työkaluja, joiden avulla on helppo kutsua rutiinia yhdellä kielellä toisesta. C-kirjastojen linkittäminen esimerkiksi Java-koodiin on suhteellisen helppoa. API: iden ymmärtäminen on tärkeää.
Jättiläisten hartiat kannattaa seisoa
Kuvittele, että sinusta on tullut Erlangin tai jonkin muun uuden kielen opetuslapsi. Päätät, että se tarjoaa parhaan alustan vakaan, virheettömän sovelluksen kirjoittamiseen. Tämä on hieno näkemys, mutta voi kestää vuosia, ennen kuin kirjoitat kaiken Java- tai PHP-koodin uudelle valitsemallesi kielelle. Toki, koodisi voi osoittautua dramaattisesti paremmaksi, mutta onko se lisäajan arvoinen?
Kehysten avulla voimme hyödyntää edessämme tulleiden kovaa työtä. Emme ehkä pidä heidän valitsemastaan arkkitehtuurista ja voimme riitauttaa toteutuksen yksityiskohdista, mutta on tehokkaampaa tukahduttaa valituksemme ja löytää tapa elää erojen kanssa. On niin paljon helpompaa periä kaikki hyvät ja huonot koodipohjat kehyksen kautta. Kun otat macho-reitin kirjoittamalla kaiken itse uudella suosikkikielelläsi sen suosituimpien kehysten sijasta, et voi nauttia uuden valintasi kermasta yhtä nopeasti kuin yksinkertaisesti siirtyä kehysvalmistajille ja heidän sovellusliittymilleen.
Arkkitehtuurin tunteminen on tärkeätä, ei syntaksia
Kun suurin osa koodauksesta merkitsee yhteen API-kutsuja, ei ole paljon etua kielen omaleimaisuuden oppimisessa. Toki, sinusta voisi tulla asiantuntija siitä, kuinka Java alustaa staattiset kentät kohteissa, mutta sinun olisi paljon parempi selvittää, kuinka hyödyntää Lucene-, JavaDB- tai jonkin muun koodipinon tehoa. Voisit viettää kuukausia törmäämällä Objective-C-kääntäjien optimointirutiiniin, mutta uusimman Applen ydinkirjaston oppiminen tekee koodistasi todella huutavan. Saat paljon oppimalla kehyksen valinnaisia yksityiskohtia kuin sen kielen syntaksin, jolla kehys lepää.
Suurin osa koodistamme viettää suurimman osan ajastaan kirjastojen sisäisissä silmukoissa. Kielen yksityiskohtien saaminen voi auttaa, mutta tietäen, mitä kirjastoissa tapahtuu, voi maksaa dramaattisesti.
Algoritmit hallitsevat
Ohjelmointikielen oppiminen voi auttaa taistelemaan muuttujiin kätketyllä datalla, mutta se vie vain niin pitkälle. Todellinen este on saada algoritmit oikein, ja kehykset määrittelevät ja toteuttavat ne yleensä.
Monet ohjelmoijat ymmärtävät, että on vaarallista ja turhaa viettää aikaa vakioalgoritmien ja tietorakenteiden uudelleen käyttöönottoon. Toki, saatat pystyä virittämään sen hieman tarpeisiisi, mutta riskin tehdä hienovaraisia virheitä. Kehyksiä on testattu laajasti vuosien varrella. Ne edustavat yhteistä sijoitustamme ohjelmistoinfrastruktuuriin. Ei ole monia esimerkkejä siitä, milloin on järkevää "irrottaa ruudukosta", heittää syrjään toisten ahkera työ ja rakentaa algoritminen mökki omin käsin.
Oikea lähestymistapa on tutkia kehyksiä ja oppia käyttämään niitä parhaalla mahdollisella tavalla. Jos valitset väärän tietorakenteen, voit muuttaa lineaarisen työn sellaiseksi, joka vie aikaa, joka on syötekoon neliöllinen funktio. Se on iso vaivaa, kun menet virus.
