Analisis kesalahan khas programer pemula: bagean 1

Hello, donya! Sawise sampeyan wis sinau kabeh sing perlu lan pungkasanipun njaluk nyewo minangka intern utawa junior, sampeyan bisa uga santai, tengen? Ora ketompo carane iku! Kabeh mung diwiwiti ... Ana akeh perkara anyar lan ora bisa dimangerteni ing saubengé sampeyan, lan carane ora ngaco kaya iki langsung metu saka gapura? Sing bakal kita pirembagan dina iki. Ing artikel iki, aku pengin ndeleng kesalahan umum sing ditindakake dening pamula lan menehi sawetara tips saka pengalamanku dhewe babagan carane nyingkiri. Dadi, ayo miwiti tanpa ado maneh:

1. Wedi njaluk bantuan kanca sing luwih berpengalaman

Kita kabeh manungsa, lan kita kabeh wedi katon bodho, utamane ing mripate kanca-kanca sing mentas dicithak, luwih berpengalaman. Sawise entuk pakaryan sing sepisanan, para pangembang asring nyerah marang rasa wedi iki lan ora bisa nyingkirake awake dhewe, nyoba ngerteni kabeh dhewe. Ing wektu sing padha, wong bisa diubengi dening kolega sing luwih berpengalaman, sing bakal bisa nuntun dheweke ing dalan sing paling bener, sing bakal mbantu supaya ora luwih akeh kesalahan lan "bumps" sing ora perlu. Mulane, elinga: aja wedi takon: sampeyan pamula, lan kabeh wong ngerti iki kanthi sampurna. Yen sampeyan takon, ora ana sing bakal ngalahake sampeyan. Mbok menawa malah sebaliknya: sampeyan bakal luwih cepet kekancan karo kolega lan wiwit komunikasi luwih aktif karo dheweke. Aku bakal ngomong luwih akeh: luwih sampeyan takon lan ngrembug macem-macem masalah teknis, luwih cepet sampeyan bisa metu saka sepatu pemula ijo lan tuwuh dadi ahli ing lapangan sampeyan. Lan siji liyane saran. Aja nglirwakake StackOverFlow . Ing konteks iki, maksudku takon babagan sumber daya iki. Ing tangan siji, butuh sawetara wektu kanggo njaluk jawaban kanggo pitakonan sampeyan. Nanging ing sisih liya, sampeyan bisa langsung sinau babagan sawetara pendekatan kanggo ngrampungake masalah saiki lan ndeleng saka perspektif sing rada beda. Aku uga kaya Wigati sing nulis komentar-jawaban, njlentrehake pitakonan kanggo pitakonan ing StackOverFlow saka pangembang liyane, saliyane plus ing karma, wis entuk manfaat praktis: sampeyan duwe kesempatan kanggo ngrembug lan ngerti masalah iki luwih jero.

2. Aja nyoba golek informasi dhewe

Mungkin kesalahan iki minangka sisih mbalikke saka sing sadurunge. Maksudku nalika sampeyan miwiti narik kolega lan kenalan karo saben masalah utawa masalah. Takon iku apik, nanging sampeyan ora kudu adoh banget karo pitakonan, yen ora, sampeyan bisa uga bosen. Babagan pisanan sing kudu ditindakake yen sawetara titik sing ora bisa dingerteni yaiku nggunakake katrampilan telusuran ing mesin telusuran sing paling apik - Google. Ana wong sing wis nemoni akeh kesalahan sing ora bisa dingerteni lan masalah liyane. Lan sampeyan bakal kaget banget yen sampeyan Google lan ndeleng jumlah wong sing kenal karo masalah sing padha, lan sing wis nampa jawaban lengkap sing cocog kanggo digunakake ing karyane. Adhedhasar iki, sampeyan bisa kerep krungu kolega njawab pitakonan - "Google iku." Sampeyan ora kudu gelo karo jawaban iki, amarga sawise kabeh, kolega sampeyan dudu guru pribadhi sing ngirimake kabeh seluk-beluk lapangan kerja sampeyan. Expanses Internet tanpa wates bakal mbantu sampeyan kanthi bimbingan kasebut. Kadhangkala programmer uga diarani wong sing nduweni sabuk ireng ing panelusuran Google . Mulane, nalika kita macet, kita pisanan Google masalah, lan yen ora ana solusi sing ditemokake (jarang, nanging kedadeyan), banjur kita miwiti takon karo kolega. Sampeyan kudu takon langsung, ora nalika ana sawetara kesalahan utawa kesalahan sing ora bisa dingerteni, nanging nalika milih pendekatan kanggo ngatasi masalah. Sawise kabeh, dheweke bisa ndeleng ngluwihi sampeyan lan langsung ngandhani kepiye cara iki utawa pendekatan kasebut bisa ditindakake ing jangka panjang.

