Analisis kesilapan biasa yang dilakukan oleh pengaturcara baru, pt. 1

Hai dunia! Sebaik sahaja anda telah mempelajari semua yang anda perlu ketahui dan akhirnya mula bekerja sebagai pelatih atau pembangun junior, anda mungkin boleh berehat, bukan? Tidak. Segala-galanya baru bermula untuk anda... Anda dikelilingi oleh banyak perkara yang baru dan tidak dapat difahami. Bagaimana anda tidak mengosongkannya keluar dari pintu pagar? Itulah yang akan kita bincangkan hari ini. Dalam artikel ini, saya ingin menganalisis kesilapan pemula biasa dan memberi nasihat, berdasarkan pengalaman saya sendiri, tentang cara mengelakkannya. Jadi, mari kita mulakan tanpa berlengah lagi:

1. Takut untuk mendapatkan bantuan daripada rakan sekerja yang lebih berpengalaman

Kita semua manusia. Kami semua takut kelihatan bodoh, terutamanya di mata rakan sekerja baru kami yang lebih berpengalaman. Apabila pemaju mengambil kerja pertama mereka, mereka sering dibimbing oleh ketakutan ini dan, dengan berat mendengar, menarik diri ke dalam diri mereka sendiri, cuba memikirkan segala-galanya sendiri. Selain itu, seseorang boleh dikelilingi oleh rakan sekerja yang lebih berpengalaman, yang, seterusnya, dapat menunjukkan dia ke arah yang paling menjanjikan, membantu mengelakkan lebih banyak kesilapan dan "benjolan di kepala" yang tidak perlu. Jadi ingat: jangan takut untuk bertanya soalan. Anda seorang pemula dan semua orang memahami perkara ini dengan baik. Apabila anda bertanya, tiada siapa yang akan memukul anda dengan kayu. Mungkin sebaliknya akan berlaku: anda akan menjadi kawan dengan rakan sekerja anda dengan lebih cepat dan mula menikmati komunikasi yang lebih aktif dengan mereka. saya Saya akan mengatakan lebih banyak lagi: lebih banyak anda bertanya dan membincangkan pelbagai isu teknikal, lebih cepat anda akan dapat menghilangkan kulit pemula hijau anda dan berkembang menjadi pakar dalam bidang anda. Dan satu lagi nasihat. Jangan jadi orang asingStackOverflow . Saya secara khusus bercakap tentang bertanya soalan mengenai sumber ini. Di satu pihak, ia mengambil sedikit masa untuk mendapatkan jawapan kepada soalan anda. Tetapi sebaliknya, anda mungkin dengan cepat mempelajari pelbagai pendekatan untuk menyelesaikan masalah anda dan melihatnya dari sudut yang sedikit berbeza. Saya juga ingin ambil perhatian bahawa terdapat faedah praktikal untuk menulis ulasan/jawapan dan menulis soalan penjelasan tentang soalan StackOverflow daripada pembangun lain: anda mendapat peluang untuk berdebat dan menyelidiki isu dengan lebih mendalam, apatah lagi rangsangan karma.

2. Tidak cuba mencari maklumat sendiri

Kesilapan ini boleh dianggap sebaliknya daripada kesilapan sebelumnya.Di sini saya maksudkan apabila anda mula mengganggu rakan sekerja dan kenalan anda tentang setiap masalah atau cegukan yang anda hadapi. Bertanya itu bagus, tetapi jangan berlebihan dengan soalan. Jika tidak, orang lain mungkin menganggap anda menjengkelkan. Jika anda keliru tentang sesuatu, perkara pertama yang perlu dilakukan ialah menggunakan kemahiran carian anda dalam enjin carian terbaik — Google. Orang lain telah pun menghadapi kebanyakan kesilapan yang tidak dapat difahami dan isu lain. Dan anda akan agak terkejut jika anda google soalan anda dan melihat bilangan orang yang biasa dengan masalah yang sama, dan yang telah menerima jawapan lengkap yang boleh anda gunakan dalam kerja anda sendiri. Itulah sebabnya anda sering mendengar rakan sekerja anda membalas dengan "Google it". jangan Jangan tersinggung dengan jawapan ini — rakan sekerja anda bukanlah guru peribadi anda yang mesti menyampaikan semua kehalusan bidang kerja anda. Keluasan Internet yang tidak berkesudahan akan menjadi mentor anda. Kadangkala pengaturcara juga dirujuk sebagaiorang yang mempunyai tali pinggang hitam dalam carian Google . Jadi jika kita mempunyai "hiccup", kita terlebih dahulu google masalahnya. Jika penyelesaian tidak dapat ditemui (ini jarang berlaku, tetapi ia berlaku), barulah kita mula bertanya kepada rakan sekerja. Soalan segera adalah untuk mendapatkan nasihat tentang pendekatan yang harus anda pilih untuk menyelesaikan masalah lebih daripada apa yang anda akan lakukan apabila anda terkena bonggol laju atau mesej ralat yang tidak dapat difahami. Lagipun, mereka mungkin dapat melihat di luar pendekatan pilihan anda dan segera meramalkan ke mana pendekatan tertentu akan membawa kepada jangka panjang.

