Analisis kesilapan tipikal pengaturcara pemula: bahagian 1

Hai dunia! Selepas anda mempelajari semua yang anda perlukan dan akhirnya diterima sebagai pelatih atau junior, anda mungkin boleh berehat, bukan? Tidak kira bagaimana keadaannya! Segala-galanya baru bermula... Terdapat banyak perkara baharu dan tidak dapat difahami di sekeliling anda, dan bagaimana untuk tidak mengacau seperti ini terus keluar dari pintu masuk? Itulah yang akan kita bincangkan hari ini. Dalam artikel ini, saya ingin melihat kesilapan biasa yang dilakukan oleh pemula dan memberikan beberapa petua dari pengalaman saya sendiri tentang cara mengelakkannya. Jadi, mari kita mulakan tanpa berlengah lagi:

1. Takut meminta bantuan rakan sekerja yang lebih berpengalaman

Kita semua manusia, dan kita semua takut kelihatan bodoh, terutamanya di mata rakan sekerja kita yang baru dicetak dan lebih berpengalaman. Sebaik sahaja mereka mendapat pekerjaan pertama mereka, pembangun sering menyerah kepada ketakutan ini dan tanpa ampun menarik diri, cuba memikirkan segala-galanya sendiri. Pada masa yang sama, seseorang boleh dikelilingi oleh rakan sekerja yang lebih berpengalaman, yang pada mulanya akan dapat membimbingnya di sepanjang jalan yang paling betul, yang akan membantu mengelakkan lebih banyak kesilapan dan "benjolan" yang tidak perlu. Oleh itu, ingat: jangan takut untuk bertanya soalan: anda seorang pemula, dan semua orang memahami ini dengan sempurna. Apabila anda bertanya, tiada siapa yang akan memukul anda dengan kayu. Mungkin juga sebaliknya: anda akan berkawan dengan rakan sekerja anda dengan lebih pantas dan mula berkomunikasi dengan lebih aktif dengan mereka. Saya akan mengatakan lebih banyak: lebih banyak anda bertanya dan membincangkan pelbagai isu teknikal, lebih cepat anda boleh keluar dari kasut seorang pemula hijau dan berkembang menjadi pakar dalam bidang anda. Dan satu lagi nasihat. Jangan abaikan StackOverFlow . Dalam konteks ini, saya maksudkan bertanya soalan mengenai sumber ini. Di satu pihak, ia mengambil sedikit masa untuk mendapatkan jawapan kepada soalan anda. Tetapi sebaliknya, anda boleh segera mempelajari beberapa pendekatan untuk menyelesaikan masalah semasa dan melihatnya dari perspektif yang sedikit berbeza. Saya juga ingin ambil perhatian bahawa menulis jawapan-komen, menjelaskan soalan kepada soalan mengenai StackOverFlow daripada pembangun lain, sebagai tambahan kepada karma, mempunyai faedah praktikal: anda mempunyai peluang untuk membincangkan dan memahami isu ini dengan lebih mendalam.

2. Jangan cuba mencari maklumat sendiri

Mungkin ralat ini adalah bahagian belakang dari yang sebelumnya. Maksud saya apabila anda mula menarik rakan sekerja dan kenalan anda dengan setiap masalah atau masalah. Bertanya adalah bagus, tetapi anda tidak boleh pergi terlalu jauh dengan soalan, jika tidak, anda mungkin akan bosan. Perkara pertama yang perlu dilakukan jika beberapa perkara yang tidak dapat difahami timbul ialah menggunakan kemahiran carian anda dalam enjin carian terbaik - Google. Seseorang telah menghadapi sebahagian besar kesilapan yang tidak dapat difahami dan isu lain. Dan anda akan agak terkejut jika anda Google dan melihat bilangan orang yang biasa dengan masalah yang sama, dan yang telah menerima jawapan komprehensif yang sesuai untuk digunakan dalam kerja mereka. Berdasarkan ini, anda sering mendengar rakan sekerja menjawab soalan - "Google itu." Anda tidak sepatutnya tersinggung dengan jawapan ini, kerana lagipun, rakan sekerja anda bukanlah seorang guru peribadi yang harus menyampaikan semua selok-belok bidang kerja anda. Keluasan Internet yang tidak berkesudahan akan membantu anda dengan bimbingan sedemikian. Kadangkala pengaturcara juga dipanggil orang yang mempunyai tali pinggang hitam dalam carian Google . Oleh itu, apabila kami tersekat, kami mula-mula Google masalah itu, dan jika tiada penyelesaian ditemui (jarang, tetapi ia berlaku), maka kami mula bertanya kepada rakan sekerja kami. Perlu bertanya kepada mereka dengan segera, bukan apabila terdapat beberapa jenis gangguan atau ralat yang tidak dapat difahami, tetapi apabila memilih pendekatan untuk menyelesaikan masalah. Lagipun, mereka boleh melihat di luar anda dan dengan serta-merta memberitahu bagaimana pendekatan ini atau itu mungkin berlaku dalam jangka masa panjang.

