Clean Code, Seberapa bersih?

Saya ingin memulai artikel ini dengan sebuah quote yang cukup terkenal.

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” — Martin Fowler

Bertemu kembali dengan saya, Yudistira. Pada kesempatan kali ini, saya ingin berbagi cerita bagaimana saya dan kawan-kawan tim A1 menerapkan clean code dalam setiap tahap penulisan kode dalam pengembangan proyek kami. Sebelum itu …

Clean Code? Apa yang bersih?

Clean code adalah suatu prinsip dalam penulisan kode program yang harus memenuhi kaidah-kaidah penulisan program yang baik. Arti kata “baik” di sini akan dijelaskan dalam poin-poin yang akan dijelaskan di bawah. Clean code juga bisa menjadi suatu ukuran dari kualitas kode.

Mengapa harus clean code?

Terkadang dalam tim ada yang berpendapat seperti ini, “Clean code? Buang-buang waktu saja.”, “Aduh, menambah pekerjaan saja.” dan keluhan lainnya. Pendapat seperti itu tidak sepenuhnya salah karena memang ada pekerjaan yang bertambah dan memakan waktu lebih.

Sekarang saya ingin memberikan perspektif lain mengenai Clean code yang saya kutip dari https://hackernoon.com/engineers-dont-want-clean-code-2dd64cc361c1.

Your engineers don’t want clean code. Your engineers want to move fast. Clean code is just the method that allows engineers to move fast.

Programmer ingin bekerja cepat. Clean code bertujuan untuk membantu programmer bekerja cepat. Tidak ada konflik motivasi yang terjadi.

Clean code memang tidak membantu seseorang menuliskan kode lebih cepat. Clean code juga tidak membantu menyelesaikan masalah pemrograman kompleks menjadi lebih cepat. Clean code membantu programmer untuk membaca kode dengan lebih cepat.

Membaca? Bukan menulis kode?

Ya. Clean code akan membantu programmer untuk membaca kode. Menurut penulis buku panduan Clean code Robert C. Martin, bahwa rasio antara waktu yang dihabiskan untuk membaca dengan menulis kode adalah 10 : 1. Programmer selalu membaca ulang kode yang pernah dituliskan atau membaca kode teman satu tim sebelum menuliskan kode yang ia kerjakan. Belum lagi jika harus menelusuri bagian kode yang menyebabkan bug. Akan lebih baik jika kita dapat menuliskan kode yang mudah dibaca.

Menulis Clean Code

Memberi komentar

Pada bagian ini saya akan menjelaskan beberapa poin yang perlu diperhatikan dalam menuliskan Clean code. Saya juga akan menyertakan contoh bagaimana saya menerapkan poin tersebut dalam proyek kami.

1. Penulisan Komentar
   Komentar pada kode dituliskan secukupnya saja. Kode yang baik justru adalah kode yang dapat dipahami tanpa komentar. Jika kode anda perlu diberi komentar, bisa jadi kode yang ditulis kurang baik sehingga perlu ditulis ulang (perhatikan poin-poin lainnya).
2. Penamaan (variable, function, etc)
   Ada beberapa poin yang perlu diperhatikan dalam pemberian nama. Pertama, tulis nama yang berarti, bukan sekedar singkatan atau huruf asal saja. Kedua, suatu variabel atau fungsi benar-benar memiliki satu konsep saja. Jika memang perlu melakukan dua hal yang berbeda, pisahkan menjadi dua variabel atau fungsi yang berbeda. Lalu, perhatikan konvensi penulisan nama yang digunakan oleh tim, seperti kami yang menggunakan standar pylint untuk menulis kode python.
3. Penulisan Fungsi
   Suatu fungsi cukup memiliki satu tujuan saja, tidak melakukan dua hal atau lebih sekaligus. Hindari penulisan kode nested yang terlalu dalam. Hindari side effect, suatu fungsi melakukan hal sesuai namanya saja tidak lebih. Tidak lupa sertakan error handling untuk mengatasi hal-hal yang tidak diduga. Lebih baik melempar exception daripada mendapatkan hasil yang tidak tahu datangnya dari mana. Dan yang paling penting adalah konsep DRY atau Don’t repeat yourself. Gunakan kode atau design pattern yang sudah ada.
4. Layout Formatting dan Code Smells
   Hindari code smells (Ada banyak!!). Anda tidak perlu menghafal dan mencari setiap code smells secara manual. Terdapat tool bernama linter yang dapat mendeteksi dan memberi tahu letak code smells dan kesalahan pada format layout. Kelompok kami menggunakan pylint yang dilengkapi dengan plugin pylint-django sebagai linter.

Beberapa Contoh

DRY

• Menggunakan class yang disediakan Django REST (inheritance) pada package generics sehingga tidak perlu menuliskan fungsi get dan post kembali.

Fungsi

• Memberi nama fungsi yang sesuai tujuan, yaitu mendapatkan data user.
• Pemberian nama variabel juga sesuai dengan isinya, response hasil dari request dan json adalah isi json-nya.
• Exception handling jika koneksi internet terputus. Kesepakatan kami adalah mengisinya dengan json kosong.

Linter