3. Copy-paste wuta

Nanging Googling masalah lan, kanthi mangkono, solusi kasebut duwe pitfalls. Contone, blind copy-paste . Iki biasane kedadeyan yen sampeyan nemokake masalah sing padha (nanging bisa uga ora padha) lan ing ngisor iki, contone, ing StackOverFlow ana solusi. Sampeyan njupuk solusi iki, nyalin lan nempel dhewe, tanpa rinci banget. Banjur sampeyan utawa rekan proyek sampeyan nemokake sawetara bug aneh utawa prilaku sing salah saka fungsi sampeyan. Lan langsung ora ana sing ngerti saka ngendi asale sikil. Banjur, mesthi, papan kanthi kode iki bakal ditemokake, lan sampeyan mesthi ora bakal dipuji kanggo keputusan iki. Mulane, yen sampeyan nemokake solusi sing wis siap ing StackOverFlow (utawa ing papan liya), sampeyan kudu nganalisa kanthi rinci, apa iku, kepiye lan kenapa. Mbok google fungsi iki lan katon ing dokumentasi kanggo. Lan mung sawise ngleksanakake menyang proyek sampeyan.

4. Mbuwang solusi sing salah

Nalika nulis solusi, kadhangkala kedadeyan dadi saya rumit lan pungkasane tekan buntu. Lan sampeyan nyoba kanggo complicate liyane lan liyane supaya piye wae ngatasi masalah iki nggunakake pendekatan iki tinimbang nyoba kanggo golek liyane, alternatif liyane bisa digunakake. Mungkin sampeyan mung ngrasakake energi lan wektu sing sampeyan gunakake, mula sampeyan mutusake: apa wae, aja nyerah, nanging ngrampungake masalah kasebut kanthi cara iki. Iki dudu pendekatan sing bener. Paling ora ing pemrograman. Cepet sampeyan nyoba pendekatan liyane, luwih akeh wektu sampeyan bakal nyimpen. Dadi, aja wedi nyoba lan nyoba pendekatan liyane, sanajan sampeyan wis nandur modal wektu iki. Kajaba iku, iki bakal dadi poin kanggo pengalaman sampeyan, amarga sampeyan bakal nyoba sawetara pendekatan lan luwih sinau babagan iki.

5. Wedi takon babagan tugas saiki

Nggarap proyek biasane teka kanggo ngrampungake sawetara tugas (Tugas). Contone, ing Jira . Lan tugas kasebut ora mesthi diterangake kanthi rinci lan jelas. Biasane ditulis dening pimpinan tim, lan iki uga wong, yen kedadeyan kasebut. Padha uga lali kanggo nambah soko utawa ora njupuk menyang akun sing ora banget menowo karo fungsi iki utawa sing. Ya, utawa sampeyan ora duwe akses menyang proyek kasebut (contone, akses menyang Database, server log, lan liya-liyane). Lan saiki, sawise nampa tugas, sinau kanggo luwih saka sawetara jam, sampeyan isih njagong lan katon ing layar ing bewilderment. Lan tinimbang terus ngerteni iki ora ana gunane, sampeyan kudu miwiti takon / njlentrehake pitakonan marang sing nggawe tugas iki. Contone, ing aplikasi sing digunakake kanggo komunikasi ing tim (contone, Microsoft Teams) utawa langsung minangka komentar ing tugas iki. Ing tangan siji, yen sampeyan nulis pitakonan ing pesen pribadi, paling kamungkinan jawaban bakal luwih cepet, amarga wong bakal langsung ndeleng pitakonan. Ing sisih liya, kanthi takon pitakonan ing Jira, sampeyan duwe bukti yen sampeyan nindakake, yaiku, nganalisa masalah kasebut. Ana cara kanggo nyepetake proses iki: takon pitakonan minangka komentar ing Jira lan ngirim link kanggo komentar iki ing pesen pribadi karo panjalukan kanggo dipikir.