3. Salin-tampal buta

Tetapi Googling masalah dan, sewajarnya, penyelesaiannya mempunyai perangkapnya. Contohnya, salin-tampal buta . Ini biasanya berlaku apabila anda menemui masalah yang sama (tetapi mungkin tidak sama) dan di bawahnya, sebagai contoh, pada StackOverFlow terdapat penyelesaian. Anda mengambil penyelesaian ini, menyalin dan menampalnya sendiri, tanpa terlalu terperinci. Dan kemudian anda atau rakan sekerja projek anda menemui beberapa pepijat pelik atau tingkah laku yang tidak betul pada fungsi anda. Dan serta-merta tiada siapa yang tahu dari mana datangnya kaki itu. Kemudian, sudah tentu, tempat dengan kod ini akan ditemui, dan anda pasti tidak akan dipuji untuk keputusan ini. Oleh itu, apabila anda mencari penyelesaian siap sedia di StackOverFlow (atau di tempat lain), pertama sekali anda mesti menganalisisnya secara terperinci, apakah itu, bagaimana dan mengapa. Mungkin google fungsi ini dan lihat dokumentasi untuknya. Dan hanya selepas itu melaksanakannya ke dalam projek anda.

4. Melemparkan penyelesaian yang salah

Apabila menulis penyelesaian, kadangkala ia menjadi semakin rumit dan akhirnya menemui jalan buntu. Dan anda cuba merumitkannya lebih dan lebih untuk menyelesaikan masalah ini menggunakan pendekatan ini dan bukannya cuba mencari alternatif lain yang lebih boleh dilaksanakan. Mungkin anda hanya berasa kesal dengan tenaga dan masa yang anda habiskan, jadi anda membuat keputusan: tidak kira apa, jangan berputus asa, tetapi selesaikan masalah dengan cara ini. Ini bukan pendekatan yang betul sepenuhnya. Sekurang-kurangnya dalam pengaturcaraan. Lebih cepat anda mencuba pendekatan yang berbeza, lebih banyak masa anda akan menjimatkan. Oleh itu, jangan takut untuk mencuba dan mencuba pendekatan lain, walaupun banyak masa yang anda telah laburkan dalam pendekatan ini. Selain itu, ini akan menjadi mata untuk pengalaman anda, kerana anda akan mencuba beberapa pendekatan dan mempelajari bidang ini dengan lebih baik.

5. Takut bertanya tentang tugasan semasa

Bekerja pada projek biasanya datang untuk menyelesaikan beberapa tugasan (Tugas). Contohnya, di Jira . Dan tugas-tugas ini tidak selalu diterangkan secara terperinci dan jelas. Mereka biasanya ditulis oleh ketua pasukan, dan ini juga orang, jika itu berlaku. Mereka juga mungkin terlupa untuk menambah sesuatu atau tidak mengambil kira bahawa anda tidak begitu biasa dengan fungsi ini atau itu. Nah, atau anda tidak mempunyai sebarang akses kepada projek (contohnya, akses kepada Pangkalan Data, ke pelayan log, dan sebagainya). Dan sekarang, setelah menerima tugas itu, setelah mempelajarinya selama lebih daripada beberapa jam, anda masih duduk dan melihat skrin dengan bingung. Dan daripada terus memikirkan perkara ini sia-sia, anda harus mula bertanya soalan utama/menjelaskan kepada pencipta tugasan ini. Katakan, dalam aplikasi yang anda gunakan untuk komunikasi dalam pasukan (contohnya, Microsoft Teams) atau secara langsung sebagai ulasan di bawah tugasan ini. Di satu pihak, jika anda menulis soalan dalam mesej peribadi, kemungkinan besar jawapannya akan lebih cepat, kerana orang itu akan melihat soalan itu dengan segera. Sebaliknya, dengan bertanya soalan dalam Jira, anda mempunyai bukti bahawa anda melakukan sesuatu, iaitu menganalisis masalah. Terdapat cara untuk mempercepatkan proses ini: tanya soalan sebagai ulasan dalam Jira dan hantar pautan ke ulasan ini dalam mesej peribadi dengan permintaan untuk melihat.

