Analisis kesalahan umum yang dilakukan oleh programmer pemula, pt. 1

Halo Dunia! Setelah Anda mempelajari semua yang perlu Anda ketahui dan akhirnya bekerja sebagai pekerja magang atau junior dev, Anda mungkin bisa santai, bukan? Tidak. Semuanya baru saja dimulai untuk Anda... Anda dikelilingi oleh banyak hal yang baru dan tidak dapat dipahami. Bagaimana Anda tidak mengacaukannya langsung dari gerbang? Itulah yang akan kita bicarakan hari ini. Pada artikel ini, saya ingin menganalisis kesalahan pemula yang umum dan memberikan beberapa saran, berdasarkan pengalaman saya sendiri, tentang cara menghindarinya. Jadi, mari kita mulai tanpa basa-basi lagi:

1. Takut mencari bantuan dari rekan kerja yang lebih berpengalaman

Kita semua manusia. Kita semua takut terlihat bodoh, terutama di mata rekan baru kita yang lebih berpengalaman. Ketika pengembang mengambil pekerjaan pertama mereka, mereka sering dibimbing oleh ketakutan ini dan, dengan suara berat, menarik diri, mencoba memikirkan semuanya sendiri. Selain itu, seseorang dapat dikelilingi oleh rekan kerja yang lebih berpengalaman, yang, pada gilirannya, dapat mengarahkannya ke arah yang paling menjanjikan, membantu menghindari lebih banyak kesalahan dan "benturan di kepala" yang tidak perlu. Jadi ingat: jangan takut untuk bertanya. Anda seorang pemula dan semua orang memahami ini dengan sangat baik. Saat Anda bertanya, tidak ada yang akan memukul Anda dengan tongkat. Bahkan mungkin yang sebaliknya akan terjadi: Anda akan lebih cepat berteman dengan kolega Anda dan mulai menikmati komunikasi yang lebih aktif dengan mereka. SAYA' akan mengatakan lebih banyak lagi: semakin banyak Anda bertanya dan mendiskusikan berbagai masalah teknis, semakin cepat Anda dapat melepaskan kulit pemula yang hijau dan tumbuh menjadi ahli di bidang Anda. Dan satu nasihat lagi. Jangan menjadi orang asing bagiStackOverflow . Saya secara khusus berbicara tentang mengajukan pertanyaan tentang sumber daya ini. Di satu sisi, butuh waktu untuk mendapatkan jawaban atas pertanyaan Anda. Namun di sisi lain, Anda dapat dengan cepat mempelajari berbagai pendekatan untuk memecahkan masalah Anda dan melihatnya dari sudut yang sedikit berbeda. Saya juga ingin mencatat bahwa ada manfaat praktis untuk menulis komentar/jawaban dan menulis pertanyaan klarifikasi tentang pertanyaan StackOverflow dari pengembang lain: Anda mendapat kesempatan untuk berdebat dan menggali lebih dalam masalah, belum lagi peningkatan karma.

2. Tidak berusaha mencari informasi sendiri

Kesalahan ini bisa dianggap sebagai kebalikan dari yang sebelumnya.Di sini maksud saya ketika Anda mulai mengganggu kolega dan kenalan Anda tentang setiap masalah atau cegukan yang Anda temui. Bertanya itu baik, tetapi jangan berlebihan dengan pertanyaan. Kalau tidak, orang mungkin menganggap Anda menjengkelkan. Jika Anda bingung tentang sesuatu, hal pertama yang harus dilakukan adalah melatih keterampilan pencarian Anda di mesin pencari terbaik — Google. Orang lain telah mengalami sebagian besar kesalahan yang tidak dapat dipahami dan masalah lainnya. Dan Anda akan sangat terkejut jika Anda mencari di Google pertanyaan Anda dan melihat jumlah orang yang mengetahui masalah serupa, dan yang telah menerima jawaban lengkap yang dapat Anda terapkan dalam pekerjaan Anda sendiri. Itu sebabnya Anda akan sering mendengar rekan Anda membalas dengan "Google itu". Mengenakan' jangan tersinggung dengan jawaban ini - kolega Anda bukanlah guru pribadi Anda yang harus menyampaikan semua seluk-beluk bidang pekerjaan Anda. Hamparan Internet yang tak ada habisnya akan menjadi mentor Anda. Terkadang programmer juga disebut sebagaiorang dengan sabuk hitam di penelusuran Google . Jadi jika kita mengalami "cegukan", pertama-tama kita mencari masalahnya di Google. Jika solusi tidak dapat ditemukan (ini jarang terjadi, tetapi itu terjadi), barulah kita mulai bertanya kepada rekan kerja. Pertanyaan langsung adalah untuk mendapatkan saran tentang pendekatan mana yang harus Anda pilih untuk memecahkan masalah lebih dari apa yang akan Anda lakukan ketika Anda menabrak kecepatan atau pesan kesalahan yang tidak dapat dipahami. Lagi pula, mereka mungkin dapat melihat melampaui pendekatan pilihan Anda dan segera memprediksi ke mana arah pendekatan apa pun dalam jangka panjang.

3. Menyalin dan menempel secara membabi buta

Tetapi masalah googling dan solusinya memiliki kekurangan. Misalnya, menyalin dan menempel secara membabi buta .Ini biasanya terjadi ketika Anda menemukan masalah yang serupa (tetapi mungkin tidak persis sama) dan solusi terkait, misalnya, di StackOverflow. Anda mengambil solusi ini dan menyalin dan menempelkannya tanpa mempelajari lebih lanjut detailnya. Dan kemudian Anda atau rekan kerja Anda menemukan beberapa bug aneh atau perilaku yang salah dalam kode Anda. Dan tidak ada yang bisa langsung menebak dari mana asalnya. Akhirnya, tentu saja, tempat dengan kode yang disalin akan ditemukan, dan Anda pasti tidak akan dipuji atas solusi Anda. Oleh karena itu, ketika Anda menemukan solusi siap pakai di StackOverflow (atau di mana pun), Anda harus terlebih dahulu memahami apa, bagaimana, dan mengapa. Mungkin google fungsi yang relevan dan baca dokumentasinya. Dan hanya setelah Anda selesai melakukannya, Anda harus menambahkannya ke proyek Anda.

4. Tetap dengan solusi yang salah

Saat menulis solusi, terkadang Anda akan menemukan bahwa itu terus menjadi semakin rumit, akhirnya menemui jalan buntu. Dan kemudian Anda mencoba membuat solusinya lebih rumit untuk membuatnya bekerja daripada mencari alternatif lain yang lebih cocok. Mungkin Anda merasa telah menginvestasikan banyak waktu dan tenaga dan oleh karena itu memutuskan bahwa, apa pun yang terjadi, Anda tidak akan menyerah dan akan menyelesaikan masalah dengan pendekatan Anda saat ini. Ini bukan sikap yang tepat. Setidaknya dalam pemrograman. Semakin cepat Anda mencoba pendekatan yang berbeda, semakin banyak waktu yang Anda hemat pada akhirnya. Jadi jangan takut untuk bereksperimen dan mencoba pendekatan lain, terlepas dari jumlah waktu yang telah Anda investasikan pada pendekatan Anda saat ini. Terlebih lagi, dengan mencoba berbagai pendekatan dan mendalami subjeknya, Anda akan

5. Takut bertanya tentang tugas Anda saat ini

Bekerja pada proyek pengembangan perangkat lunak biasanya bermuara pada melakukan tugas-tugas tertentu. Misalnya di Jira. Tugas-tugas ini tidak selalu diuraikan secara jelas dan rinci. Deskripsi tugas biasanya ditulis oleh pemimpin tim, yang juga manusia biasa. Mereka mungkin lupa menambahkan sesuatu atau gagal memperhitungkan fakta bahwa Anda tidak terbiasa dengan fungsi ini atau itu. Atau mungkin Anda tidak memiliki akses apa pun ke proyek (misalnya, akses ke database, server log, dan sebagainya). Dan sekarang, Anda telah menerima tugas, mempelajarinya selama lebih dari beberapa jam, tetapi Anda masih duduk di sana, menatap layar dengan bingung. Alih-alih terus gagal mencoba memahami hal ini, Anda harus mulai meminta klarifikasi atau bimbingan dari siapa pun yang membuat tugas tersebut. Misalnya, di aplikasi yang digunakan tim Anda untuk komunikasi (misalnya, Microsoft Teams), Anda dapat mengajukan pertanyaan atau memberikan komentar langsung terkait tugas tersebut. Di satu sisi, jika Anda menulis pertanyaan Anda dalam pesan pribadi, Anda mungkin akan mendapatkan jawaban lebih cepat, karena orang tersebut akan segera melihat pertanyaan Anda. Di sisi lain, dengan mengajukan pertanyaan di Jira, Anda membuktikan bahwa Anda sedang melakukan sesuatu, yaitu menganalisis masalah. Ada cara untuk mempercepat proses ini: ajukan pertanyaan Anda di komentar di Jira lalu di DM, berikan tautan ke komentar Anda dan minta untuk melihatnya.

6. Menempatkan ekspektasi tinggi yang tidak realistis pada pemimpin tim

Sekali lagi, ini adalah sisi lain dari poin sebelumnya. Pemimpin tim adalah kepala tim pengembangan. Sebagai aturan, pemimpin tim Anda menghabiskan sebagian besar waktunya untuk berbagai jenis komunikasi. Namun, dia juga menulis kode agar tidak melupakan segala sesuatu tentang pemrograman. Seperti yang bisa Anda pahami, kehidupan seorang pemimpin tim sangat sibuk. Menarik-narik lengan baju pemimpin tim Anda setiap kali Anda perlu bersin jelas tidak akan menyenangkan. Bayangkan setiap anggota tim membombardir pemimpin dengan banyak pertanyaan. Itu bisa membuat siapa pun gila, bukan? Dan jika Anda menumpuk banyak pertanyaan, pemimpin tim Anda harus menghabiskan banyak waktu untuk menjawab Anda. Apa yang dapat dilakukan untuk mengurangi jumlah pertanyaan yang diarahkan pada pimpinan tim:

• Jelajahi dokumentasi proyek secara lebih mendalam untuk mengurangi jumlah titik buta.
• Arahkan pertanyaan Anda ke anggota tim Anda yang lain. Mereka mungkin akrab dengan fungsi ini seperti pemimpinnya, atau bahkan mungkin lebih, karena kemungkinan besar fungsi tersebut ditulis oleh salah satu dari mereka.

Alternatifnya, Anda dapat melihat anotasi di IDE kepada siapa dan kapan kode di baris tertentu terakhir kali diubah. Itulah tepatnya bagaimana Anda bisa mengetahui siapa orang yang paling tepat untuk mengajukan pertanyaan Anda. Seperti yang mungkin sudah Anda sadari, ketika berbicara tentang pertanyaan kepada pimpinan tim, seperti halnya pertanyaan kepada rekan kerja, Anda perlu mencoba menemukan media yang menyenangkan — jangan takut untuk bertanya, tetapi juga jangan terlalu banyak bertanya dari mereka.

7. Takut akan ulasan kode

Tinjauan kodeadalah tahapan yang terjadi sebelum Anda mengirimkan kode Anda ke aplikasi umum (ke cabang bersama, misalnya, master atau dev). Pemeriksaan ini dilakukan oleh pengembang yang tidak terlibat dalam tugas, yang mata segarnya dapat mendeteksi kesalahan, ketidakakuratan, atau kekurangan dalam gaya kode Anda yang luput dari perhatian saat Anda pertama kali menulis kode. Jika ada kritik, itu dibiarkan sebagai komentar pada bagian-bagian tertentu dari kode. Dalam hal ini, pengembang yang menulis kode harus memperbaiki kesalahan yang teridentifikasi dalam ulasan (atau mendiskusikan keputusannya dengan peninjau, mungkin meyakinkannya bahwa keputusan tersebut benar). Kemudian kode tersebut dikirimkan untuk ditinjau berulang kali hingga peninjau tidak memiliki komentar lagi. Peninjau bertindak sebagai "gerbang" sebelum kode dilakukan. Tantangannya adalah bahwa banyak pemrogram pemula menganggap tinjauan kode sebagai kritik dan kutukan. Mereka tidak menghargai ulasan kode dan takut terhadapnya. Seharusnya tidak. Ulasan kode adalah hal yang memungkinkan kami meningkatkan kode kami. Lagi pula, kami menerima informasi penting tentang apa yang kami lakukan salah dan apa yang perlu diperhatikan. Anda harus mempertimbangkan setiap tinjauan kode sebagai bagian dari kurva pembelajaran, sesuatu yang dapat membantu Anda menjadi lebih baik. Saat seseorang mengomentari kode Anda, dia berbagi pengalaman dan praktik terbaik dengan Anda. Saya pribadi tidak percaya Anda bisa menjadi programmer yang baik tanpa mendapatkan ulasan kode. Karena Anda bahkan tidak menyadari kualitas kode Anda dan apakah orang luar yang berpengalaman akan menunjukkan kesalahan. tidak menghargai ulasan kode dan takut terhadapnya. Seharusnya tidak. Ulasan kode adalah hal yang memungkinkan kami meningkatkan kode kami. Lagi pula, kami menerima informasi penting tentang apa yang kami lakukan salah dan apa yang perlu diperhatikan. Anda harus mempertimbangkan setiap tinjauan kode sebagai bagian dari kurva pembelajaran, sesuatu yang dapat membantu Anda menjadi lebih baik. Saat seseorang mengomentari kode Anda, dia berbagi pengalaman dan praktik terbaik dengan Anda. Saya pribadi tidak percaya Anda bisa menjadi programmer yang baik tanpa mendapatkan ulasan kode. Karena Anda bahkan tidak menyadari kualitas kode Anda dan apakah orang luar yang berpengalaman akan menunjukkan kesalahan. tidak menghargai ulasan kode dan takut terhadapnya. Seharusnya tidak. Ulasan kode adalah hal yang memungkinkan kami meningkatkan kode kami. Lagi pula, kami menerima informasi penting tentang apa yang kami lakukan salah dan apa yang perlu diperhatikan. Anda harus mempertimbangkan setiap tinjauan kode sebagai bagian dari kurva pembelajaran, sesuatu yang dapat membantu Anda menjadi lebih baik. Saat seseorang mengomentari kode Anda, dia berbagi pengalaman dan praktik terbaik dengan Anda. Saya pribadi tidak percaya Anda bisa menjadi programmer yang baik tanpa mendapatkan ulasan kode. Karena Anda bahkan tidak menyadari kualitas kode Anda dan apakah orang luar yang berpengalaman akan menunjukkan kesalahan. melakukan kesalahan dan apa yang patut diperhatikan. Anda harus mempertimbangkan setiap tinjauan kode sebagai bagian dari kurva pembelajaran, sesuatu yang dapat membantu Anda menjadi lebih baik. Saat seseorang mengomentari kode Anda, dia berbagi pengalaman dan praktik terbaik dengan Anda. Saya pribadi tidak percaya Anda bisa menjadi programmer yang baik tanpa mendapatkan ulasan kode. Karena Anda bahkan tidak menyadari kualitas kode Anda dan apakah orang luar yang berpengalaman akan menunjukkan kesalahan. melakukan kesalahan dan apa yang patut diperhatikan. Anda harus mempertimbangkan setiap tinjauan kode sebagai bagian dari kurva pembelajaran, sesuatu yang dapat membantu Anda menjadi lebih baik. Saat seseorang mengomentari kode Anda, dia berbagi pengalaman dan praktik terbaik dengan Anda. Saya pribadi tidak percaya Anda bisa menjadi programmer yang baik tanpa mendapatkan ulasan kode. Karena Anda bahkan tidak menyadari kualitas kode Anda dan apakah orang luar yang berpengalaman akan menunjukkan kesalahan.

8. Kecenderungan untuk keputusan misterius

Berbagai tugas/masalah seringkali dapat memiliki beberapa solusi berbeda. Dan dari semua solusi yang tersedia, pemula cenderung menggunakan yang paling rumit dan misterius. Dan itu masuk akal: programmer pemula baru kemarin mempelajari banyak algoritma, pola, dan struktur data yang berbeda, sehingga tangan mereka gatal untuk mengimplementasikan beberapa di antaranya. Percayalah, saya seperti itu, jadi saya tahu apa yang saya bicarakan :) Saya mengalami situasi di mana saya menerapkan beberapa fungsi untuk waktu yang lama. Ternyata sangat, sangat rumit. Kemudian pengembang senior menulis ulang kode saya. Tentu saja, saya sangat tertarik untuk melihat apa dan bagaimana dia mengubahnya. Saya melihat implementasinya dan kagum betapa sederhananya itu. Dan ada kode tiga kali lebih sedikit. Dan juga luar biasa, pengujian otomatis untuk fungsi ini tidak dihapus atau diubah! Dengan kata lain, logika umum tetap sama. Dari sini, saya sampai pada kesimpulan bahwasolusi yang paling cerdik selalu sederhana . Setelah realisasi ini, pengkodean menjadi lebih mudah, dan kualitas kode saya melonjak ke tingkat yang jauh lebih tinggi. Lalu kapan perlu menerapkan pola desain dan algoritme mewah, Anda bertanya? Saat menerapkannya akan menjadi solusi paling sederhana dan paling ringkas.

9. Menemukan kembali roda

Roda adalah solusi tahan lama yang ditemukan sejak lama. Dalam anti-pola ini, pengembang mengimplementasikan solusi miliknya sendiri untuk masalah yang telah dipecahkan. Terkadang solusi yang ada ini lebih baik daripada yang dibuat oleh programmer. Sebagai aturan, menemukan kembali roda akan menyebabkan hilangnya waktu dan penurunan produktivitas, karena solusi yang Anda temukan mungkin jauh dari yang terbaik, atau, Anda mungkin tidak menemukannya sama sekali. Meskipun demikian, kami tidak dapat mengesampingkan kemungkinan untuk membuat solusi independen kami sendiri: jika kami melakukannya, yang tersisa hanyalah pemrograman salin dan tempel. Pemrogram harus dipandu dengan baik oleh tugas pemrograman spesifik yang muncul untuk menyelesaikannya secara kompeten dan cepat, baik dengan menggunakan solusi yang sudah jadi atau dengan membuat solusi khusus. Di tangan satunya, di universitas dan kursus online, kami dibombardir dengan berbagai jenis tugas yang tampaknya dirancang untuk membantu kami menemukan kembali roda. Tapi hanya sekilas: Tujuan sebenarnya di sini adalah mengembangkan pemikiran algoritmik dan penguasaan sintaks bahasa yang lebih dalam. Tugas semacam itu juga membantu Anda untuk lebih memahami algoritme dan struktur data, dan memberi Anda keterampilan untuk mengimplementasikan pasangan yang lebih canggih, jika perlu (ini terkadang diperlukan, tetapi sangat jarang). Dalam kehidupan nyata, Anda tidak perlu menemukan roda Anda sendiri di sebagian besar kasus, karena roda yang memenuhi kebutuhan Anda sudah ada sejak lama. Mungkin kurangnya pengalaman Anda menghalangi Anda untuk mengetahui tentang keberadaan implementasi dari fungsionalitas yang Anda butuhkan. Di sinilah Anda perlu mengambil saran yang diberikan pada poin pertama artikel ini, yaitu, meminta bantuan rekan yang lebih berpengalaman. Mereka akan dapat memandu Anda (misalnya, mengarahkan Anda ke arah yang benar dalam penelusuran Google) atau menyarankan penerapan tertentu (misalnya, beberapa perpustakaan).

10. Gagal menulis tes