3. Menyalin dan menampal secara membabi buta

Tetapi masalah googling dan penyelesaiannya mempunyai masalahnya. Contohnya, menyalin dan menampal secara membabi buta .Ini biasanya berlaku apabila anda menemui masalah yang sama (tetapi mungkin tidak sama) dan penyelesaian yang berkaitan, sebagai contoh, pada StackOverflow. Anda ambil penyelesaian ini dan salin dan tampalnya tanpa menyelidiki butiran lanjut. Dan kemudian anda atau rakan sekerja anda menemui beberapa pepijat pelik atau tingkah laku yang salah dalam kod anda. Dan tiada siapa yang dapat meneka dengan segera dari mana mereka datang. Akhirnya, sudah tentu, tempat dengan kod yang disalin akan ditemui, dan anda pasti tidak akan dipuji untuk penyelesaian anda. Oleh itu, apabila anda menjumpai penyelesaian siap sedia pada StackOverflow (atau di mana-mana sahaja), anda mesti terlebih dahulu memahami dengan teliti apa, bagaimana, dan mengapa. Mungkin google fungsi yang berkaitan dan baca dokumentasi untuknya. Dan hanya selepas anda melakukannya, anda harus menambahkannya pada projek anda.

4. Berpegang kepada penyelesaian yang salah

Apabila menulis penyelesaian, anda kadang-kadang akan mendapati bahawa ia sentiasa menjadi lebih dan lebih rumit, akhirnya tiba di jalan buntu. Dan kemudian anda cuba membuat penyelesaian yang lebih terperinci untuk entah bagaimana menjadikannya berfungsi dan bukannya mencari alternatif lain yang lebih sesuai. Mungkin anda rasa anda telah melaburkan banyak masa dan usaha dan oleh itu memutuskan bahawa, tidak kira apa, anda tidak akan berputus asa dan anda akan menyelesaikan masalah dengan pendekatan sedia ada anda. Ini bukan sikap yang betul. Sekurang-kurangnya dalam pengaturcaraan. Lebih cepat anda mencuba pendekatan yang berbeza, lebih banyak masa anda akan menjimatkan akhirnya. Oleh itu, jangan takut untuk mencuba dan mencuba pendekatan lain, tanpa mengira jumlah masa yang anda telah laburkan dalam pendekatan semasa anda. Lebih-lebih lagi, dengan mencuba pelbagai pendekatan dan menyelam lebih mendalam ke dalam subjek, anda'

5. Takut untuk bertanya soalan tentang tugasan anda sekarang