6. Ngarepake banget saka pimpinan tim

Maneh, iki minangka sisih flip saka titik sadurunge. Pimpinan tim yaiku wong sing dadi kepala tim pangembangan. Minangka aturan, umume wektu anggota tim kasebut digunakake kanggo macem-macem jinis komunikasi. Lan ing wektu sing padha, dheweke uga nulis kode supaya ora lali apa kabeh. Kaya sing sampeyan ngerteni, iki minangka karakter sing sibuk banget. Lan twitching gedhe banget kanggo saben wahing jelas ora bakal nggawe dheweke seneng. Mbayangno yen saben anggota tim dibombardir karo akeh pitakonan. Dadi sampeyan bisa edan, ta? Lan ora bakal nggumunake yen kanthi akeh pitakonan saka sampeyan, dheweke bakal mangsuli sampeyan nganti suwe. Apa sing bisa ditindakake kanggo nyuda jumlah pitakon menyang pimpinan tim:

• Sinau dokumentasi proyek iki luwih jero kanggo nyuda jumlah buta.
• Takon pitakonan kanggo anggota tim liyane. Iku cukup bisa sing padha menowo karo fungsi iki minangka timbal, utawa malah luwih, amarga paling kamungkinan siji saka wong-wong mau wrote fungsi sing.

Utawa, ing IDE sampeyan bisa ndeleng ing anotasi: sapa lan nalika pungkasan ngganti kode ing baris tartamtu. Kanthi cara iki, kita bakal ngerti sapa sing paling bener kanggo takon pitakonan iki. Kaya sing wis dingerteni, nalika takon karo pimpinan tim, uga nalika takon karo kanca-kanca, sampeyan kudu nyoba njaga tegese emas - aja wedi takon, nanging uga ora ngganggu kanthi jumlah sing akeh banget.

7. Wedi review kode

Review kode utawa review kode minangka tahapan sadurunge ngunggah kode menyang aplikasi umum (menyang cabang umum, contone, master utawa dev). Priksa iki ditindakake dening pangembang sing ora ana hubungane karo tugas iki, sing bisa, kanthi tampilan anyar, nemokake kesalahan, ora akurat utawa kekurangan ing gaya kode sing ora digatekake ing tahap wiwitan pangembangan. Yen ana komentar, ditinggalake minangka komentar menyang bagean tartamtu saka kode kasebut. Ing kasus iki, pangembang sing nindakake tugas iki kudu mbenerake kesalahane miturut review (utawa ngrembug keputusane karo reviewer, bisa uga ngyakinake dheweke babagan bener keputusane). Sawisé iku, kirim maneh kanggo review, lan sateruse nganti reviewer ora komentar. Reviewer dadi "filter" sadurunge ngunggah kode. Dadi, akeh programer pemula nganggep review kode minangka kritik lan kutukan. Dheweke ora ngajeni lan wedi karo dheweke, lan iku salah. Iku review kode sing ngidini kita nambah kode kita. Sawise kabeh, kita nampa informasi penting babagan apa sing salah lan apa sing kudu digatekake. Sampeyan perlu kanggo ndeleng saben review kode minangka bagéan saka learning, soko sing bisa mbantu nambah. Nalika ana wong menehi komentar babagan kode sampeyan, dheweke bakal nuduhake pengalaman, praktik paling apik. Kanggo kula, sampeyan ora bisa dadi programmer sing apik tanpa njupuk review kode. Amarga sampeyan ora ngerti carane apik kode lan apa ana kesalahane ana saka sudut pandang saka wong experienced saka njaba.

