Ing dina liyane aku diwawancarai pangembang JavaScript sing nglamar kanggo posisi senior. Kolega, sing uga ana ing wawancara, njaluk calon nulis fungsi sing bakal nggawe panjalukan HTTP lan, yen ora kasil, coba maneh kaping pirang-pirang.
Dheweke nulis kode kasebut langsung ing papan, mula cukup kanggo nggambar kira-kira. Yen dheweke mung nuduhake yen dheweke ngerti babagan masalah kasebut, kita mesthi bakal kepenak. Nanging, sayangΓ©, dheweke ora bisa nemokake solusi sing sukses. Banjur kita, chalking munggah kanggo kasenengan, mutusakΓ© kanggo nggawe tugas sing sethitik luwih gampang lan takon marang kanggo nguripake fungsi karo callbacks menyang fungsi dibangun ing janji.
Nanging sayang. Ya, ketok yen dheweke tau nemoni kode kaya ngono. Dheweke ngerti ing istilah umum carane kabeh bisa ana. Kabeh sing dibutuhake yaiku sketsa solusi sing nuduhake pemahaman konsep kasebut. Nanging, kode sing ditulis calon ing papan kasebut ora ana gunane. Dheweke duwe ide sing ora jelas babagan janji apa sing ana ing JavaScript lan ora bisa nerangake kenapa dheweke dibutuhake. Kanggo junior iki mesthi bisa diapura, nanging dheweke ora cocog maneh karo posisi senior. Kepiye pangembang iki bisa ndandani kewan omo ing rantai janji sing rumit lan nerangake marang wong liya apa sing ditindakake?
Pangembang nganggep kode sing wis digawe kanthi jelas
Sajrone proses pangembangan, kita terus-terusan nemoni bahan sing bisa direproduksi. Kita nransfer fragmen kode supaya kita ora kudu nulis maneh saben wektu. Mulane, kanthi fokus kabeh perhatian kita ing bagean-bagean kunci, kita ndeleng kode sing wis rampung sing bisa digunakake minangka bukti - kita mung nganggep yen kabeh bakal bisa ditindakake.
Lan biasane ora bisa, nanging yen ana masalah, ngerti mekanika luwih akeh tinimbang mbayar.
Mangkono, calon kita kanggo posisi pangembang senior nganggep obyek janji dadi jelas. Dheweke bisa uga duwe ide babagan carane ngatasi nalika kedadeyan ing kode wong liya, nanging dheweke ora ngerti prinsip umum lan ora bisa mbaleni nalika wawancara. Mungkin dheweke ngelingi fragmen kasebut kanthi ati - ora angel banget:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Aku uga nindakake - lan kita bisa uga wis rampung ing sawetara titik. Dheweke mung ngeling-eling sepotong kode supaya bisa digunakake ing karyane, nanging mung duwe ide umum babagan cara kerjane kabeh ing kana. Nanging yen pangembang bener-bener ngerti konsep kasebut, dheweke ora kudu ngelingi apa-apa - dheweke mung bakal ngerti carane nindakake, lan bakal gampang ngasilake kabeh sing dibutuhake ing kode.
Bali menyang oyod
Ing 2012, nalika dominasi kerangka front-end durung ditetepake, jQuery mrentah jagad iki, lan aku maca buku kasebut. , pangarang dening John Resig, pangripta jQuery.
Buku iki mulang maca carane nggawe jQuery dhewe saka ngeruk lan menehi kaweruh unik menyang proses pamikiran sing mimpin kanggo nggawe perpustakaan. Ing taun-taun pungkasan, jQuery wis ilang popularitas, nanging aku isih nyaranake buku kasebut. Sing paling nggumunake babagan dheweke yaiku perasaan sing terus-terusan yen aku bisa mikir kabeh iki dhewe. Langkah-langkah sing diterangake dening penulis katon logis banget, mula aku wiwit mikir yen aku bisa nggawe jQuery kanthi gampang yen aku mung mudhun.
Mesthi, ing kasunyatan, aku ora bakal bisa nindakake kaya iki - aku bakal mutusake manawa angel banget. Solusi dhewe bakal katon banget prasaja lan naif kanggo bisa, lan aku bakal nyerah. Aku bakal nggolongake jQuery minangka barang sing jelas, ing operasi sing bener sing sampeyan kudu percaya kanthi wuta. Salajengipun, aku meh ora bakal mbuwang wektu delving menyang mekanika perpustakaan iki, nanging mung bakal nggunakake minangka jinis kothak ireng.
Nanging maca buku iki nggawe aku dadi wong sing beda. Aku wiwit maca kode sumber lan nemokake yen implementasine saka akeh solusi nyatane transparan, malah ketok. Ora, mesthi, kanggo mikir bab kaya iki ing dhewe iku crita liyane. Nanging sinau kode wong liya lan ngasilake solusi sing wis ana sing mbantu kita nggawe apa wae.
Inspirasi sing sampeyan entuk lan pola sing sampeyan wiwiti bakal ngganti sampeyan minangka pangembang. Sampeyan bakal nemokake manawa perpustakaan apik sing sampeyan gunakake lan sampeyan wis biasa mikir minangka artefak gaib ora bisa digunakake ing sihir, nanging mung ngrampungake masalah kanthi laconically lan akal.
Kadhangkala sampeyan kudu ngetung kode kasebut, nganalisa langkah demi langkah, nanging iki kepiye, kanthi langkah-langkah cilik lan konsisten, sampeyan bisa mbaleni dalan penulis menyang solusi kasebut. Iki bakal ngidini sampeyan nyilem luwih jero menyang proses coding lan menehi kapercayan luwih akeh babagan solusi sampeyan dhewe.
Nalika aku miwiti nggarap janji, aku kaya sihir murni. Banjur aku ngerteni manawa dheweke adhedhasar panggilan balik sing padha, lan jagad pamrogramanku dadi kuwalik. Dadi pola, tujuane kanggo nylametake kita saka callback, dhewe diimplementasikake nggunakake callback?!
Iki mbantu aku ndeleng prakara kasebut kanthi mripat sing beda-beda lan ngerti manawa iki dudu potongan kode sing abstruse ing ngarepku, kerumitan larangan sing ora bakal dakpahami sajrone uripku. Iki mung pola sing bisa dimangerteni tanpa masalah amarga penasaran lan kecemplung jero. Iki carane wong sinau kode lan tuwuh minangka pangembang.
Reinvent wheel iki
Dadi maju lan reinvent gembong: nulis kode data naleni dhewe, nggawe janji homegrown, utawa malah nggawe solusi manajemen negara dhewe.
Ora masalah yen ora ana sing bakal nggunakake kabeh iki - nanging saiki sampeyan ngerti carane nindakake. Lan yen sampeyan duwe kesempatan kanggo nggunakake pangembangan kasebut ing proyek sampeyan dhewe, mula umume apik banget. Sampeyan bakal bisa ngembangake lan sinau babagan liya.
Titik ing kene ora ngirim kode menyang produksi, nanging kanggo sinau sing anyar. Nulis implementasine dhewe saka solusi sing wis ana minangka cara sing apik kanggo sinau saka programer sing paling apik lan kanthi mangkono ngasah katrampilan sampeyan.
Source: www.habr.com