Rehat kopi #103. Untuk membela “Kode Bersih”: 100 tip abadi

Sumber: Hackernoon “Clean Code” oleh Robert C. Martin adalah buku pemrograman paling direkomendasikan sepanjang masa. Telusuri buku menggunakan kueri “buku terbaik untuk pengembang perangkat lunak” dan Anda hampir pasti akan menemukan buku ini di hasil penelusuran. Meskipun beberapa orang merasa bahwa Clean Code tidak layak untuk diperhatikan, saya berpendapat bahwa sentimen seperti itu sangat keliru. Ya, beberapa nasihat dalam buku ini patut dipertanyakan. Ya, beberapa kontennya sepertinya ketinggalan jaman. Ya, beberapa contoh membingungkan. Itu semua benar. Namun jangan terburu-buru mengabaikan banyak tip bermanfaat yang ditawarkan buku ini! Mengabaikan Kode Bersih sepenuhnya hanya karena beberapa ide buruk bukanlah solusi terbaik. Jadi, tanpa basa-basi lagi, yuk simak tips terbaik yang ditawarkan Clean Code! Kami akan membahas setiap bab, merangkum ide-ide yang ditawarkan Paman Bob dan rekan penulisnya.

Bab 1: Kode Bersih

1. Jumlah keseluruhan kekacauan meningkat seiring waktu.

2. Memulihkan sistem yang ketinggalan jaman dari awal sangatlah sulit. Refactoring dan perbaikan bertahap akan menjadi pilihan terbaik untuk ini.

3. Dalam basis kode yang berantakan, tugas yang seharusnya hanya memakan waktu beberapa jam bisa memakan waktu berhari-hari atau berminggu-minggu untuk diselesaikan.

4. Luangkan waktu untuk bertindak cepat.

5. Kode bersih melakukan satu hal dengan baik. Kode buruk mencoba melakukan terlalu banyak.

6. Kode bersih telah diuji dengan baik.

7. Saat membaca kode yang ditulis dengan baik, setiap fungsi melakukan kira-kira seperti yang Anda harapkan.

8. Jika Anda tidak setuju dengan prinsip yang diajarkan oleh seseorang dengan pengalaman bertahun-tahun, Anda setidaknya harus mempertimbangkan sudut pandangnya sebelum mengabaikannya.

9. Kode dibaca lebih sering daripada yang tertulis.

10. Kode yang lebih mudah dibaca lebih mudah diubah.

11. Tinggalkan basis kode lebih baik daripada saat Anda menemukannya (Peraturan Pramuka).

Bab 2: Arti Nama

1. Pilih nama variabel Anda dengan hati-hati.

2. Memilih nama yang bagus itu sulit.

3. Nama variabel atau fungsi harus menunjukkan apa variabel atau fungsi tersebut dan bagaimana penggunaannya.

4. Hindari penggunaan nama variabel berkarakter tunggal, kecuali untuk nama yang umum digunakan, seperti i untuk variabel penghitung dalam satu lingkaran.

5. Hindari penggunaan singkatan pada nama variabel.

6. Nama variabel harus dapat diucapkan sehingga Anda dapat membicarakannya dan mengucapkannya dengan lantang.

7. Gunakan nama variabel yang mudah ditemukan.

8. Kelas dan objek harus mempunyai nama yang berbentuk kata benda.

9. Nama metode dan fungsi harus berupa pasangan kata kerja atau kata kerja-kata benda.

Bab 3: Fungsi

1. Fungsinya harus kecil.

2. Fungsi tersebut harus melakukan satu tindakan.

3. Fungsi harus memiliki nama deskriptif.

4. Ekstrak kode di badan if/else atau alihkan pernyataan ke dalam fungsi yang diberi nama dengan jelas.

5. Batasi jumlah argumen yang dibutuhkan suatu fungsi.

6. Jika suatu fungsi memerlukan banyak argumen konfigurasi, pertimbangkan untuk menggabungkannya ke dalam satu variabel parameter konfigurasi.

7. Fungsi harus murni, artinya tidak memiliki efek samping dan tidak mengubah argumen masukannya.

8. Fungsi tersebut harus berupa perintah atau query, namun tidak boleh keduanya sekaligus (Command Query Separation).

9. Lebih baik menghilangkan kesalahan dan pengecualian dari kode daripada meninggalkan kesalahan dalam kode.

10. Ekstrak kode duplikat ke dalam fungsi yang diberi nama dengan jelas (Jangan Ulangi Sendiri).

11. Tes unit membuat pemfaktoran ulang lebih mudah.

Bab 4: Komentar

1. Komentar mungkin salah. Mereka mungkin salah pada awalnya, atau mungkin awalnya akurat dan kemudian menjadi ketinggalan jaman seiring dengan perubahan kode.

2. Gunakan komentar untuk menjelaskan mengapa hal ini ditulis seperti itu, daripada menjelaskan apa yang terjadi.

3. Komentar seringkali dapat dihindari dengan menggunakan variabel yang diberi nama dengan jelas dan mengekstrak bagian kode ke dalam fungsi yang diberi nama dengan jelas.

4. Awali komentar TODO dengan awalan yang konsisten agar lebih mudah ditemukan. Tinjau dan bersihkan komentar TODO Anda secara berkala.

5. Jangan gunakan Javadocs hanya untuk kepentingan menggunakannya. Komentar yang menggambarkan apa yang dilakukan suatu metode, argumen apa yang diperlukan, dan apa yang dikembalikannya adalah hal yang mubazir dan paling buruk menyesatkan.

6. Komentar harus mencakup semua informasi relevan dan konteks yang dibutuhkan pembaca. Jangan malas saat menulis komentar.

7. Komentar log dan komentar penulis file tidak diperlukan karena kontrol versi dan git menyalahkan.

8. Jangan mengomentari kode mati. Hapus saja. Jika Anda merasa memerlukan kode tersebut di masa mendatang, itulah gunanya kontrol versi.

Bab 5: Pemformatan

1. Sebagai sebuah tim, pilih serangkaian aturan untuk memformat kode Anda, lalu terapkan aturan tersebut secara konsisten. Apa pun aturan yang Anda setujui, Anda harus mencapai kesepakatan.

2. Gunakan pemformatan kode otomatis dan penganalisis kode. Jangan mengandalkan orang untuk menemukan dan memperbaiki setiap kesalahan pemformatan secara manual. Ini tidak efisien, tidak produktif, dan membuang-buang waktu saat meninjau kode.

3. Tambahkan spasi vertikal di antara baris kode untuk memisahkan blok kode terkait secara visual. Yang Anda butuhkan hanyalah membuat satu garis baru antar kelompok.

4. File kecil lebih mudah dibaca, dipahami, dan dipindahkan dibandingkan file besar.

5. Variabel harus dideklarasikan di dekat tempat penggunaannya. Untuk fungsi kecil biasanya terletak di bagian atas fungsi.

6. Bahkan untuk fungsi pendek atau pernyataan if, tetap format dengan benar daripada menulisnya dalam satu baris.

Bab 6: Objek dan Struktur Data

1. Detail implementasi dalam suatu objek harus disembunyikan di balik antarmuka objek. Dengan menyediakan antarmuka untuk digunakan oleh konsumen suatu objek, Anda mempermudah pemfaktoran ulang detail implementasi di kemudian hari tanpa menyebabkan perubahan yang dapat menyebabkan gangguan. Abstraksi membuat refactoring lebih mudah.

2. Sepotong kode apa pun tidak boleh memiliki pengetahuan tentang internal objek yang dioperasikannya.

3. Saat bekerja dengan suatu objek, Anda harus meminta objek tersebut untuk menjalankan perintah atau kueri, daripada menanyakan tentang internal objek tersebut.

Bab 7: Memperbaiki Kesalahan

1. Penanganan kesalahan tidak boleh mengganggu kode lainnya dalam modul.

2. Lebih baik menghilangkan kesalahan dan pengecualian dari kode daripada meninggalkan kesalahan dalam kode.

3. Tulis pengujian dengan kesalahan untuk memastikan kode Anda mengidentifikasi kesalahan tersebut dan tidak melewatkannya.

4. Pesan kesalahan harus informatif, dengan semua konteks yang diperlukan seseorang untuk memecahkan masalah secara efektif.

5. Membungkus API pihak ketiga dalam lapisan abstraksi yang tipis memudahkan penggantian satu pustaka dengan pustaka lainnya di masa mendatang.

6. Membungkus API pihak ketiga dalam lapisan abstraksi yang tipis membuatnya lebih mudah untuk meniru perpustakaan selama pengujian.

7. Gunakan pola Kasus Khusus atau pola Objek Null untuk menangani perilaku luar biasa, seperti ketika data tertentu tidak ada.

Bab 8: Batasan

1. Pustaka pihak ketiga membantu mempercepat pengiriman produk dengan memungkinkan Anda melakukan outsourcing berbagai tugas.

2. Tulis tes untuk memastikan Anda menggunakan perpustakaan pihak ketiga dengan benar.