Bekerja pada projek pembangunan perisian biasanya bermuara kepada melaksanakan tugas tertentu. Contohnya, di Jira. Tugas-tugas ini tidak selalu digariskan dengan jelas dan terperinci. Perihalan tugas biasanya ditulis oleh ketua pasukan, yang juga manusia biasa. Mereka mungkin terlupa untuk menambah sesuatu atau gagal mengambil kira hakikat bahawa anda tidak biasa dengan fungsi ini atau itu. Atau mungkin anda tidak mempunyai sebarang akses kepada projek (contohnya, akses kepada pangkalan data, pelayan log, dan sebagainya). Dan kini, anda telah menerima tugas itu, mempelajarinya selama lebih daripada beberapa jam, tetapi anda masih duduk di sana, menatap skrin dengan bingung. Daripada terus gagal untuk cuba memahami perkara ini, anda harus mula meminta penjelasan atau bimbingan daripada sesiapa yang mencipta tugasan itu. Contohnya, dalam apl yang digunakan oleh pasukan anda untuk komunikasi (contohnya, Microsoft Teams), anda mungkin bertanya soalan atau membuat ulasan langsung mengenai tugas itu. Di satu pihak, jika anda menulis soalan anda dalam mesej peribadi, anda mungkin akan mendapat jawapan lebih cepat, kerana orang itu akan melihat soalan anda dengan serta-merta. Sebaliknya, dengan bertanya soalan dalam Jira, anda mewujudkan bukti bahawa anda melakukan sesuatu, iaitu menganalisis masalah. Terdapat cara untuk mempercepatkan proses ini: tanya soalan anda dalam ulasan di Jira dan kemudian dalam DM, lepaskan pautan ke ulasan anda dan minta untuk melihat.

6. Meletakkan jangkaan tinggi yang tidak realistik terhadap ketua pasukan

Sekali lagi, ini adalah bahagian sebalik titik sebelumnya. Ketua pasukan ialah ketua pasukan pembangunan. Sebagai peraturan, ketua pasukan anda menghabiskan sebahagian besar masanya untuk pelbagai jenis komunikasi. Namun, dia juga menulis kod untuk tidak melupakan segala-galanya tentang pengaturcaraan. Seperti yang anda faham, kehidupan ketua pasukan adalah sangat sibuk. Menarik lengan ketua pasukan anda setiap kali anda perlu bersin jelas tidak menyenangkan. Bayangkan setiap ahli pasukan mengebom mendahului dengan sekumpulan soalan. Itu boleh membuat sesiapa menjadi gila, bukan? Dan jika anda menimbun banyak soalan, maka ketua pasukan anda perlu meluangkan banyak masa untuk menjawab anda. Apakah yang boleh dilakukan untuk mengurangkan bilangan soalan yang ditujukan kepada ketua pasukan:

• Terokai dokumentasi projek dengan lebih mendalam untuk mengurangkan bilangan titik buta.
• Arahkan soalan anda kepada ahli pasukan anda yang lain. Mereka mungkin biasa dengan fungsi ini seperti petunjuk, atau mungkin lebih banyak lagi, kerana kemungkinan besar fungsi itu ditulis oleh salah seorang daripada mereka.

Sebagai alternatif, anda boleh melihat anotasi dalam IDE kepada siapa dan bila kod dalam baris tertentu kali terakhir ditukar. Itulah cara anda boleh mengetahui siapa orang yang paling sesuai untuk bertanya soalan anda. Seperti yang anda mungkin sudah sedar, apabila ia datang kepada soalan kepada ketua pasukan, sama seperti soalan kepada rakan sekerja, anda perlu cuba mencari medium yang menggembirakan — jangan takut untuk bertanya, tetapi juga jangan tanya terlalu banyak daripada mereka.

7. Takut pada ulasan kod

Kajian kodialah peringkat sedemikian yang berlaku sebelum anda menyerahkan kod anda kepada aplikasi biasa (ke cawangan kongsi, contohnya, master atau dev). Semakan ini dilakukan oleh pembangun yang tidak terlibat dalam tugasan, yang mata segarnya dapat mengesan ralat, ketidaktepatan atau kecacatan dalam gaya kod anda yang tidak disedari semasa anda menulis kod anda pada mulanya. Sekiranya terdapat kritikan, ia ditinggalkan sebagai ulasan pada bahagian tertentu kod. Dalam kes ini, pembangun yang menulis kod mesti membetulkan ralat yang dikenal pasti dalam semakan (atau membincangkan keputusannya dengan penyemak, mungkin meyakinkannya bahawa ia adalah betul). Kemudian kod itu diserahkan untuk semakan lagi dan lagi sehingga penyemak tidak mempunyai ulasan lagi. Penyemak bertindak sebagai "pintu masuk" sebelum kod dilakukan. Cabarannya ialah ramai pengaturcara baru menganggap semakan kod sebagai kritikan dan kutukan. Mereka tidak menghargai ulasan kod dan takut dengannya. Mereka tidak sepatutnya. Ulasan kod adalah perkara yang membolehkan kami menambah baik kod kami. Lagipun, kami menerima maklumat penting tentang perkara yang kami lakukan salah dan perkara yang patut diberi perhatian. Anda harus mempertimbangkan setiap semakan kod sebagai sebahagian daripada keluk pembelajaran, sesuatu yang boleh membantu anda menjadi lebih baik. Apabila seseorang mengulas pada kod anda, dia berkongsi pengalaman dan amalan terbaik dengan anda. Saya secara peribadi tidak percaya anda boleh menjadi pengaturcara yang baik tanpa mendapat ulasan kod. Kerana anda tidak mengetahui kualiti kod anda dan sama ada orang luar yang berpengalaman akan menunjukkan kesilapan. t menghargai ulasan kod dan takut dengannya. Mereka tidak sepatutnya. Ulasan kod adalah perkara yang membolehkan kami menambah baik kod kami. Lagipun, kami menerima maklumat penting tentang perkara yang kami lakukan salah dan perkara yang patut diberi perhatian. Anda harus mempertimbangkan setiap semakan kod sebagai sebahagian daripada keluk pembelajaran, sesuatu yang boleh membantu anda menjadi lebih baik. Apabila seseorang mengulas pada kod anda, dia berkongsi pengalaman dan amalan terbaik dengan anda. Saya secara peribadi tidak percaya anda boleh menjadi pengaturcara yang baik tanpa mendapat ulasan kod. Kerana anda tidak mengetahui kualiti kod anda dan sama ada orang luar yang berpengalaman akan menunjukkan kesilapan. t menghargai ulasan kod dan takut dengannya. Mereka tidak sepatutnya. Ulasan kod adalah perkara yang membolehkan kami menambah baik kod kami. Lagipun, kami menerima maklumat penting tentang perkara yang kami lakukan salah dan perkara yang patut diberi perhatian. Anda harus mempertimbangkan setiap semakan kod sebagai sebahagian daripada keluk pembelajaran, sesuatu yang boleh membantu anda menjadi lebih baik. Apabila seseorang mengulas pada kod anda, dia berkongsi pengalaman dan amalan terbaik dengan anda. Saya secara peribadi tidak percaya anda boleh menjadi pengaturcara yang baik tanpa mendapat ulasan kod. Kerana anda tidak mengetahui kualiti kod anda dan sama ada orang luar yang berpengalaman akan menunjukkan kesilapan. melakukan kesalahan dan apa yang patut diberi perhatian. Anda harus mempertimbangkan setiap semakan kod sebagai sebahagian daripada keluk pembelajaran, sesuatu yang boleh membantu anda menjadi lebih baik. Apabila seseorang mengulas pada kod anda, dia berkongsi pengalaman dan amalan terbaik dengan anda. Saya secara peribadi tidak percaya anda boleh menjadi pengaturcara yang baik tanpa mendapat ulasan kod. Kerana anda tidak mengetahui kualiti kod anda dan sama ada orang luar yang berpengalaman akan menunjukkan kesilapan. melakukan kesalahan dan apa yang patut diberi perhatian. Anda harus mempertimbangkan setiap semakan kod sebagai sebahagian daripada keluk pembelajaran, sesuatu yang boleh membantu anda menjadi lebih baik. Apabila seseorang mengulas pada kod anda, dia berkongsi pengalaman dan amalan terbaik dengan anda. Saya secara peribadi tidak percaya anda boleh menjadi pengaturcara yang baik tanpa mendapat ulasan kod. Kerana anda tidak mengetahui kualiti kod anda dan sama ada orang luar yang berpengalaman akan menunjukkan kesilapan.

8. Kecenderungan untuk membuat keputusan misteri

