Programmēšana

7 iemesli, kāpēc ietvarstruktūras ir jaunās programmēšanas valodas

Astoņdesmitajos gados vienkāršākais veids, kā sākt nerd cīņu, bija paziņot, ka jūsu iecienītākā programmēšanas valoda ir vislabākā. C, Pascal, Lisp, Fortran? Programmētāji stundām ilgi skaidroja, kāpēc viņu īpašais klauzulas veidošanas veids ir pārāks par jūsu veidu.

Tas bija toreiz. Mūsdienās cīņas ar sintaksi un struktūru lielā mērā ir beigušās, jo pasaule ir saplūdusi pēc dažiem vienkāršiem standartiem. Atšķirības starp semikoliem, cirtainajām iekavām un jebko C, Java un JavaScript ir nelielas. Joprojām pastāv interesantas debates par mašīnrakstīšanu un slēgšanu, taču lielākā daļa no tām ir strīdīgas, jo automatizācija novērš plaisu. Ja jums nepatīk norādīt datu tipu, pastāv lielas iespējas, ka dators varēs secināt tieši to, ko domājāt. Ja jūsu priekšnieks vēlas JavaScript, bet jums patīk Java, savstarpējs kompilators pārveidos visu jūsu statiski ierakstīto Java par minimizētu JavaScript, kas ir gatavs darbam pārlūkprogrammā. Kāpēc jācīnās, kad tehnoloģijai ir mūsu mugura?

Šodien interesanta darbība ir ietvaros. Kad es apsēdos kopā ar citiem mācībspēkiem Džona Hopkinsa universitātē, lai plānotu jaunu kursu, sarunā dominēja ietvari. Vai leņķiskais ir labāks par Emberu? Vai tas viss ir Node.js?

Mēs izstrādājām aptaujas kursu, kas izpētītu vissvarīgāko programmatūras pakotņu arhitektūru, kas ir interneta pamats. Tas bija darbības centrs, kas ir vērts aptaujas kursam, kurā tiktu pētīta vissvarīgāko programmatūras pakotņu arhitektūra, kas aptver mūsdienu internetu.

Šajā ziņā ietvari ir jaunās programmēšanas valodas. Tajos atrodamas mūsdienu kodēšanas jaunākās idejas, filozofijas un praktiskās iespējas. Daži aizdegas, bet daudzi kļūst par jaunajiem pamatelementiem programmēšanā. Šeit ir septiņi aspekti, kas veicina ietvara tendenci un padara ietvarus par jauno iecienītāko neredzamo cīņu karsto vietu.

Lielākā daļa kodēšanas veido API savienošanu

Bija laiks, kad programmatūras rakstīšana nozīmēja izmantot visas savas zināšanas par programmēšanas valodu, lai maksimāli izspiestu kodu. Bija jēga apgūt rādītāju, funkciju un darbības jomas sarežģītību - koda kvalitāte bija atkarīga no pareizas darbības. Mūsdienās automatizācija lielā mērā tiek galā ar šo problēmu. Ja kodā atstājat nevērtīgus paziņojumus, neuztraucieties. Sastādītājs izdzēš mirušo kodu. Ja atstājat norādes karājošām, atkritumu savācējs, iespējams, to izdomās.

Turklāt kodēšanas prakse tagad ir atšķirīga. Lielākā daļa kodu tagad ir gara API izsaukumu rinda. Laiku pa laikam notiek datu formatēšana starp API izsaukumiem, taču pat šos darbus parasti apstrādā citas API. Daži laimīgie dabū uzrakstīt gudru, mazliet bakstāmu, žonglējošu kodu mūsu mašīnu zarnām, taču lielākā daļa no mums strādā ar augstākiem slāņiem. Mēs vienkārši vadām cauruli starp API.

Tāpēc svarīgāk ir saprast, kā darbojas API un ko tā var darīt. Kuras datu struktūras tā pieņem? Kā rīkojas algoritmi, kad datu kopa palielinās? Šādi jautājumi ir svarīgāki mūsdienu programmēšanā nekā jautājumi par sintaksi vai valodu. Patiešām, tagad ir vairāki rīki, kas atvieglo rutīnas izsaukšanu vienā valodā no citas. Tas ir salīdzinoši vienkārši, piemēram, saistīt C bibliotēkas ar Java kodu. Svarīga ir API izpratne.