6. Terlalu mengharap daripada ketua pasukan

Sekali lagi, ini adalah bahagian sebalik titik sebelumnya. Ketua pasukan ialah orang yang menjadi ketua pasukan pembangunan. Sebagai peraturan, kebanyakan masa ahli pasukan sedemikian dibelanjakan untuk pelbagai jenis komunikasi. Dan pada masa yang sama, dia juga menulis kod supaya tidak lupa apa itu semua. Nah, seperti yang anda faham, ini adalah watak yang sangat sibuk. Dan kedutan yang berlebihan untuk setiap bersin jelas tidak akan menggembirakannya. Bayangkan jika setiap ahli pasukan membombardirnya dengan sekumpulan soalan. Jadi anda boleh menjadi gila, bukan? Dan ia tidak akan menghairankan bahawa dengan banyak soalan di pihak anda, dia akan menjawab anda untuk masa yang lama. Apakah yang boleh anda lakukan untuk mengurangkan bilangan soalan kepada ketua pasukan:

• Kaji dokumentasi projek ini dengan lebih mendalam untuk mengurangkan bilangan bintik buta.
• Tanya soalan kepada ahli pasukan yang lain. Ada kemungkinan bahawa mereka sudah biasa dengan fungsi ini sebagai peneraju, atau lebih, kerana kemungkinan besar salah seorang daripada mereka menulis fungsi itu.

Sebagai alternatif, dalam IDE anda boleh melihat anotasi: siapa dan bila kali terakhir menukar kod dalam baris tertentu. Dengan cara ini kita akan mengetahui siapa yang paling tepat untuk bertanya soalan ini. Seperti yang anda mungkin sudah faham, apabila bertanya soalan kepada ketua pasukan, dan juga apabila bertanya soalan kepada rakan sekerja, anda perlu cuba mengekalkan nilai emas - jangan takut untuk bertanya, tetapi juga jangan mengganggu mereka dengan nombor yang berlebihan.

7. Takut pada semakan kod

Semakan kod atau semakan kod ialah peringkat sebelum memuat naik kod ke aplikasi biasa (ke cawangan biasa, contohnya, master atau dev). Semakan ini dijalankan oleh pembangun yang tidak berkaitan dengan tugas ini, yang boleh, dengan rupa yang segar, menemui ralat, ketidaktepatan atau kekurangan dalam gaya kod yang tidak disedari pada fasa awal pembangunan. Jika terdapat ulasan, ia ditinggalkan sebagai ulasan kepada bahagian tertentu kod. Dalam kes ini, pembangun yang melaksanakan tugas ini mesti membetulkan kesilapan mengikut semakan (atau membincangkan keputusannya dengan penyemak, mungkin meyakinkannya tentang ketepatan keputusannya). Selepas itu, hantar semula untuk semakan, dan seterusnya sehingga pengulas tidak mempunyai ulasan. Penyemak berfungsi sebagai "penapis" sebelum memuat naik kod. Jadi, ramai pengaturcara baru menganggap semakan kod sebagai kritikan dan kutukan. Mereka tidak menghargainya dan takut kepadanya, dan itu salah. Ia adalah semakan kod yang membolehkan kami menambah baik kod kami. Lagipun, kami menerima maklumat penting tentang apa yang kami lakukan salah dan apa yang perlu kami beri perhatian. Adalah perlu untuk melihat setiap semakan kod sebagai sebahagian daripada pembelajaran, sesuatu yang boleh membantu anda bertambah baik. Apabila seseorang meninggalkan komen pada kod anda, dia berkongsi dengan anda pengalamannya, amalan terbaiknya. Bagi saya, anda tidak boleh menjadi pengaturcara yang baik tanpa mendapat semakan kod. Kerana anda tidak tahu betapa bagusnya kod anda dan sama ada terdapat sebarang kesilapan di sana dari sudut pandangan orang yang berpengalaman dari luar.

8. Kecenderungan untuk mengaburkan penyelesaian