Pelbagai tugas/masalah selalunya boleh mempunyai beberapa penyelesaian yang berbeza. Dan daripada semua penyelesaian yang ada, pemula cenderung menggunakan yang paling kompleks dan misteri. Dan itu masuk akal: pengaturcara baru semalam mempelajari banyak algoritma, corak dan struktur data yang berbeza, jadi tangan mereka gatal untuk melaksanakan sebahagian daripadanya. Percayalah, saya begitu, jadi saya tahu apa yang saya maksudkan :) Saya mempunyai situasi di mana saya telah melaksanakan beberapa fungsi untuk masa yang lama. Ia ternyata sangat, sangat rumit. Kemudian pembangun kanan menulis semula kod saya. Sudah tentu, saya sangat berminat untuk melihat apa dan bagaimana dia mengubahnya. Saya melihat pelaksanaannya dan kagum dengan betapa mudahnya ia. Dan terdapat tiga kali lebih sedikit kod. Dan juga menakjubkan, ujian automatik untuk fungsi ini tidak dialih keluar atau diubah! Dengan kata lain, logik umum tetap sama. Dari sini, saya sampai pada kesimpulan bahawapenyelesaian yang paling bijak sentiasa mudah . Selepas kesedaran ini, pengekodan menjadi lebih mudah, dan kualiti kod saya melonjak ke tahap yang jauh lebih tinggi. Kemudian bilakah berbaloi untuk menggunakan corak reka bentuk dan algoritma mewah, anda bertanya? Apabila memohon mereka akan menjadi penyelesaian yang paling mudah dan paling padat.

9. Mencipta semula roda

Roda adalah penyelesaian tahan lama yang telah dicipta lama dahulu. Dalam anti-corak ini, pembangun melaksanakan penyelesaian proprietarinya sendiri untuk masalah yang telah diselesaikan. Kadangkala penyelesaian sedia ada ini lebih baik daripada apa yang dihasilkan oleh pengaturcara. Sebagai peraturan, mencipta semula roda akan membawa kepada kehilangan masa dan produktiviti yang berkurangan, kerana penyelesaian yang anda temui mungkin jauh dari yang terbaik, atau, anda mungkin tidak menemuinya sama sekali. Walau bagaimanapun, kami tidak boleh menolak kemungkinan mencipta penyelesaian bebas kami sendiri: jika kami melakukannya, maka yang tinggal hanyalah salin dan tampal pengaturcaraan. Pengaturcara harus dipandu dengan betul oleh tugas pengaturcaraan khusus yang timbul untuk menyelesaikannya dengan cekap dan segera, sama ada dengan menggunakan penyelesaian siap sedia atau dengan mencipta penyelesaian tersuai. Di satu pihak, di universiti dan dalam kursus dalam talian, kami dihujani dengan pelbagai jenis tugas yang kelihatan direka untuk membantu kami mencipta semula roda. Tetapi hanya pada pandangan pertama: Tujuan sebenar di sini adalah membangunkan pemikiran algoritma dan penguasaan sintaks bahasa yang lebih mendalam. Tugasan sedemikian juga membantu anda memahami algoritma dan struktur data dengan lebih baik, dan memberi anda kemahiran untuk melaksanakan rakan sejawat yang lebih canggih, jika perlu (ini kadangkala perlu, tetapi ia sangat jarang berlaku). Dalam kehidupan sebenar, anda tidak perlu mencipta roda anda sendiri dalam kebanyakan kes, kerana roda yang memenuhi keperluan anda telah wujud sejak sekian lama. Mungkin kekurangan pengalaman anda menghalang anda daripada mengetahui tentang kewujudan pelaksanaan fungsi yang anda perlukan. Di sinilah anda perlu mengambil nasihat yang diberikan dalam perkara pertama artikel ini, iaitu, minta bantuan rakan sekerja yang lebih berpengalaman. Mereka akan dapat membimbing anda (contohnya, menunjukkan anda ke arah yang betul dalam carian Google anda) atau mencadangkan pelaksanaan tertentu (contohnya, beberapa perpustakaan).

10. Kegagalan menulis ujian

Semua pemula tidak suka ujian menulis. Tetapi mengapa kita harus memilih pemula, di sini? Pembangun yang lebih berpengalaman juga tidak suka menulis ujian, tetapi mereka lebih memahami sebab ujian diperlukan. Apabila anda benar-benar hijau, anda tertanya-tanya mengapa anda perlu menulisnya. Semuanya berfungsi, jadi tidak boleh ada sebarang kesilapan. Tetapi bagaimana anda memastikan bahawa perubahan anda tidak akan memecahkan sesuatu di tempat lain dalam sistem? Rakan sekerja anda tidak akan menghargainya jika anda meneruskan perubahan yang mendatangkan lebih banyak bahaya daripada kebaikan. Di sinilah ujian datang untuk menyelamatkan kita. Lebih banyak kod aplikasi dilindungi oleh ujian, lebih baik (ini dipanggil liputan kod atau liputan ujian). Jika aplikasi mempunyai liputan ujian yang baik, maka anda boleh menjalankan semua ujian untuk mencari tempat yang akan dipecahkan oleh kod anda. Dan seperti yang saya katakan dalam contoh di atas, apabila pembangun kanan memfaktorkan semula kod, ujian tidak gagal. Ini kerana logik umum tidak berubah. Kami menggunakan ujian untuk menunjukkan sama ada logik fungsi tertentu telah berubah atau tidak. Jadi, walaupun anda tidak suka ujian menulis, ia pasti berguna dan berbaloi dengan masa yang dihabiskan untuknya.