Milžu pleciem ir vērts stāvēt

Iedomājieties, ka esat kļuvis par Erlangas vai citas jaunas valodas mācekli. Jūs izlemjat, ka tā piedāvā vislabāko platformu stabilas, bez kļūdām saturošas lietotnes rakstīšanai. Tas ir jauks noskaņojums, taču var paiet gadi, līdz jūs pārrakstīsit visu Java vai PHP pieejamo kodu savā jaunākajā izvēlētajā valodā. Protams, jūsu kods varētu izrādīties dramatiski labāks, bet vai tas ir vērts papildu laiku?

Rāmji ļauj mums izmantot to cilvēku smago darbu, kuri nāca mūsu priekšā. Mums var nepatikt viņu izvēlētā arhitektūra, un mēs varam strīdēties par ieviešanas detaļām, taču efektīvāk ir apslāpēt mūsu sūdzības un atrast veidu, kā sadzīvot ar atšķirībām. Izmantojot sistēmu, ir daudz vieglāk pārmantot visu koda labo un slikto. Paņemot mačo maršrutu, rakstot visu pats savā iecienītajā jaunajā valodā, nevis vienā no tā populārākajiem ietvariem, neļausit izbaudīt jaunās izvēles krēmu tik ātri, kā tas būtu vienkārši atlikt ietvara veidotājiem un viņu API.

Svarīga ir arhitektūras pārzināšana, nevis sintakse

Kad lielākajā daļā kodēšanas tiek apvienoti API izsaukumi, valodas īpatnību apgūšanā nav daudz priekšrocību. Protams, jūs varētu kļūt par ekspertu, kā Java inicializē statiskos laukus objektos, taču jums būtu daudz labāk izdomāt, kā izmantot Lucene vai JavaDB vai kādas citas kodu kaudzes spēku. Jūs varētu pavadīt mēnešus, ķēpājoties ar Objective-C kompilatoru optimizēšanas kārtību, taču, apgūstot jaunākās Apple pamatbibliotēkas sīkumus, jūsu kods patiešām liks kliegt. Jūs daudz tālāk apgūsiet ietvara izvēlīgās detaļas, nevis valodas sintaksi, uz kuras balstās ietvars.

Lielākā daļa mūsu koda lielāko daļu laika pavada bibliotēku iekšējās cilpās. Valodas detaļu pareiza iegūšana var palīdzēt, taču, zinot, kas notiek bibliotēkās, tas var dramatiski atmaksāties.

Dominē algoritmi

Apgūstot programmēšanas valodu, varat palīdzēt žonglēt ar mainīgajos glabātajiem datiem, taču tas jūs aizved tikai tik tālu. Patiesais šķērslis ir algoritmu pareizība, un tos parasti nosaka un ievieš ietvari.

Daudzi programmētāji saprot, ka ir bīstami un tērēt laiku, atkārtoti ieviešot standarta algoritmus un datu struktūras. Protams, jūs varētu to mazliet pielāgot savām vajadzībām, taču jūs riskējat pieļaut smalkas kļūdas. Gadu gaitā rāmji ir plaši pārbaudīti. Tie pārstāv mūsu kolektīvos ieguldījumus programmatūras infrastruktūrā. Nav daudz piemēru, kad ir jēga “iet nost no režģa”, mest pie malas citu smago darbu un ar savām divām rokām uzbūvēt algoritmisko kabīni.

Pareizā pieeja ir izpētīt ietvarus un uzzināt, kā tos izmantot savā labā. Ja izvēlaties nepareizu datu struktūru, jūs varētu pārvērst lineāro darbu par tādu, kas prasa laiku, kas ir ievades lieluma kvadrātiskā funkcija. Tas ir liels apgrūtinājums, kad esat vīrusu pārņēmis.

$config[zx-auto] not found$config[zx-overlay] not found