3. Gunakan pola adaptor untuk menjembatani kesenjangan antara API perpustakaan pihak ketiga dan API yang ingin Anda miliki.

4. Membungkus API pihak ketiga dalam lapisan abstraksi yang tipis memudahkan penggantian satu pustaka dengan pustaka lainnya di masa mendatang. (Ulangi dari Bab 7)

5. Membungkus API pihak ketiga dalam lapisan abstraksi yang tipis membuatnya lebih mudah untuk meniru perpustakaan selama pengujian. (Ulangi dari Bab 7)

6. Cobalah untuk tidak memberi tahu aplikasi Anda terlalu banyak informasi tentang detail perpustakaan pihak ketiga mana pun.

7. Lebih baik bergantung pada apa yang Anda kendalikan daripada pada apa yang tidak Anda kendalikan.

Bab 9: Tes Unit

1. Kode pengujian harus sebersih kode produksi (dengan beberapa pengecualian, biasanya terkait dengan memori atau efisiensi).

2. Saat kode produksi berubah, kode pengujian juga berubah.

3. Pengujian membantu menjaga kode produksi Anda tetap fleksibel dan mudah dikelola.

4. Pengujian memungkinkan Anda membuat perubahan, memungkinkan Anda melakukan refaktorisasi dengan percaya diri tanpa takut tidak menyadarinya.

5. Susun pengujian Anda menggunakan pola Arrange-Act-Assert (juga dikenal sebagai Build-Operate-Check, Setup-Exercise-Verify, atau Give-When-Then).

6. Gunakan fungsi khusus domain untuk membuat pengujian lebih mudah ditulis dan dibaca.

7. Skor satu konsep per tes.

8. Tes harus cepat.

9. Tes harus independen.

10. Pengujian harus dapat diulang.

11. Tes tidak memerlukan konfirmasi.

12. Pengujian harus ditulis tepat waktu, sesaat sebelum atau setelah kode produksi ditulis, bukan beberapa bulan kemudian.

13. Jika pengujian Anda buruk, kemungkinan besar ada bug dalam kode Anda.

Bab 10: Kelas

1. Kelas harus kecil.

2. Kelas seharusnya hanya bertanggung jawab pada satu hal dan hanya mempunyai satu alasan untuk berubah (prinsip tanggung jawab tunggal).

3. Jika Anda tidak dapat menemukan nama yang jelas untuk kelas tersebut, mungkin kelas tersebut terlalu besar.

4. Pekerjaan Anda tidak berakhir ketika Anda mendapatkan sepotong kode untuk berfungsi. Langkah selanjutnya adalah memfaktorkan ulang dan membersihkan kode.

5. Menggunakan banyak kelas kecil dibandingkan beberapa kelas besar dalam aplikasi Anda mengurangi jumlah informasi yang harus dipahami pengembang saat mengerjakan tugas tertentu.

6. Memiliki rangkaian pengujian yang baik memungkinkan Anda melakukan refaktorisasi dengan percaya diri saat Anda memecah kelas besar menjadi kelas yang lebih kecil.

7. Kelas hendaknya terbuka untuk perluasan, tetapi tertutup untuk modifikasi (prinsip buka-tutup).

8. Antarmuka dan kelas abstrak menciptakan lapisan yang membuat pengujian lebih mudah.

Bab 11: Sistem

1. Gunakan injeksi ketergantungan untuk memberikan fleksibilitas kepada pengembang untuk meneruskan objek apa pun dengan antarmuka yang sesuai ke kelas lain.

2. Gunakan injeksi ketergantungan untuk membuat antarmuka antar objek dalam aplikasi Anda untuk mempermudah pengujian.

3. Sistem perangkat lunak tidak seperti sebuah bangunan yang perlu dirancang terlebih dahulu. Kota-kota tersebut lebih mirip kota yang tumbuh dan berkembang seiring berjalannya waktu, beradaptasi dengan kebutuhan saat ini.

4. Tunda pengambilan keputusan sampai saat kritis terakhir.

5. Gunakan bahasa khusus domain sehingga pakar dan pengembang domain menggunakan terminologi yang sama.

6. Jangan terlalu memperumit sistem Anda. Gunakan hal paling sederhana yang berhasil.

Bab 12: Penerapan

1. Sistem yang tidak dapat diuji tidak dapat diverifikasi, dan sistem yang tidak dapat diverifikasi tidak boleh diterapkan.

2. Tes penulisan menghasilkan desain yang lebih baik karena kode yang mudah diuji sering kali menggunakan injeksi ketergantungan, antarmuka, dan abstraksi.