11. Komen yang berlebihan

Ramai pembangun mengalami kesempurnaan, dan pemula tidak terkecuali. Mereka kadangkala menunjukkan hanya satu aspek kecenderungan ini apabila mereka mula mengulas tentang semua orang dan segala-galanya. Malah membuat komen yang tidak perlu, kerana kod itu sangat jelas:

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

Tidak semua pengaturcara pemula segera menyedari bahawa kod mengulas tidak selalu baik, kerana komen yang berlebihan mengacaukan kod dan menjadikannya sukar untuk dibaca. Dan bagaimana jika kod berubah, tetapi komen lama tidak dikemas kini? Kemudian mereka hanya akan menyesatkan dan mengelirukan kita. Jadi mengapa membuat komen sedemikian sama sekali? Biasanya, kod yang ditulis dengan baik tidak perlu diulas , kerana segala-galanya di dalamnya sudah jelas dan boleh dibaca. Jika anda perlu menulis ulasan, maka anda telah merosakkan kebolehbacaan kod dan cuba untuk membetulkan keadaan. Pendekatan terbaik ialah menulis kod yang boleh dibaca dari awal lagi, iaitu kod yang tidak memerlukan ulasan. Saya juga tidak dapat membantu tetapi menyebut keperluan untuk mengikuti konvensyen penamaan yang betul untuk kaedah, pembolehubah dan kelas. Inilah peraturan saya: Komen terbaik ialah sama ada tiada ulasan atau penamaan yang betul yang menerangkan dengan jelas fungsi dalam aplikasi anda.

12. Penamaan yang buruk

Pemula bermain pantas dan longgar dalam menamakan kelas, pembolehubah, kaedah, dll. Contohnya, dengan mencipta kelas yang namanya langsung tidak menerangkan tujuannya. Atau mereka mengisytiharkan pembolehubah dengan nama pendek, seperti x . Mereka apabila dua lagi pembolehubah dinamakan n dan ydicipta, mengingati apa yang x bertanggungjawab menjadi sangat sukar. Menghadapi situasi ini, anda perlu berfikir dengan teliti tentang kod itu, menganalisisnya di bawah mikroskop (mungkin menggunakan penyahpepijat), mengkaji fungsi untuk memahami apa yang sedang berlaku. Di sinilah konvensyen penamaan yang betul yang saya nyatakan di atas membantu kami. Nama yang betul meningkatkan kebolehbacaan kod, sekali gus mengurangkan masa yang diperlukan untuk membiasakan diri anda dengan kod tersebut, kerana menggunakan kaedah adalah lebih mudah apabila namanya lebih kurang menggambarkan fungsinya. Segala-galanya dalam kod terdiri daripada nama (pembolehubah, kaedah, kelas, objek, fail, dll.), jadi perkara ini menjadi sangat penting apabila mencipta kod yang betul dan bersih. Anda harus ingat bahawa nama itu harus menyampaikan makna, sebagai contoh, mengapa pembolehubah itu wujud, apa yang dilakukannya, dan bagaimana ia digunakan. Saya akan perhatikan lebih daripada sekali bahawa komen terbaik untuk pembolehubah adalah untuk memberikannya nama yang baik. Untuk kajian yang lebih mendalam tentang ulasan dan penamaan yang betul, saya mengesyorkan membaca klasik abadi:"Kod Bersih: Buku Panduan Ketukangan Perisian Tangkas" oleh Robert Martin . Pada nota itu, bahagian pertama artikel ini (refleksi saya) telah sampai ke penghujungnya. Akan bersambung...