Hello, donya! Sawise sampeyan wis sinau kabeh sing perlu kanggo ngerti lan pungkasanipun njaluk bisa dadi intern utawa junior dev, sampeyan bisa uga santai, tengen? Ora. Kabeh mung diwiwiti kanggo sampeyan ... Sampeyan diubengi dening akeh sing anyar lan ora bisa dingerteni. Carane ora meneng metu saka gapura? Mekaten ingkang badhe kita rembag dinten punika. Ing artikel iki, aku pengin nganalisa kesalahane wong anyar sing umum lan menehi saran, adhedhasar pengalamanku dhewe, babagan cara nyingkiri. Dadi, ayo miwiti tanpa ado maneh:
1. Wedi njaluk bantuan saka kolega sing luwih berpengalaman
Kita kabeh manungsa. Kita kabeh wedi katon bodho, utamane ing mripate kanca-kanca anyar sing luwih berpengalaman. Nalika pangembang njupuk proyek sing sepisanan, dheweke asring dipandu dening rasa wedi iki lan, kanthi swara sing abot, mundur menyang awake dhewe, nyoba ngerteni kabeh dhewe. Kajaba iku, wong bisa diubengi dening kolega sing luwih berpengalaman, sing, kanthi mangkono, bisa nuding dheweke ing arah sing paling njanjeni, mbantu supaya luwih akeh kesalahan lan "bumps ing sirah" sing ora perlu. Dadi elinga: aja wedi takon. Sampeyan pamula lan kabeh wong ngerti iki kanthi becik. Yen sampeyan takon, ora ana sing bakal ngalahake sampeyan nganggo teken. Mbok menawa malah ngelawan bakal kelakon: sampeyan bakal dadi kanca karo kolega luwih cepet lan wiwit seneng komunikasi aktif karo wong-wong mau. aku Bakal ngomong luwih akeh: luwih akeh sampeyan takon lan ngrembug macem-macem masalah teknis, luwih cepet sampeyan bisa ngilangi kulit anyar sing ijo lan dadi ahli ing lapangan sampeyan. Lan siji liyane saran. Aja dadi wong liyoStackOverflow . Aku khusus ngomong babagan takon babagan sumber daya iki. Ing tangan siji, butuh sawetara wektu kanggo njaluk jawaban kanggo pitakonan sampeyan. Nanging ing sisih liya, sampeyan bisa kanthi cepet sinau macem-macem pendekatan kanggo ngrampungake masalah sampeyan lan ndeleng saka sudut sing rada beda. Aku uga pengin nyathet yen ana keuntungan praktis kanggo nulis komentar / jawaban lan nulis pitakonan sing njlentrehake babagan pitakonan StackOverflow saka pangembang liyane: sampeyan entuk kesempatan kanggo debat lan nyelidiki luwih jero babagan masalah kasebut, ora kanggo nambah karma.
2. Ora nyoba nggoleki informasi dhewe
Kesalahan iki bisa dianggep minangka flipside saka sing sadurunge.Maksudku nalika sampeyan miwiti ngganggu kanca lan kenalan babagan saben masalah utawa hiccup sing sampeyan temoni. Njaluk iku apik, nanging aja nganti overboard karo pitakonan. Yen ora, wong bisa uga ngganggu sampeyan. Yen sampeyan bingung babagan apa wae, sing kudu ditindakake yaiku ngleksanani katrampilan telusuran ing mesin telusuran sing paling apik - Google. Wong liya wis nemoni akeh kesalahan sing ora bisa dingerteni lan masalah liyane. Lan sampeyan bakal kaget banget yen sampeyan nggoleki pitakonan sampeyan ing google lan ndeleng jumlah wong sing kenal karo masalah sing padha, lan sing wis nampa jawaban lengkap sing bisa ditrapake ing karya sampeyan dhewe. Mulane sampeyan bakal kerep krungu rekan sampeyan mangsuli nganggo "Google it". Nganggo' Aja gelo karo jawaban iki - kolega sampeyan dudu guru pribadi sing kudu menehi kabeh subtleties ing lapangan kerja sampeyan. Expanses Internet tanpa wates bakal dadi mentor sampeyan. Kadhangkala programer uga diarani minangkawong sing nganggo sabuk ireng ing panelusuran Google . Dadi yen kita duwe "hiccup", kita pisanan google masalah. Yen solusi ora bisa ditemokake (iki arang, nanging kedadeyan), mung banjur kita miwiti takon kolega. Pitakonan langsung yaiku kanggo njaluk saran babagan pendekatan sing kudu sampeyan pilih kanggo ngatasi masalah luwih saka apa sing bakal ditindakake nalika sampeyan nabrak kacepetan utawa pesen kesalahan sing ora dingerteni. Sawise kabeh, dheweke bisa uga bisa ndeleng ngluwihi pendekatan sing disenengi lan langsung prédhiksi ing endi pendekatan apa wae bakal mimpin ing jangka panjang.
3. Nyalin lan nempel kanthi wuta
Nanging masalah googling lan solusi duwe pitfalls. Contone, nyalin lan nempel kanthi wuta .Iki biasane kedadeyan nalika sampeyan nemokake masalah sing padha (nanging bisa uga ora padha) lan solusi sing gegandhengan, contone, ing StackOverflow. Sampeyan njupuk solusi iki lan nyalin-lan-tempel tanpa luwih rinci. Banjur sampeyan utawa rekan kerja sampeyan nemokake sawetara bug aneh utawa prilaku sing ora bener ing kode sampeyan. Lan ora ana sing bisa langsung ngira saka ngendi asale. Pungkasane, mesthi, papan sing nganggo kode sing disalin bakal ditemokake, lan sampeyan mesthi ora bakal dipuji kanggo solusi sampeyan. Mulane, yen sampeyan nemokake solusi sing wis siap ing StackOverflow (utawa ing ngendi wae), sampeyan kudu ngerti apa, kepiye, lan ngapa. Mbok google fungsi sing cocog lan maca dokumentasi kanggo iku. Lan mung sawise sampeyan nindakake, sampeyan kudu nambahake menyang proyek sampeyan.
4. Kelet karo solusi sing salah
Nalika nulis solusi, sampeyan bakal sok dong mirsani sing terus dadi liyane lan liyane rumit, pungkasanipun tekan ing buntu. Banjur sampeyan nyoba nggawe solusi kasebut luwih njlimet supaya bisa digunakake tinimbang golek alternatif liyane sing luwih cocog. Mungkin sampeyan aran kaya sampeyan nandur modhal akeh wektu lan gaweyan lan mulane mutusaké sing, ora ketompo apa, sampeyan ora bakal nyerah lan sampeyan bakal ngatasi masalah karo pendekatan sing wis ana. Iki dudu sikap sing bener. Paling ora ing pemrograman. Cepet sampeyan nyoba pendekatan sing beda, luwih akeh wektu sampeyan bakal ngirit ing pungkasan. Dadi aja wedi nyoba lan nyoba pendekatan liyane, preduli saka jumlah wektu sampeyan wis nandur modhal saiki. Apa maneh, kanthi nyoba macem-macem pendekatan lan nyilem luwih jero menyang subyek, sampeyan
5. Wedi takon babagan tugas sing saiki
Nggarap proyek pangembangan piranti lunak biasane mung kanggo nindakake tugas tartamtu. Contone, ing Jira. Tugas-tugas kasebut ora mesthi digarisake kanthi jelas lan rinci. Deskripsi tugas biasane ditulis dening pimpinan tim, sing uga mung manungsa. Padha bisa lali kanggo nambah soko utawa gagal kanggo akun kasunyatan sing ora menowo iki utawa fungsi sing. Utawa mbok menawa sampeyan ora duwe akses menyang proyek kasebut (contone, akses menyang database, server log, lan liya-liyane). Lan saiki, sampeyan wis nampa tugas, sinau kanggo luwih saka sawetara jam, nanging sampeyan isih lungguh ana, mandeng ing layar bingung. Tinimbang terus gagal nyoba mangertos iki, sampeyan kudu miwiti njaluk klarifikasi utawa tuntunan saka sapa wae sing nggawe tugas kasebut. Contone, ing app sing digunakake tim kanggo komunikasi (contone, Microsoft Teams), sampeyan bisa takon utawa menehi komentar langsung babagan tugas kasebut. Ing tangan siji, yen sampeyan nulis pitakonan sampeyan ing pesen pribadi, sampeyan bakal entuk jawaban luwih cepet, amarga wong kasebut bakal langsung ndeleng pitakonan sampeyan. Ing sisih liya, kanthi takon pitakonan ing Jira, sampeyan nggawe bukti yen sampeyan nindakake, yaiku, nganalisa masalah kasebut. Ana cara kanggo nyepetake proses iki: takon pitakonan sampeyan ing komentar ing Jira banjur ing DM, nyelehake link menyang komentar lan takon kanggo ndeleng.
6. Nempatake pangarepan sing ora nyata ing pimpinan tim
Maneh, iki minangka sisih flip saka titik sadurunge. Pimpinan tim minangka kepala tim pangembangan. Minangka aturan, pimpinan tim sampeyan nggunakake akeh wektu kanggo macem-macem jinis komunikasi. Nanging, dheweke uga nulis kode supaya ora lali kabeh babagan pemrograman. Kaya sing sampeyan ngerteni, urip pimpinan tim sibuk banget. Narik lengen klambi tim sampeyan saben-saben sampeyan kudu wahing, mesthi ora bakal nyenengake. Mbayangno saben anggota tim bombarding timbal karo Bunch saka pitakonan. Sing bisa nggawe wong edan, ta? Lan yen sampeyan numpuk akeh pitakonan, pimpinan tim sampeyan kudu nglampahi akeh wektu kanggo mangsuli sampeyan. Apa sing bisa ditindakake kanggo nyuda jumlah pitakonan sing diarahake marang pimpinan tim:
Jelajahi dokumentasi proyek kanthi luwih jero kanggo nyuda jumlah buta.
Langsung pitakonan sampeyan menyang anggota tim liyane. Padha bisa uga akrab karo fungsi iki minangka timbal, utawa bisa uga luwih akeh, amarga fungsi kasebut paling mungkin ditulis dening salah sijine.
Utawa, sampeyan bisa ndeleng ing anotasi ing IDE kanggo sapa lan nalika kode ing baris tartamtu pungkasan diganti. Sing persis carane sampeyan bisa ngerteni sapa sing paling cocog kanggo takon sampeyan. Kaya sing wis dingerteni, nalika nerangake pitakon menyang pimpinan tim, kaya pitakon karo kanca-kanca, sampeyan kudu nyoba golek media sing seneng - aja wedi takon, nanging uga aja takon akeh. saka wong-wong mau.
7. Wedi review kode
A review kodeminangka tahapan sing kedadeyan sadurunge ngirim kode menyang aplikasi umum (menyang cabang sing dienggo bareng, contone, master utawa dev). Priksa iki ditindakake dening pangembang sing ora melu tugas, sing mripate seger bisa ndeteksi kesalahan, ora akurat, utawa cacat ing gaya kode sampeyan sing ora digatekake nalika sampeyan nulis kode sampeyan. Yen ana kritik, ditinggalake minangka komentar ing bagean tartamtu saka kode kasebut. Ing kasus iki, pangembang sing nulis kode kudu mbenerake kesalahan sing diidentifikasi ing review (utawa ngrembug keputusane karo reviewer, bisa uga ngyakinake dheweke yen dheweke bener). Banjur kode kasebut diajukake kanggo ditinjau maneh lan maneh nganti pamawas ora ana komentar maneh. Reviewer tumindak minangka "gateway" sadurunge kode dileksanakake. Tantangan kasebut yaiku akeh programer pemula nganggep review kode minangka kritik lan kutukan. Dheweke ora ngapresiasi ulasan kode lan wedi karo dheweke. Padha ora kudu. Ulasan kode persis apa sing ngidini kita nambah kode. Sawise kabeh, kita nampa informasi penting babagan apa sing kita tindakake salah lan apa sing kudu digatekake. Sampeyan kudu nimbang saben review kode minangka bagéan saka kurva learning, soko sing bisa mbantu dadi luwih apik. Nalika ana wong sing menehi komentar babagan kode sampeyan, dheweke nuduhake pengalaman lan praktik paling apik karo sampeyan. Aku wong ora pracaya sampeyan bisa dadi programmer apik tanpa njupuk review kode. Amarga sampeyan ora ngerti kualitas kode sampeyan lan manawa wong njaba sing berpengalaman bakal nuduhake kesalahan. t appreciate reviews kode lan wedi wong. Padha ora kudu. Ulasan kode persis apa sing ngidini kita nambah kode. Sawise kabeh, kita nampa informasi penting babagan apa sing kita tindakake salah lan apa sing kudu digatekake. Sampeyan kudu nimbang saben review kode minangka bagéan saka kurva learning, soko sing bisa mbantu dadi luwih apik. Nalika ana wong sing menehi komentar babagan kode sampeyan, dheweke nuduhake pengalaman lan praktik paling apik karo sampeyan. Aku wong ora pracaya sampeyan bisa dadi programmer apik tanpa njupuk review kode. Amarga sampeyan ora ngerti kualitas kode sampeyan lan manawa wong njaba sing berpengalaman bakal nuduhake kesalahan. t appreciate reviews kode lan wedi wong. Padha ora kudu. Ulasan kode persis apa sing ngidini kita nambah kode. Sawise kabeh, kita nampa informasi penting babagan apa sing kita tindakake salah lan apa sing kudu digatekake. Sampeyan kudu nimbang saben review kode minangka bagéan saka kurva learning, soko sing bisa mbantu dadi luwih apik. Nalika ana wong sing menehi komentar babagan kode sampeyan, dheweke nuduhake pengalaman lan praktik paling apik karo sampeyan. Aku wong ora pracaya sampeyan bisa dadi programmer apik tanpa njupuk review kode. Amarga sampeyan ora ngerti kualitas kode sampeyan lan manawa wong njaba sing berpengalaman bakal nuduhake kesalahan. re mengkono salah lan apa worth mbayar manungsa waé kanggo. Sampeyan kudu nimbang saben review kode minangka bagéan saka kurva learning, soko sing bisa mbantu dadi luwih apik. Nalika ana wong sing menehi komentar babagan kode sampeyan, dheweke nuduhake pengalaman lan praktik paling apik karo sampeyan. Aku wong ora pracaya sampeyan bisa dadi programmer apik tanpa njupuk review kode. Amarga sampeyan ora ngerti kualitas kode sampeyan lan manawa wong njaba sing berpengalaman bakal nuduhake kesalahan. re mengkono salah lan apa worth mbayar manungsa waé kanggo. Sampeyan kudu nimbang saben review kode minangka bagéan saka kurva learning, soko sing bisa mbantu dadi luwih apik. Nalika ana wong sing menehi komentar babagan kode sampeyan, dheweke nuduhake pengalaman lan praktik paling apik karo sampeyan. Aku wong ora pracaya sampeyan bisa dadi programmer apik tanpa njupuk review kode. Amarga sampeyan ora ngerti kualitas kode sampeyan lan manawa wong njaba sing berpengalaman bakal nuduhake kesalahan.
8. Propensity kanggo pancasan arcane
Macem-macem tugas/masalah asring duwe sawetara solusi sing beda. Lan saka kabeh solusi sing kasedhiya, pamula cenderung nggunakake sing paling rumit lan arcane. Lan sing masuk akal: programer anyar wingi sinau macem-macem algoritma, pola, lan struktur data, mula tangane gatel kanggo ngetrapake sawetara. Dipercaya kula, Aku kaya sing, supaya aku ngerti apa aku ngomong bab :) Aku wis kahanan ngendi aku wis ngleksanakake sawetara fungsi kanggo dangu. Ternyata rumit banget. Banjur pangembang senior nulis ulang kodeku. Mesthi, aku kasengsem banget kanggo ndeleng apa lan carane dheweke ngganti. Aku katon ing implementasine lan kaget carane akeh prasaja iku. Lan ana kode kaping telu kurang. Lan nggumunake, tes otomatis kanggo fungsi iki ora dicopot utawa diowahi! Ing tembung liyane, logika umum tetep padha. Saka iki, aku teka ing kesimpulan singsolusi paling akale tansah prasaja . Sawise kesadaran iki, coding dadi luwih gampang, lan kualitas kode saya mlumpat menyang tingkat sing luwih dhuwur. Banjur kapan migunani kanggo ngetrapake pola desain lan algoritma sing apik, sampeyan takon? Nalika nglamar bakal dadi solusi sing paling gampang lan kompak.
9. Reinventing setir
Roda minangka solusi awet sing diciptakake ing jaman biyen. Ing anti-pola iki, pangembang ngleksanakake solusi kepemilikan dhewe kanggo masalah sing wis ditanggulangi. Kadhangkala solusi sing wis ana iki luwih apik tinimbang apa sing ditindakake dening programmer. Minangka aturan, reinventing setir bakal mimpin kanggo wektu ilang lan ngurangi produktivitas, amarga solusi sing sampeyan nemokake bisa uga adoh saka sing paling apik, utawa, uga, sampeyan ora bisa nemokake siji ing kabeh. Sing jarene, kita ora bisa ngilangi kemungkinan nggawe solusi mandiri: yen kita nindakake, kabeh sing bakal ditinggalake yaiku program copy-and-paste. Programmer kudu dipandu kanthi bener dening tugas pemrograman khusus sing muncul kanggo ngrampungake kanthi cekap lan cepet, kanthi nggunakake solusi sing wis siap utawa nggawe solusi khusus. Ing tangan siji, ing universitas lan ing kursus online, kita bombarded karo macem-macem jinis tugas sing koyone dirancang kanggo bantuan kita reinvent gembong. Nanging mung sepisanan: Tujuan nyata ing kene yaiku ngembangake pamikiran algoritma lan penguasaan sintaksis basa sing luwih jero. Tugas kasebut uga mbantu sampeyan luwih ngerti algoritma lan struktur data, lan menehi katrampilan kanggo ngleksanakake mitra sing luwih canggih, yen perlu (iki kadhangkala perlu, nanging arang banget). Ing urip nyata, sampeyan ora perlu kanggo invent dhewe wheel ing mayoritas akeh banget saka kasus, wiwit wheel sing nyukupi kabutuhan wis watara kanggo dangu. Mungkin pengalaman sampeyan nyegah sampeyan ora ngerti babagan anane implementasine fungsi sing sampeyan butuhake. Ing kene sampeyan kudu njupuk saran sing diwenehake ing titik pisanan artikel iki, yaiku, njaluk bantuan kolega sing luwih berpengalaman. Dheweke bakal bisa nuntun sampeyan (contone, ngarahake sampeyan menyang arah sing bener ing panelusuran Google) utawa menehi saran implementasine tartamtu (contone, sawetara perpustakaan).
10. Gagal nulis tes
Kabeh pemula ora seneng tes nulis. Nanging kenapa kita kudu milih wong anyar, ing kene? Pangembang sing luwih berpengalaman uga ora seneng nulis tes, nanging luwih ngerti sebabe tes dibutuhake. Nalika sampeyan wis rampung ijo, sampeyan wonder apa sampeyan kudu nulis mau. Kabeh bisa, supaya ora ana kesalahan. Nanging kepiye sampeyan mesthekake yen owah-owahan sampeyan ora bakal ngrusak ing papan liya ing sistem kasebut? Kolega sampeyan ora bakal ngormati yen sampeyan nggawe owah-owahan sing nyebabake luwih akeh gawe piala tinimbang apik. Iki ngendi tes teka kanggo ngluwari kita. Sing luwih akeh kode aplikasi dijamin dening tes, luwih apik (iki diarani jangkoan kode utawa jangkoan tes). Yen aplikasi kasebut nduweni jangkoan tes sing apik, mula sampeyan bisa nindakake kabeh tes kanggo nemokake papan sing bakal dirusak dening kode sampeyan. Lan kaya sing dakkandhakake ing conto ing ndhuwur, nalika pangembang senior refactored kode, tes ora gagal. Iki amarga logika umum ora owah. Kita nggunakake tes kanggo nduduhake apa logika fungsi tartamtu wis diganti utawa ora. Dadi, sanajan sampeyan ora seneng nulis tes, mesthi migunani lan migunani kanggo wektu sing ditindakake.
11. Komentar sing akeh banget
Akeh pangembang nandhang sangsara saka perfeksionisme, lan pemula ora ana sing istiméwa. Kadhang-kadhang kasebut mung siji aspek saka kecenderungan iki nalika wiwit menehi komentar babagan kabeh wong lan kabeh. Malah nggawe komentar sing ora perlu, amarga kode kasebut jelas banget:
Cat cat =newCat();// Cat object
Ora kabeh programer pemula langsung nyadari yen kode komentar ora mesthi apik, amarga komentar sing berlebihan clutter kode lan nggawe angel diwaca. Lan yen kode diganti, nanging komentar lawas ora dianyari? Banjur dheweke mung bakal nyasarké lan mbingungake kita. Banjur kok nggawe komentar kaya ngono? Biasane, kode sing ditulis kanthi apik ora perlu dikomentari , amarga kabeh wis jelas lan bisa diwaca. Yen sampeyan kudu nulis komentar, mula sampeyan wis ngrusak keterbacaan kode kasebut lan nyoba ngatasi kahanan kasebut. Pendekatan sing paling apik yaiku nulis kode sing bisa diwaca saka wiwitan, yaiku kode sing ora mbutuhake komentar. Aku uga ora bisa ngomong nanging kudu ngetutake konvensi jeneng sing bener kanggo metode, variabel, lan kelas. Iki aturanku: Komentar sing paling apik yaiku ora ana komentar utawa jeneng sing bener sing nggambarake fungsi ing aplikasi sampeyan kanthi jelas.
12. Jenenge ala
Newbies sing muter cepet lan ngeculke ing menehi jeneng kelas, variabel, cara, etc. Contone, dening nggawe kelas kang jeneng ora njlèntrèhaké waé. Utawa padha ngumumake variabel kanthi jeneng sing cendhak, kaya x . Padha nalika loro variabel liyane jenenge n lan ydigawe, ngelingi apa x tanggung jawab kanggo dadi angel banget. Ngadhepi kahanan iki, sampeyan kudu mikir kanthi ati-ati babagan kode kasebut, nganalisa ing mikroskop (mbok menawa nggunakake debugger), sinau fungsi supaya mung ngerti apa sing kedadeyan. Iki ngendi konvensi jeneng sing bener sing dakkandhakake ing ndhuwur bisa mbantu. Jeneng sing bener nambah keterbacaan kode, saéngga nyuda wektu sing dibutuhake kanggo familiarize dhewe karo kode kasebut, amarga nggunakake metode luwih gampang nalika jenenge nggambarake fungsine. Kabeh ing kode kasusun saka jeneng (variabel, metode, kelas, obyek, file, etc.), Dadi titik iki dadi penting banget nalika nggawe bener, kode resik. Sampeyan kudu eling yen jeneng kasebut kudu menehi makna, contone, kenapa variabel kasebut ana, apa sing ditindakake, lan carane digunakake. Aku bakal nyathet luwih saka sepisan yen komentar sing paling apik kanggo variabel yaiku menehi jeneng sing apik. Kanggo sinau sing luwih jero babagan komentar lan jeneng sing bener, aku nyaranake maca klasik sing langgeng:"Kode Bersih: Buku Pegangan Kerajinan Piranti Lunak Agile" dening Robert Martin . Ing cathetan kasebut, bagean pisanan artikel iki (renunganku) wis rampung. Diterusake...
Dadi, ayo miwiti tanpa ado maneh:
Maksudku nalika sampeyan miwiti ngganggu kanca lan kenalan babagan saben masalah utawa hiccup sing sampeyan temoni. Njaluk iku apik, nanging aja nganti overboard karo pitakonan. Yen ora, wong bisa uga ngganggu sampeyan. Yen sampeyan bingung babagan apa wae, sing kudu ditindakake yaiku ngleksanani katrampilan telusuran ing mesin telusuran sing paling apik - Google. Wong liya wis nemoni akeh kesalahan sing ora bisa dingerteni lan masalah liyane. Lan sampeyan bakal kaget banget yen sampeyan nggoleki pitakonan sampeyan ing google lan ndeleng jumlah wong sing kenal karo masalah sing padha, lan sing wis nampa jawaban lengkap sing bisa ditrapake ing karya sampeyan dhewe. Mulane sampeyan bakal kerep krungu rekan sampeyan mangsuli nganggo "Google it". Nganggo' Aja gelo karo jawaban iki - kolega sampeyan dudu guru pribadi sing kudu menehi kabeh subtleties ing lapangan kerja sampeyan. Expanses Internet tanpa wates bakal dadi mentor sampeyan. Kadhangkala programer uga diarani minangkawong sing nganggo sabuk ireng ing panelusuran Google . Dadi yen kita duwe "hiccup", kita pisanan google masalah. Yen solusi ora bisa ditemokake (iki arang, nanging kedadeyan), mung banjur kita miwiti takon kolega. Pitakonan langsung yaiku kanggo njaluk saran babagan pendekatan sing kudu sampeyan pilih kanggo ngatasi masalah luwih saka apa sing bakal ditindakake nalika sampeyan nabrak kacepetan utawa pesen kesalahan sing ora dingerteni. Sawise kabeh, dheweke bisa uga bisa ndeleng ngluwihi pendekatan sing disenengi lan langsung prédhiksi ing endi pendekatan apa wae bakal mimpin ing jangka panjang.
Iki biasane kedadeyan nalika sampeyan nemokake masalah sing padha (nanging bisa uga ora padha) lan solusi sing gegandhengan, contone, ing StackOverflow. Sampeyan njupuk solusi iki lan nyalin-lan-tempel tanpa luwih rinci. Banjur sampeyan utawa rekan kerja sampeyan nemokake sawetara bug aneh utawa prilaku sing ora bener ing kode sampeyan. Lan ora ana sing bisa langsung ngira saka ngendi asale. Pungkasane, mesthi, papan sing nganggo kode sing disalin bakal ditemokake, lan sampeyan mesthi ora bakal dipuji kanggo solusi sampeyan. Mulane, yen sampeyan nemokake solusi sing wis siap ing StackOverflow (utawa ing ngendi wae), sampeyan kudu ngerti apa, kepiye, lan ngapa. Mbok google fungsi sing cocog lan maca dokumentasi kanggo iku. Lan mung sawise sampeyan nindakake, sampeyan kudu nambahake menyang proyek sampeyan.
Lan yen sampeyan numpuk akeh pitakonan, pimpinan tim sampeyan kudu nglampahi akeh wektu kanggo mangsuli sampeyan. Apa sing bisa ditindakake kanggo nyuda jumlah pitakonan sing diarahake marang pimpinan tim:
