Analisis kesalahan umum programmer pemula: bagian 1

Halo Dunia! Setelah Anda mempelajari semua yang Anda butuhkan dan akhirnya dipekerjakan sebagai pekerja magang atau junior, Anda mungkin bisa bersantai, bukan? Tidak peduli bagaimana keadaannya! Semuanya baru saja dimulai... Ada banyak hal baru dan tidak dapat dipahami di sekitar Anda, dan bagaimana tidak membuat kekacauan seperti ini begitu saja? Itulah yang akan kita bicarakan hari ini. Pada artikel ini, saya ingin melihat kesalahan umum yang dilakukan oleh pemula dan memberikan beberapa tips dari pengalaman saya sendiri tentang cara menghindarinya. Jadi, mari kita mulai tanpa basa-basi lagi:

1. Takut meminta bantuan rekan yang lebih berpengalaman

Kita semua adalah manusia, dan kita semua takut terlihat bodoh, terutama di mata rekan-rekan kita yang baru dan lebih berpengalaman. Begitu mereka mendapatkan pekerjaan pertama mereka, para pengembang sering kali menyerah pada ketakutan ini dan menarik diri, mencoba memikirkan semuanya sendiri. Pada saat yang sama, seseorang dapat dikelilingi oleh rekan-rekan yang lebih berpengalaman, yang, pada gilirannya, pada awalnya akan mampu membimbingnya ke jalan yang paling benar, yang akan membantu menghindari lebih banyak kesalahan dan “benjolan” yang tidak perlu. Oleh karena itu, ingatlah: jangan takut untuk bertanya: Anda seorang pemula, dan semua orang memahami hal ini dengan sempurna. Ketika Anda bertanya, tidak ada yang akan memukul Anda dengan tongkat. Mungkin malah sebaliknya: Anda akan lebih cepat berteman dengan kolega Anda dan mulai berkomunikasi lebih aktif dengan mereka. Saya akan mengatakan lebih banyak: semakin banyak Anda bertanya dan mendiskusikan berbagai masalah teknis, semakin cepat Anda dapat keluar dari posisi seorang pemula yang ramah lingkungan dan tumbuh menjadi ahli di bidang Anda. Dan satu nasihat lagi. Jangan abaikan StackOverFlow . Dalam konteks ini, maksud saya mengajukan pertanyaan tentang sumber ini. Di satu sisi, perlu waktu untuk mendapatkan jawaban atas pertanyaan Anda. Namun di sisi lain, Anda mungkin langsung mempelajari beberapa pendekatan untuk memecahkan masalah saat ini dan melihatnya dari sudut pandang yang sedikit berbeda. Saya juga ingin mencatat bahwa menulis komentar-jawaban, mengklarifikasi pertanyaan atas pertanyaan tentang StackOverFlow dari pengembang lain, selain nilai tambah dalam karma, memiliki manfaat praktis: Anda memiliki kesempatan untuk mendiskusikan dan memahami masalah ini lebih dalam.

2. Jangan mencoba mencari informasi sendiri

Mungkin kesalahan ini adalah kebalikan dari kesalahan sebelumnya. Maksud saya ketika Anda mulai menarik kolega dan kenalan Anda dengan setiap masalah atau masalah. Bertanya itu baik, tetapi Anda tidak boleh bertanya terlalu jauh, jika tidak, Anda mungkin akan bosan. Hal pertama yang harus dilakukan jika muncul hal yang tidak dapat dipahami adalah menerapkan keterampilan pencarian Anda di mesin pencari terbaik - Google. Seseorang telah mengalami sebagian besar kesalahan yang tidak dapat dipahami dan masalah lainnya. Dan Anda akan terkejut jika Anda mencarinya di Google dan melihat sejumlah orang yang akrab dengan masalah serupa, dan telah menerima jawaban komprehensif yang sesuai untuk digunakan dalam pekerjaan mereka. Berdasarkan hal ini, Anda sering mendengar rekan kerja menjawab pertanyaan - “Google it.” Anda tidak boleh tersinggung dengan jawaban ini, karena bagaimanapun rekan Anda bukanlah guru pribadi yang harus menyampaikan segala seluk-beluk bidang pekerjaan Anda. Hamparan internet yang luas akan membantu Anda dalam pendampingan tersebut. Terkadang seorang programmer juga disebut sebagai orang dengan sabuk hitam di pencarian Google . Oleh karena itu, ketika kita mengalami kebuntuan, pertama-tama kita mencari masalahnya di Google, dan jika tidak ada solusi yang ditemukan (jarang, tetapi itu terjadi), barulah kita mulai bertanya kepada rekan-rekan kita. Sebaiknya tanyakan kepada mereka segera, bukan ketika ada kesalahan atau kesalahan yang tidak dapat dipahami, tetapi ketika memilih pendekatan untuk menyelesaikan suatu masalah. Lagi pula, mereka dapat melihat lebih jauh dari apa yang Anda lakukan dan langsung mengetahui bagaimana pendekatan ini atau itu akan terwujud dalam jangka panjang.

3. Salin-tempel secara buta

Namun mencari masalah di Google dan, karenanya, solusinya memiliki kendala tersendiri. Misalnya saja copy-paste buta . Ini biasanya terjadi ketika Anda menemukan masalah serupa (tetapi mungkin tidak persis sama) dan di bawahnya, misalnya, di StackOverFlow ada solusinya. Anda mengambil solusi ini, menyalin dan menempelkannya sendiri, tanpa menjelaskan terlalu banyak detail. Dan kemudian Anda atau rekan proyek Anda menemukan beberapa bug aneh atau perilaku fungsi Anda yang salah. Dan saat itu juga tidak ada yang tahu dari mana asal kaki itu. Kemudian, tentu saja, tempat dengan kode ini akan ditemukan, dan Anda pasti tidak akan dipuji atas keputusan ini. Oleh karena itu, ketika Anda menemukan solusi siap pakai di StackOverFlow (atau di tempat lain), pertama-tama Anda harus menganalisisnya secara detail, apa itu, bagaimana dan mengapa. Mungkin Google fungsi ini dan lihat dokumentasinya. Dan baru setelah itu terapkan ke dalam proyek Anda.

4. Memberikan solusi yang salah

Saat menulis solusi, terkadang solusinya menjadi semakin kompleks dan akhirnya menemui jalan buntu. Dan Anda mencoba untuk semakin memperumitnya untuk menyelesaikan masalah ini dengan menggunakan pendekatan ini alih-alih mencoba mencari alternatif lain yang lebih bisa diterapkan. Mungkin Anda hanya merasa kasihan atas energi dan waktu yang Anda habiskan, sehingga Anda memutuskan: apa pun yang terjadi, jangan menyerah, tetapi selesaikan masalah dengan cara ini. Ini bukan pendekatan yang tepat. Setidaknya dalam pemrograman. Semakin cepat Anda mencoba pendekatan lain, semakin banyak waktu yang Anda hemat. Jadi jangan takut untuk bereksperimen dan mencoba pendekatan lain, meskipun Anda sudah menghabiskan banyak waktu untuk melakukan pendekatan ini. Selain itu, ini akan menjadi poin pengalaman Anda, karena Anda akan mencoba beberapa pendekatan dan mempelajari bidang ini dengan lebih baik.

5. Takut bertanya tentang tugas yang sedang dikerjakan

Pengerjaan suatu proyek biasanya dilakukan untuk menyelesaikan beberapa tugas (Tasks). Misalnya saja di Jira . Dan tugas-tugas tersebut tidak selalu dijelaskan secara rinci dan jelas. Biasanya ditulis oleh pimpinan tim, dan ini juga manusia, jika itu terjadi. Mereka mungkin juga lupa menambahkan sesuatu atau tidak memperhitungkan bahwa Anda tidak terlalu paham dengan fungsi ini atau itu. Ya, atau Anda tidak memiliki akses apa pun ke proyek tersebut (misalnya, akses ke Database, ke server log, dan sebagainya). Dan sekarang, setelah menerima tugas, setelah mempelajarinya selama lebih dari beberapa jam, Anda masih duduk dan melihat layar dengan bingung. Dan daripada terus memikirkan hal ini tanpa hasil, Anda sebaiknya mulai mengajukan pertanyaan yang mengarahkan/mengklarifikasi kepada pembuat tugas ini. Misalnya, dalam aplikasi yang Anda gunakan untuk komunikasi dalam tim (misalnya, Microsoft Teams) atau langsung sebagai komentar di bawah tugas ini. Di satu sisi, jika Anda menulis pertanyaan dalam pesan pribadi, kemungkinan besar jawabannya akan lebih cepat, karena orang tersebut akan langsung melihat pertanyaan tersebut. Sebaliknya, dengan mengajukan pertanyaan di Jira, Anda memiliki bukti bahwa Anda sedang melakukan sesuatu, yaitu menganalisis masalah. Ada cara untuk mempercepat proses ini: ajukan pertanyaan sebagai komentar di Jira dan kirimkan tautan ke komentar ini dalam pesan pribadi dengan permintaan untuk melihatnya.

