Code Is Garbage
“Kode adalah Sampah”
Jargon tersebut sudah lama ada, akan tetapi nampaknya belum ada, atau sedikit orang yang menanggapinya dengan serius dan mencoba mencari solusinya.
Masalah ini jauh lebih serius dari sekedar jargon saja. Ini adalah masalah senilah Ratusan Juta bahkan Milyaran Rupiah.
“It is real, a real multi billion problem.”
Saya merekomendasikan khususnya untuk setiap Produk Owner / Project Manager dan Tech Lead dan para developer software memahami ini.
Cerita Singkat
Suatu ketika dalam interview saya untuk sebuah project berbasis Flutter, Product Manager menanyakan kepada saya;
“Apakah mas bisa menggunakan flutter?”
Saya menjawab “ya namun saya bukan Expert”. Saya adalah Android Developer, dan saya menggunakan Kotlin / Java / C++ Sebagai basis kode saya. Saya lalu mengatakan;
“Saya bukan seorang Expert dalam flutter, tetapi saya tau cara menulis kode dengan baik. Dan untuk saya pribadi itu adalah hal paling penting. Lebih penting dari stack apa yang akan kita gunakan nantinya.”
Interviewer kemudian menanyakan;
“Yang anda maksud dengan kode yang baik itu seperti apa?”
Seperti Apa Kode yang Baik Itu?
Ada banyak ide mengenai bagaimana kode yang baik itu, dan “Ya” semuanya benar. Tetapi apa benar saja cukup?
Jika anda bertanya kepada expert, mungkin dia akan menjawab : Kode yang baik adalah kode yang SOLID, atau Clean, atau Modular dan sebagainya, dan itu sermua Benar.
Tapi apakah Benar Saja cukup? Harap memahami ini kata-kata berikut;
“Setiap Ide memiliki Tujuan untuk diraih dan Value untuk diperoleh. Semua Ide itu benar, karena mereka memiliki pondasi Theory dan Value mereka sendiri. Dan apapun yang anda pilih adalah benar, jika memang value ide itu yang ingin anda peroleh.”
Apa yang dimaksud dengan Value dan apa saja Value tersebut?
Value
Setiap Ide memiliki Value dan Tujuan untuk diraih.
Apapun Ide yang anda pilih, selama anda memang ingin memperoleh Value dari Ide tersebut maka anda melakukan hal yang benar.
Jadi pada dasarnya apapun jawabannya, jawaban itu adalah benar jika memang Value atau Tujuan dari Ide tersebut adalah sesuatu yang ingin anda capai.
Akan tetapi itulah pertanyaan terbesarnya:
“Value apa yang ingin anda dapatkan?”
Jika anda mengutamakan modularitas maka SOLID principle adalah Ide yang cocok untuk anda.
Jika anda mengutamakan kecantikan maka Clean Code adalah Ide yang cocok untuk anda.
Bahkan jika anda mengatakan kode yang baik adalah kode yang Reactive jika anda tau value yang ingin anda raih maka itu juga jawaban yang benar.
Saya memiliki Ide saya sendiri mengenai Seperti Apa Kode yang Baik itu.
Ide yang Saya Pilih
Sesuai dengan judul artikel ini; Kode adalah Sampah, kode yang baik menurut saya adalah Kode yang bukan sampah.
Tunggu dulu jangan terburu-buru menyimpulkan. Artikel ini bukan untuk menghakimi siapapun, melainkan ini adalah masalah yang NYATA dan masalah ini bernilai Ratusan Juta.
Sebelum masuk ke ide tersebut, ada baiknya kita mengetahui latar belakang jargon ini dan kita akan memahami dimana letak masalahnya.
Kronologi
Jargon ini lahir ketika seorang developer, membuka kembali kode yang dulu dia buat, dan seperti biasa “He don’t know what on earth is going on there”.
Dia tidak mengerti kode yang dia buat sendiri. Sungguh konyol sekali, dan dari situ lahir lah jargon tersebut “Kode adalah sampah”.
Selama ini, ini hanya menjadi jargon meme saja dan sesuatu yang bisa di maklumi. Akan tetapi seiring berkembangnya proyek yang anda kerjakan dan semakin kompleks, ini akan menjadi masalah besar.
Anda mungkin bisa beralasan bahwa ini adalah masalah Kompetensi si developer. Bukan, ini lebih dari itu.
Another Story
Saya sedang bekerja pada sebuah proyek Software Define Radio (SDR).
Sebuah software yang ditulis dalam C++, yang berfungsi untuk menganalisa spectrum sinyal.
Dan seperti yang anda pikirkan; I don’t know what on earth is goin on that code.
Bukan karena kode ini “Jelek” sama sekali tidak.
Kode ini cukup solid, clean dan sangat rapi. Tetapi itu semua tetap tidak membuat kode ini menjadi hal yang mudah untuk di pahami.
Saya langsung down ketika melihat begitu banyak GLOBAL VARIABLE dalam header file sebuah Class. Saya bahkan belum membaca kodenya baru headernya.
Selanjutnya saya membaca keseluruhan kode. Kode tersebut sangat rapi, sangat baik, akan tetapi, I still didn’t get it.
Kemampuan saya dalam kompetensi yang diperlukan cukup baik, bahkan saya pribadi merasa mampu membuat ulang software tersebut dari scratch.
Saya juga sudah mendemokan prototype software analisa sinyal sederhana, dengan semua teori dan algoritmanya.
Transformasi Fourier adalah algoritma utama yang di gunakan dalam software ini, dan ini bukan hal sulit untuk saya, dan bukan kali pertama saya membuat software serupa.
Akan tetapi sekalipun saya menguasai semua stack, framework, algoritma dan teori yang dibutuhkan, itu masih belum cukup untuk membuat kode ini menjadi hal yang mudah untuk saya pahami.
Dimana letak masalahnya?
Masalahnya adalah; Kode ini adalah sampah.
Bukan karena kode ini jelek, melainkan karena saya membacanya satu kali, dan saya tidak mengerti.
Kode adalah Sampah
Dari Kronologi dan Cerita diatas. Kita dapat menyimpulkan bahwa;
Kode adalah sampah adalah kode yang ketika didelegasikan, developer selanjutnya tidak memahami apa yang terjadi dalam kode tersebut.
Baik kepada developer lain maupun kepada pembuat kode itu sendiri.
Ketika kode tersebut di baca dan tidak ada yang mengerti, maka kode itu adalah sampah. Tidak peduli seberapa SOLID atau Clean kode tersebut. Kode itu akan dibuang / dilupakan kemudian dibuat ulang, baik ditulis ulang maupun direkonstruksi ulang dalam logika si developer.
Ini adalah masalah besar. Me-maintain kode tersebut seringnya memerlukan waktu untuk mempelajari, dan effort yang cukup besar bahkan mungkin sangat besar.
Bahkan setelah mempelajari kodenya, tidak ada garansi bahwa kode tersebut dapat di modifikasi dengan mudah.
Belum lagi adanya kemungkinan merusak Runtime Process ketika kode tersebut di modifikasi; “Nobody Know”.
Terimakasih sudah membaca sejauh ini, saya menyarankan anda untuk bernafas sejenak dan mungking mengambil secangkir kopi, sebelum melanjutkan membaca. Relax. Big thanks 😊.
Up Next : Letak Permasalahan, Side Effect dan Object Oriented Programming, Solusi, dan Kesimpulan.
Letak Permasalahan
Sekali lagi saya mengatakan, saya tidak sedang menghakimi kode ini. Kode ini sangat baik, sangat SOLID dan Clean.
Masalah sebenarnya bukan pada kode tersebut.
Saya juga yakin jika anda setuju bahwa; We need something more. Akan tetapi;
What is it? What is wrong?
Saya juga menanyakan hal yang sama; What is wrong? Where is the problem?
Sebenarnya masalah nya sudah terlihat jelas sejak awal cerita dimulai pada bagian Another Story.
Masalah pertama yang saya temui adalah adanya begitu banyak GLOBAL VARIABLE.
Saya rasa anda pun akan merasakannya juga jika berada pada posisi saya. Tanpa perlu membaca kodenya kalian pasti akan langsung tau bahwa ada begitu banyak “SIDE EFFECT” didalam kode itu.
Tidak ada yang tau dimana saja side effect itu terjadi, bahkan mungkin orang yang menulis kode tersebut juga tidak mengetahuinya.
Itulah masalah terbesarnya; GLOBAL VARIABLE dan SIDE EFFECT.
Side Effect dan Object Oriented Programming
Tidak ada kesalahan dalam kode ini. Solid Clean, sangat baik.
Saya menyadari, problemnya bukan ada pada bagaimana developer menulis kode, melainkan pada “Thinking Framework” yang adalah “Object Oriented Programming” itu sendiri.
Object Oriented Programming mengijinkan hal tersebut untuk dilakukan, dan bukan tanpa alasan. Alasanya adalah performa yang lebih cepat.
Side Effect adalah hal yang menakutkan, karna itu saya tidak begitu menyukai Reactive Programming. Bukan karna Reactive programming adalah hal yang buruk, akan tetapi karena Paradigmanya sangat tidak terbatas, oleh karena itu prinsib ini harus dibatasi oleh sesuatu. Reactive kadang bermakna: It can Explode or worse It will.
Notes: Saya mungkin melakukan kesalahan dengan menyebut reactive programming saat saya pertama merilis artikel ini pada Februari 2023. Saya akan mengklarifikasinya:
Bahkan sampai saat ini, functional pattern belum begitu populer dalam pemrogramman mobile atau desktop yang adalah ekspertise saya. Hingga tahun 2022 akhir, kotlin belum secara luas digunakan dalam pemrogramman mobile dan desktop — dan java masih secara luar digunakan. Pada mobile software — sekalipun kotlin sudah memiliki FLow, RX java masih digunakan secara luas. Dan pemrogramman reactive masih diimplementasikan secara Imperative. Ini adalah masalah besar yang sangat Rumit. Penggunaan Reactive programming ditambah dengan Side Effect diamana-mana adalah bencana. Penggunaan Cannel atau Event Bus, Hidden Control Flow, Hidden Dependency, dan One-Off event adalah hal yang akan kita jumpai di semua Software desktop dan mobile kala itu.
Tidak ada yang tau apa yang anda pikirkan ketika melakukan Side Effect, saya tekan kan TIDAK ADA YANG TAHU. Siapapun tidak memiliki pilihan selain menelusurinya kode yang anda buat, dan seringnya it is so Painful.
Tetapi tidak ada yang salah, sekali lagi, anda tidak berdosa ketika melakukan Side Effect saat menggunakan Object Oriented Programming.
Karena Object Oriented programming sendiri mengijinkan hal tersebut untuk dilakukan.
Inilah sumber masalahnya dan kenapa masalah ini begitu besar; Adalah karena sumber dari masalahnya ada pada Paradigma Object Oriented Programming itu sendiri. Yang menciptakan Norma dan Thinking Framework untuk kita membuat kode.
Norma adalah kumpulan ide yang kita sepakati tentang baik dan buruk, serta apa yang boleh dan tidak boleh kita lakukan, sementara Thinking Framework menciptakan kebiasaan kita dalam menulis kode.
Saya tidak sedang mendeskreditkan Paradigma Object Oriented Programming, ini tetap sebuah Paradigma yang luarbiasa dan telah menyumbangkan Kesadaran yang sangat luar bisa, seperti; Pattern, SOLID Principle, Clean Code dan sebagainya.
It is AMAZING. Akan tetapi, sayangnya AMAZING tidak menyelesaikan masalah ini.
Saya tahu, ada banyak cara yang direkomendasikan, mulai dari Abstraksi, Enkapsulasi, Immutability, Pattern, Architecture. Akan tetapi, anda bisa bayangkan semahal apa itu semua.
Dan sayangnya bahasa yang berorientasi Object umumnya kurang mensupport ide tentang Immutability.
Misalnya:
- Kotlin tidak memiliki opsi untuk membuat Immutable function’s arguments.
- C++ developers menyukai pointer, dan normalnya orang yang mengunakan C++ tidak suka membuang-buang memory. Oleh karenanya mereka menggunakan pointer untuk membuat memory menjadi lebih efisien.
Bisa kita simpulkan bahwa masalahnya ini berada di level Norma itu sendiri. Tentang apa yang benar dan salah menurut Paradigma OOP, dan penting tidak penting menurut paradigma bahasa pemrogramman yang di gunakan.
Dari sini mungkin sudah terlihat kemana arah pembahasan kita, yakni: mengganti OOP dengan Functional Programming Pattern.
Tenang, saya tidak sedang berusaha menggoyahkan iman teman-teman dengan mengatakan bahwa Functional Programming lebih baik.
Functional Programming Pattern memang jauh lebih baik dalam hal Simplicity, akan tetapi dia memiliki best practice-nya sendiri.
Pada C++ misalnya, saya pribadi merasa tidak makesense menggunakan functional programming pattern pada C++ walaupun saya sangat ingin menggunakannya. Karena C++ secara Normativ bertujuan untuk menjadi Reliable dan Memory Efficient. Sementara Functional Programming seperti kita tau, jauh lebih lambat dan kontroversial terkait istilah “Memory Efficient”. Dimana masalah terbesar dari Functional Programming adalah Hipper Memory Allocation .
Teman-teman yang menggunakan C/C++ pasti memahami masalah ini pada Functional Programming Pattern, dan seberapa lambat functional programming pattern jika dikomparasikan dengan Object Oriented programming.
Dan sebagai bahasa yang ditujukan untuk mesin level rendah, Functional Programming Pattern sangat tidak makesense secara Normativ.
Akan tetapi saya tidak menutup kemungkinan bahwa dalam beberapa kasus saya akan menggunakan Functional Programming Pattern pada C++.
Solusi
Terimakasih sudah membaca sampai kesini.
Jujur saja saya tidak memiliki solusi yang konkrit, dalam arti; solusi yang akan “menghilangkan” sumber masalahnya.
Karena sperti sebelumnya kita bahas, ini adalah masalah level “Paradigma” yang menciptakan Norma dan Framework Berfikir kita. Masalahnya adalah Paradigma OOP itu sendiri.
Akan tetapi solusi praktis tentu ada, tetapi perlu digarisbawahi bahwa solusi praktis selalu menyesuaikan pada studi kasus. Untuk kasus saya sendiri solusi saya adalah sebagai berikut;
Kasus pertama
Saya adalah Android Programmer. Saya menggunakan Kotlin, dan saya tidak membuat software untuk Low Level Machine.
Untuk kasus ini saya memilih opsi untuk sebisa mungkin menggunakan Functional Programming Pattern, karena Hipper Memory Allocation Problem tidak berdampak signifikan pada Enterprise Mobile App.
Yang saya lakukan adalah;
- Menanamkan kesadaran akan pattern pada kode saya.
Contohnya, dalam Core Module terutama Core Common / Main, hanya boleh berisi 2 hal saja. Yakni Pattern dan Util.
Dimana Pattern hanya boleh berupa Interface class dan Abstract implementasinya. Dan Util hanya boleh berisi Pure Function / Monoid. Selengkapnya mungkin akan saya bahas di artikel selanjutnya jika kalian tertarik. - Sebisa mungkin menggunakan Pure Function dan Monoid untuk segala hal.
- Void function harus dijalankan sebagai Effect.
- Melokalisasi Side Effect.
Pattern adalah cara kita mengenali sebuah benda. Pattern membantu kita untuk mengenali dalam sekali lihat benda apa itu dan bagaimana cara berinteraksi dengannya. Inilah kenapa menanamkan kesadaran untuk menggunakan Pattern dalam segala hal adalah hal yang baik.
Pattern bukan Interface, kita harus membedakan Pattern dan Interface. Interface dapat tidak memiliki arti, akan tetapi Pattern selalu memiliki arti dan fungsi yang sama, yakni untuk mengenali sesuatu dan menjelaskan bagaimana cara berinteraksi dengannya secara umum.
Saya juga menyarankan kita untuk berhenti melakukan “Interface Segregation” dan mulai melakukan “Pattern Segregation”. Contohnya, sekor kuda memiliki pattern Hewan, Mamalia, Vertebrata, Herbivora dan sebagainya.
Void function as an Effect semua void function harus dijalankan sebagai side effect. Alasannya sederhana, karena void function pasti memiliki side effect.
Metode ini membantu kita untuk langsung mengetahui dimana saja kemungkinan terjadinya side effect dan menilai seberapa baik kode kita (atau seberapa sampah kode kita, menurut konteks dari artikel ini).
Melokalisasi Side Effect; Jika kita menggunakan Object Oriented Programing kita tidak punya pilihan selain menggunakan class. Oleh karena itu saya menyarankan sebuah peraturan, dimana hanya 1st level function yang boleh melakukan side effect (1st level function adalah fungsi yang pertama kali berinteraksi dengan event).
Scope function yang lebih rendah tidak boleh melakukan side effect.
Kasus kedua
Kasus kedua adalah C++ programming pada mesin level rendah atau sebuah software yang menitik beratkan performa sebagai hal yang penting.
Pertama, jika itu adalah mesin level rendah; Jika anda ingin menggunakan Functional Programming Pattern, baik sebagian atau menyeluruh, maka anda perlu memastikan itu dapat dilakukan terkait dengan masalah Hipper Memory Allocation Problem.
Hiper memory allocation problem adalah masalah pada functional programming dimana memory akan dialokasikan dengan sangat banyak dan dide-alokasikan dengan sangat cepat. Seperti pada map function. Jika kita melakukan map pada sebuah list, maka kita akan mengalokasikan memory untuk seluruh list baru yang dihasilkan. Jika kita melakukan chaining map beberapa kali maka memory yang dialokasikan sebanyak list.size x n-operation. Akan tetapi, setelah operasi selesai, memori akan segera dide-alokasikan.
Kedua, anda harus berdiskusi dengan produk owner terkait Penurunan perfoma yang cukup signifikan jika anda ingin menggunakan functional programming pattern, apakah masih dapat di toleransi atau tidak.
Tetapi yang jelas, performa pasti dapat di improve.
Kesimpulan
- Masalah ini adalah nyata dan sangat mahal.
Sebagai developer, saya memilih menjadikan ini sebagai ide utama untuk saya capai, yaitu:
“Sebuah kode yang baik adalah kode yang dapat didelegasikan” - Ide apapun yang anda pilih adalah benar selama anda memahami value apa yang ingin anda capai dari ide tersebut.
Terimakasih telah membaca sejauh ini semoga bermanfaat. Cheers.
Catatan
Mungkin terbesit dipikian anda pada kesimpulan nomor 1;
Berarti tidak perlu SOLID? Tidak perlu Clean?
Saya tidak mengatakan demikian. Akan tetapi perlu kita pahami, SOLID dan Clean Code adalah Prinsib yang lahir dari permasalahan Object Oriented Programming.
Artinya mereka tidak selalu berlaku secara general. Sebagai contoh, Functional programming tidak mengenal Interface Segregation, tidak mengenal Dependency Inversion, Liskov Subtitution Principle dsb. Paradigma-paradigma itu lahir dari studi kasus Object Oriented yang artinya dia ditujukan untuk diaplikasikan pada OOP style programming.
Sementara Functional Programming menggunakan paradigma yang berbeda seperti; Pure Function, Monoid, Monoid Chain, dan Group Theory.
Saya tidak mengatakan “Tidak perlu SOLID” atau “Tidak Perlu Clean Code”. Akan tetapi prinsib-prinsib itu memiliki tujuannya sendiri, terkait problem dan dimana dia di-implemntasikan, dan saya juga setuju bahwa sangat penting untuk memahami dan menguasai kedua prinsib tersebut.
