Buat Kodemu jadi Supel

Image from Pexels

harinya sebagai programmer pasti selalu berkutat dengan barisan kode.

baik kode yang di tulis oleh kita sendiri atau kode yang di tulis oleh rekan kerja kita.

hari-hari nya pasti ada 2 hal teknis yang selalu kita kerjakan , yaitu membaca dan menulis kode.

tapi tahukah anda , Robert C. Martin (Uncle Bob) dalam bukunya “Clean Code: A Handbook of Agile Software Craftsmanship” bekata “the ratio of time spent reading (code) versus writing is well over 10 to 1”

“rasio waktu di habis kan untuk membaca kode di banding menulis itu 10 banding 1”


kebanyakan programmer, terutama programmer pemula beranggapan apabila kode yang dia buat bisa berjalan dan memenuhi deadline, artinya kerjaan sudah selesai.

padahal tidak.

kita programmer sering kali membuat aplikasi tidak berhenti hanya sampai satu kali rilis saja.

versi aplikasi kita tidak akan pernah berhenti bertambah, selama aplikasi kita masih terus di gunakan.

artinya kita akan terus berhubungan dengan kode-kode lama di versi sebelumnya dari aplikasi kita.

dan seringkali kita kebingungan membaca kode lama itu , bahkan jika itu kode yang kita tulis sendiri.

mungkin saat pertama kita menulis kode, kita paham dengan apa yang kita tulis , dan itu bertahan sampai beberapa waktu , dan sampai kemudian kita tidak paham lagi dan hanya tuhan yang paham 😅

dan kalau udah kayak gitu, hari nya kita sebagai programmer akan lebih banyak di gunakan hanya untuk memahami kode yang sebelumnya sudah kita buat.

Siap-siap di marahin bos, karena di anggap gak kerja 😝

oke jadi gimana cara nya ?


Buat kode mu bercerita

kita menulis kode tujuannya untuk menyelesaikan masalah, bukan membuat masalah.

kadang kala, programmer ingin terlihat jenius , ketik sana , ketik sini, jalanin programnya , jalan normal. saat kode nya di review oleh rekan kerjanya , pada muntah semua 😝

ini kenyataannya , kode kita hanya bisa di baca oleh kita sendiri .

seharusnya kita harus benar-benar sadar dan pahami, bahwa kode yang tulis ini bukan untuk diri sendiri. kode kita akan di baca oleh orang lain.

maka kita perlu agar kode kita bisa bercerita kepada orang lain.

kita programmer ini kayak penulis, yang saya tahu kebanyakan penulis menulis bukan untuk dibaca oleh diri mereka sendiri.

mereka menulis untuk di baca oleh orang lain.


Buat kode Kita mudah dibaca dan dirawat

jadi saat kita menulis kode, ceritakan proses bisnis yang sedang di selesaikan dengan kode.

contoh kecil, tulis nama variabel dengan nama yang sesuai dengan tujuan dan isi variabel.

jangan pernah nulis variable hanya dengan satu karakter saja.

misal kalau di php : $x , $y , $z.

orang pasti pusing, apa isi dan fungsinya variabel tersebut.

jangan takut untuk menulis nama variabel, method , class yang agak panjang.

gapapa nulis namanya agak panjang yang penting maksud dan isi nya tersampaikan ke rekan kita yang baca.

lalu bila aplikasi kita melakukan banyak hal sama di tempat yang berbeda-beda, maka jangan menulis ulang kode dengan fungsi yang sama.

lebih baik buat kode itu jadi sebuah method , dan panggil method itu di tempat-tempat yang dibutuhkan.

apa gunanya ?

kode kita jadi mudah dibaca, kode yang di tulis lebih sedikit, semakin sedikit kode yang ditulis tentu waktu kita makin efektif dan misal kan di method itu ada bug, maka kita cukup debug di method tersebut saja sekali dan semua nya kembali normal lagi.

bayangin kalau kita lakuin yang nulis semua kode yang sama di banyak tempat. artinya kita akan menghabiskan banyak waktu memperbaikinya di banyak tempat.

lalu ikutin standard coding , misal kalau di php ada psr

http://www.php-fig.org/psr/psr-1/

dengan mengikuti standard coding, maka kode kita semakin kolaboratif karena semua orang mengikuti standar kodingan yang sama.

oke, mungkin kita beranggapan masing-masing dari kita punya gaya koding unik yang nyaman buat diri sendiri.

tapi harus di ingat, kita menulis kode bukan hanya untuk komputer tapi juga untuk manusia yang lain.

Code Refactor dan Code Review

code refactor, apa itu ?

http://www.php-fig.org/psr/psr-1/

dari wikipedia kata nya :

“Code refactoring is the process of restructuring existing computer code — changing the factoring — without changing its external behavior”

jadi refactor itu, mungkin bisa diandaikan kayak rehap rumah. kita ubah-ubah bagian rumah nya, tanpa merubah maksud rumah tersebut di bangun.

seringkali ketika programmer ngoding yang dipikirkan itu satu, yaitu bagaimana agar kode yang dibuat menjadi solusi yang menyelesaikan masalah.

karena terlalu terpaku kepada penyelesaian masalah. kita jadi kurang memperhatikan masalah readable dan maintainable kode yang kita buat.

jadi solusinya adalah refactor kode kita!

jadi kayak bersih-bersih abis kerja hehe, kita sudah berhasil menyelesaikan masalah dengan kode kita, selanjutnya tinggal di bersihkan dan dipercantik kode nya.

tapi ingat, jangan sampai refactor yang dibuat, justru malah merusak solusi yang sudah jadi.

dan refactor tidak hanya dilakukan ketika kita selesai koding, pokoknya ketika kita lagi ngoding jika sekiranya menemukan kode yang perlu di refactor maka cepat segera lakukan.

saya juga sering kali memulai hari dengan merefactor kode-kode saya di hari sebelumnya dan kode rekan saya, karena saya gak bisa nahan kalau lihat kode udah kayak medan perang.

selanjutnya yaitu Code Review

ya seperti namanya review, artinya kita minta teman untuk mereview kode yang sudah dibuat, minta untuk memberikan saran dan kritik yang membangun agar kode kita menjadi lebih baik lagi.

jangan pernah menganggap kode yang kita buat itu sudah bagus, jika belum pernah di perlihatkan kepada orang lain.


mungkin itu yang bisa saya bagi mengenai bagaimana membuat kode kita menjadi supel. kenapa saya milih kata supel, karena supel itu kan aritnya mudah bergaul, ramah.

jadi kita membuat kode yang supel, yang akan ramah jika di baca oleh orang lain dan pandai bercerita sehingga gak akan ngebingungin orang lain hehe.

terima kasih telah membaca dan tolong di share ya agar semakin banyak rekan programmer kita yang menulis kode berkualitas.

Happy Coding 😄 😄 💻

Tolong Like dan Share ya !

Leave a Reply

Your email address will not be published. Required fields are marked *