Clean Code? Untuk apa?

We are tired of writing crap - Uncle bob.

· 2 menit untuk membaca
Clean Code? Untuk apa?
Photo by Clay Banks / Unsplash

Jika kamu sudah menjadi programmer selama 2 tahun atau lebih, kamu pasti merasakan bagaimana rasanya produktifitas kamu turun gara-gara kodingan orang lain yang berantakan. Tim yang awalnya bergerak dengan sangat cepat, lambat laun akan melambat seiring dengan pertambahan fitur dan kebutuhan. Setiap perubahan akan menyenggol fitur lain sehingga lama-lama produktifitas secara asimptotik akan mendekati nol.

Setelah itu kamu akan memberikan ide kepada atasanmu untuk menulis ulang kode yang sudah ada. Atasanmu tidak mau menambah resource untuk proyek yang baru tetapi dia sadar akan penurunan produktifitas. Mau tidak mau atasanmu menyetujui pembuatan proyek yang baru.

Tim terbaik pun akan dibentuk untuk mengembangkan sistem yang baru, semua berlomba-lomba untuk bisa masuk kedalam ladang yang masih hijau ini, dan pada akhirnya tim ini harus membuat ulang tidak hanya dengan fitur yang sama tetapi juga berlomba agar tidak ketinggalan fitur baru yang harus ditambahkan ke dalam sistem yang lama.

Balapan dengan sistem lama ini akan berlangsung cukup lama, malah bisa mencapai 10 tahun, dan setelah selesai anggota tim terbaik pun sudah berpencar dan anggota yang sekarang pun meminta untuk redesign karena sistem ini pun berantakan.

Untuk menghindari kejadian di atas, maka diperlukanlah kode yang bersih.

Apa itu Clean Code?

Suatu baris kode dapat dikatakan bersih apabila dapat dengan mudah dimengerti oleh seluruh anggota tim.  Sebuah kode yang bersih dapat dengan mudah dibaca dan di-enhance oleh developer lainnya. Dengan kode yang mudah dimengerti, maka dihasilkanlah kode yang mudah dibaca, diubah, ditambah, dan dipelihara.

Aturan Umum

Aturan umum dari clean code adalah sebagai berikut.

  • Ikuti standard convention yang ada pada bahasa pemrograman kamu.
  • Keep it simple, selalu buat kode yang simpel dan kurangi kompleksitas sebisa mungkin.
  • Aturan anak pramuka, tinggalkan perkemahan lebih bersih dari waktu ditemukan.
  • Selalu temukan akar permsalahaan.

Aturan Desain

  • Letakkan data-data yang dapat dikonfigurasi pada level yang lebih tinggi (jadikan konstanta).
  • Lebih baik gunakan polymorphism dibangding if/else atau switch/case.
  • Pisahkan kodingan multitrheading.
  • Hindari over-configurability.
  • Gunakan dependency injection.
  • Ikuti Hukum Demeter, sebuah kelas seharusnya hanya mengetahui dependecy lansungnya saja.

Tips agar mudah dipahami

  • Konsisten, jika kamu melakukan sesuatu dengan cara A, maka untuk hal yang sama tetap gunakan cara A.
  • Gunakan variabel yang menjelaskan dirinya sendiri.
  • Gunakan enkapsulasi untuk kondisi batas.
  • Lebih baik gunakan value object seperti EmailAddess dibanding dengan String yang menampung isian email. (Gunakan Value Object dibanding tipe data primitif).
  • Hindari kebergantungan logika. Jangan tulis method yang hanya berjalan dengan semestinya bergantung dengan sesuatu hal lain yang ada dikelas yang sama.
  • Hindari negative conditionals.

Aturan penamaan

  1. Gunakan nama yang deskriptif dan tidak ambigu.
  2. Buatlah perbedaan yang berarti.
  3. Gunakan nama yang dapat diucapkan.
  4. Gunakan nama yang dapat dilakukan pencarian terhadapnya.
  5. Ganti magic numbers dengan konstanta.
  6. Hindari encoding. Jangan tambahkan prefiks atau type information.

Aturan function

  1. Pendek
  2. Hanya melakukan satu hal.
  3. Gunakan nama yang deskriptif.
  4. Diutamakan argumen yang lebih sedikit.
  5. Tidak punya efek samping.
  6. Jangan gunakan flag argument. Pisahkan method menjadi beberapa method independen yang dapat dipanggil tanpa flag tersebut.

Objek dan struktu data

  1. Sembunyikan struktur internal.
  2. Lebih baik gunakan struktur data.
  3. Hindari struktur hybrid (setengah objek, setengah data).
  4. Pendek.
  5. Melakukan satu hal.
  6. Instance variable yang sedikit.
  7. Base class tidak perlu tahu turunannya.
  8. Lebih baik memiliki function yang banyak.
  9. Lebih diutakaman non-static method dibanding static method.

Test

  1. One assert per test.
  2. Readable.
  3. Fast.
  4. Independent.
  5. Repeatable.

Ciri-ciri kode yang buruk

  1. Rigidity. Software menjadi kaku, susah untuk diubah.
  2. Fragility. Fitur lain rusak jika diubah di suatu tempat.
  3. Immobility. Sebagian kode tidak dapat digunakan kembali di tempat lain.
  4. Kompleksitas yang tidak penting.
  5. Terlalu banyak repetisi.
  6. Kode sulit untuk dimengerti.