8. Cenderung kanggo solusi abstruse

Asring tugas / masalah sing beda bisa duwe sawetara solusi sing beda. Lan kabeh solusi sing kasedhiya, pamula biasane nggunakake sing paling rumit lan "abstruse". Lan bener: yen programmer anyar wingi sinau macem-macem algoritma, pola, struktur data, tangane gatel kanggo ngetrapake salah sijine. Ya, lan aku pengin, supaya ngomong, nyatakake aku. Pracayaa, aku kaya ngono lan aku ngerti apa sing dakkandhakake :) Aku duwe kahanan sing saya suwe saya nulis siji fungsi sing dadi rumit banget. Banjur ditulis maneh dening pangembang tingkat Senior +. Mesthi, aku kasengsem kanggo ndeleng apa lan carane dheweke ngganti. Aku katon ing implementasine lan kaget carane akeh prasaja dadi. Lan kode wis dadi telu kurang. Lan ing wektu sing padha, tes kanggo fungsi iki ora owah lan ora gagal! Tegese, logika umum tetep padha. Saka iki aku teka menyang kesimpulan sing: solusi paling akale tansah prasaja . Sawise kesadaran iki, nulis kode dadi luwih gampang, lan dadi luwih dhuwur. Banjur, nalika sampeyan kudu nggunakake pola lan algoritma, sampeyan takon? Banjur, nalika nggunakake bakal dadi cara sing paling gampang lan kompak.

9. Penemuan sepedha

Konsep iki uga dikenal minangka penemuan setir. Intine dumunung ing kasunyatan manawa pangembang ngetrapake solusi dhewe kanggo masalah sing wis ana solusi, lan kaping pirang-pirang luwih apik tinimbang sing diciptakake dening programmer. Minangka aturan, nyipta sepeda dhewe bakal nyebabake mundhut wektu lan nyuda efisiensi karya pangembang, amarga solusi bisa uga ora ditemokake sing adoh saka sing paling apik, utawa ora bisa ditemokake. Ing wektu sing padha, kita ora bisa ngilangi kemungkinan keputusan independen. Programmer kudu njelajah kanthi bener tugas sing bisa katon ing ngarepe supaya bisa ngrampungake kanthi cekap lan pas wektune, nggunakake solusi sing wis siap utawa nggawe dhewe. Ing tangan siji, ing universitas lan kursus, kita dibombardir karo macem-macem tugas sing kudu mbantu kita nggawe sepeda. Nanging iki mung ing kawitan marketing. Nyatane, tujuan iki kanggo ngembangake pamikiran algoritma lan penguasaan sintaksis basa sing luwih jero. Lan tugas kasebut uga mbantu luwih ngerti algoritma / struktur, lan, yen perlu, menehi katrampilan kanggo ngetrapake analog sing luwih maju (nanging iki arang banget dibutuhake). Ing gesang nyata, ing akèh-akèhé saka kasus, ora perlu kanggo invent setir dhewe, minangka analog wis dawa ana sing gawe marem kabutuhan kita. Mungkin, amarga pengalaman sampeyan, sampeyan ora bakal ngerti babagan anane implementasine fungsi iki utawa sing sampeyan butuhake. Ing kene sampeyan kudu nggunakake titik pisanan saka artikel iki, yaiku, njaluk bantuan saka kolega sing luwih berpengalaman. Dheweke bakal bisa nuntun sampeyan (contone, menehi saran menyang arah menyang Google) utawa menehi saran implementasine tartamtu (perpustakaan tartamtu).

10. Aja nulis tes

Kabeh pemula ora seneng karo tes nulis. Kepiye babagan pemula: wong sing ora anyar uga ora seneng nulis tes, nanging luwih ngerti sebabe dibutuhake. Nalika sampeyan wis rampung ijo, sampeyan mikir: kenapa nulis? Kabeh bisa digunakake, lan ora ana kesalahan. Nanging kepiye sampeyan bisa yakin manawa owah-owahan sampeyan ora bakal ngrusak bagean liya ing sistem kasebut? Kolega sampeyan ora bakal ngormati yen sampeyan nindakake owah-owahan sing ngganggu luwih akeh tinimbang entuk manfaat. Iki ngendi tes teka kanggo ngluwari. Luwih akeh aplikasi dilindhungi dening tes, luwih apik (uga disebut persentase jangkoan). Yen aplikasi kasebut uga dilindhungi dening tes, kanthi mbukak kabeh, sampeyan bisa nemokake papan sing bisa rusak amarga owah-owahan sampeyan. Lan kaya sing dakkandhakake ing conto ing ndhuwur, nalika refactoring fungsi, tes ora gagal, lan kabeh amarga logika umum ora owah. Iki tegese tes uga bisa nuduhake apa logika fungsi tartamtu wis diganti utawa ora. Dadi, sanajan sampeyan ora seneng nulis tes, ana keuntungan sing ora diragukan saka dheweke, lan entuk wektu sing dibutuhake.

11. Kakehan komentar

Akeh pangembang nandhang sangsara saka perfeksionisme, lan para pamula ora ana sing istiméwa. Nanging kadhangkala efek samping saka kepinginan iki yaiku dheweke mulai menehi komentar babagan kabeh wong lan kabeh. Malah sing ora perlu, amarga wis jelas banget:

Cat cat = new Cat(); // cat Object

Ora kabeh programer pemula langsung nyadari yen kode komentar ora mesthi apik, amarga kode kasebut bakal dadi luwih rame lan angel diwaca. Apa yen kode diganti, nanging ora ana komentar? Pranyata dheweke bakal ngapusi kita lan mung mbingungake kita. Apa banjur komentar kaya ngono? Biasane, kode sing ditulis kanthi apik ora perlu komentar , amarga kabeh sing ana ing kono wis jelas lan bisa diwaca. Yen sampeyan nulis komentar, tegese sampeyan wis ngrusak readability kode lan nyoba kanggo Gamelan metu kahanan. Pendekatan sing paling apik yaiku nulis kode sing bisa diwaca sing ora kudu ditambah karo komentar. Aku uga ora bisa ora nyebutake jeneng metode, variabel lan kelas sing bener, yaiku, aturan sing aku tindakake dhewe: Komentar sing paling apik yaiku ora ana komentar, lan tinimbang, jeneng sing bener sing nggambarake iki kanthi jelas. utawa fungsi kasebut ing aplikasi sampeyan.

12. Jenenge ala

Asring, pamula falsify jeneng kelas, variabel, cara, etc Contone, nalika padha nggawe kelas kang jeneng ora njlèntrèhaké waé ing kabeh. Utawa variabel digawe kanthi jeneng cendhak, kaya x , lan nalika rong variabel liyane sing jenenge n lan y digawe , dadi angel banget kanggo ngelingi apa sing ditindakake x . Ing kasus kaya mengkono, sampeyan kudu kasebut kanthi teliti, mikir kode lan sinau fungsi iki ing mikroskop (mbok menawa nggunakake debugger a) supaya mung ngerti apa sing kedados ana. Iki minangka jeneng sing bener ing kode sing dakkandhakake ing ndhuwur bisa mbantu. Jeneng sing bener nambah keterbacaan kode kasebut, mula ngirit wektu kanggo familiarization, amarga luwih gampang nggunakake metode sing jeneng kasebut nggambarake fungsine. Ing kode, kabeh kasusun saka jeneng (variabel, metode, kelas, obyek file, lan sapiturute), titik iki dadi penting banget nalika nggawe kode sing bener lan resik. Sampeyan kudu eling yen jeneng kasebut kudu menehi makna: kenapa, umpamane, variabel kasebut ana, apa sing ditindakake lan cara digunakake. Lan aku bakal nyathet maneh lan maneh yen komentar sing paling apik kanggo njlentrehake variabel yaiku jeneng sing bener. Kanggo sinau sing luwih jero babagan komentar lan jeneng sing bener, aku menehi saran supaya maca klasik sing langgeng: "Kode sing resik. Penciptaan, analisis lan refactoring, Robert Martin . Ing cathetan iki, bagean pisanan artikel iki (refleksi) wis rampung. Diterusake…