3. Serangkaian pengujian yang baik akan menghilangkan rasa takut akan kerusakan aplikasi Anda saat melakukan refactoring.

4. Duplikasi kode menimbulkan lebih banyak risiko karena ada lebih banyak tempat dalam kode yang dapat diubah dan bahkan lebih banyak tempat di mana kesalahan dapat disembunyikan.

5. Kode yang Anda tulis sekarang lebih mudah dipahami karena Anda terlibat secara mendalam dalam memahaminya. Tidak mudah bagi orang lain untuk cepat mencapai tingkat pemahaman yang sama.

6. Sebagian besar biaya proyek perangkat lunak terkait dengan pemeliharaan jangka panjang.

7. Pengujian berfungsi sebagai dokumentasi nyata tentang bagaimana aplikasi Anda seharusnya (dan memang demikian) berperilaku.

8. Jangan bergerak lebih jauh setelah kode Anda berfungsi. Luangkan waktu untuk membuatnya lebih jelas dan mudah dimengerti.

9. Orang berikutnya yang akan membaca kode Anda dalam waktu dekat kemungkinan besar adalah Anda. Berbaik hatilah pada diri Anda di masa depan dengan menulis kode yang mudah dimengerti.

10. Tolak dogma. Rangkullah pragmatisme.

11. Dibutuhkan waktu puluhan tahun untuk menjadi insinyur perangkat lunak yang benar-benar baik. Anda dapat mempercepat kurva belajar Anda dengan belajar dari para ahli di sekitar Anda dan mempelajari pola desain yang umum digunakan.

Bab 13: Paralelisme

1. Menulis kode paralel itu sulit.

2. Terkadang bug dan masalah yang sulit direproduksi sering kali merupakan masalah konkurensi.

3. Pengujian tidak menjamin aplikasi Anda bebas bug, namun akan meminimalkan risiko.

4. Pelajari tentang masalah konkurensi umum dan kemungkinan solusinya.

Bab 14: Penyempurnaan Berurutan

1. Kode bersih biasanya tidak dimulai dengan kertas kosong. Anda menulis solusi kasar terlebih dahulu dan kemudian memfaktorkannya ulang agar lebih bersih.

2. Merupakan suatu kesalahan untuk berhenti mengerjakan kode setelah kode tersebut mulai berfungsi. Luangkan waktu untuk membuatnya lebih baik lagi setelah berhasil.

3. Kerusuhan meningkat secara bertahap.

4. Jika Anda merasa kesulitan menambahkan fitur terlalu sulit atau memakan waktu terlalu lama, berhentilah menulis fitur dan mulailah melakukan pemfaktoran ulang.

5. Perubahan bertahap seringkali lebih baik daripada membangun kembali dari awal.

6. Gunakan Test-Driven Development (TDD) untuk membuat perubahan kecil dalam jumlah besar.

7. Desain perangkat lunak yang baik melibatkan pemisahan masalah dalam kode Anda dan memisahkan kode menjadi modul, kelas, dan file yang lebih kecil.

8. Lebih mudah membersihkan kekacauan segera setelah Anda membuatnya daripada membersihkannya nanti.

Bab 15: Internal JUnit

1. Nama variabel negatif atau ekspresi kondisional sedikit lebih sulit dipahami dibandingkan nama variabel positif.

2. Refactoring adalah proses berulang yang penuh dengan trial and error.

3. Tinggalkan basis kode lebih baik daripada saat Anda menemukannya (Peraturan Pramuka). (Diulang dari Bab 1)

Bab 16: Memfaktorkan Ulang SerialDate

1. Peninjauan kode dan kritik terhadap kode kami menjadikan kami lebih baik, dan kami harus menyambutnya.

2. Pertama-tama buat kodenya berfungsi, lalu perbaiki.

3. Tidak semua baris kode memerlukan pengujian.

Bab 17: Bau dan Heuristik

1. Kode bersih bukanlah seperangkat aturan, melainkan sistem nilai yang menentukan kualitas pekerjaan Anda.

[Dalam bab ini, Paman Bob mencantumkan 66 variasi kode dan heuristiknya, banyak di antaranya dibahas di sisa buku ini. Mereproduksinya di sini pada dasarnya berarti menyalin dan menempelkan nama setiap item, jadi saya menahan diri untuk tidak melakukannya. Saya sarankan Anda membaca bukunya saja!]

Kesimpulan

Mari kita akhiri dari awal: Clean Code oleh Robert C. Martin adalah buku pemrograman paling direkomendasikan sepanjang masa. Ada alasan bagus untuk ini.