• Gambar di atas adalah contoh linter yang sedang beraksi.
• Dijelaskan bahwa terdapat naming style yang tidak tepat pada baris ke-20 kolom ke-1 sehingga saya jadi tahu bagian mana yang perlu diperbaiki.

Refactoring & Design Pattern

Kebetulan di atas saya sudah menyinggung kata design pattern. Saya juga sudah menyinggung code smells dan cara saya mengatasinya. Mulai dari sini, saya tidak akan membahas clean code lagi, namun masih ada hubungannya dengan menerapkan dan mencapai clean code, yaitu Refactoring dan Design Pattern.

Refactoring, Berubah tapi Tidak Berbeda

Pertama kali saya mendapatkan materi refactoring adalah saat mengambil mata kuliah Advance Programming. Definisi dari refactoring adalah proses mengubah struktur dari kode (kode yang sudah dibuat) tanpa mengubah perilaku aslinya (external behavior).

Ada beberapa alasan mengapa refactoring dilakukan. Namun, alasan yang utama adalah memperbaiki dan memperbagus struktur internal dari suatu (bagian) kode. Alasan-alasan lainnya kurang lebih serupa dengan tujuan dari penerapan clean code. Membuat menjadi lebih mudah dibaca dan lebih mudah mencari bug, juga alasan modularity dan reusability.

Refactor dilakukan untuk “membasmi” code smells. Beberapa jenis code smells seperti long method, duplicate code, terlalu banyak parameter dan lain-lain. Seperti yang saya jelaskan pada bagian sebelumnya, kelompok kami sudah menggunakan linter untuk mengatasi sebagian code smells (sudah tersedia). Hal-hal lain yang perlu diperhatikan dan perlu diperiksa sendiri adalah adanya kode duplikat. Biasakan menggunakan abstract class dan teknik lain untuk mengatasi hal tersebut.

dalam TDD

Refactor juga menjadi salah satu tahap dalam skema pemrograman TDD. Proses refactoring biasa dilakukan setelah kode sudah melalui test (GREEN). Test dapat dimanfaatkan sebagai indikator apakah kode berubah perilaku dari yang sebelumnya sehingga dapat menggagalkan test (RED).

Design Pattern, Belajar dari Pengalaman

Beberapa design pattern

Pernahkah Anda bertemu suatu permasalahan (dalam software engineering) yang belum pernah Anda temui? Lalu, Anda mencari tahu di stackoverflow bagaimana cara menyelesaikan permasalahan tersebut? Konsep yang akan dibahas mirip seperti contoh di atas, namun untuk permasalahan yang sedikit lebih kompleks.

Dalam software engineering, Design Pattern adalah pasangan masalah dengan solusi. Design Pattern adalah solusi umum yang dapat digunakan ulang untuk mengatasi suatu permasalahan software design tertentu. Design pattern bukanlah produk final yang bisa langsung dipakai begitu saja. Bentuknya adalah deskripsi atau template yang bisa digunakan untuk menyelesaikan masalah tersebut.

Alasan?

Ada beberapa alasan mengapa menggunakan design pattern sangat direkomendasikan, yaitu:

1. Mempercepat proses pengembangan (Relatif, namun pasti lebih cepat daripada mulai dari awal).
2. Sudah teruji dan dapat digunakan oleh orang lain (atau domain lain).
3. Komunikasi dengan tim atau orang lain lebih mudah karena pattern sudah dikenal atau sering digunakan.

Bagaimana di tim A1?

Di kelompok kami, yang sebenarnya mungkin seluruh kelompok juga menggunakannya, kami menggunakan pattern yang standar dan sering digunakan dalam pengembangan Web, yaitu Model-View-Controller (MVC) pattern.

Django Framework dan MVC/MVT/MTV

MVT atau MVT

MVC adalah pattern yang biasa digunakan dalam pengembangan aplikasi web. Pattern tersebut membagi aplikasi menjadi beberapa layer yang berinteraksi dan melakukan tugas-tugas yang berbeda pada setiap layer. Pada Django, ada sedikit perbedaan istilah yaitu view yang berlaku seperti controller. Berikut penjelasan untuk setiap layer:

1. Model (Model)
   Model atau models.py adalah bagian yang berurusan langsung dengan database. Django menerapkan ORM untuk membuat dan mengakses object/row dalam database.
2. View (View/Controller)
   views.py atau yang lebih sering dikenal sebagai controller adalah bagian yang mengatur business logic atau alur dari aplikasi web.
3. Template (Template/View)
   Template adalah bagian yang berinteraksi langsung dengan user atau pengguna aplikasi seperti halaman html dan kawan-kawannya.

Contoh struktur kami

Dengan menggunakan framework Django, kami tidak perlu membangun ulang web dari awal lagi, cukup mengimplementasi fungsi pada struktur yang sudah disediakan.

Kesimpulan

Clean code dapat mempercepat proses pengembangan. Ada beberapa poin yang perlu diperhatikan untuk mencapai clean code. Refactor dan Design Pattern adalah salah satu alat yang dapat digunakan untuk mencapai clean code.

Saya rasa tulisan ini sudah cukup. Sampai jumpa di tulisan saya yang berikutnya. Semoga bermanfaat. Terima kasih.

Bye

— Muhammad Yudistira Hanifmuti