Apakah normal bagi seorang programmer untuk tidak memiliki kejelasan 100% atas kode mereka sendiri pada suatu waktu? [Tutup]

Saya bukan programmer ahli jadi ini mungkin mengapa, tapi saya menyadari bahwa setiap kali saya membuat kode kompleks (seperti game Catur yang baru saya buat), saya dapat menulis kode yang benar untuk membuat program bekerja, walaupun saya menemukan itu nanti atau bahkan beberapa detik setelah! - Saya sering harus berhenti, dan berpikir, bagaimana cara kerjanya?

Bukan hanya itu, tetapi saya juga cenderung tidak memikirkan kode, dan sebagai gantinya saya cukup mengetik. Sebagai contoh, dalam permainan Catur saya, saya memutuskan untuk menggunakan array lima dimensi untuk memproses gerakan, dan saya menemukan saya bisa melakukan ini tanpa terlalu banyak berpikir secara sadar. Namun, ketika saya berhenti dan membacanya, saya merasa sulit untuk memahami seluruh konsep lima dimensi, dan saya butuh beberapa menit untuk sepenuhnya memahami apa yang saya lakukan, dan bagaimana kode itu sendiri bekerja.

Apakah normal bagi programmer ketika menulis kode kompleks untuk tidak mengerti apa yang mereka lakukan setengah dari waktu?

Tidak, itu tidak normal ¹ . Setidaknya, itu tidak normal untuk programmer yang baik. Mungkin ini normal untuk seseorang belajar program.

Menulis perangkat lunak tidak hanya menampar baris kode sampai ia berfungsi. Anda perlu secara sadar bekerja membuat kode mudah dimengerti. Seorang programmer yang saya hormati sekali mengatakan kepada saya "kode dibaca jauh lebih banyak daripada yang tertulis" . Meskipun itu harus sepenuhnya jelas, itu adalah fakta yang belum kusadari sampai dia memberitahuku. Sebagian besar kode Anda ditulis hanya sekali, mungkin ditulis ulang sekali atau dua kali lagi, tetapi akhirnya Anda akan sering membaca kode selama masa pakai perangkat lunak.

Jika Anda menemukan kode sulit dipahami beberapa menit setelah menulisnya, itu adalah sinyal bahwa kode Anda terlalu kompleks. Berhenti menambahkan kode, dan cari cara yang lebih baik. Sebagai contoh, array lima dimensi hampir tidak pernah merupakan ide yang baik. Bahkan programmer yang benar-benar pintar pun kesulitan memahami struktur data yang begitu kompleks.

Programmer yang sama yang memberi tahu saya tentang keterbacaan kode juga mengatakan "tunjukkan struktur data Anda dan saya bisa memberi tahu Anda bagaimana kode Anda bekerja" . Artinya, kode yang baik dimulai dengan struktur data yang bersih dan mudah dipahami. Jika Anda mendesain data dengan benar, kode ini hampir merupakan masalah sekunder. Diakui, pernyataan ini sedikit hiperbola karena perangkat lunak jelas lebih dari sekadar data, tetapi dimulai dengan data. Jadi, bekerja untuk menciptakan struktur data yang bersih dan mudah dipahami dan kode akan jauh lebih mudah dipahami.

¹ Tentu saja ada kode di luar sana yang sangat kompleks dan sulit dipahami bahkan oleh programmer paling cerdas sekalipun. Beberapa masalah pada dasarnya rumit. Namun, saya berani mengatakan bahwa sebagian besar kode yang ditulis oleh sebagian besar programmer bukan jenis kode itu.

Ada dua jenis ini: 1.) kebingungan 2.) ketidaktahuan bahagia

Yang pertama buruk dan mungkin menghilang seiring waktu dan pengalaman.

Yang kedua adalah bagus jika proyek menjadi lebih besar: Jika Anda harus mengingat setiap detail implementasi hanya untuk dapat bekerja dengan kode Anda, ada yang salah dengan itu (lihat "menyembunyikan informasi").

Setiap pengembang akan lupa bagaimana kode itu bekerja, jadi dia menulisnya sedemikian rupa sehingga pengembang baru lainnya akan mengerti dan dapat mempertahankannya tanpa merusak bagian lain dari program yang tidak dikenalnya juga.

Jadi "tidak tahu" sebenarnya konstan dalam pengembangan perangkat lunak - hanya bagaimana atau apakah Anda mengelolanya.

Saya akan mengatakan itu lebih umum daripada orang yang mau mengakui. Bahkan Brian Kernighan menyinggung hal itu:

Debugging dua kali lebih sulit daripada menulis kode di tempat pertama. Karena itu, jika Anda menulis kode sepintar mungkin, Anda, menurut definisi, tidak cukup pintar untuk debug itu.

Saat kami berkendara ke toko, kami membuat urutan penyesuaian terperinci untuk posisi pedal dan roda kemudi. Ini sangat mudah saat ini. Sekarang, bayangkan jika Anda merekam penyesuaian itu di atas kertas dan memberikannya kepada seorang teman yang membutuhkan petunjuk arah ke toko.

Demikian pula, kami suka menulis kode pada satu tingkat abstraksi, tetapi kami suka membacanya dalam beberapa lapisan abstraksi yang lebih tinggi. Karenanya, cara favorit kami untuk menulis dan membaca kode bertentangan. Itu berarti membuat kode mudah dibaca biasanya merupakan langkah yang terpisah dan sadar, dengan serangkaian keterampilan yang berbeda.

Apa yang membuat programmer bagus adalah ketika mereka kesulitan membaca apa yang baru saja mereka tulis, mereka membuat abstraksi pada saat itu. Seorang programmer yang lebih baik melakukannya berkali-kali, setiap kali memilih. Akhirnya, programmer berpengalaman memulai lebih jauh di sepanjang proses, tetapi mereka sering masih dapat melihat ruang untuk perbaikan setelah membaca apa yang baru saja mereka tulis.

Saya pikir ini adalah sesuatu yang akan hilang dengan pengalaman.

Jika Anda menulis sistem yang kompleks, Anda perlu memiliki kemampuan untuk menulis kode yang bersih dan dapat dipelihara yang dapat dipahami oleh Anda di masa depan dan orang lain di masa depan. Jadi, pada dasarnya, hal yang Anda lakukan sekarang tidak dapat diskalakan.

Anda akan memiliki banyak momen di mana Anda melihat beberapa kode yang Anda tulis 6 bulan lalu dan berpikir "apa yang terjadi di sini?", Tetapi jika itu terjadi sehari setelah Anda menulis kode, Anda harus berpikir 'bersih kode lebih.

Sumber: tidak pernah menggunakan array 5 dimensi :)

"Normal" sangat subyektif, jadi saya katakan: ini sangat umum, tetapi harus dihindari.

Salah satu fitur dari "kode yang baik" (saya mendengar hal seperti itu ada) adalah kejelasan: itu harus sejelas masalah mendasar memungkinkannya. Jika masalahnya kompleks, kodenya juga akan rumit, tetapi itu adalah kompleksitas yang melekat , berlawanan dengan kompleksitas yang tidak disengaja (saya pertama kali mendengar perbedaan dalam pembicaraan Rich Hickey ) yang diperkenalkan oleh salah atau tidak menggunakan alat, pola, teknik, dan praktik.

Ada beberapa kasus ketika ketidakjelasan dapat diterima bahkan ketika masalahnya tidak terlalu rumit, misalnya jika Anda menulis situs promo yang Anda tahu akan bertahan selama kampanye pemasaran berlangsung. Itu adalah kode membuang yang tidak boleh dipertahankan. Untuk kasus lain (dan sebagian besar), itu tidak dapat diterima, karena mempertahankan kode semacam itu akan memakan banyak biaya. Namun, itu biasa.

Terkait:

• When Understanding artinya Menulis Ulang - artikel tentang masalah memahami kode.
• ML yang efektif - pembicaraan panjang tentang, di antara ML / OCaml, bagaimana menulis kode untuk "pembaca" (yaitu pengelola): "Pilih pembaca dari penulis." Saya sarankan menonton itu, apa pun bahasa yang Anda gunakan.

Saya tidak berpikir itu normal, tetapi untuk program yang sangat kompleks, seperti program catur yang Anda sebutkan, saya pikir itu pasti mungkin.

Bertahun-tahun yang lalu, ketika saya baru lulus sekolah (jadi saya masih relatif tidak berpengalaman menulis program besar), saya menulis kompiler nyata pertama saya. Penguraiannya mudah, tetapi kemudian saya perlu menargetkannya untuk empat set instruksi mikroprosesor yang berbeda. Saya bermaksud untuk menulis kompiler dalam bahasanya sendiri, jadi saya pertama kali hanya menggunakan fitur-fitur dari bahasa yang benar-benar saya butuhkan, menulis generator kode pertama dalam bahasa assembly, dan menguji bahwa itu menghasilkan kode yang benar untuk subset dari bahasa tersebut. Saya kemudian dapat menggunakan kompilator untuk mengkompilasi sendiri sejak saat itu, dan menambahkan fitur yang tersisa dan juga menggunakannya dalam kompiler itu sendiri