6. Berharap terlalu banyak dari pemimpin tim

Sekali lagi, ini adalah kebalikan dari poin sebelumnya. Pemimpin tim adalah orang yang menjadi kepala tim pengembangan. Biasanya, sebagian besar waktu anggota tim dihabiskan untuk berbagai jenis komunikasi. Dan pada saat yang sama, dia juga menulis kode agar tidak lupa apa itu semua. Seperti yang Anda pahami, ini adalah karakter yang sangat sibuk. Dan kedutan berlebihan setiap bersin jelas tidak akan membuatnya bahagia. Bayangkan jika setiap anggota tim membombardirnya dengan banyak pertanyaan. Jadi kamu bisa jadi gila, kan? Dan tidak mengherankan jika dengan banyaknya pertanyaan dari Anda, dia akan menjawab Anda untuk waktu yang lama. Apa yang dapat Anda lakukan untuk mengurangi jumlah pertanyaan kepada pimpinan tim:

• Pelajari dokumentasi proyek ini lebih dalam untuk mengurangi jumlah titik buta.
• Ajukan pertanyaan kepada anggota tim lainnya. Sangat mungkin bahwa mereka sama familiarnya dengan fungsi ini seperti pemimpinnya, atau bahkan lebih, karena kemungkinan besar salah satu dari mereka menulis fungsi tersebut.

Alternatifnya, di IDE Anda dapat melihat anotasi: siapa dan kapan terakhir kali mengubah kode pada baris tertentu. Dengan cara ini kita akan mengetahui siapa yang paling benar menanyakan pertanyaan ini. Seperti yang mungkin sudah Anda pahami, ketika mengajukan pertanyaan kepada pemimpin tim, serta ketika mengajukan pertanyaan kepada rekan kerja, Anda perlu berusaha untuk menjaga maksud emas - tidak takut untuk mengajukan pertanyaan, tetapi juga tidak mengganggu mereka dengan jumlah yang berlebihan.

7. Takut akan peninjauan kode

Review kode atau code review merupakan tahapan sebelum mengupload kode ke aplikasi umum (ke cabang umum, misalnya master atau dev). Pemeriksaan ini dilakukan oleh pengembang yang tidak terkait dengan tugas ini, yang dapat, dengan tampilan baru, menemukan kesalahan, ketidakakuratan, atau kekurangan dalam gaya kode yang luput dari perhatian pada tahap awal pengembangan. Jika ada komentar, dibiarkan sebagai komentar pada bagian kode tertentu. Dalam hal ini, pengembang yang melakukan tugas ini harus memperbaiki kesalahan sesuai dengan review (atau mendiskusikan keputusannya dengan reviewer, mungkin meyakinkan dia tentang kebenaran keputusannya). Setelah itu dikirim kembali untuk ditinjau, begitu seterusnya hingga reviewer tidak memberikan komentar. Reviewer berfungsi sebagai “filter” sebelum mengupload kode. Jadi, banyak pemrogram pemula menganggap tinjauan kode sebagai kritik dan kutukan. Mereka tidak menghargainya dan takut padanya, dan itu salah. Peninjauan kode inilah yang memungkinkan kami meningkatkan kode kami. Bagaimanapun, kita menerima informasi penting tentang kesalahan apa yang kita lakukan dan apa yang harus kita perhatikan. Penting untuk melihat setiap tinjauan kode sebagai bagian dari pembelajaran, sesuatu yang dapat membantu Anda meningkatkan diri. Ketika seseorang meninggalkan komentar pada kode Anda, dia berbagi dengan Anda pengalamannya, praktik terbaiknya. Bagi saya, Anda tidak bisa menjadi programmer yang baik tanpa mendapatkan review kode. Karena Anda tidak tahu seberapa bagus kode Anda dan apakah ada kesalahan di sana dari sudut pandang orang luar yang berpengalaman.

