Sebagai anak muda yang punya gairah belajar dan berpikir situasi ideal untuk menciptakan masa depan yang terbaik sesuai keinginan masyarakat. Clean Code jadi panduan programmer/developer manapun yang baru merangkak di karir ini. Sampai suatu ketika, gue ngerasa clean code malah jadi bottleneck.
Clean Code
Gue pertama kali baca buku Clean Code oleh Robert C. Martin tahun 2019, tebal dan penuh dengan kode bahasa Java, walaupun begitu konsep dan idenya cocok untuk diterapkan dimanapun.
Konsep Clean Code ngambil ide dari OOP, yaitu Abstraction. Mengubah situasi/kejadian/objek menjadi semacam abstraksi. Analogi dari menghidupkan senter misalnya, kita tidak perlu menyambungkan kabel hanya untuk menghidupkan senter, tetapi menyiapkan serangkaian kabel untuk dipasang tombol senter (abstraction) sehingga memudahkan pengguna untuk menghidupkan senter (implementation).
Konsep ini memudahkan developer karena kode menjadi mudah dibaca, extendable, dan mudah diuji-coba. Tapi, hanya berlaku pada situasi ideal ketika projek dikembangkan berorientasi pada requirement—catatan kebutuhan dan behaviour dari software. Disituasi lainnya, requirement masih meraba-raba dan tidak concrete, clean code berpotensi jadi bottleneck dan pekerjaan menjadi lebih kompleks dari seharusnya.
Clean Code menjadi bottleneck.
Gue ngerjain aplikasi bagian tampilan (frontend) yang mana menampilkan laporan dari berbagai biaya, dikelompokkan berdasarkan kategori, periode dan beberapa anak-anak kategori lainnya.
Secara intuitif, gue pastinya implementasi clean code dengan melihat pola biaya yang dikelompokkan per kategori (kategori sumber data), sehingga beberapa biaya yang menggunakan kategori yang sama tidak sulit untuk dimodifikasi karena terdapat single-source of truth.
- Beberapa biaya (dokumen) yang sama dalam satu kategori menggunakan abstraction/class yang sama.
- Implementasi Adapter Pattern, sehingga ada satu pintu yang memilih abstraction mana yang digunakan
- Beberapa bagian dalam satu kategori yang memiliki monkey patch, menggunakan metode Bridge Pattern
Semuanya berjalan dengan baik, satu-dua permintaan perubahan masih bisa ditangani hingga akhirnya ada permintaan “biaya X tambahkan ….”, karena biaya X, dibuat percabangan logika yang unik untuk kategori A.
Singkat waktu, beberapa kategori abstraction menjadi semakin kompleks, perubahan dari masing-masing biaya semakin liar. kategori A dan B menjadi obsolete, dan harus buat kategori baru. Tapi, itu akan membuat pekerjaan menjadi lebih lama dan logika dari aplikasi semakin kompleks sehingga sulit dikembangkan dimasadepan. Let me think for a sec.
Apakah ada yang salah dengan struktur kodeku? bagaimana mengatasi masalah ini? jika biaya X, Y dan Z dalam kategori A, kenapa tidak dibuat satu class kategori saja agar mempermudah patching?
Ternyata, cara berpikir ini salah. Aku terlalu fokus pada clean code, reusable dan modular. aku berpikir kalau sebenarnya masing-masing biaya/kategori itu sebuah fitur, tapi sebuah Dokumen Laporan karena biaya X dan Y walaupun sama, tetapi merupakan Dokumen laporan dengan pola dokumennya masing-masing. Dokumen tidak mementingkan modularitas, tetapi dokumen laporan yang sesuai kebutuhan. Cara pandang ini mengubah cara berpikir terhadap fitur.
- Setiap Biaya merupakan dokumen, setiap dokumen punya polanya masing-masing walaupun mirip satu sama lain.
- Setiap biaya memiliki area domain masing-masing.
- Setiap biaya tidak berhubungan dengan lainnya, independen.
- Duplikasi kode tidak terhindarkan tetapi dapat mengatasi permintaan yang unik dari client
Struktur Clean code, struktur pattern, bridge, dan lain-lain tidak lagi dipakai—semuanya dilabel sebagai deprecated, aku mengubah struktur aplikasi menjadi modular terhadap masing-masing dokumen laporan, tidak peduli seberapa mirip, setiap dokumen memiliki kehidupannya masing-masing.
Tapi, bukankah ini clean code?
Pekerjaan menjadi repetitif, copy-paste. Ada sekitar lebih dari 15 dokumen dalam satu folder. Tetapi pekerjaan menjadi lebih mudah dikerjakan:
- Review lebih mudah, satu dokumen mengendalikan satu tampilan saja.
- Perubahan permintaan lebih mudah ditambah, permintaan fitur/perbaikan bisa dikerjakan dengan mudah, perubahan di satu dokumen tidak mengubah dokumen lainnya.
- Perlu menyiapkan template untuk dokumen-dokumen baru.
Kode menjadi modular terhadap masing-masing dokumen, tidak ada lagi abstraction yang mengendalikan beberapa dokumen biaya sekaligus, kecuali abstraction parameter yang digunakan disemua dokumen.
wait, aku masih menggunakan abstraction? bukankah ini clean code?
Readability
Aku membandingkan kode lama dan baru.
- Kode lama berfokus pada modular terhadap kategori, sedangkan kode baru modular terhadap dokumen.
- Kode lama lebih sulit dibaca, karena diskusi sering mengarahkan kepada dokumen, bukan kategori sehingga aku harus pertanyakan “dokumen X ada dikategori mana?”, lalu telusuri dalam-dalam lokasi kode asli.
- Kode baru mudah dibaca dan diubah, “kita update dokumen/biaya X”, lalu langsung mengarah ke dokumen yang dituju.
Fokus utama dari Clean Code adalah readability, KIIS (Keep it simple S…), dan konsitensi. Cara membuat fitur tidak peduli seperti apa, selagi mudah dibaca itu sudah cukup.
Keseimbangan
Dalam menulis kode perlu keseimbangan dalam kualitas dan kuantitas. Beberapa kondisi memerlukan kualitas yang tinggi dan pada kasus lain perlu kuantitas yang tinggi pula. Kualitas pekerjaan tidak dilihat dari seberapa banyak kode yang dibuat, seberapa efektif, atau seberapa cepat. Semuanya tergantung subjektifitas dalam pekerjaan dan judgement dari manusia itu sendiri.
Sekian dari saya, terima kasih.
Add a comment