Intinya

Kerjakan frontend dan backend setiap fitur bersamaan dalam satu waktu, bukan backend duluan sampai selesai atau sebaliknya.

Intro

Mengerjakan project fullstack bukanlah kebiasaan saya. Ketika bekerja dalam tim, saya biasa hanya fokus mengerjakan backend dan terkadang merangkap jadi "tukang setup" infrastruktur sederhana. Tidak terbiasanya saya karena beberapa alasan. Yang menurut saya paling berpengaruh:

1. Saya belum pernah, baik sendiri ataupun dengan tim, merasakan atau menggunakan workflow yang mana programmer tinggal translate ke kode. Alias saya menganalisis requirement dari stakeholder yang kadang besoknya bisa banyak berubah, membuat berbagai keputusan "on the fly", dan secara bersamaan langsung membuat implementasinya.
2. Saya (mungkin sedikit klaim) agak perfeksionis dalam hal desain dan kode meski skill masih cupu. Saya memberikan diri saya standar bahwa jika membuat desain harus bersih, lega, dan enak dipandang. Sedangkan di sisi kode, saya mempunyai obsesi membuat kode yang rapih dan bisa se-natural mungkin untuk dibaca.
3. Saya selalu berpikir bahwa context-switching dalam waktu yang singkat itu memberikan lebih banyak beban karena memerlukan effort yang lebih besar.

Beberapa biasanya menjadi sesuatu yang diapresiasi saat bekerja dalam tim, namun menjadi semacam "perangkap" ketika saya bekerja sendiri dan mengambil peran fullstack.

Kenapa

Eh, aku bisa fokus backend aja nggak? aku fullstack bisa sih, tapi nanti malah projectnya jadi lebih lama selesainya.

Yap, itu adalah gambaran reaksi saya ketika diminta mengerjakannya. Kenapa seperti itu? seringnya karena:

1. Ngga ada wireframe/mockup UI, otomatis menambah hal yang perlu dipikirkan bersamaan saat membuat implementasi.
2. Analysis Paralysis yang suka muncul tiba-tiba: Ngerjain frontend semua dulu atau backend semua dulu?
3. Kalo frontend semua dulu, dan pakai data dummy buat pengganti API, gimana kalo nanti struktur data dummny nya ternyata susah dibuat dibackend? atau bisa tapi malah seperti "melawan" tool yang dipakai. Malah membuat kerumitan yang ngga perlu. Kalo udah gini? paling enak ya rubah frontend!
4. Kalo backend semua dulu, tentu nanti frontendnya gampang kan? tinggal nampilin data dari API aja? Ini biasanya benar kalo saya cuma fokus backend. Tapi ketika fullstack, terkadang saya nggak sadar malah membuat API yang simpel di backend tapi mempersulit saat digunakan frontend. Ibaratnya seperti saya ngga ada empati sama programmer frontendnya, yang ironisnya saya sendiri. Kalo udah gini? enaknya ubah lagi!

Eksplorasi Pencerahan

Dititik ini biasanya saya udah stress duluan karena seperti ngga ada progress sama sekali meskipun udah banyak yang dikerjakan. Hingga saya terpikirkan mengenai proses produksi dalam Lean Manufacturing yang dibahas dalam buku The Lean Startup, tepatnya tentang "Single-Piece Flow".

Single-Piece Flow dalam The Lean Startup digambarkan dengan seorang ayah yang membantu anaknya memasukkan buletin kedalam amplop, yang mana tiap amplopnya perlu diberi alamat, stampel, dan sebagainya. Sebuah kegiatan yang proses pengerjaannya secara bertahap.

Anaknya memberikan instruksi kepada ayahnya untuk menyelesaikan keseluruhan bagian sebelum beralih ke bagian selanjutnya, seperti melipat semua amplop dulu, kemudian baru memasukkan buletinnya, dan sebagainya. Sang anak mengelompokkan tiap proses dan mengerjakan proses demi proses dalam satu waktu.

Sedangkan ayahnya ngga melakukan seperti yang diinstruksikan. Ayahnya malah langsung mengerjakan semua yang dibutuhkan untuk membuat satu amplop lengkap dan kemudian beralih ke amplop selanjutnya. Artinya sang ayah melipat amplop, memasukkan buletin, memberikan stampel, dan lain-lain yang tiap iterasinya menghasilkan satu amplop lengkap.

Ternyata metode yang dipakai ayah bisa menyelesaikan semua amplop lebih cepat daripada anaknya. Metode ini dinamakan Single-Piece Flow, atau One-Piece Flow, atau Continuous Flow.

Pengaplikasian

Single-Piece Flow dalam konteks kita berarti mengerjakan satu value/fitur dalam satu waktu, ini artinya backend dan frontend secara bersamaan.

Kenapa metode ini bisa lebih cepat selesainya meskipun kelihatannya lebih lambat? Kalau dalam kasus saya, metode ini menjadi masuk akal karena cerita tersebut sangat berkorelasi dengan yang saya alami sendiri, terutama hal-hal yang saya sebutkan sebelumnya:

1. Mengerjakan dengan ukuran batch yang besar (semua backend atau frontend dulu) artinya kita ngga akan tahu jika ada bagian tertentu yang bermasalah yang menyebabkan kita ngga bisa menyelesaikan satu produk utuh. Dengan Single-Piece Flow, kita akan langsung tahu bagian apa yang bermasalah dan bisa dengan cepat kita perbaiki.
2. Dengan Single-Piece Flow kita bisa memperkecil kemungkinan mengubah banyak bagian (atau malah mengubah seluruhnya) dari kode yang telah dibuat karena adanya masalah atau ketidakcocokan tadi.
3. Dengan Single-Piece Flow kita bisa fokus membuat value daripada menghabiskan waktu untuk menganalisis dan membuat keputusan teknis dari requirement yang selalu berubah. Paling tidak seburuk-buruknya kode masih bisa menjalankan fungsi semestinya. Dan mencoba membuat kode yang perfect di awal dalam kondisi requirement yang selalu berubah bisa jadi malah memberikan technical dept kedepannya.

Penutup

Sejauh ini dengan menerapkan metode tersebut, saya bisa lebih fokus untuk membuat implementasi yang memberikan value daripada terperangkap dalam analisis teknikal.

Disclaimer

Saya menganggap diri saya masih dalam level junior, dan tulisan berikut adalah bagaimana saya mencapai yang saya tuliskan di judul dan bagaimana benefitnya untuk saya.