Selalunya tugas/masalah yang berbeza boleh mempunyai beberapa penyelesaian yang berbeza. Dan daripada semua penyelesaian yang ada, pemula biasanya menggunakan yang paling kompleks dan "abstruse". Dan memang benar: jika pengaturcara baru semalam mengkaji banyak algoritma, corak, struktur data yang berbeza, maka tangannya gatal untuk melaksanakan salah satu daripadanya. Ya, dan saya mahu, kononnya, mengisytiharkan diri saya. Percayalah, saya sendiri pun begitu dan saya tahu apa yang saya cakapkan :) Saya mempunyai situasi di mana saya menghabiskan masa yang lama untuk menulis satu fungsi yang ternyata sangat, sangat kompleks. Kemudian ia ditulis semula oleh pembangun peringkat Kanan+. Sudah tentu, saya berminat untuk melihat apa dan bagaimana dia mengubahnya. Saya melihat pelaksanaannya dan kagum betapa ia menjadi lebih mudah. Dan kod itu telah menjadi tiga kali lebih sedikit. Dan pada masa yang sama, ujian untuk fungsi ini tidak berubah dan tidak gagal! Maksudnya, logik umum tetap sama. Dari sini saya sampai pada kesimpulan bahawa: penyelesaian yang paling bijak sentiasa mudah . Selepas kesedaran ini, menulis kod menjadi lebih mudah, dan ia menjadi ketara lebih tahap tinggi. Jadi, bilakah patut menggunakan corak dan algoritma, anda bertanya? Kemudian, apabila menggunakannya akan menjadi cara yang paling mudah dan paling padat.

9. Ciptaan basikal

Konsep ini juga dikenali sebagai ciptaan roda. Intipatinya terletak pada fakta bahawa pembangun melaksanakan penyelesaiannya sendiri kepada masalah yang penyelesaiannya sudah wujud, dan berkali-kali lebih baik daripada yang dicipta oleh pengaturcara. Sebagai peraturan, mencipta basikal anda sendiri akan membawa kepada kehilangan masa dan penurunan dalam kecekapan kerja pemaju, kerana penyelesaian mungkin tidak dijumpai yang jauh dari yang terbaik, atau mungkin tidak dijumpai sama sekali. Pada masa yang sama, seseorang tidak boleh menolak kemungkinan keputusan bebas. Pengaturcara mesti menavigasi dengan betul tugas yang mungkin muncul di hadapannya untuk menyelesaikannya dengan cekap dan tepat pada masanya, menggunakan penyelesaian siap sedia atau mencipta sendiri. Di satu pihak, di universiti dan dalam kursus kita dihujani dengan pelbagai jenis tugas yang sepatutnya membantu kita mendapatkan tangan kita untuk mencipta basikal. Tetapi ini hanya pada pandangan pertama. Sebenarnya, tujuan ini adalah untuk membangunkan pemikiran algoritma dan penguasaan sintaks bahasa yang lebih mendalam. Dan tugasan sedemikian juga membantu untuk lebih memahami algoritma/struktur, dan, jika perlu, berikan mereka kemahiran untuk melaksanakan analog lanjutan mereka (tetapi ini sangat jarang diperlukan). Dalam kehidupan sebenar, dalam kebanyakan kes, tidak perlu mencipta roda anda sendiri, kerana analog telah lama wujud yang memenuhi keperluan kita. Mungkin, disebabkan pengalaman anda, anda tidak akan mengetahui tentang kewujudan pelaksanaan fungsi ini atau itu yang anda perlukan. Di sinilah anda perlu menggunakan perkara pertama artikel ini, iaitu, meminta bantuan daripada rakan sekerja yang lebih berpengalaman. Mereka akan dapat membimbing anda (contohnya, menasihati ke arah mana kepada Google) atau mencadangkan pelaksanaan tertentu (pustaka tertentu).

10. Jangan tulis ujian