8. Kecenderungan untuk mengambil keputusan yang sulit dipahami

Seringkali tugas/masalah yang berbeda dapat memiliki beberapa solusi berbeda. Dan dari semua solusi yang ada, pemula biasanya menggunakan solusi yang paling rumit dan “muskil”. Dan memang benar: jika seorang programmer pemula baru kemarin mempelajari banyak algoritma, pola, struktur data yang berbeda, maka tangannya sudah gatal untuk mengimplementasikan salah satunya. Ya, dan saya ingin menyatakan diri saya sendiri. Percayalah, saya sendiri juga seperti itu dan saya tahu apa yang saya bicarakan :) Saya mengalami situasi di mana saya menghabiskan waktu lama untuk menulis satu fungsi yang ternyata sangat, sangat kompleks. Kemudian ditulis ulang oleh pengembang tingkat Senior+. Tentu saja saya tertarik melihat apa dan bagaimana dia mengubahnya. Saya melihat penerapannya dan kagum melihat betapa sederhananya penerapannya. Dan kodenya menjadi tiga kali lebih sedikit. Dan pada saat yang sama, pengujian fungsi ini tidak berubah dan tidak gagal! Artinya, logika umumnya tetap sama. Dari sini saya sampai pada kesimpulan bahwa: solusi paling cerdik selalu sederhana . Setelah realisasi ini, menulis kode menjadi lebih mudah, dan menjadi lebih canggih. Kalau begitu, kapan sebaiknya menggunakan pola dan algoritma, Anda bertanya? Kemudian, saat menggunakannya akan menjadi cara paling sederhana dan ringkas.

9. Penemuan sepeda

Konsep ini dikenal juga dengan penemuan roda. Esensinya terletak pada kenyataan bahwa pengembang mengimplementasikan solusinya sendiri terhadap suatu masalah yang solusinya sudah ada, dan berkali-kali lebih baik daripada solusi yang ditemukan oleh programmer. Biasanya, menciptakan sepeda sendiri akan membuang-buang waktu dan mengurangi efisiensi kerja pengembang, karena solusi yang jauh dari yang terbaik mungkin tidak ditemukan, atau mungkin tidak ditemukan sama sekali. Pada saat yang sama, kita tidak bisa mengabaikan kemungkinan adanya keputusan independen. Pemrogram harus menavigasi dengan benar tugas-tugas yang mungkin dihadapinya untuk menyelesaikannya secara kompeten dan tepat waktu, menggunakan solusi yang sudah jadi atau menciptakan solusinya sendiri. Di satu sisi, di universitas dan kursus kita dibombardir dengan berbagai macam tugas yang seharusnya membantu kita dalam membuat sepeda. Tapi ini hanya sekilas. Faktanya, tujuannya adalah untuk mengembangkan pemikiran algoritmik dan penguasaan sintaksis bahasa yang lebih dalam. Dan tugas-tugas seperti itu juga membantu untuk lebih memahami algoritma/struktur, dan, jika perlu, memberi mereka keterampilan untuk mengimplementasikan analog lanjutannya (tetapi hal ini sangat jarang diperlukan). Dalam kehidupan nyata, dalam sebagian besar kasus, tidak perlu menciptakan roda sendiri, karena analog telah lama ada yang memenuhi kebutuhan kita. Mungkin, karena pengalaman Anda, Anda tidak akan mengetahui keberadaan implementasi fungsi tertentu yang Anda perlukan. Di sinilah Anda perlu menggunakan poin pertama artikel ini, yakni meminta bantuan rekan yang lebih berpengalaman. Mereka akan dapat memandu Anda (misalnya, menyarankan arah mana ke Google) atau menyarankan penerapan tertentu (perpustakaan tertentu).

10. Jangan menulis tes