Semua pemula tidak menyukai tes menulis. Tapi mengapa kita harus memilih pemula, di sini? Pengembang yang lebih berpengalaman juga tidak suka menulis tes, tetapi mereka lebih memahami mengapa tes diperlukan. Ketika Anda benar-benar hijau, Anda bertanya-tanya mengapa Anda harus menulisnya. Semuanya berfungsi, jadi tidak mungkin ada kesalahan. Tapi bagaimana Anda memastikan bahwa perubahan Anda tidak merusak sesuatu di tempat lain dalam sistem? Kolega Anda tidak akan menghargai jika Anda mendorong perubahan yang menyebabkan lebih banyak kerugian daripada kebaikan. Di sinilah ujian datang untuk menyelamatkan kita. Semakin banyak kode aplikasi dicakup oleh pengujian, semakin baik (ini disebut cakupan kode atau cakupan pengujian). Jika aplikasi memiliki jangkauan pengujian yang baik, maka Anda dapat menjalankan semua pengujian untuk menemukan tempat yang akan rusak oleh kode Anda. Dan seperti yang saya katakan pada contoh di atas, ketika pengembang senior memfaktorkan ulang kode, pengujian tidak gagal. Ini karena logika umum tidak berubah. Kami menggunakan pengujian untuk mendemonstrasikan apakah logika fungsionalitas tertentu telah berubah atau tidak. Jadi, meskipun Anda tidak menyukai tes menulis, tes tersebut pasti berguna dan sepadan dengan waktu yang Anda habiskan untuk mengerjakannya.

11. Komentar yang berlebihan

Banyak pengembang menderita perfeksionisme, dan pemula tidak terkecuali. Mereka kadang-kadang mewujudkan hanya satu segi dari kecenderungan ini ketika mereka mulai mengomentari semua orang dan segalanya. Bahkan membuat komentar yang tidak perlu, karena kodenya sangat jelas:

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

Tidak semua pemrogram pemula segera menyadari bahwa mengomentari kode tidak selalu baik, karena komentar yang berlebihan mengacaukan kode dan membuatnya sulit dibaca. Dan bagaimana jika kodenya berubah, tetapi komentar lama tidak diperbarui? Maka mereka hanya akan menyesatkan dan membingungkan kita. Lalu mengapa membuat komentar seperti itu? Biasanya, kode yang ditulis dengan baik tidak perlu dikomentari , karena semua yang ada di dalamnya sudah jelas dan dapat dibaca. Jika Anda perlu menulis komentar, maka Anda telah merusak keterbacaan kode dan mencoba untuk memperbaiki situasi tersebut. Pendekatan terbaik adalah menulis kode yang dapat dibaca sejak awal, yaitu kode yang tidak memerlukan komentar. Saya juga tidak bisa tidak menyebutkan perlunya mengikuti konvensi penamaan yang benar untuk metode, variabel, dan kelas. Inilah aturan saya: Komentar terbaik adalah tidak ada komentar atau penamaan yang benar yang dengan jelas menggambarkan fungsionalitas dalam aplikasi Anda.

12. Penamaan yang buruk

Pemula bermain cepat dan longgar dalam penamaan kelas, variabel, metode, dll. Misalnya, dengan membuat kelas yang namanya sama sekali tidak menjelaskan tujuannya. Atau mereka mendeklarasikan variabel dengan nama pendek, seperti x . Mereka ketika dua variabel lagi bernama n dan ydibuat, mengingat apa yang menjadi tanggung jawab x menjadi sangat sulit. Menghadapi situasi ini, Anda harus memikirkan kode dengan hati-hati, menganalisisnya di bawah mikroskop (mungkin menggunakan debugger), mempelajari fungsionalitas untuk memahami apa yang sedang terjadi. Di sinilah konvensi penamaan yang benar yang saya sebutkan di atas membantu kami. Nama yang benar meningkatkan keterbacaan kode, sehingga mengurangi waktu yang diperlukan untuk membiasakan diri Anda dengan kode, karena menggunakan metode jauh lebih mudah jika namanya kurang lebih menggambarkan fungsinya. Segala sesuatu dalam kode terdiri dari nama (variabel, metode, kelas, objek, file, dll.), jadi poin ini menjadi sangat penting saat membuat kode yang benar dan bersih. Anda harus ingat bahwa nama harus menyampaikan arti, misalnya mengapa variabel itu ada, apa fungsinya, dan bagaimana itu digunakan. Saya akan mencatat lebih dari sekali bahwa komentar terbaik untuk sebuah variabel adalah memberinya nama yang bagus. Untuk mempelajari lebih dalam tentang komentar dan penamaan yang benar, saya sarankan membaca klasik abadi:"Kode Bersih: Buku Pegangan Pengerjaan Perangkat Lunak Agile" oleh Robert Martin . Pada catatan itu, bagian pertama dari artikel ini (refleksi saya) telah berakhir. Bersambung...