Semua pemula tidak suka ujian menulis. Bagaimana pula dengan pemula: bukan pemula juga tidak suka ujian menulis, tetapi mereka lebih memahami mengapa ia diperlukan. Apabila anda benar-benar hijau, anda berfikir: mengapa menulisnya? Semuanya berfungsi, dan tidak boleh ada ralat. Tetapi bagaimana anda boleh memastikan bahawa perubahan anda tidak memecahkan sesuatu di bahagian lain sistem? Rakan sekerja anda tidak akan menghargainya jika anda meneruskan perubahan yang mengganggu lebih daripada yang mereka manfaatkan. Di sinilah ujian datang untuk menyelamatkan. Lebih banyak permohonan diliputi oleh ujian, lebih baik (juga dipanggil peratusan liputan). Jika aplikasi itu dilindungi dengan baik oleh ujian, dengan menjalankan semuanya, anda mungkin menemui tempat yang boleh dipecahkan oleh perubahan anda. Dan seperti yang saya katakan dalam contoh di atas, apabila memfaktorkan semula fungsi, ujian tidak gagal, dan semuanya kerana logik umum tidak berubah. Ini bermakna bahawa ujian juga boleh menunjukkan sama ada logik fungsi tertentu telah berubah atau tidak. Jadi, walaupun anda tidak suka ujian menulis, terdapat faedah yang tidak diragukan daripadanya, dan ia berbaloi dengan masa yang dihabiskan untuknya.

11. Mengulas secara berlebihan

Ramai pembangun mengalami kesempurnaan, dan pemula tidak terkecuali. Tetapi kadang-kadang kesan sampingan dari keinginan ini ialah mereka mula mengulas tentang semua orang dan segala-galanya. Malah apa yang tidak diperlukan, kerana ia sangat jelas:

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

Tidak semua pengaturcara pemula segera menyedari bahawa mengulas kod bukanlah perkara yang baik, kerana kod itu akan menjadi lebih berantakan dan sukar dibaca. Bagaimana jika kod itu ditukar, tetapi tiada komen untuknya? Ternyata dia akan menipu kita dan hanya mengelirukan kita. Kenapa komen sedemikian? Biasanya, kod yang ditulis dengan baik tidak perlu mengulas , kerana segala-galanya di dalamnya sudah jelas dan boleh dibaca. Jika anda menulis ulasan, ini bermakna anda telah merosakkan kebolehbacaan kod dan cuba untuk melancarkan keadaan. Pendekatan terbaik ialah menulis kod yang boleh dibaca pada mulanya yang tidak perlu ditambah dengan komen. Saya juga tidak dapat mengelak daripada menyebut penamaan kaedah, pembolehubah dan kelas yang betul, iaitu, peraturan yang saya sendiri patuhi: Komen terbaik ialah ketiadaan ulasan, dan sebaliknya - penamaan yang betul yang menerangkan dengan jelas ini atau itu fungsi dalam aplikasi anda.

12. Penamaan yang buruk

Selalunya, pemula memalsukan nama kelas, pembolehubah, kaedah, dll. Contohnya, apabila mereka mencipta kelas yang namanya tidak menerangkan tujuannya sama sekali. Atau pembolehubah dicipta dengan nama pendek, seperti x , dan apabila dua lagi pembolehubah bernama n dan y dicipta , ia menjadi sangat sukar untuk mengingati apa yang x lakukan . Dalam kes sedemikian, anda perlu memikirkan dengan teliti tentang kod dan mengkaji fungsi ini di bawah mikroskop (mungkin menggunakan penyahpepijat) untuk memahami apa yang berlaku di sana. Di sinilah penamaan yang betul dalam kod yang saya nyatakan di atas membantu kami. Nama yang betul meningkatkan kebolehbacaan kod, dengan itu menjimatkan masa untuk membiasakan diri, kerana lebih mudah untuk menggunakan kaedah di mana nama itu lebih kurang menggambarkan fungsinya. Dalam kod, semuanya terdiri daripada nama (pembolehubah, kaedah, kelas, objek fail, dll.), perkara ini menjadi sangat penting apabila mencipta kod yang betul dan bersih. Perlu diingat bahawa nama itu harus menyampaikan makna: mengapa, sebagai contoh, pembolehubah itu wujud, apa yang dilakukannya dan bagaimana ia digunakan. Dan saya akan perhatikan lagi dan lagi bahawa komen terbaik untuk menerangkan pembolehubah adalah namanya yang betul. Untuk kajian yang lebih mendalam tentang ulasan dan penamaan yang betul, saya menasihati anda untuk membaca klasik abadi: "Kod bersih. Penciptaan, analisis dan pemfaktoran semula”, Robert Martin . Pada nota ini, bahagian pertama artikel ini (refleksi) telah sampai ke penghujungnya. Akan bersambung…