Seperti yang dikatakan oleh penulis legendaris Jules Verne: "Minimum yang digunakan cukup memadai." Di era kita ini, konsep minimum yang digunakan dengan baik berlaku untuk kode. Menyedihkan tapi benar: di dunia kode modern ada terlalu banyak. Untuk lebih tepatnya, ada terlalu banyak kode yang tidak perlu, di antaranya kode yang berguna hanya mencekik.
Mengingat hal di atas, kode yang tidak perlu adalah jahat secara default. Memburuk seiring waktu. Itu membutuhkan dukungan berkelanjutan. Berisi bug yang perlu Anda cari. Ketika fungsi baru muncul, kode lama harus disesuaikan dengannya. Semakin banyak kode yang Anda miliki, semakin banyak kesalahan yang Anda miliki di dalamnya. Semakin banyak waktu verifikasi atau kompilasi, semakin lama karyawan baru akan memahami sistem Anda.
Dan di atas semua lompatan ini, kode ditulis oleh programmer. Semakin banyak, semakin banyak programmer yang dibutuhkan. Ketika jumlah programmer meningkat, demikian pula biaya komunikasi di antara mereka, yang selanjutnya berkontribusi pada biaya pengembangan dan pemeliharaan kode.
Untuk semua masalah ini, ada satu solusinya: tulis lebih sedikit kode. Pendekatan ini memiliki banyak keunggulan:
- Lebih sedikit kode untuk dikembangkan = lebih sedikit biaya pengembangan
- Lebih sedikit kode dalam pengembangan = lebih sedikit biaya perawatan
- Lebih sedikit kode dalam pengembangan = lebih sedikit bug
- Lebih sedikit kode untuk dikembangkan = pengujian yang lebih efisien
Dan yang paling penting: semakin sedikit kode yang Anda paksakan untuk dibaca orang, semakin besar kemungkinan seseorang akan membacanya sama sekali.
Berikut adalah beberapa cara Anda dapat mengurangi kode.
Prinsip YAGNI (“Anda Tidak Membutuhkannya”)
Prinsip "Anda tidak membutuhkannya" (sering disebut sebagai YAGNI - You Aint 'Need It) berarti aturan pemrograman ekstrem berikut: "Sadari peluang ini atau itu hanya ketika itu benar-benar diperlukan, dan bukan ketika Anda menganggap bahwa dia akan segera dibutuhkan. " Bahkan jika Anda seratus persen yakin bahwa fungsi ini tidak dapat dilakukan di masa depan, jangan mulai menerapkannya sekarang.
Ada dua alasan untuk praktik ini:
- Anda menghemat waktu dengan menolak menulis kode yang saat ini tidak diperlukan.
- Kualitas kode meningkat - Anda tidak mencemarinya dengan fragmen yang didasarkan pada dugaan yang kurang lebih benar, dan tetap berada di basis kode, bahkan jika tebakan ini tidak dikonfirmasi.
Konsep YAGNI cukup masuk akal terlepas dari metodologi manajemen proyek apa yang Anda patuhi. Arsitektur yang baik membutuhkan keseimbangan kemungkinan yang seimbang. Arsitektur buruk terdiri dari sekelompok fungsi sketsa yang menghasilkan basis kode yang Anda dukung untuk disiksa.
Aturan dasar di sini adalah: fokus pada apa yang jelas dibutuhkan, dan jangan berpikir tentang apa yang mungkin terjadi.
Jangan menulis kode yang kebal
Kode kebal adalah kode ideal, kode yang akan bekerja di bawah data input apa pun dan kondisi apa pun. Gagasan untuk menciptakan sesuatu yang serupa memiliki daya tarik tersendiri, terutama bagi pengembang ambisius yang menganggap kegagalan dalam beberapa skenario sebagai penghinaan pribadi. Namun, menulis (atau mencoba menulis) kode kebal adalah ide kosong, karena segala sesuatu di dunia memiliki batasnya sendiri, dan kode tidak terkecuali.
Mencoba menerapkan modul ideal, Anda akan meresepkan kondisi tambahan, sehingga menambah kerumitan pada basis kode, yang bertentangan dengan tujuan utama kode. Modul ini akan menjadi semakin luas dari waktu ke waktu, menghabiskan lebih banyak sumber daya dan menjadi kandidat untuk pemeliharaan yang ceroboh.
Itulah sebabnya, jika Anda bermaksud untuk menulis lebih sedikit kode, Anda harus berusaha keras untuk implementasi semudah mungkin, dari kategori "hanya untuk bekerja."
Panduan Pemrograman Ekstrim menyebutkan dua aturan emas untuk menulis kode sederhana:
- Pertama, terapkan fungsi baru dengan cara paling primitif yang hanya bisa berfungsi. Jangan membangun superstruktur yang menakjubkan, jangan memperbaiki diri sendiri - pastikan semuanya dimulai. Pastikan kode lolos tes unit untuk fungsionalitas baru (dan untuk yang lama juga, seperti biasa).
- Kemudian - dan ini adalah bagian penting dari aturan - refactor sistem dan sederhanakan kode sebanyak mungkin untuk semua fungsi yang saat ini terkandung dalam produk. Ikuti prinsip KERING dan prinsip-prinsip lain yang membantu membuat sistem lebih rapi.
Jangan lupa: kami tidak berusaha untuk jalur terpendek, tetapi untuk hasil paling sederhana.
Dengan demikian, kita mulai dengan memecah metode yang ada menjadi beberapa bagian. Dalam hal ini, opsi pengujian akan bekerja tanpa kegagalan. Kemudian kami mengubah (dalam arah penyederhanaan) salah satu metode kecil yang dihasilkan dengan memperhatikan pilihan tes berikutnya dan seterusnya.
Ingatlah bahwa kesederhanaan adalah jantung keanggunan. Kemampuan untuk mengendalikan dan menghilangkan kompleksitas yang tidak perlu adalah pemrograman yang luar biasa.
Jangan membuat kode lebih buruk
Aturan ini dapat dianggap sebagai sumpah Hipokrates untuk pengembang. Mereka yang terlibat dalam pemrograman terus-menerus mendengar tip untuk tidak mengambil jalan pintas dan tidak mencari solusi yang dapat merusak kode dan menyebabkan degradasinya.
Prosedur pengembangan perangkat lunak, seperti prosedur medis, seringkali melibatkan campur tangan kasar dan tindakan merusak. Selain itu, alat dan teknik yang kami gunakan sering kali baru dan belum diverifikasi (atau tidak diverifikasi). Selain itu, kami tidak memiliki analog dari Dewan Perizinan Medis atau Kantor Kontrol Produk yang akan mengatur praktik dan alat pengembangan yang kami pilih. Dengan demikian, kami terkadang mengekspos pasien kami, yaitu, perangkat lunak, ke prosedur yang terkait dengan risiko yang tidak perlu, dan bahkan tidak sepenuhnya memahami apa risiko ini.
Kadang-kadang, dalam proses memperbaiki masalah, kita melakukan lebih banyak kerusakan daripada kebaikan. Dalam bukunya "Kode Sempurna", yang merupakan bagian dari literatur emas untuk para programmer, Steve McConnell menulis bahwa jika Anda bekerja bukan pada akar masalahnya, tetapi pada gejalanya, Anda hanya memperburuk situasi - Anda membodohi diri sendiri - Anda membodohi diri sendiri, menciptakan ilusi bahwa masalah itu diselesaikan .
Tetapi terkadang mengamati aturan ini bisa sangat sulit. Terkadang kode yang ketinggalan jaman berada dalam kondisi sedemikian rupa sehingga praktis mustahil untuk mengimplementasikan fungsi baru dengan benar tanpa merusaknya. Oleh karena itu, agar lebih realistis, Anda perlu sedikit mengubah aturan: dari "Jangan membuat kode lebih buruk" menjadi "Jika Anda menurunkan kualitas kode, Anda harus menyadari apa yang Anda lakukan."
Benar juga. Jika Anda tidak melihat cara untuk mengimplementasikan fitur yang diperlukan dan tidak merusak kode, peringatkan anggota tim lain sebelum melakukan perubahan. Intinya adalah bahwa dalam hal ini Anda sengaja menurunkan kualitas kode.
Tentu saja, ini tidak akan membuat kode yang buruk menjadi lebih baik, tetapi dengan begitu Anda akan punya waktu untuk memikirkan situasinya. Pengalaman menunjukkan bahwa orang sering tidak mencapai solusi optimal hanya karena mereka siap menerima ide pertama yang muncul di pikiran mereka. Perhatikan bahwa kami tidak mengharuskan Anda meminta izin atau membantu menemukan solusi terbaik.
Keuntungan lain dari metode ini adalah mengurangi kemungkinan kejutan yang tidak menyenangkan di saat-saat buruk - seluruh tim tahu masalah apa yang seharusnya terjadi. Berkat ini, Anda dapat bekerja dalam tim dalam arti penuh kata dan menangani situasi ini tepat waktu.
Hindari konkurensi yang berlebihan
Konkurensi adalah pedang bermata dua. Itu harus digunakan hanya jika Anda tidak bisa melakukannya tanpanya.
Ketika kode dieksekusi secara berurutan, lebih mudah untuk memahami dan mencari kesalahan. Saat menggunakan konkurensi, operasi dilakukan baik secara bersamaan atau dalam urutan yang terdistorsi. Implementasi spesifik ini menciptakan banyak masalah dalam mengidentifikasi dan memperbaiki kesalahan. Jelas, itu menyulitkan arsitektur dan implementasi fungsi sekaligus pada beberapa tingkatan. Berikut adalah beberapa masalah yang dapat menyebabkan konkurensi yang diterapkan dengan buruk:
- Kondisi balapan: operasi mulai terjadi tanpa terduga
- Mutual blocking: objek yang terlibat cross-block sambil menunggu operasi simultan untuk menyelesaikan
- Kurangnya sumber daya: operasi secara stabil tidak mendapatkan akses ke sumber daya yang diperlukan yang diharapkannya
Salah satu bencana paling terkenal yang terkait dengan pengembangan perangkat lunak disebabkan oleh kondisi yang tidak saling tergantung yang ditentukan secara tidak tepat. Kesalahan pemrograman dengan Therac-25, alat radioterapi, menyebabkan kematian empat orang.
Perlu dicatat bahwa sebagian besar bahasa dan kerangka kerja pemrograman modern menyediakan alat khusus untuk debugging concurrency. Tetapi, pada akhirnya, semuanya tergantung pada pengembang - dialah yang memutuskan kapan, di mana dan bagaimana menerapkannya untuk mencapai hasil terbaik.
Jangan menabrak penimbunan
Penimbunan patologis adalah jenis perilaku yang ditandai oleh pengumpulan sejumlah besar hal yang tidak perlu dan keengganan untuk menyingkirkannya; Namun, hal-hal dapat menempati sebagian besar ruang hidup, yang dapat menyebabkan cedera dan stres.
Ketika gejala akumulasi muncul di antara pengembang, mereka mulai melekat pada sepotong kode, bahkan jika sudah usang atau penuh dengan bug. Pengembang semacam itu tidak pernah menghapus kode itu sendiri dan umumnya menentang praktik ini. Jika Anda memberi tahu mereka tentang hal ini secara langsung, dapatkan jawaban dalam semangat: "Dia mungkin suatu hari nanti diperlukan" atau "Tanpa ini, saya tidak dapat melakukan operasi X" dan seterusnya.
Pernahkah sindrom Plyushkin menyerang Anda? Mungkin Anda meninggalkan ide untuk menertibkan karena Anda mengerti bahwa Anda tidak punya cukup waktu untuk mencari tahu semua kekacauan ini? Jika demikian, maka Anda masih menderita karena penimbunan dan kekacauan total dalam kehidupan kerja Anda.
Menabung itu tidak rasional. Jika menurut Anda kehadiran beberapa kode dapat dibenarkan, tetapi Anda tidak sepenuhnya yakin akan hal itu, tandai sesuai sehingga Anda dapat kembali lagi nanti. Jadi itu tidak akan hilang dari ingatan Anda. Adapun kode, yang tidak memenuhi tujuan tertentu dan tidak penting, harus dihapus dan intinya.
Seorang programmer yang baik sedang berupaya meningkatkan kode dari hari ke hari, dan seiring waktu, kualitas kode terus berkembang. Kode usang yang ditulis oleh programmer yang baik selalu menonjol karena akurasinya - profesional tidak meninggalkan kekacauan setelah diri mereka sendiri; Bagaimanapun, kode adalah reputasi kita dan merekalah yang akan menghakimi kita. Seperti yang dikatakan Robert Martin dengan benar: "Kebenaran hanya dapat ditemukan dalam kode."