Semua pemula tidak menyukai tes menulis. Bagaimana dengan pemula: non-pemula juga tidak menyukai tes menulis, tetapi mereka lebih memahami mengapa tes itu diperlukan. Ketika Anda benar-benar hijau, Anda berpikir: mengapa menulisnya? Semuanya berfungsi, dan tidak ada kesalahan. Namun bagaimana Anda bisa yakin bahwa perubahan yang Anda lakukan tidak merusak bagian lain dari sistem? Kolega Anda tidak akan menghargai jika Anda memaksakan perubahan yang lebih mengganggu daripada manfaatnya. Di sinilah tes bisa membantu. Semakin banyak suatu aplikasi tercakup dalam pengujian, semakin baik (disebut juga persentase cakupan). Jika aplikasi tercakup dalam pengujian, dengan menjalankan semuanya, Anda mungkin menemukan tempat yang dapat dirusak oleh perubahan Anda. Dan seperti yang saya katakan pada contoh di atas, ketika memfaktorkan ulang fungsionalitas, pengujian tidak gagal, dan semua itu karena logika umum tidak berubah. Artinya pengujian juga dapat menunjukkan apakah logika fungsi tertentu telah berubah atau tidak. Jadi meskipun Anda tidak menyukai tes menulis, tidak diragukan lagi ada manfaatnya, dan tes tersebut sepadan dengan waktu yang dihabiskan untuk tes tersebut.

11. Berkomentar berlebihan

Banyak pengembang menderita perfeksionisme, tidak terkecuali pemula. Namun terkadang efek samping dari keinginan ini adalah mereka mulai mengomentari semua orang dan segalanya. Bahkan yang tidak diperlukan, karena sudah jelas:

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

Tidak semua programmer pemula langsung menyadari bahwa mengomentari kode tidak selalu merupakan hal yang baik, karena kode tersebut akan menjadi lebih berantakan dan sulit dibaca. Bagaimana jika kodenya diubah, tetapi tidak ada komentar? Ternyata dia akan menipu kita dan hanya membuat kita bingung. Lalu mengapa komentar seperti itu? Biasanya, kode yang ditulis dengan baik tidak memerlukan komentar , karena semua isinya sudah jelas dan dapat dibaca. Jika Anda menulis komentar, itu berarti Anda telah merusak keterbacaan kode dan mencoba memuluskan situasi. Pendekatan terbaik adalah dengan menulis kode yang dapat dibaca terlebih dahulu dan tidak harus dilengkapi dengan komentar. Saya juga mau tidak mau menyebutkan penamaan metode, variabel, dan kelas yang benar, yaitu aturan yang saya sendiri patuhi: Komentar terbaik adalah tidak adanya komentar, dan sebagai gantinya, penamaan yang benar yang menjelaskan hal ini dengan jelas atau fungsionalitas itu di aplikasi Anda.

12. Penamaan yang buruk

Seringkali para pemula memalsukan nama kelas, variabel, metode, dll. Misalnya saja ketika mereka membuat kelas yang namanya tidak menjelaskan tujuannya sama sekali. Atau sebuah variabel dibuat dengan nama pendek, seperti x , dan ketika dua variabel lagi bernama n dan y dibuat , menjadi sangat sulit untuk mengingat apa yang dilakukan x . Dalam kasus seperti itu, Anda harus memikirkan kode dengan cermat dan mempelajari fungsi ini di bawah mikroskop (mungkin menggunakan debugger) untuk memahami apa yang terjadi di sana. Di sinilah penamaan yang benar dalam kode yang saya sebutkan di atas dapat membantu kita. Nama yang benar meningkatkan keterbacaan kode, sehingga menghemat waktu pengenalan, karena jauh lebih mudah menggunakan metode yang namanya kurang lebih menggambarkan fungsinya. Dalam kode, semuanya terdiri dari nama (variabel, metode, kelas, objek file, dll), poin ini menjadi sangat penting saat membuat kode yang benar dan bersih. Perlu diingat bahwa nama harus menyampaikan arti: mengapa, misalnya, variabel itu ada, apa fungsinya, dan bagaimana penggunaannya. Dan saya akan mencatat berulang kali bahwa komentar terbaik untuk mendeskripsikan suatu variabel adalah nama yang benar. Untuk mempelajari lebih dalam tentang komentar dan penamaan yang benar, saya menyarankan Anda untuk membaca buku klasik abadi: “Kode bersih. Penciptaan, analisis, dan pemfaktoran ulang”, Robert Martin . Pada catatan ini, bagian pertama artikel ini (refleksi) telah berakhir. Bersambung…