Saya kemudian menulis generator kode backend untuk setiap mikroprosesor, dan menguji bahwa mereka semua menghasilkan kode yang benar, tetapi sementara benar itu tidak terlalu optimal. Jadi saya kemudian mulai menulis pengoptimal untuk setiap pembuat kode.

Ketika saya menguji output dari generator kode setelah menambahkan semua optimasi, saya sering terkejut dengan kode yang dihasilkan oleh kompiler. Itu sering kali bukan cara saya menulis kode dengan tangan, tetapi itu benar dan cukup ringkas.

Ketika itu tidak jelas bagi saya bagaimana pembuat kode menghasilkan beberapa kode yang dilakukannya, saya mencoba untuk menindaklanjuti logika dengan tangan tetapi ada saat-saat saya menyerah begitu saja. Jika saya telah menambahkan banyak jejak keluaran saya akan bisa mengikutinya, tapi saya tidak repot karena kode yang dihasilkan memuaskan dan saya harus melanjutkan ke proyek lain.

Ada banyak jawaban yang layak di sini.

Saya punya beberapa hal dalam hal ini.

Salah satunya adalah jika Anda tidak mengerti mengapa kode Anda tampaknya berfungsi, maka a) mungkin tidak (mungkin hanya sepertinya berfungsi), dan b) Anda juga tidak memahami domain masalah dengan cukup baik ketika Anda mulai coding, atau tidak memecah domain masalah menjadi unit yang lebih kecil, disederhanakan sebelum Anda mulai.

Pandangan saya yang lain tentang ini adalah bahwa kunci sebenarnya adalah menggunakan pola akal sehat dan konvensi dalam kode Anda. Itu topik yang jauh lebih besar daripada yang bisa diatasi oleh satu posting kecil. Tetapi cari literatur yang baik tentang masalah ini, termasuk beberapa standar lama seperti buku "Code Complete" dan "Writing Solid Code."

Detail implementasi berubah. Satu-satunya konstanta yang nyata adalah tujuan fungsional kode. Jika Anda pernah menulis lebih dari satu fungsi, Anda akan melupakan detail implementasi granular dari waktu ke waktu. Tetapi Anda tentu harus memahami cara kerja potongan-potongan ketika Anda membangunnya, dan Anda harus bisa menggambar diagram keseluruhan dan memahami bagaimana potongan-potongan itu bekerja bersama.

Jika Anda menggunakan pola, dan mengikuti konvensi akal sehat, akan jauh lebih mudah untuk memilih kembali detail implementasi spesifik ketika Anda melihat kode lagi. Atau ketika seseorang yang belum pernah melihat kode sebelumnya melihatnya untuk pertama kali. Selain itu, mengikuti konvensi dan pola tersebut selama jangka waktu akan berarti bahwa detail implementasi akan menonjol dari konvensi dan pola itu sendiri, yang merupakan faktor lain yang akan membuat kode lebih mudah untuk dipahami.

Sebagian besar masalah yang kita tangani dengan perangkat lunak sifatnya kompleks. Desain perangkat lunak adalah latihan dalam mengelola kompleksitas.

Saya tidak akan menyebutnya normal , tetapi pasti bisa terjadi. Jika itu terjadi pada Anda tak lama setelah Anda menulis potongan kode yang dimaksud, saya kira baik kode Anda tidak perlu rumit dan harus disederhanakan, atau Anda hanya dengan mudah terganggu. :)

Tetapi jika Anda menyimpan kode Anda, berkonsentrasi pada proyek-proyek lain, dan kembali ke sana setelah berminggu-minggu, berbulan-bulan, atau bahkan bertahun-tahun, tidak terlalu mengejutkan bahwa Anda harus memikirkannya lagi.

Tetapi ada sesuatu yang dapat Anda lakukan tentang ini. Dari apa yang Anda katakan, tampaknya Anda tidak cukup memikirkan kode Anda ketika Anda menulisnya, dan dengan demikian Anda mempersulit diri Anda di masa depan untuk memahami apa yang sedang terjadi. Gunakan pengetahuan itu untuk keuntungan Anda: Ini adalah motivasi terbaik untuk menghasilkan kode yang terstruktur, terdokumentasi dengan baik, dan dapat dipahami. Anda tahu dari pengalaman langsung apa yang terjadi ketika Anda tidak menjaga kualitas kode Anda. Mengetahui hal itu akan membuat Anda menjadi programmer yang lebih baik dalam jangka panjang. Ketika Anda berkolaborasi dalam proyek perangkat lunak, kolega Anda akan berterima kasih karena telah menghasilkan kode yang dapat dimengerti. Dan tingkat cacat kode Anda akan meningkat juga.