Revolusi Coding Ruby Saya

Tidak ada manusia yang lahir dengan sekaligus membawa pengetahuan. Semua manusia tanpa terkecuali pada awalnya pasti “kosongan” alias tidak mengetahui apa-apa.

Untungnya kita diciptakan dengan sebuah kemampuan untuk belajar. Dengan proses ini, yang tadinya tidak tahu menjadi tahu, yang tadinya tidak bisa menjadi bisa.

Semua bidang ilmu pasti membutuhkan sebuah proses yang namanya belajar untuk menjadikan kita lebih pintar. Nah, tidak ada pengecualian untuk bidang ilmu yang kita semua sukai ini, ngoding!

Blog post kali ini saya menulis tentang beberapa contoh kodingan yang saya anggap sebuah improvement dari hasil proses belajar. Kode yang saya contohkan masing-masing terdiri dari 2 buah versi. Versi pertama adalah kode lama yang mewakili masa sebelum mengetahui suatu teknik/ilmu yang ternyata ada dan yang kedua merupakan revisi dari versi pertama setelah mengalami proses pembelajaran.

Map

Waktu itu di tempat saya kerja sedang ada kuis yang wajib dikerjakan oleh semua engineer. Kuisnya berupa soal pemrograman yang ada di hackerrank.com

Dari deskripsi soal yang diberikan, langkah awal yang harus kita lakukan adalah mengubah input string berupa deretan angka yang dipisahkan oleh spasi menjadi sebuah array angka.

Karena hal seperti ini sangat jelas dan gampang maka langsung saya tulis kodenya seperti ini, apa yang ada dipikiran langsung saya tulis dalam bentuk kode program.

Hasil akhirnya, kode yang saya tulis berhasil lolos semua test case yang diberikan oleh si pembuat soal. Horee.

Singkatnya, setelah melihat kode dari beberapa teman, saya baru tahu kalau kodingan yang saya tulis di atas tadi bisa dibuat lebih sederhana menjadi seperti berikut.

Terlihat lebih bagus ya solusi yang akhir ini, Ruby banget.

Seolah-olah kalau sudah bisa menggunakan kode yang singkat dan cantik seperti ini di Ruby maka derajat kita akan naik 😀

Kondisi if dan duplikasi

Salah satu hal yang agak menyebalkan adalah proses code review. Tujuan proses ini sangat bagus dan justru membuat saya mendapatkan banyak ilmu.

Yang membuat saya sebal adalah lantaran seringnya kode yang saya tulis mendapatkan feedback dari reviewer untuk diperbaiki. Artinya secara tidak langsung adalah kode yang saya tulis semrawut ?

Contohnya adalah kode di bawah ini.

Maksudnya jelas. Jika suatu transaksi sudah dibayar maka catat pada recent_transaction data berbentuk array dengan indeks pertama berupa boolean true dan indeks kedua adalah tanggal transaksi dibuat. Jika transaksi belum atau tidak dibayar maka nilai boolean-nya adalah false.

Pede dong saya.
Kemudian reviewer memanggil dan menunjukkan bahwa kode yang saya tulis bisa menjadi lebih simpel dengan cara seperti ini.

Oooh man I feel like shit ?
Bagaimana bisa saya tidak “sampai” kesitu cara mikirnya.

Saya cuma mengelus dada, menarik nafas panjang diikuti dengan bergumam dalam hati “jancuk, revisi meneh ini adalah proses belajar nak” sebagai upaya untuk ngadem-ngademke ati.

Tidak Semua Method Butuh Parameter

Pada suatu hari yang saya lupa entah cerah atau mendung, ada sebuah tugas gampang yang menghampiri. Setiap kali ada transaksi yang dibuat melalui fitur “Beli Lagi”, track datanya supaya tahu berapa orang yang menggunakan fitur ini dan mungkin juga untuk menggali informasi lainnya.

Butuh waktu lumayan untuk memahami alur dari kode yang sudah ada sebelumnya. Begitu ketemu, dalam sekejap saya tambahkan beberapa baris kode termasuk di dalamnya yang berbentuk semacam ini.

Apakah kali ini reviewer akan menemukan sesuatu yang bisa diperbaiki?
Jika ada, kamu tahu kode seperti apa yang akan menjadi perbaikannya?

Hahahaa
Ternyata memang ada dan perbaikannya adalah seperti kode di bawah ini.

Karena secara umum transaksi tidak dibuat dari fitur “Beli Lagi” yang artinya nilai default untuk repurchase adalah false, maka hanya akan ada satu nilai yang di-set ke attribute repurchase yaitu true. Jadi buat apa menggunakan parameter pada method-nya?

Bermain dengan Magic

Kali ini tidak akan ada reviewer yang terlibat.

Setelah beberapa waktu melihat kode Ruby maka sedikit demi sedikit saya mulai mengenali kode-kode yang tampaknya aneh karena sekilas seperti magic.

Pada suatu kesempatan saya menggunakan magic ini untuk menuliskan kode yang jika dibuat dengan menggunakan cara “biasa” adalah berbentuk sebagai berikut.

Dengan sedikit “aneh-aneh” yang saya pelajari, kode di atas saya ubahlah menjadi sesuatu yang mungkin justru membingungkan bagi yang belum familiar dengan “aneh-aneh” yang bisa dilakukan oleh ruby.

Weird gak?
Kedua kode memiliki behaviour yang sama.

Again, saya merasa jika sudah bisa menggunakan kode yang aneh-aneh seperti itu maka seolah-olah level kita naik. Naik dari segi bahasa Ruby pastinya. Kalau mau seolah-olah naik dari segi desain berarti harus ngerti dan menerapkan pola desain / design pattern.

Kesejajaran =

Point kali ini terkait dengan keindahan. Sebelumnya jika menulis banyak baris kode yang menggunakan assignment maka yang saya tulis berbentuk seperti berikut.

Tanda sama dengan selalu dipisahkan dengan 1 spasi di depan dan 1 spasi juga di belakang. Lumayan readable daripada tanpa ada spasi yang memisahkan seperti misalnya gini.

Adapun sekarang, saya selalu sebisa mungkin untuk membuat semua tanda sama dengan sejajar antara yang satu dengan yang lainnya. Bagi saya ini jauh lebih enak dilihat. At least dengan begini, developer yang nanti meneruskan pekerjaan saya akan jadi sedikit terbantu haha.

Facebook Comments
 

Agung Setiawan

Agung Setiawan adalah software engineer di BukaLapak.com, penulis sekaligus pecinta sastra, dan pembaca buku

 
Halo, perkenalkan saya Agung Setiawan.
Saya Software Engineer di BukaLapak.
Simak pemikian saya soal dunia Software Engineering via Twitter di @agungsetiawanmu dan facebook
Blog ini saya update seminggu sekali jadi sering-sering saja mampir
Mau belajar Vim bareng saya?
Belajar ngoding dari nol menggunakan PHP

Leave a Reply

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