Sofware Refactoring (@imrenagi).mp3

. Halo, halo.

Nyobain-nyobain suaraku bagus nggak? Atau kayak kemarin?

Jelas sih. Bagus sih. Definisinya kayak gimana?

Maksudnya jelas nggak? Kemarin kan sempat agak jauh kan di space yang kemarin. Nggak sih lumayan jelas. Oke.

Kita nunggu agak ramean dulu kali ya.

Nunggu kurung. Kurung. Oke lah ya. Upetra jentang biru sekarang. Malah nge-judging orang. Emang kenapa kalau jentang biru? Jentang biru tuh aku ada predisposed judgment gitu. Padahal kalau mau bisa subscribe ya, monetisasi kanal gitu di Twitter itu harus jentang biru dulu. Ngeselin nggak? Udah nggak bisa ya. Bukannya bisa support gitu.

Bisa masukin kayak Patreon gitu.

Oh nggak. Ini yang subscribernya Twitter. Kalau misalkan kita sangat menarik gitu kan. Jadi only fans tapi text.

Only fans. Gokil.

Oke. Mulai berdatangan. Halo semuanya. Selamat malam.

Kita tunggu agak ramean dulu. Malam ini kita akan bahas tentang software refactoring.

Oke.

Barang emas didit malam ini.

Ya tapi aku mau set stage dulu nih. Aku nggak pernah baca bukunya Ken Beck atau apa ya. Aku refactoring asal aja. Ini street knowledge. Bukan book knowledge. Kalau name dropping nggak bisa nih. Menurut Ken Beck nggak bisa. Menurut saya sendiri.

Ini nggak baca sampai selesai tapi kita bahas pengalaman lah. Karena kemarin sebenarnya triggernya adalah gue kemarin iseng nanya, kalau kodingannya direfactor. Dan ternyata dua puluhan persen itu pernah kesinggung. Nah mungkin nanti kita bahas sebenarnya gimana sih. Kenapa itu bisa kejadian dan hal-hal seperti itu.

Oke sip sip. Oke kita tunggu berapa menit? 19.02? 19.03?

18.02 lah. Ini udah ada sekitar...

19 pak. Oh iya. Sorry sorry. Beda timezone. Itu humblebrag banget sumpah.

Oke. Udah nih? Ini siapa nih request?

Kita mulai aja ya.

Halo semuanya. Selamat malam. Selamat bergabung di Twitter Space kali ini bareng saya Imbre. Dan ada Mas Didit juga. Kita malam ini akan bahas tentang software refactoring. Mungkin nanti kalau teman-teman ada yang punya pendapat, pandangan, atau mungkin juga ingin bertanya. Nanti silahkan raise hand aja. Nanti akan kita masukin ke speaker. Jadi perkenalan gue Imbre. Tukang heboh di Twitter. Gak heboh-heboh banget sih sebenarnya. Dan satu lagi ada co-host kita Mas Didit. Mas Didit silahkan perkenalkan diri.

Halo. Nama saya Didit. Kalau beberapa minggu terakhir bikin ribut, mohon maaf. Gitu aja sih. Tapi yang saya pastikan kalau baca tweet-tweetan saya, banyakkan pendapat saya sendiri dan gak bisa pakai disclaimer. The opinion is my own. Not my employer. Employernya saya sendiri juga. Jadi gak bisa pakai disclaimer itu kayak orang-orang lain. Nanti ntar lagi. Ntar lagi bisa kayaknya. Hah? Ntar lagi? Gak juga ya. Tidak berencana. Jadi kita mulai aja kali ya.

Silahkan nanti teman-teman yang mau ngobrol, silahkan request aja. Kalau mau request dari sekarang juga silahkan. Jadi gue buka tweet gue dulu. Kemarin mana ya? Cari dulu. Memang ini kalau kurang preparation kayak gini. Nah ini. Jadi kemarin sebenarnya penasaran. Gue nanya, apakah kalian pernah merasa tersinggung ketika kodingan yang kalian tulis itu dirombak atau direwrite oleh orang lain? Dan ternyata 26% itu bilang pernah. Dan 74% itu bilang enggak. Ada alasannya macam-macam. Jadi sebenarnya ada yang bilang enggak masalah. Karena mungkin kodingan dia emang masih dari segi desain atau kualitas masih kurang. Jadi kalau seandainya ada yang mau merefactor juga enggak apa-apa. Tapi ada juga yang bilang sebenarnya enggak apa-apa. Tapi kalau seandainya ada isu, nah itu sebenarnya yang malesin. Misalkan setelah direfactor malah terjadi ada isu. Terus ujung-ujungnya yang dicari adalah orang yang pertama kali nulis. Bukan orang yang merubah. Terus habis itu ada yang bilang juga kalau seandainya senior, ada juga yang enggak suka kodingannya dikoreksi. Enggak tahu juga kenapa. Ada yang bilang kalau mau merefactor sebaiknya kasih tahu dulu sebelum merefactor. Mungkin lebih untuk menghormati saja. Atau untuk ngasih tahu nanti kalau seandainya ada apa-apa. Yang ngeganti dan yang digantipun kodingannya juga bisa sama-sama jump in untuk solve problem. Jadi ada banyaklah opini-opininya. Jadi kalau menurut Mas Didit sendiri nih, pengalaman Mas Didit, kalau dalam proses pengembangan software sebenarnya refactoring itu sebenarnya harusnya terjadi kapan sih? Kita mulai dari sana dulu, kapan orang harus melakukan refactoring?

Oke. Jadi kapan kita harus melakukan refactoring? Ini jawabannya sebenarnya ada yang bilang abis production dan segala macam. Kalau aku dari titik pertama kita nulis kode itu udah harus mulai mikirkan refactoring. Cuman itu problemnya, itu kan didrive sama heuristik. Heuristik itu kan sesuatu atau intuisi heuristik yang itu sudah terjadi, terbentuk ketika kita sudah punya ngelakuin hal good practice tertentu. Tapi kalau dari sisi refactoringnya mulai kapan? Mulai nulis kode. Jadi mulai nulis kode, mulai direfactor pelan-pelan. Karena kode pertama kita biasanya yang penting jalan dulu. Kode pertama itu bukan kode pertama selama production. Benar-benar kode pertama bikin fungsi. Terus fungsinya panjang, yaudah direfactor jadi fungsi baru. Terus misalnya kayak bisa pakai pattern yang lebih sesuai, yaudah langsung direfactor aja saat itu juga.

Menarik. Sebenarnya kalau kita ngomongin life cycle TDD kan sebenarnya juga kayak gitu. Mulai dari nulis test, kemudian bikin fail, kemudian bikin pass, kemudian baru akhirnya refactor lagi. Kalau lo sendiri melakukan proses itu enggak? Apakah lo selalu mulai dengan test atau kemudian setelah lo pass testnya kemudian baru lo refactor atau lo implementasi dulu aja,

ini kayaknya bisa direfactor nih? Ini sebenarnya pertanyaan tricky karena gue orang yang enggak terlalu percaya TDD. Hanya gini, apa namanya, kalau TDD itu gampang banget karena lo bikin test, habis itu mulai dari testnya, yang penting behavior-nya jalan. Test kemudian dibikin working, habis itu direfactor kodenya biar tetap testnya jalan dan kodenya lebih clean, lebih baik. Siapa tahu ada superfluous code tambahan, macam-macam lah. Refactor kan juga termasuk rename variable, termasuk refactor kan. Kalau gue itu, makanya aku bilang sambil coding, sambil direfactor, ya karena gue itu tidak terlalu adhere ke TDD. Kalau jokingly gue selalu bilang DDD, Dedicated Driven Development, suka-suka gue. Jadi emang buat aku yang penting jalan dulu. Ketika sudah jalan, itu baru ditulis testnya. Tapi biasanya aku diprotes, kok kayak gitu? Sebabnya aku sudah ngelakuin TDD berkali-kali dari dulu. So, it's something yang sudah aku mulai kerja sama Imri dulu di Icehouse 2015 sudah ngelakuin TDD terus. Jadi ketika sudah sampai ke titik ini, aku pakai pattern lain, jadi pakai best practice yang lain yang aku deploy dulu, kemudian ditulis testnya di atas deployment itu. Karena aku jadi tahu, oh ini feedbacknya kayak mana, dan segala macam. Explicitly aku kadang-kadang nggak tulis test dulu, aku bikin API, aku bikin frontend, deploy ke production. Tapi ya itu yang aku lakukan lagi-lagi karena skill yang kerjain sekarang itu kecil. Jadi risikonya itu kecil banget kalau misalkan ada problem di production. Cuma ketika aku kerja di Unicorn, aku pernah di Unicorn atau di tempat-tempat yang codebase-nya sudah besar, itu mulai semua testing harus dimulai, semua refactoring harus dimulai dengan menulis test. Jadi kalau bagian itu belum ada testnya, jangan pernah ada refactor. Karena itu kode orang lain. Jadi kode orang lain kadang-kadang kita nggak ngerti behaviornya kayak mana yang betul, outputnya. Nah, tadi ada yang tanya apakah harus minta izin, nyewu dulu sama yang punya kode. Menurut aku nggak. Menghubungi yang punya kode itu ada negatif efeknya, yaitu nyalahin yang nulis kode pertama kali. Yang mana itu bukan dinamik atau kultur tim yang sehat menurut aku. Hubungi yang punya kode pertama kali, yang mungkin sudah pindah ke tim lain, itu buat dapetin konteksnya. Paling pairing bareng sejam, dua jam. Minta tolong untuk kita bisa nulis testnya di situ. Dan test itu harus ada. Walaupun aku nulis testnya belakangan, prinsip aku test harus ada. Baik itu di layer integration, di layer HTTP call, apapun kalau nggak bisa di bawah, nggak bisa unit, di atasnya. Nggak bisa di atasnya lagi, sampai dapet titik dimana kita bisa ngetes. Nah, ketika udah dapet itu, dapet titiknya, kita nulis testnya, kita bisa validasi input sama outputnya, barulah kita bisa mulai refactor kode orang lain. Gitu kalau menurut aku.

Betul, betul, betul. Gue juga setuju sih. Karena kalau gue, yang gue lakukan di kantor adalah sebenarnya lebih brutal lagi. Karena sebenarnya yang gue lakukan, itu sebenarnya nge-develop internal platform kan. Dan itu pun juga belum di-roll out gitu. Dan yang gue minta lakukan ke tim kantor gue sebenarnya yaudah, kejar fitur dulu aja. Mungkin konteksnya mirip dengan ketika lu mengerjakan proyek yang tidak riski. Tidak riski kan bisa artiannya belum di-deploy, belum dipakai user beneran, atau mungkin skalanya yang kecil. Nah, kalau konteks gue adalah mungkin karena memang belum dipakai. Jadi kalau seandainya ada apapun, yaudah nggak masalah juga kalau udah di-deploy ke production. Dan ketika udah di-deploy ke production, baru biasanya udah aman nih fiturnya. Dan yang terjadi kalau gue observe adalah orang kadang, kalau mikirin tes itu kadang ke-skip ya. Karena mungkin dikejar-kejar juga dengan deadline segala macem. Ada tes tapi mungkin nggak komplit. Dan yang biasanya gue lakukan adalah setelah itu ke-deploy, setelah itu ke-tes, jadi baru kelihatan nih, oh ternyata setelah satu atau dua fitur ini di-deploy, kita baru bisa nih kelihatan pattern-nya kayak gini. Dan codingan yang sekarang itu kayaknya ada yang kurang pas. Dan di situ biasanya gue ngelihat, oh ini ada peluang untuk refactoring. Dan di sana juga barulah kemudian ngikut apa yang tadi lo bilang. Kayak kalau misalkan mau nge-refactor, coba reach out dulu, ini konteksnya seperti apa, kemudian ada tes yang missing, tes apa yang belum di-cover, kemudian kita bikin tesnya dulu, kemudian baru refactor. Dan gue melihat itu sebenarnya proses seperti itu emang agak lambat di awal karena kita spend waktu untuk nulis tes, tapi ketika udah di belakang, itu speednya jadi jauh lebih cepat karena kita nggak perlu ngeverifikasi dengan menjalankan aplikasinya terus-terusan. Kalau misalkan bikin HTTP server, kita bikin lagi, kita jalanin lagi HTTP servernya, kemudian kita masukin JSON payload. Kalau udah ada tes, ya sebenarnya kan cukup sesederhana dengan menjalankan tes aja sebenarnya. Nah, tapi kalau gue pribadi ada isu juga kadang-kadang. Misalkan ketika gue nge-refactor, ada tuh yang dikeluhkan di tweet itu juga, ketika udah di-refactor ternyata ada hal yang salah kayak gitu. Nah, lu pernah mengalami hal kayak gitu nggak? Kalau seandainya lu mengalami hal seperti itu, apa yang biasanya dilakukan? Apakah lu menyalahkan diri lu sendiri atau menyalahkan orang, atau apa yang biasanya lu lakukan kalau setelah di-refactor ternyata malah muncul bug baru?

Siapa nge-refactor siapa nih? Kalau gue, karena gue manusia, keinginan gue pertama pasti nyalahin orang dong, mana mau gue bertanggung jawab. Tapi itu dalam hati aja gitu kan? Yang terjadi ala ini kode brengsek banget gitu misalnya ya. Sudah, that's it. Itu cuma first verse aja. Tapi ini aku ngomongin dari isi reaksi. Kadang-kadang orang bisa membedakan reaksi sama aksinya. Reaksiku kayak gini. Terus, kadang-kadang mungkin juga gara-gara kode kayak gini, susah di-refactor. But, tetap kalau misalkan di-refactor sampai broken, sebenarnya salah kita sendiri. Salah yang terakhir pegang kode. Karena sebenarnya, refactor itu kan harus ada tujuannya nih. Menurut aku, refactor itu hanya buat kode yang baru. Ini kalau aku ya. Sebelum aku kerja sekarang kan juga kerja di satu perusahaan FMCG. Yang dia itu, customer-nya berubah-ubah nih BFR-nya sesuai dengan apa yang di... Karena secara baru juga. Ketika customer berubah, kemudian mau bikin mengubah BFR dari funnel-nya. Itu ada kode legasi. Gede kode legasinya. Kalau di-refactor, ya nulis tes dulu di-refactor. Dengan menurut dari customer-nya. Kalau kita sampai yang terakhir menggang kode ini salah, broken gitu ya. Broken dalam artiannya nge-broken yang ditargetkan refactor tadi ke BFR customer tadi, itu salah kita. Kita tidak paham enough dengan bentuk kode yang baru itu satu. Tapi yang kedua, kalau itu broken ke tempat lain, nge-break tempat lain, itu udah risiko. Menurut aku itu udah selalu bawa risiko. Dan risiko itu kalau kode itu ada risk plan-nya. Kode misalkan di domain itu risikonya gede. Kalau yang cuma di bagian protokol, bagian JSON, itu risikonya kecil. Walaupun customer-nya crash, tapi risikonya kecil buat nge-break yang lain. Jadi kalau itu udah siap dengan risikonya. Kalau udah kayak gitu, tinggal misalkan nge-break di sistem yang nggak kita pegang, kita harus ngomong sama yang bersangkutan. Kadang-kadang sesuatu yang kita refactor itu tanpa kita tahu, ternyata ada dependensi ke tempat lain. Artinya itu bukan kerjaan kita doang. Kita sebagai driver-nya yang punya inisiatif, harus bisa berkomunikasi dengan tim lain yang bisa ngebantuin kita ngelakuin refactor tersebut. Kalau itu sampai blocking, ya sudah. Tapi kalau nge-break, ya itu udah risiko. Ya diterima aja, nggak apa-apa. Simple aja kalau gue sih. Sesuatu pasti ada risikonya. Dan kode itu pasti ada risk plan-nya. Dan kita mengubah kode, ada risikonya. Kita mengecilkan kode. Mengecilkan risiko kode itu break dengan cara satu, kasih tes. Tapi itu nggak cukup sih. Aku belajar dari tempat bekerja dulu, di Gojek. Itu fiture flag, itu penting juga. Jadi yang kau lakukan bukan dengan kodenya langsung diubah, tapi nggak copy dulu. Di-copy dulu, kemudian dikasih feature flag di situ. Dikasih metric dan segala macam. Jadi itu benar-benar mengurangi risiko. Apakah akan break? Kemungkinan break. Tapi kalau break, radiusnya kan kecil, di-lockout ke berapa persen. Ini ngomong aja di jauh. Nggak cuma refactor, tapi juga CICD, feature flag, dan segala hal. Yang sebenarnya yang sekarang gue konsultan, yang gue ngomong sama customer-customer gue, dan juga secara pribadi kalau gue bikin software, selalu yang gue build pertama kali, CICD sama monitoring. Karena masalah ini. Jadi biar kita bisa refactor, istilahnya itu mercilessly. Gak apa-apa, copas aja copas, ganti. Lihat behaviornya, yang lama buang. Itu pattern yang aku lakuin sekarang. Tidak dengan mengganti kode lama ke kode baru yang kita nggak tahu. Karena kode yang lama ini sudah battle-tested, sudah di-production misalnya. Mau kayak mana jeleknya, itu kan tetap kode yang sudah ngasih uang. Sudah dipakai oleh beratus ribu, berjuta-juta customer. Nggak bisa langsung diganti itu aja tanpa ada. Ini seni, sudah ngomongin refactor, sudah ngomongin seni. Karena segala hal yang kita belajari, desain pattern, dan segala macam, itu jadi kepakai ketika ngelakuin ini. Karena kita perlu pakai adapter, kita perlu pakai façade, kita perlu pakai macam-macam yang di-gank over. Itu baru itu berguna buat diimplementasikan. Bukan cuma karena ingin implementasi, itu bukan. Jadi titulnya apa nih kalau misalkan ada dua implementasi yang berguna, oh kita perlu pakai strategi, oh ini perlu pakai dynamic dispatch, oke berarti harus pakai yang lain, adapter. Dan lain sebagainya. Itu cara refactor yang menurut gue sin. Kita meninggalkan kode lama dan kode baru, lama-lama yang sama, habis itu dibuang. Tapi kepanjangan, digress-nya terlalu jauh. Tapi kira-kira kayak gitu sih.

Mungkin kalau teman-teman tadi ada beberapa yang sudah request, tapi ketika sudah di-assign speaker, tiba-tiba hilang. Kita lanjut dulu kali ya. Kalau teman-teman ada yang ingin komentar, silahkan request to speak aja nanti kita allow. Tadi ada satu hal yang tiba-tiba bikin gue jadi kepikiran. Jadi salah satu ketika kita ngomongin legacy, dan misalkan gini, ada yang biasanya gue lakukan adalah gue tidak melakukan refactor out of nowhere. Jadi kalau seandainya ada wisdom, yang boy squad rule kalau nggak salah, yang kalau lo menemukan sesuatu yang kotor, itu bersihin. Apa sih? If you... Aduh, gue lupa bahasa Inggrisnya apa. Pokoknya yang kalau lo melihat sesuatu ada yang nggak rapi, ya lo rapiin deh. Gue cukup religious dalam mengikuti rules itu. Tapi yang gue lakukan adalah gue akan melakukan refactor ketika gue perlu melakukan penambahan, dan penambahan gue itu, misalnya gue melakukan perubahan fitur baru, dan ternyata fitur baru gue itu sebenarnya harusnya bisa menggunakan legacy code. Tapi masalahnya legacy code ini mungkin nggak bisa mensupport itu. Yang disana kalau seandainya gue melihat, oh kayaknya disini ada kemungkinan atau apa ya, peluang untuk bisa sekalian nge-refactor. Dan biasanya disitu gue melakukan refactoring. Dan lagi-lagi sebelum melakukan refactoring itu emang perlu nambahin tes dan segala macam. Dan gue setuju banget sih poin dimana lo bilang sebenarnya kalau refactor itu kita nggak bisa random, dan setelah itu pun juga harus ada hal-hal yang perlu kita lakukan untuk memastikan bahwa changes kita itu nggak nge-break hal lain. Tapi sebenarnya kalau kita lihat, ketika changes kita yang, misalkan gue merubah modul A, ternyata jadi ada isu di modul B. Sebenarnya walaupun ada error, sebenarnya gue melihat bahwa ada peluang sebenarnya ketika kita melakukan refactor, jadinya kita menemukan isu di modul lain yang sebelumnya mungkin nggak ke-discover sama tes yang udah ada di modul tersebut. Mungkin ada changes yang gue bikin, changes yang gue buat, kemudian bisa mengakibatkan unexpected input di modul lain atau gimana gitu. Dan itu pun sebenarnya kalau kita lihat bisa jadi lesson learned juga untuk modul lain bahwa kemungkinan kan ada input-input seperti ini. Dan gue melihat itu sebagai kesempatan untuk memperkuat modul-modul lain juga sih. Mungkin setelah kita menemukan bug-nya, kita jadi bisa tahu bahwa, oh ada case ini yang nggak ke-cover atau sebenarnya case ini valid atau nggak. Kalau seandainya valid, yaudah kita tambahin testnya. Tapi kalau seandainya nggak valid, ya berarti tugas gue yang memastikan bahwa modul yang gue ubah tadi tidak menghasilkan input-input yang sebenarnya nggak mungkin kejadian. Jadi gue melihatnya ada hal-hal seperti itu juga.

Kira-kira kayak gitu sih.

Ada pertanyaan.

Ada pertanyaan sih. Kalau ada teman-teman di sini yang mau berpendapat. Maksudku gini, aku baru ngerti cara refactor yang swift.

Itu ketika sudah ter-exposed dengan monitoring.

Aku ke-exposed dengan itu dengan baik, baru aku ngerti, oh refactor itu seperti ini. Sebelumnya aku yang nge-refactor, tapi yang nge-replace aja. Dan ini ternyata ketika aku ngomong sama yang sekarang, kayak customer aku, kemudian internal tim aku juga. Mereka juga berpikir refactor itu langsung nge-replace. Aku nggak ngerti apakah ini emang common. Jadi di-replace, break. Kesel lah seniornya karena nge-break. Gitu kira-kira yang terjadi biasanya. Tapi belum ter-exposed dengan cara bahkan untuk nge-deploy sesuatu pun, itu nge-replace kode orang. Aku suspicion ku aja. Sampai kesel nge-break itu. Emang nggak bisa gitu dimatiin, kemudian balik ke kode lama bentar. Aku mikirnya oke. Ternyata nggak semua orang itu. Ada prinsip yang tadi aku bilang, yang suka aku ngomongin, aku nggak suka dry. Karena kayak gitu nggak dry. Karena dicopas, kode aja dua. Kode yang lama, kode yang baru. Kadang-kadang servicenya aku copas. Kalau misalkan yang dicopas itu bisa. Cuma kodenya dan juga servicenya. Kalau emang sudah terlalu susah, otomatis harus di-rewrite. Tapi lagi-lagi nge-rewrite-nya itu juga harus safe. Apakah memang exposure ke teknik re-factor dan re-write ini masih belum spread banget di luar exclusive group. Maksudku kayak teman-teman yang kerja di Unicorn,

yang benar-benar sudah ada top-down SOP buat ngelakuin itu.

Karena ngelihat sekarang ini benar-benar kayak yang di small guys ini, mereka nggak ngerti. Aku harus ngajarin juga. So, I think that's the first thing sebelum re-factor itu selain testing, TDD, pattern, dan lain macam, monitoring.

Kalau gue ngelihatnya mungkin ini ya, Mas Didit. Kuncinya kan sebenarnya, kalau kita ngomongin DevOps, DevOps itu kan development operations. Untuk punya cycle DevOps itu kan, hal yang paling penting itu sebenarnya adalah ICD dan monitoring menurut gue. Masalahnya adalah ketika typical developer itu, kalau seandainya mereka bikin sesuatu, let's say in general, gue nggak bisa generalisir juga sih, tapi mungkin lebih kayak yang mereka pedulikan itu ketika nge-develop aplikasi pertama kali itu sebenarnya adalah aplikasinya jalan dan nambahin fitur-fitur. Sementara hal-hal yang kayak related dengan operation, kayak monitoring, kemudian bahkan mungkin CICD lah. CICD, monitoring, atau bahkan fitur flag itu sesuatu yang nggak terbayangkan di awal gitu. Kalau gue ngelihat pun kayak beda ya. Misalkan kalau seandainya di kantor, kita ngomongin tim produk yang udah lebih besar, itu biasanya strateginya udah lebih mature. Tapi kalau seandainya kita nge-initialize, misalkan gue lagi nge-init, small initiative di tim gue misalkan. Dan hal-hal itu pun kadang juga sering dikesampingkan sampai ada orang yang lebih senior yang mau memberikan dorongan gitu loh, kayak push dari atas gitu. Kita butuh ini loh. Baru kemudian ada efort-efort yang mulai bergerak ke arah sana. Mulai kemudian mikirin monitoring, baru kemudian mikirin fitur flag dan segala macam. Jadi ya itu sih kalau menurut gue, developernya mungkin nggak aware. Mungkin karena belum pernah berpengalaman dengan hal-hal seperti itu. Apalagi kalau misalkan kita ngomongin fitur flag, bukan ditanya fitur flag aja mungkin pada belum tahu kan. Mungkin ada juga yang ditanya fitur flag itu mau bikin gimana ya simple environment variable juga. Dan bahkan kalau seandainya lebih advance lagi, ternyata udah ada kan software-software yang bisa ngelakuin fitur flag di runtime kayak gitu. Dan itu kan butuh experience yang lumayan panjang juga sampai lu bisa tahu bahwa ternyata ada fitur flag yang bisa ngerubah behavior-nya runtime gitu. Nah kebanyakan mungkin orang-orang itu belum sampai sana. Apalagi monitoring, nge-setup monitoring aja mungkin orang udah bingung gini, gimana gue mau nge-setup monitoring dan segala macam. Sebenarnya kalau gue ngelihatnya kayak gitu ya, makanya banyak orang-orang yang developer pada umumnya yang mungkin experience full di development itu banyak yang belum pernah ke-expose aja dengan hal-hal kayak gitu. Dan ya begitu lah makanya kalau kita balik lagi ke refactoring, ya itu tadi. Mungkin ketika nge-refactor pun, mereka nggak punya monitoring. Kalau mereka nge-refactor, mereka mungkin juga nggak ngelihat apakah setelah nge-refactor itu, impact-nya terhadap performance kayak gimana, latensi gimana, mungkin error-nya gimana. Nah itu pun nggak ada. Jadi apalagi kita ngomongin fitur flag. Gue ngelihatnya yang common itu sebenarnya orang step-nya itu biasanya CICD dulu, kemudian baru punya monitoring, atau mungkin monitoring dulu CICD dulu, tapi fitur flag itu biasanya agak-agak ke belakang. Kalau gue ngelihatnya. Jadi ya wajar aja changes-changes yang tadi itu mulai banyak.

Tapi fitur flag itu gampang banget. Cuma pake environment variable, terus di-restart. Coupe CTL juga beres. Iya, betul.

Tapi kadang banyak yang nggak aware juga. Masalahnya itu emang belum pernah tahu aja gimana fitur flag.

Iya, kayak masalah exposure aja. Tapi ini ada yang mau ngomong, tadi request. Ini dari Mbak atau Mas nih. Amanah Aluvian. Silahkan lho, kalau mau. Halo. Maaf, lagi di kereta cukup berisik, Mas. Bentar ya, bentar.

Nggak apa-apa. Silahkan, Mbak.

Kenalin, aku Hama. Profesinya bukan sebagai engineer ataupun developer. Masih berisik nggak ya?

Nggak, nggak, nggak.

Oke. Bentar, Mas. Bentar ya. Iya, lagi OTP mau ke Jakarta. Bentar ya, Mas.

Nggak apa-apa. Nggak apa-apa, Mbak. Silahkan.

Oke, aku lanjutin. Maaf banget, teman-teman. Noise-nya banyak banget. Aku Hama. Profesinya itu sebagai product owner di salah satu perusahaan otomotif. Di korporasi sih lebih tepatnya. Kondisinya tuh gini. Kita tuh kemarin teman-teman dev tuh udah ngerancang untuk refactor beberapa service gitu kan ya. Tapi prosesnya tuh cukup menjadi pertanyaan untuk stakeholder. Karena memang resourcenya kan yang dibutuhkan untuk proses tersebut kan cukup banyak ya. Dan impact ke bisnisnya kan cukup menjadi questionable karena memang sifatnya teknis banget kan. Nah, mau minta tanya sih. Dari kacamata aku sebagai orang product owner yang mungkin cukup minim untuk tahu sisi teknisnya ya. Sebenarnya tujuan refactor kan pengennya ke arah yang lebih baik ya. Apakah itu jadi lebih cepat? Ataukah codenya jadi lebih simple sehingga lebih scalable? Nah, yang menjadi concern tuh sebenarnya apa aja sih? Mungkin bisa dijabarin karena aku tadi cukup terlambat ya. Mohon maaf banget. Sama aku mau nanya. Ada gak sih kemungkinan ketika kita bilang kita mau refactor untuk ke arah yang lebih baik gitu ya. Tapi ternyata ketika implementasi dengan proses refactor itu. Ternyata ada possibility bahwa kemungkinannya tuh realitanya gak cukup lebih baik. Bahkan yang lama masih cukup mumpuni kok gitu. Sama tadi bahas terkait monitoringnya. Bisa dijabarin lebih panjang gak sih mas terkait monitoring itu tuh sebenarnya berapa lama untuk kita bisa tahu bahwa dengan proses refactor ini dengan code yang baru itu lebih baik atau solve problem kita gitu kan ya. Matrixnya tuh apa aja sama durasinya kita kira berapa lama? Apakah 3 bulan, 6 bulan atau tergantung dari kapasitas trafficnya atau gimana. Mungkin bisa dijabarin. Terima kasih banyak. Maaf.

Ya, terima kasih Mbak Ama. Wah ini menarik nih sebenarnya. Jadi ada input dari orang produk yang mungkin berpikirnya lebih ke bisnis. Gimana software refactoring itu bisa mempengaruhi bisnis atau enggak. Di sini ada Mas Ari juga sama Ziko. Tapi mungkin kita bahas dulu tentang bisnis ini kali Mas Didit ya. Boleh.

Lo mau komentar dulu. Boleh. Tapi ini common pattern ya Mbak Aman. I can't really empathize with your problem. This is very common pattern. Engineer datang ke tim produk terus eh aku minta refactoring dong 6 bulan no new feature. Nah gue nanya dulu, gue nanya balik ke lo deh Mre. Lo bakal approve nggak kalau ada developer kayak gini? Tentu saja tidak.

Kalau time spendnya terlalu panjang tapi justifikasinya untuk refactoring aja kalau gue sih biasanya akan mempertanyakan dulu ya. Tapi ujuk-ujuk kayaknya enggak sih.

Jadi sebenarnya refactoring itu Mbak itu menurut saya adalah meningkatkan internal quality dari software tersebut. Jadi memang kalau ditanyain apakah ada impact ke bisnisnya kadang-kadang minuscule. Tapi yang tadi saya dengar asumsi saya adalah sebenarnya itu enggak minta refactoring itu minta di rewrite sebenarnya itu. Itu rewrite. Dan rewrite itu adalah sesuatu yang big question. Dan itu menurut aku pertanyaan stakeholder maupun pengguna kalau itu questionable bisnis impactnya itu sudah benar. Sudah benar. Karena lead yang baik, ini aku jadi mau kritisi juga. Banyak lead yang yaudah di rewrite aja. Lead yang baik itu bisa memproposalkan sebuah solusi di mana kita ingin meningkatkan internal quality itu tanpa disrupt bisnis yang ada sekarang. Sehingga biasanya kalau saya ngelakuin refactoring saya tidak pernah ada sesi refactoring. Tidak pernah ada. Kalau ada minta refactoring seminggu dua minggu aja saya nggak kasih. Karena refactoring itu jalan terus menerus ketika membuat sebuah fitur. Kecuali kalau bilang oh ini blocking, ini harus dibenerin dulu. Itu bukan refactoring, itu bug fixing. Jadi kita nemuin bug yang ternyata itu terjadi ketika kita bikin fitur baru. Nah ini kualitas lead seperti ini yang kemarin ada Mas Ibam juga. Kualitas lead seperti ini yang dicari sebenarnya. Jadi yang kemarin dibilang bisa triple digits. Karena this is the quality yang cukup tricky. Dan untuk ngelakuin itu, itu perlu hal yang selain refactoring. Kalau tadi ada pertanyaan juga. Apakah berapa lama kira-kira? Jawabannya nggak ada Pak. Session refactoring itu harusnya nggak ada. Ini menurut aku ya. Silahkan walau ada Om Ari atau siapa aja yang mau berpendapat. Kalau menurut aku itu session refactoring itu harusnya tidak ada. Karena ada beberapa startup yang konsol itu hampir mati cuma gara-gara mau ngerirai ini. Jadi aku sangat against the refactoring session 36 bulan itu nggak mau. Kalau mau ya ada fitur baru di-deliver. Sambil di-deliver kita lihat, anggaplah di tempat selama saya. Oh kita mau refactor search. Tidak bisa cuma refactor bagian belakangnya. Tapi waktu itu oke kita mau bisa search-nya ini bisa di segmentasi ini. Ternyata yang sistem sekarang belum bisa. Otomatis harus nge-refactor out, ngebikin server baru, service baru. Itu kerjaan end-to-end, nggak cuma developer aja. Tapi sponsornya itu dari lead-nya, kemudian developer juga, kemudian infrastruktur juga. Semuanya terlibat dalam kegiatan itu. Jadi nggak bisa cuma ganti kode aja. Menurut aku kayak gitu. Terima kasih.

Mas Ari, mungkin mas Ari punya pendapat juga tentang ini. Ya terima kasih sudah dikasih kesempatan. Sebenarnya tadi sebenarnya pengen nanya juga. Cuma tadi pas dengerin yang jawaban dari pertanyaan terakhir, jadi ada pengen komentar juga. Mungkin tadi pertanyaan tadi Judith sempat bilang ada nyinggung-nyinggung tentang SOP. Apakah perlu ada, soalnya saya belum pernah lihat ada SOP yang khusus tentang membahas apa aja yang harus dilakukan dalam refactoring, for example. Apakah perlu ada SOP semacam itu. Kalau tentang yang tadi, saya juga sepakat sih. Kalau waktunya terlalu lama itu bukan refactoring, namanya free write jadinya. Biasanya refactor kan kita kontinus proses. Jadi misalnya dalam setiap proses development ada hal-hal yang, oh ini kayaknya bisa direfactor, kita masukkan sebagai bagian dalam commit di kerjaan tersebut. Cuma saya juga kadang-kadang merasa ada perlu waktu yang mungkin gak sampai berminggu-minggu, mungkin bisa satu hari atau dua hari per sprint. Khusus untuk refactoring terutama yang berkaitan dengan technical depth. Soalnya kan seringkali kita tarik ulur dengan team product, team product ingin ini segera release, sementara dari kita merasa ini masih ada hal-hal yang bisa diimprove, akhirnya masuk ke tech depth. Dan semakin lama kan biasanya tech depth itu numpuk. Jadi kadang-kadang perlu, kayak waktu misalnya ini kayaknya fiturnya agak-agak kosong nih sprint ini. Terus ngobrol dengan product, mungkin kita mau pakai beberapa hari khusus untuk refactoring, beberapa hal yang terkait dengan tech depth yang ada disitu. Jadi kalau saya rasa sih mungkin ya kayak gitu sih prosesnya. Thank you. Makasih Mas Ari. Tadi Mas Ari juga punya pertanyaan tentang SOP. Gue punya pertanyaan dulu tentang, eh pertanyaan, punya komentar dulu tentang pertanyaan Mbak Ama. Jadi tadi Mbak Ama sempat nanyain juga soal monitoring. Kalau menurut gue adalah sebenarnya proses refactoring itu kan tadi kayaknya Mas Didit, Mas Ari pun juga udah sepakat bahwa sebenarnya refactoring itu adalah kontinus proses kan. Kalau gue ngeliatnya adalah setiap melakukan codingan yang tadi gue bilang, ketika ada melihat kesempatan untuk melakukan refactoring, biasanya gue akan melakukan refactoring, tapi dengan tahapannya adalah memahami dulu apa yang ada, kemudian bikin tes, kemudian baru refactor. Tapi tanpa itu gue tidak akan ujuk-ujuk melakukan refactoring. Nah once proses refactoring itu udah selesai, sebenarnya yang ingin kita dapatkan itu kan sebenarnya adalah feedback dari apa yang kita lakukan. Kalau kita ngubah sesuatu, apakah akan ngaruh ke latency, apakah akan ngaruh ke mungkin dari availability dan segala macam. Nah biasanya yang harus dilakukan adalah ya nge-deploy changes itu. Dan ketika udah di-deploy itu biasanya bisa langsung kelihatan apa yang berubah dari changes tadi. Misalkan ketika nge-refactor, oh kita memperbaiki struktur kode, tapi ternyata ada kenaikan di latency. Dengan adanya monitoring tadi sebenarnya kita bisa jadi tahu bahwa ada kemungkinan changes yang tadi itu bikin latency-nya naik. Dan dengan latency naik ini berarti kita harus doing something else untuk menyelesaikan permasahan latency tadi. Jadi dari sana kita dapat input lagi bahwa oh refactoring ini punya downside bahwa dia bikin latency. Pertanyaannya gimana caranya kita bisa mungkin nge-refactor lagi atau melakukan sedikit adjustment supaya isu latency tadi jadi hilang. Jadi sebenarnya harusnya monitoring itu pun juga instant asalkan dia segera di-deploy. Tapi kalau seandainya proses refactoring-nya itu membutuhkan katanya waktu berbulan-bulan, otomatis feedback yang akan kita dapatkan jadinya juga lebih lama ke depannya. Maksudnya kita butuh waktu nih refactoring 6 bulan gitu. Ternyata setelah refactoring-nya 6 bulan tuh selesai di-deploy semuanya buyar. Availability turun, latency naik, dan segala macam. Jadi kalau menurut saya sih latency itu harusnya monitoring itu harusnya bisa memberikan feedback itu tadi. Gimana caranya biar itu nggak kejadian mungkin ya lagi-lagi ada yang kita pakai fitur flex supaya kita bisa rollback ke fitur sebelumnya dan segala macam. Jadi kira-kira seperti itu sih. Mas Ibrahim mau menambahkan?

Iya, thank you Mas Ibrahim. Ini sorry nih aku gap-tech, baru sekali nyoba Twitter Space. Aku setuju banget yang tadi Mas Didit bilang ya, bahwa rewrites itu biasanya kill a company. Mungkin kalau teman-teman pengen cek historinya, ada yang terkenal itu adalah rewritenya Netscape. Netscape itu dulu kayak Google Chrome, di tengah-tengah tahun 90-an dia yang merajai browser market, valuenya sampai miliaran dolar, cuman mereka decide untuk rewrite sampai setahun lebih, dan akhirnya mereka kehilang momentum, scrap rewritenya, balik lagi ke codebase lama, dan akhirnya kalah dari pasaran. So itu contoh ya, dimana memang rewrites itu kind of like a last resort sih, biasanya menurutku juga satu itu. Kedua, sejalan juga bahwa segala macam rewrite atau refactor, menurutku itu harus satu hal yang bisa dikuantifikasi before afternya. Karena kalau misalnya kita gak bisa kuantifikasi, menurutku itu cuma memenuhi ego pribadi aja, kayak oh gue pengen coba teknologi baru gitu misalnya. Sedangkan kita harus bisa take a step back dan melihat, oke kalau gue ngelakuin refactoring ini, objektifnya apa, bisa gue kuantifikasi atau enggak. Tadi kan Mas Imre bilang latency ya, misalnya yang lain juga tentang transaksi makin banyak yang bisa di handle gitu. Atau bahkan simply engineers jadi bisa kerja lebih cepat, karena tech dept ada yang ter-address, itu boleh juga kok jadi alasan. Tapi sebagai tech lead, kita perlu berani mengkuantifikasi dan menjanjikan impact itu seperti apa. Satu itu. Kedua adalah mengkomunikasikan ke stakeholders. Kasian kalau stakeholders itu cuman bilang, trust me bro, gue bakal refactor ini, tapi mereka kebingungan ini berapa lama dan impactnya apa gitu. Misalnya impactnya adalah kita bisa develop lebih cepat, kita perlu menjelaskan ke mereka, value-nya ini bikin development time yang sebelumnya 2 minggu, ke depannya bakal seminggu gitu. Jadi kita bisa deliver fitur-fitur lebih cepat. Dan kita perlu ingat bahwa in the end, ini cuma satu di antara sekian banyak prioritas bisnis ya, dari apa yang kita kembangin gitu. Jadi kita harus bisa juga ngebandingin ini dengan value-value bisnis lain. Misalnya ngembangin fitur yang bakal drive additional revenue atau transaction atau user-based growth misalnya. Dan dari situ kita argue bahwa investing time ke rewrite ini atau refactoring ini bakal give more impact. Jadi kalau nggak bisa di-quantify, kalau kita nggak bisa berani commit bahwa impactnya bakal kayak gini kalau kita invest waktu segini, dan kalau kita nggak bisa jelasin ke stakeholders, sebaiknya jangan dilakuin. Kalaupun ada yang mau ya, kayak tadi Mas Dilip bilang ya, masukin itu sebagai bagian dari next feature improvements, kalau memang ada yang bisa diimprove, dan overheadnya nggak gitu tinggi ya silahkan dimasukin, tapi jangan sampai malah misalnya adding overhead by 50%, cuma gara-gara saya mau ubah jadi bahasa lain gitu. Itu kasihan juga user-useran bisnis kita kalau kita maksian kayak gitu. Itu aja Mas Imran, back to you.

Terima kasih Mas Ibram. Mbak Mas silahkan ada komentar.

Masih banyak untuk jawabannya, mungkin tadi mau nanya terakhir aja, berarti kalau sehabis kita refactor itu tuh ada possibility bahwa apa yang kita refactor itu nimbulin issue yang lain sehingga kita bisa rollback ya Mas ya. Thank you. Ini juga salah satu teknik refactor atau rewrite, anggaplah just di tempat saya sebelumnya itu ada kegiatan rewrite, dan resikonya cukup gede sebenarnya. Tapi itu sampai saya keluar pun, tim bisnis nggak tahu, nggak kerasa gitu. Sebab memang kalau dibilang ada resikonya, ada. Cara mengurangi risikonya adalah dengan cara ngedeploy, kalau anggap mau rewrite ya, anggaplah ini jadi ke rewrite. Yang direwrite itu se-early as possible, dan kita benar tadi kata Mas Ibram, harus bisa quantify. Bahkan kalau bisa, anggaplah biasanya ini excuse-nya use developer nih, biar bisa develop lebih cepat. Lebih cepat tuh ada baseline-nya loh. Misalkan sekarang kita develop itu ngedeploy-nya cuma bisa seminggu sekali. Dengan cara kita membuat sistem baru ini, kita bisa deploy sehari lima kali. Itu kan udah satu kuantifikasi yang cukup enak diomongkan ke stakeholder. Oke, berarti perubahannya bisa misalkan saya ngubah sekarang, nanti sore udah bisa out dong dengan cara kita investasi seperti itu. Tanpa kuantifikasi, kalau saya yang punya bisnis sangat merahukan, bahkan kalau saya engineer selalu jawabnya, mau saya rewrite, ngapain direwrite. Saya tanya gitu. Ada yang bisa dikuantifikasi atau enggak? Atau kalau itu bisa mendukung fitur yang bisa, anggaplah ini early startup, bisa mendukung growth dari startup tersebut, dan itu adalah sesuatu yang perlu dilakukan, ya bilang gitu. Oh ini bisa untuk mendukung X, sehingga kita mesti rewrite bagian Y. Yang itu rewrite dan refactor dua-duanya itu, ya tadi mesti ada kuantifikasi itu benar banget sih. Dan itu kalau sampai ada yang minta tiga bulan, sampai empat bulan harus ada question, saran saya ke Mbak adalah tanyain. Kira-kira impact-nya apa? Oh bisa develop lebih cepat. Baseline-nya apa? Lebih cepatnya gimana? Sehingga biar minimal kalau itu inisiatif tech lead di developer secara umum, itu mereka berpikir lebih lanjut untuk, oh ternyata ini enggak semuanya perlu di refactor. Mungkin cuma modul ini doang yang refactor dulu, kemudian yang kedua, ketiga. Dan dari ketika refactor dikomunikasikan, oh setiap kali ada perubahan ini, ternyata kita bisa meningkatkan latensi sekian. Kemudian, oh dengan ini kita enabling sesuatu yang baru. Itu harus bisa berkomunikasi. Kalau ada question, berarti belum clear value yang didapat dari refactor atau rewrite tersebut. Itu aja kali ya, Pak Nyabang.

Sedikit menambahkan sih, pengen share juga pengalaman di kantor. Jadi sebenarnya kan kalau, gue kan di kantor tuh tim infra ya. Jadi tim infra itu banyak didatengin sama orang-orang untuk minta bantuan terkait infrastruktur. Apakah bikin VM atau bikin database dan segala macam. Dan misalkan, contoh sederhananya adalah ada suatu request yang biasanya itu membutuhkan proses, apa namanya, manual proses dari kita tim infra misalkan. Dan itu adalah sistem legacy. Kemudian muncul ada ide, bahwa kayaknya kita kalau mau nge-automate ini, kita nggak bisa pakai sistem legacy ini karena alasan-alasan ini. Dan selain alasan tadi yang perlu kita justifikasi adalah itu. Kalau biasanya orang datang ke kita untuk memprovision VM itu, karena misalkan prosesnya manual sebagai contoh, itu butuh waktunya 10 menit. Itu dengan kita mungkin mau melakukan rewrite atau bikin sistem yang baru, berapa improvement yang bisa kita janjikan. Misalkan karena full jadi otomatis, jadinya ya mungkin jadi 2 menit, 3 menit, dan seterusnya. Dan itu adalah salah satu faktor. Tapi kalau seandainya kita ngomongin scalenya lebih gede, angka-angka tadi yang sebenarnya terlihat kecil itu, kalau seandainya dalam skala besar, itu jadinya jadi jauh lebih impactful. Misalkan kita nerima request untuk bikin VM atau database sehari itu bukan 1 atau 2, tapi misalkan 50. Kalau 50 dikali tadi 10 menit, 500 menit yang kita spend untuk manual proses tadi. Tapi kalau seandainya kita sudah punya, benar nggak? 500 kali 10, 5 ribu menit ya misalkan. Tapi kalau seandainya kita melakukan improvement ini, kontifikasinya adalah berapa waktu yang disave, dan kemudian dikali dengan jumlah request yang biasanya masuk tiap hari. Nah itu salah satu bentuk justifikasi yang bisa kita pakai juga untuk rewrite. Biasanya kalau kita mau melakukan rewrite, tapi kalau seandainya refactoring, biasanya lagi-lagi itu cuma continuous process. Mudah-mudahan menjawab ya Mbak Maya. Tadi kita lanjut ke pertanyaan Mas Ari dulu. Ini ada Iswa sama Mas Ibam juga. Mas Didit, kalau menurut Mas-Mas di sini, tadi Mas Ari sempat nanya, kalau refactoring itu ada SOP-nya nggak sih? Atau ada sesuatu yang harus diikutin gitu nggak? Oke aku dulu kali ya.

SOP-nya sebenarnya bukan SOP refactoring sih. Tadi yang aku bilang SOP itu SOP deployment sebenarnya. SOP deployment. Jadi contohnya kalau kita bikin kode baru itu, tadi aku bilang dicopas, kemudian dikasih logging, dikasih metric, itu SOP deployment sih yang maksud tadi.

Bukan SOP refactoring harus apa nggak? Ya gitu aja sih. Kalau gue punya... Tapi, sorry. Ya, silakan Mas Ari. Menanya, tapi menurut Didit atau menurut speaker yang lain, perlu nggak kita di sebuah organisasi punya SOP untuk refactoring? Dan kira-kira kalau misalnya perlu, apa yang perlu dimasukkan ke sana? Gue punya komentar. Kalau menurut gue sebenarnya SOP untuk monitoring itu nggak perlu. Kalau menurut gue ya. Yang dibutuhkan itu mungkin SOP atau guideline atau checklist untuk changes. Jadi misalkan ada changes yang dilakukan oleh product engineer yang kemudian kita akan punya checklist untuk ngecek beberapa hal. Misalkan ketika dia melakukan changes, itu apakah ada perubahan penambahan test coverage atau bahkan test coverage-nya berkurang. Kemudian kalau seandainya mereka melakukan penambahan fitur baru, apakah sudah ada metrics yang di-enable, apakah ada metrics baru atau nggak. Kemudian kalau seandainya mereka bikin fungsi baru, apakah sudah ada trace-nya dan segala macam. Kalau menurut gue kita butuhnya hal-hal yang sifatnya lebih general untuk software development instead of khusus untuk refactoring. Karena kan pada akhirnya refactoring itu juga akan di-deploy. Berarti kalau seandainya hasil refactoring itu di-deploy, sebenarnya prosesnya sama juga dengan changes yang lain. Apakah ini ada fitur toggled-nya, kalau seandainya ada fitur toggled-nya kapan mau di-enable atau di-disable. Dan menurut gue itu perlu ditulis mungkin dalam prosesnya kayak gimana. Atau kalau seandainya kita mau ngelakuin gradual rollout, rollout-nya itu berapa persen biasanya setelah berapa lama kita baru bisa nge-increase jadi let's say 50 persen, 70 persen, dan 100 persen. Apa aja metrics yang perlu di-observe. Kalau gue melihatnya kita lebih butuh SOP yang seperti itu ketimbang khusus untuk refactoring. Nggak tahu mungkin teman-teman di sini yang lain, mas-mas yang lain atau mbak-mbak yang lain ada komen juga. Belum menunggu yang lain komen, paling saya mau sedikit nambahin mungkin dari diskusi yang sebelumnya tentang masalah refactoring dan tim produk dan stakeholder. Saya juga pernah ngalamin hal yang bisa dibilang lumayan jadi bikin ada sedikit drain antara tim developer dengan tim produk. Karena waktu itu kita kurang, dalam hal ini saya sebagai lead waktu itu, kurang mengkomunikasikan alasan kenapa kita harus melakukan refactoring. Refactoring kan sebuah proses yang bisa dibilang teknikal banget dan bisa dibilang cuma orang yang ngerjain yang tahu dia tujuannya ngapain sih. Soalnya kan nggak ada kayak dokumen, PRD misalnya ini tujuannya mau ngapain. Lebih kayak ngelihat kode, oh ini kayaknya perlu digenerin gitu. Jadi agak susah dikomunikasikan, cuman menurut saya itu sebisa mungkin kalau misalnya memang sedang melakukan sebuah refactoring yang pasti dirasa perlu itu komunikasi dengan stakeholder atau misalnya tim produk atau tim lain itu memang sebaiknya sebisa mungkin selalu dikomunikasikan sedetail mungkin, jadi biar tahu tujuannya itu apa. Jadi nggak cuman dipahami oleh tim engineer sendiri atau bahkan oleh engineernya doang. Itu aja sih Pak. Terima kasih Mas Ari. Ada Iswa juga yang baru masuk sebagai speaker, ada Mas Ibam. Mas Ibam atau Iswa mungkin ada yang mau dibahas, silahkan berpendapat.

Ya, halo-halo. Aku mau nanya sih sebenarnya. Halo semua, salam kenal aku Iswa. Aku mau nanya sih Mas. Kalau dari keyakinan aku sih, kalau refactor itu kan high cost. Karena refactor itu bakal nge-produce tech debt dan melibatkan banyak stakeholders juga. Menurut Masnya di sini ada nggak sih baseline yang common gitu sebagai tolak ukur kalau misalkan refactor itu perlu atau tidaknya dilakukan. Terus yang kedua, refactor dan revamp itu kan pasti ada implikasi ya. Nah itu aku mau nanya juga sih, kapan kita butuh refactor dan kapan kita butuh revamp. Karena dari pengalaman aku, kadang aku came up, ah pengen refactor X, ah gitu. Tapi ternyata ada bottleneck. Akhirnya timeline itu jadi nared di development time.

Terima kasih Iswa. Silakan teman-teman di sini yang mau berpendapat. Ada dua hal nih sebenarnya yang ditanyakan Iswa. Refactor itu sebenarnya ada kemungkinan nambahin tech debt juga karena how we think about it. Kemudian kapan kita nge-refactor dan kemudian kapan kita nge-revamp. Siapa dulu sih?

Afinit. Eh ini gimana sih mic-nya? Aduh ini pertanyaannya susah dijawab ya. Aku agak susah ngartikulasi isi kepala aku sebenarnya. I have some ideas about that. Kalau emang ada yang bisa ngartikulasi lebih baik mungkin nanti bisa nambahin ya. Jadi kapan? Tadi revamp itu bahasa orang produk banget sih. Sebenarnya revamp itu bikin fitur baru. It's not a revamp. Terus terang aja nih. Revamp itu bahasa orang produk banget. So how gimana nge-revamp itu kan bahasa orang bisa oh ini mau di-revamp. Sebenarnya itu kan nambah skin baru. Nambah skin baru itu bukan revamp itu fitur baru. Dan yang kedua kalau ngomongin refactor. Refactor itu kayaknya masih ada sedikit diskoneksi antara refactor dan apakah perlu ada refactor. Kalau dari jawaban awal aku refactor itu mercilessly. Jadi ya refactor itu ambil jalan terus-terusan. Terus aku kepikiran oh iya bener juga ya. Kalau misalkan kita tehdet over tehdet itu kan berarti ada co-churn. Ada internal quality yang akan turun terus-terus karena ada pile of heat on top of pile of heat. Jadi sampai detik kita harus rewrite. Aku belum bisa jawab segimananya karena biasanya dari pengalaman aku kalau seperti itu sudah tidak di titik refactoring lagi. Memang harus invest waktu untuk rewrite. Invest orang untuk rewrite. Dan kalau sudah sampai titik itu ya berarti ada kesalahan. Ada kekurangan di sisi tadi. Aku tetap ke monitoring sih. Karena itu satu-satunya cara kita tahu kalau perubahan kode kita itu sane. Dan itu tidak berpengaruh atau punya pengaruh yang positif terhadap fitur yang baru di develop. Jadi memang tidak pernah ada sisi refactor. Kalau sampai sisi refactor berarti memang co-churnnya sudah sangat banyak. Dan biasanya itu sudah tidak refactor namanya sih. Bahkan kita bikin service baru di atas service itu kemudian pakai. Yang ngerjain akhirnya bukan tim developer saja. Yang akhirnya ngerjain ya tim infra juga ikut ngerjain. Karena harus bikin reverse proxy, split traffic, those kind of thing. Yang biasa terjadi kalau kita mau nge-replace legacy code.

Gue punya sedikit komentar sih terkait tech dev. Sebenarnya kalau kita berpikir lagi tentang kodingan yang kita tulis. Itu sebenarnya ketika kita menulis sesuatu itu eventually akan jadi tech dev. At some point gitu. Misalkan contohnya ketika kita bikin sesuatu, kita bikin fitur. Tapi kita tidak dengan intensi, menyadari bahwa kita tidak menulis test. Itu akan jadi tech dev. Sebenarnya proses refactoring itu kalau gue melihatnya tidak menambah tech dev. Dia mungkin akan take time karena butuh waktu untuk mengimplementasinya betul. Sama sebenarnya kalau kita nulis test duluan. Kita nulis test duluan itu kan sebenarnya kita slow di awal. Tapi kebelakang kita bisa jadi lebih cepat. Sebenarnya dengan melakukan refactoring itu sebenarnya juga kayak gitu. Balik lagi ke yang gue bilang di awal bahwa ketika kita melakukan refactoring. Ketika kita mau menambahkan sesuatu fitur. Kita perlu refactor mungkin ada kodingan legacy yang mau kita refactor. Supaya kita bisa dengan lebih gampang, relatif lebih gampang untuk menambahin fitur baru. Jadi sebenarnya refactoring itu kalau gue melihatnya itu membayar tech dev. Bukan malah menambah tech dev sebenarnya. Walaupun sebenarnya kodingan yang kita tambahin itu pun juga akan jadi tech dev pada suatu saat. Tapi setidaknya kalau kita punya banyak utang ya utang ini kita cicil-cicil dulu. Dan mencicil utang itu yang tidak dilakukan dalam satu waktu tertentu dihabisin. Karena itu nggak akan mungkin juga. Mungkin kayak tadi 6 bulan, 3 bulan itu nggak mungkin. Jadinya makanya dicicil. Ya kayak KPR aja nyicil rumah. Kecuali kita emang benar-benar sultan bisa langsung bayar cash di satu titik tertentu. Nah beda kali ya urusannya. Jadi kalau menurut gue kayak gitu. Dan kapan kita ngelakuin refactoring? Sebenarnya kapan mungkin kita ngelakuin refame ya? Kalau gue ngelihatnya itu tadi. Refame ini bisa kita lakukan kalau misalkan udah terlalu banyak bottleneck yang menghambat banyak orang. Contohnya kalau kita mau nge-refame arkitektur. Misalkan contohnya kita ngomongin monolith versus microservice. Kita punya monolith kemudian udah terlalu besar. Developernya makin banyak. Dan mungkin disanalah kita harus berpikir bahwa. Kenapa sih kalau saatnya gue mau nge-merge kodingan ke master. Gue butuh nunggu 2 jam sampai kodingan gue ke-merge. Karena ada CICD pipeline. Kemudian belum lagi nanti harus rebase dan segala macem. Dan it takes time. Dan mungkin disana baru kita perlu berpikir lagi. Bahwa kayaknya kita butuh refame dari segi arkitektur kita nih. Apakah kita mau split jadi beberapa service yang lebih kecil. 2 atau 3 dan seterusnya. Dan itu kita lakukan ketika kita udah melihat. Bahwa ada bottleneck di titik-titik tertentu. Apakah itu dari speed development. Berapa kali kita nge-deploy. Atau mungkin ada faktor lain. Seperti availability-nya turun. Kemudian ada faktor lain kayak. Ada increase di latency dan segala macem. Yang misalkan ada increase latency. Dan itu mengganggu bisnis dan segala macem. Mungkin mengganggu itu yang relatif lebih parah ya. Sampai mungkin bikin downtime berjam-jam. Nah mungkin disana kita baru perlu melakukan refame. Atau revisit lah. Apa yang udah kita punya sekarang. Kemudian berpikir apa sih yang bisa kita lakukan. Ya pada akhirnya ketika kita mengimplementasikan changes itu. Kita sebenarnya juga melakukan refame juga sebenarnya. Jadi kalau menurut gue kayak gitu. Mungkin teman-teman yang lain punya masukan. Atau Iswa sendiri ada komentar.

Ya menarik sih itu. Tadi yang aku highlight sih. Ternyata refactor itu dari pandang mas Imre. Ini ya, kita bisa menginjel cek. Nah balik lagi sih aku penasaran sih dari pengalaman mas-masnya nih. Refactor itu pernah enggak? Pernah enggak pada saat refactor. Tapi mengakibatkan di akhir itu ada RCA gitu. Ternyata ada spike atau production issue.

Kalau gue sih pernah ya.

Gimana-gimana? Pertanyaan yang malu-maluin sebenarnya.

Ya sebenarnya tadi Mas Didi sudah jawab juga. Sebenarnya kalau gue lebih ke yaudah. Karena gimana ya. Menurut kultur perusahaan ya sebenarnya. Kalau di tim, di tim gue tuh internal. Ya mungkin banyak juga teman-teman disini yang menganut ajaran blameless misalnya. Ya sebenarnya yang penting itu adalah ya. Kita bisa mencari isunya di mana. Dan kita belajar dari sana. Dan yaudah kalau udah ada RCA ya. Apa bohe buat. Itu kita udah enggak bisa ngapa-ngapain lagi. Selain mitigasi isunya secepat mungkin. Dan kemudian ya mencari tahu root cause-nya. Kemudian memperbaiki isunya. Kalau menurut gue sih gitu aja.

Mungkin Mas Didi, Mas Ari. Ini pertanyaan berat. Aku pernah bikin insiden gara-gara refaktor. Aku pernah bikin insiden gara-gara itu. Jadi pertanyaannya ya kalau udah terjadi ya sudah. Terus terang sih kalau ngomongin blameless. Eventually will be blame sih. Tergantung. Tergantung. Ini blameless itu kan sebenarnya kan. Kita fokus. Sebenarnya blameless itu bukan berarti tidak ada blame yang masuk ke tempat kita. Itu kita fokus ke nge-solve problem-nya. Daripada kita fokus ke nyari orangnya. Orangnya cuekin dulu aja orangnya walaupun gerutu gitu kan. Tapi abis itu dikroyokin ya? Nah itu. Abis itu kan pas lagi RCA dipanggil tuh sama atasan lo gimana sih. Itu tetap. Aku kadang-kadang oh blameless ya itu di-block aja lah kalau terjadi di dunia nyata. Maka kagak ya. Itu satu. Kedua, kalau terjadi gimana yaudah. Makanya kesalahan saya adalah biasanya dulu karena masih sangat polos ya. Ada dua insiden gede yang saya pernah lakukan. Satu, saya ini waktu itu masih newbie. Jadi makanya hati-hati kalau mau refaktor mau rewrite. Jadi waktu itu saya mau mengubah sesuatu yang sebenarnya. Oh kok di memori sih? Waktu kuliah saya ini diajarin kalau database itu harusnya normal. Injetnya sama ignorance aja. Jadi ketika itu ya sudah. Saya rewrite aja supaya data punya saya refaktor. Dan ternyata lambat. Emang lambat gitu. Karena tadinya satu table diload sekali, direfaktor jadi lebih normal. Satu, bisa ego. Kata Mas Ibam tadi. Yang kedua, emang bodoh aja sih. Waktu itu saya masih bodoh banget. Jadi yaudah. Jadinya lebih lambat. Nah yang terjadi gimana caranya. Saya dimarahin sama lidah saya. Tapi ya sudah dikandung di production. Yang bagusnya karena walaupun belum ada best practice kayak jaman sekarang. Waktu itu udah 10 tahun lalu, 20 tahun lalu lah. Itu yang terjadi ya langsung di switch on, switch off. Karena emang ada dua code pass tadi. Sehingga kalau udah RCE yaudah terima aja sih. Tapi emang itu kalau udah ngomongin, disalah-salahin. Itu pasti terjadi. Jadi buat teman-teman yang mungkin ada di level kepa yang masih belum pegang tim ya. Oh karenanya di timnya baik-baik aja. Gak ada salah-salah menyalahkan. Ingatlah lidah Anda pasti disalahkan sama bos Anda yang di atasnya lagi. Jadi di tempat kalian mungkin blameless tapi ya itu udah datang dari atas. So just reality of life aja sih menurut saya. Gak ada solusi buat itu.

Ya terima aja udah.

Balik lagi deh. Berarti kalau misalkan kita refactor, itu kita butuh RFC gak sih di awal? Atau yaudah kita set ini kondisi harus di refactor, kita refactor gitu. Atau kita harus butuh analisis dulu di awal? Aku bisa langsung jawab. Karena emang kejadian ini aku kejadian di perusahaan sebelumnya. Aku bener-bener refactor the whole stack end to end. RFC harus ada sih. Tadi kan ada kuantifikasi. Tapi juga ada satu alasan juga yang bisa dipakai. Enabling. Enabling new initiative. Biasanya kan tim produk punya wishlist banyak banget tuh. Kita bisa kritisi juga apakah yang kita punya sekarang ini bisa nge-drive inisiatif itu atau ini blocking ternyata. Yang sistemnya sekarang gak bisa. Nah itu perlu ada ini. Perlu ada analisis. Analisis itu kan gak cuma harus di refactor atau enggak. Tapi juga waiting. Ini dikerjain atau enggak. Mana yang harus di refactor, bagian mana yang harus di refactor, kapan harus di refactor, kapan harus di keluarkan, mana harus kita stay di situ. Those need to be done. Gak tahu ya. Ini aku ngebayanginnya sebuah proyek yang kita udah punya legacy code gede dan harus ditulis lagi atau diubah. Jadi RFC ada. Analisis ada. Itu kalau impact-nya gede. Tapi kalau cuman kecil itu ya sambil ngerjain, sambil dibenerin aja. Kalau ini perlu dikeluarin fungsinya, there is no big effort dari berbagai macam departemen sampai ke end-to-end yang harus dikerjain, ya dikerjain aja. Udah gak perlu ada RFC, gak perlu ada apa-apa.

Misalnya kita mau ngerefactor satu line jadi satu function, biar clean code gitu.

Bercanda-bercanda. Isma, ada lagi?

Kalau enggak, gue pindah ke Mas Goh.

Dapat penyesuaian. Thank you.

Thank you, Isma. Mas Goh, silahkan. Kalau ada yang mau didiskusikan.

Halo, Mas Imre, Mas Widit. Mungkin aku mau nyambung pertanyaan. Tadi udah jawab sama Mas Ibam juga di tweet. Aku bisa bayangin. Tadi kan kita perlu nge-quantify. Kita mau refactor atau kita mau revamp, harus ada sesuatu yang di-quantify. Aku bisa bayangin, tadi dari pembicaraan teman-teman ini, pertama kita carik baseline-nya dulu. Sekarang ini, kalau misalnya kita mau bikin fitur, ini misalnya seminggu bisa deploy 20 kali. Nanti kalau sudah revamp, ini bakal bisa 30 kali. Cuma yang aku tanyain, menentukan angka 30 ini dari mana? Cara nge-set angka yang kita janjikan itu gimana? Karena kita belum lakukan. Karena kita belum lakukan, kita nggak tahu. Dari pengalaman Mas Imre, Mas Widit, Mas Ari, itu biasanya gimana cara nge-set ekspektasi? Yuk.

Menarik, menarik. Silakan Mas Ari, Mas Widit, Mas Isva.

Lu dulu udah, bro. Gue lagi mikir, makanya gue lempar dulu ke orang. Ah curang, lempar ke orang.

Sorry, tadi gue lewat. Pertanyaannya apa tadi ya? Tadi pertanyaannya, kalau seandainya, kan kita butuh baseline untuk nge-quantify apakah refactoring ini akan memberikan perubahan lebih baik atau nggak? Misalkan dari yang sebelumnya kita cuma bisa 10 kali deployment per hari, setelah kita refactor jadi 30. Pertanyaannya bagaimana kita bisa mendapatkan angka 30 ini? Berdasarkan apa? Ya, ini sih, apa ya, kalau saya memandang refactor itu kan lebih ke bagian dari proses development. Misalnya kita lagi development feature baru, terus kita melihat di source code yang kita sedang perhatik, kelihatan, oh ini kayaknya bisa dibikin lebih baik nih. Misalnya di situ ada comment, this is like that, oh ini kayaknya bisa gue sekalian perbaiki, udah, sekalian diperbaiki. Jadi lebih kayak, apa namanya, conscious process, bahwa kita lihat bahwa ini bisa di-improve, ya langsung sekalian kita improve, karena mungkin berkaitan dengan yang kita kerjakan. Tapi memang ada hal-hal yang perlu, itu tadi kayak kata Bidit bilang kan, ada yang perlu, kalau kecil ya nggak perlulah, kita request for comment atau analisis. Tapi kalau misalnya sesuatu yang memang dirasa, wah ini udah nggak efektif nih, atau udah menghambat atau prosesnya terlalu lama, terus kita request untuk revamp gitu ya, karena itu pasti udah bukan refactor lagi, kalau misalnya udah berat kayak gitu, misalnya udah jadi bottleneck, dan itu pasti, apa namanya, adalah sebuah business decision. Maksudnya kita sebagai developer nggak bisa langsung memutuskan, ah ini mau gue perbaikin nih, kayaknya lambat banget, tapi prosesnya gue harus perlu waktu beberapa minggu, misalnya beberapa sprint, beberapa hari, dan efeknya besar. Kalau gitu, ya memang harus dibicarakan dulu dengan team stakeholder, misalnya gue mau perbaikin ini, prosesnya sekarang kayak gini, kalau dengan proposal yang mau gue kerjain, nanti akan ke-improve, hasilnya bakal seperti ini. Itu baru bisa gitu, tapi kalau cuma sekedar kayak, atau melihat ada function yang balik kayak, wah ini one line gue jadiin function aja misalnya, ya itu on the spot aja sih, harus report ke stakeholder. Setuju sih. Iya, bedanya yang satu refactoring itu untuk improve internal quality, tapi yang kalau seandainya akan ada improvement yang akan mempengaruhi external quality, kayak misalkan latency dan segala macam, nggak cocok disebut refactoring kali ya, mungkin lebih ke improvement. Tapi gue jadi kepikiran satu hal, kayaknya kalau seandainya pertanyaannya adalah, gimana kita bisa mendapatkan, tadi misalkan angka 30%, contohnya gini deh, tadi kalau Mas Ibam itu kan ngasih contoh incident ya, gimana caranya bisa ngurangin incident dari sekian, dari Y ke X misalkan. Nah kalau gue ngelihatnya mungkin, kita bisa tarik ke matrix yang lumayan penting, mungkin yang sangat penting dari produk itu sendiri. Misalkan incident ini akibatnya apa? Incident ini mengakibatkan error budget kita kepake, atau bahkan kita jadi hampir melewati batas SLO atau SLE, bahkan kayak gitu. Dan sebenarnya kalau seandainya ditanya improvementnya itu seberapa besar, ya kayaknya kita harus tarik lagi ke belakang. Kalau seandainya kita mau ensure bahwa SLE kita atau SLO kita tadi bisa tetap tercapai, berapa sih angka yang kita perlukan untuk melakukan improvement supaya kita tetap di batas aman SLE atau SLO. Jadi kayaknya dari sana, kalau seandainya kita pengen mendapatkan justifikasi, ya harus narik ke matrix yang kalau menurut gue dianggap penting juga oleh orang produk atau bahkan bisnis. Jadi bisa ngambil perspektif dari sana untuk nyari tau apa sih yang bisa kita lakuin supaya improvement, improvement ya gue gak ngomong risk factor, improvement ini bisa memberikan dampak ke bisnis. Jadi nariknya dari matrix bisnis. Kayaknya kayak gitu. Silahkan mungkin Mas Goh, kalau ada pendapat.

Oke. Nah, itu kalau misalnya ya, ini kan kadang-kadang ininya dugaan gitu kan. Oh ini kayaknya, ada ketidakpastian gitu kan. Oh ini kayaknya, kalau di-refame kayak gini, ini bakal lebih enak deh. Nah terus, misalnya tadi kita ngomong naik 10%, kira-kira bakal naik 10%. Nah kira-kira bakal naik 10%-nya itu apa, kita ngomong aja dulu, nanti setelah kejadian kita ukur, bener gak ini naik 10% gitu, atau dari awal angka 10% itu harus kita bener-bener punya landasan ngomong ini 10% gitu.

Sulit juga ya. Kalau menurut gue harus dicobain sih tetap. Ini pertanyaan apakah angka 10% itu kita bisa ambil atau enggak, itu gue jadi teringat dua cerita. Pertama yang cerita kemarin ngobrol sama Didit tentang story point. Story point ngambilnya dari mana? Dari ini aja, dari awang-awang gitu. Ya ambil aja 10 story point misalnya gitu. Kayak gitu. Jadi kayak yaudah ambil aja 10% misalnya. Itu yang pertama. Yang kedua, ini saya teringat, mungkin ini, enggak tahu ya, ini yang pendengarnya internasional enggak nih? Pendengarnya internasional enggak ini Pak Imre? Soalnya gue sering, kalau gue ini mungkin sedikit rasis ya. Hopefully not, tapi kayak generalization kan kadang-kadang every generalization is wrong, including this one. Gue kalau ngobrol sama kayak developer dari suatu negara, itu mereka kayaknya pede banget gitu. Kayak, oh ini segini perbaikannya, improvement-nya bakal segini persen, ini bakal meningkatkan segini persen. Ada tuh. Pokoknya mereka ngomong pede banget gitu. Nanti pas udah diimplement ya ada lagi nge-less-nya kalau enggak sesuai yang diomongin di awal gitu ya. Ada lah itu dari developer dari sebuah negara yang pede. Bukan di Indonesia, bukan di Indonesia. Ada lah negara lain. Itu pede banget developer-developernya. Pokoknya, oh ini kita kalau kasus ini nanti bakal develop, improvement-nya segini persen, segini persen. Angkanya dari mana ya kayak story point itu diambil dari awal-awal. Dan pas di ini ya nanti mereka apa namanya, misalnya enggak sesuai yang mereka janjikan, ya ada nge-less-nya lagi. Ini faktor ini, faktor ini. Jadi memang enggak akan pernah bisa kita ngasih angka yang akurat gitu ya. Kalau misalnya kita percaya diri gitu ya dengan ini kalau dari pengalaman gue 10 persen, bilang aja 10 persen, enggak apa-apa gitu. Soalnya kita enggak akan pernah bisa mengkuantifikasi secara akurat gitu kan. Kayak ini aja, kayak kita misalnya ditanya ini mau software-developernya, fitur ini habis berapa hari? Itu kan susah banget jawabnya. Tiga hari, empat hari. Ternyata kan sudah decoding, ada berbagai hal gitu yang berkaitan gitu ya. Gue jadi teringat dulu ada analogi. Orang kalau di, tentang durasi software development itu kayak disuruh ngitung garis pantai gitu. Kalau misalnya, itu beda lagi. Itu ada cerita dari negara lain. Ini ada waktu itu gue pernah baca sebuah artikel yang bagus banget. Dia bilang, kalau kita ditanya tentang software development, ngabisin berapa lama, itu kayak kita disuruh ngitung garis pantai, tapi kita ngeliat, apa namanya, foto, apa namanya gambar, misalnya pulau gitu ya, pulaunya tapi dari ketinggian berapa ribu, berapa ribu, berapa ratus kilometer misalnya. Itu kan garis pantainya terlihatnya ini ya, terlihatnya smooth gitu. Misalnya pulau Jawa, terlihatnya smooth. Tapi semakin kita zoom, mulai kelihatan tuh kayak ada peluknya, ada panjungnya gitu ya, ada yang menjorok. Semakin kita zoom lagi, tambah kelihatan lagi tuh, ada pantai yang bentuknya bergipuliko, ada yang penuh karang gitu. Jadi, kita nggak pernah bisa dapet ini gitu ya, harus zoom innya tuh dalam banget, baru bisa dapet yang itu. Tapi kan kita doesn't have that kind of luxury gitu ya, kalau misalnya untuk, setidaknya cuma untuk mengestimasi berapa waktu development aja, harus mikirin sepanjang itu. Jadi akhirnya ya, estimasi kan gitu kan, our best estimate gitu kan, apakah itu dalam hal durasi development, maupun dalam hal sejauh mana ini kira-kira nanti akan improve. Kurang lebih gitu sih. Jadi, ya itu tadi. Ambil aja dari awal-awal test for reference. Gitu.

Ya, estimation is not a problem. Boleh-boleh, silakan Mas Seti. Oke, salam kenal semuanya ya. Ini kan sebenarnya ada tiga ya, kebetulan revamp, refactoring, sama rewrite ya. Sebenarnya harus kita bedain secara khusus nih, ketiga hal ini gitu. Kalau refactoring itu, pengalaman ya, refactoring itu kita emang gak merubah secara menyuruh. Jadi kita tetap yang kayak tadi dibilang legacy. Legacy masih ada, terus kita coba untuk optimasi. Nah, optimasi ini kan bisa kita lihat dengan kejadian-kejadian di lapangan. Apakah terjadi bottleneck, ataukah terjadi banyak bugs-bugs yang sampah, dan lain-lainnya gitu. Nah, kalau sedangkan revamp sendiri, revamp sendiri itu, gue sering revamp, karena bukan product-based. Kalau dulu diganti baju yang product-based ya. Kalau sekarang ini kan konsultan yang lebih contohnya. Revamp sendiri, kebanyakan kita sudah ada coba tolak ukurnya. Misalnya, berapa banyak jumlah user yang bisa dilayanin, terus berapa bentuknya kuantitatif ataupun kualitatif yang terjadi. Misalnya, oh ya ini akan bisa di-hit sekian banyak orang, sekian banyak user gitu. Terus akan dilihat oleh, akan di-crawling oleh bot lebih baik, dan lain-lainnya. Nah, kalau rewrite sendiri ya tadi, rewrite ini kadang larinya ke arah ego ya. Ego para developer gitu. Dalam artian, ini lebih enak nih pakai golang, padahal developernya enggak tahu kapan beresnya gitu kan. Padahal pakai PHP sudah working, dan sudah enggak ada problem gitu. Malahan dimunculkan dengan rewrite menjadi problem gitu. Atau terjadi perubahan yang awal monolitik, jadi yang kayak sekarang ya. Jadinya apa? Non-monolitik tau sih. Jadinya microservices. Jadi microservices, malahan dari microservices implementasinya susah. Misalnya implementasinya susah, terus harus ngajarin banyak hal. Nah, semua ini kan sebenarnya bisa diukur gitu. Kalau ketika mau melakukannya itu harus ada ya, kalau revamp itu bukan hanya sekedar RFC ya, itu malah sampai dokumen-dokumen banyak banget tuh. Dari dokumen DRM sampai macam-macam, sampai dia terimplementasi gitu kan. Dan tes dan lain-lainnya. Sedangkan refactoring sendiri, gimana sih untuk menghitungnya? Untuk mengkualifikasinya? Kalau pengalaman, untuk refactoring ini bisa aja ya. Kemarin kita sempat merefactoring ya. Jadi legasinya itu masih menyalah. Terus kita compare sama sistem bagian-bagian yang refactoring. Jadi gimana cara mengeliminasinya? Dibilang tadi ada dua sumber kode yang bisa dipakai. Jadi tetap diarahkan ke... Traffic itu diarahkan ke dua pihak. Yang satu yang refactor, satu enggak. Nah, terus pertanyaannya, ketika pertama kali mau refactoring, gimana menghitungnya? Nah, kalau selama ini, gue selalu akan mencoba meng-compare di luar sana ya, sebenarnya kalau orang melakukan dengan cara ini, berapa sih kenaikannya? Dengan cara ini berapa kenaikannya? Atau kalau enggak, kita bikin sebuah simulasi kecil ya, untuk melihat seberapa efeknya. Nah, dari sana nanti kita masukin ke dokumen, dokumen RFC dan lain-lainnya. Ini kita ngomong refactoringnya, refactoring agak gede ya. Bukan hanya mengganti legasi kode-legasi kode kecil. Kayak misalnya dashboardnya ini untuk bagian kayak misal Ari ya, mungkin dia mobile di bagian cellernya. Ini cellernya jadi lambat ngambil data dan lain-lainnya. Nah, ini kan bisa dibagi dari data sana, nanti tinggal dilihat apakah emang benar atau enggak gitu. Kalau sudah refactoring, ada baiknya jangan balik lagi ke belakang. Karena kebanyakan, aduh gagal gitu kan, padahal kita sudah berasumsi kalau refactoring ini harusnya hasil lebih baik gitu. Nah, harusnya dilakukan optimasi dari refactoring itu. Untuk mencapai target apa yang kita omongin. Jadi refactoring itu bukan karena ego ya. Karena gue melihat developer-developer sekarang ini, programmer sekarang ini, karena ego. Karena ngelihat, wah ini tuh ada hal baru nih, engine baru nih. Atau ini ada hal-hal baru gitu yang mau diimplementasikan. Tapi kalau refactoring biasanya enggak merubah kode ya, lebih ke arah optimasi. Namanya refactoring harusnya ada data. Contoh-contoh, perubahan algoritma dari, misalnya yang simple aja lah, dari bubble search ke misalnya binary search, itu kan beda jauh ya. Kan sudah melakukan analisa, gitu. Tidak langsung ujuk-ujuk, wah ini seru nih, naikin aja. Enggak, tapi kan sudah analisa. Oh ini pasti binary search ini harus lebih baik dari bubble search. Ya kenapa enggak kita implementasikan. Kalau ternyata hasilnya tidak sesuai sama ekspektasi, berarti ada yang salah ketika implementasinya. Dengan melihat dengan kompleksitas yang lain ya. Apakah dari database-nya, atau API-nya, atau semacamnya. Selama ini namanya refactoring, pasti harusnya lebih baik daripada sebelumnya.

Kalau misalnya terjadi kesalahan, berarti salah, analisa. Refame juga, harusnya begitu juga.

Refame harusnya menghasilkan suatu hal yang lebih baik, bukan malahnya mundur. Kalau mundur untuk apa di-refame? Nah, orang bisnis, kan karena orang bisnis enggak terlalu tahu tentang coding ya, mereka intinya adalah ini naik ya. Orang techs yang kayak kita ini yang harus bisa mensuplai data-data, mensuplai semuanya. Ini loh benar loh kondisinya. Makanya kemarin itu sebenarnya orang dev itu kalau misalnya dididik ngomong itu, ya tidak hanya ngomongin gue hanya bisa dev, untuk apa gue tau server? Ya tidak hanya tau server lah. Supaya tahu oh ini kondisinya karena, misalnya tau server atau tau hal lain. Ya benar, karena posisinya kalau cuma tau, gue cuma tau dev, yang lain sudah gue mau tutup mata, biarin aja itu diurusin oleh ini. Malahan itu salah. Karena komunikasi itu harus dua arah gitu. Kalau misalnya komunikasi cuma kita serahkan ke, ini gue cuma taunya ini, gue enggak peduli, gue enggak mau tau, ini urusan lo gitu. Itu yang jadi problem di lapangan gitu. Itu sih, jadi kalau misalnya balik lagi, karena ketika kita membuat sebuah pernyataan refactoring, kita sudah tahu apa yang akan kita lakukan. Sudah tahu, sudah menganalisa. Jadi bukan hanya karena ego, bukan hanya karena suka-suka aja, enggak. Tapi emang ada data yang harus dilakukan. Ada problem di lapangan yang harus diselesaikan gitu. Baru kita refactoring gitu. Kecuali emang gatel ya, kayak dididik ngomongnya. Ini harus normal, normal level 1, normal level 2, normal atas. Aduh, jangan sampai dilakukan juga. Kalau terlihat normal ya.

Itu benar-benar kayak buka neraka.

Oke, ini Mas Ibab sudah angkat tangan. Maaf, aku putus dulu ya, Mas Aditya. Lanjut, lanjut. Pak, ini kayaknya mau nanggepin. Silahkan panggil, Pak. Halo, thank you. Ini kedengeran enggak ya? Oke, oke. Maaf, tadi aku AFK sebentar terus balik lagi. Jadi gini, kalau permasalahan terkait kuantifikasi tadi ya, memang perlu ada leap of faith dari kita. Kita enggak akan bisa come up with 100% accurate estimate. It's always impossible, apalagi di software ya. Perlu ada leap of faith bahwa memang ini bakal mempercepat by sekian-sekian. Ada teknik-teknik kayak tadi yang dibilang, bahwa kita bisa pakai story points, atau kita lihat velocity average-nya gimana, apakah memang setelah kita transisi jadi velocity point, jadi capacity per sprint berapa, kita bakal estimate jadi berapa, karena sekian point itu habis untuk bug fixing misalnya. Ada cara-cara metodologi yang bisa kita pakai untuk mengestimatikannya, tergantung mana yang kita adopsi, mana yang kita praktekin. Tapi in the end, semuanya itu pasti leap of faith. Bahwa kita bilang kita bisa commit segini, dan benar tadi Mas Govrendi bahwa memang kita measure before after-nya gimana, dan kita harapin setelahnya itu memang ada improvement. Enggak harus berhasil, banyak effort refactoring itu sebenarnya enggak berhasil. Cuman yang perlu kita pegang adalah jangan sampai lebih buruk. Itu kenapa saya selalu tekenin kita harus kuantifikasi before after-nya buat tahu apakah yang kita lakukan itu enggak malah memperburuk situasi. Cuman ada satu yang aku tadi mau tanggapin juga, bahwa not necessarily bahwa refactoring itu ternyata enggak berhasil, kita move forward. Karena kalau memang gravity of the situation yang cukup besar, bisa saja kita rollback. Aku setiap kali misalnya ada major changes, yang aku tanyakan ke tim adalah, udah ada belum rollback path-nya atau rollback strategy-nya gimana? Misalnya, tadi kan di awal Mas Didit cerita soal feature flag, atau misalnya kita punya A-B testing framework internally, bisa saja refactoring-refactoring kita itu dideploy dengan feature flag, yang masih ada sistem lamanya yang bisa kita switch atau toggle over, kalau misalnya ada something yang disastrous ke sistem kita. Jadinya di sini kita jangan sampai terjebak di sunk cost fallacy, di mana kita ngerasa udah invest sekian minggu atau sekian bulan, ternyata enggak berhasil, kita perlu bisa objektif berdasarkan data yang ada, bilang, sorry ini perlu saya rollback. We made a bet, we made a leap of faith, ternyata enggak berhasil. Kita enggak ingin menyakiti user, misalnya jadi makin lambat atau gimana. Kita enggak ingin menyakiti user, karena as a programmer, as a tech people, yang harus ter-defend adalah kepentingan user. Kalau misalnya user tersakiti, malah ada pendingan refactoring kita, kita harus berani untuk rollback, dan kita investigate lagi, kita ambil lessons learned-nya gimana, jangan sampai kekurangan lagi ke depannya. Tapi ini selalu jadi opsi yang harus terbuka ya, teman-teman semua di sini, bahwa refactoring bisa saja enggak berhasil. It's always a bet, it's always a leap of faith, kita udah do all we can to estimate, but it might fail and that's okay, itu cara kita belajarkan. Dan itu cara kita juga bisa nge-argue ke sisi bisnis, kenapa ini penting, karena bet kita adalah ini bisa improve segala macam. Saya lupa ini Mas Didit atau Mas Govrendi yang sempat nge-tweet beberapa waktu lalu, kalau kita enggak bisa ngejelasin sesuatu ke anak SD, atau Mas Imre ya, kalau kita enggak bisa ngejelasin sesuatu ke anak SD, artinya kita belum cukup paham soal itu. Itu sama juga, kalau kita belum bisa meng-quantify, dan menjelasin, dan commit, atau make a leap of faith, bahwa refactoring kita bisa improve sekian-sekian, artinya kita sebenarnya belum cukup paham, atau belum cukup pede dengan refactoringnya, so consider that as a test juga, apakah memang worth it atau enggak kita kejar refactoring ini. Itu tambahan dari aku, silahkan. Tadi Mas Go bilang, kalau soal bagaimana kita tahu, kita enggak pernah tahu, dan tadi setuju dengan Mas Ibam soal, itu leap of faith. Totally agree. Leap of faith dengan resiko yang cukup gede sebenarnya. Sebenarnya itu. Resikonya adalah, enggak mau diomongin di sini. So, that one. Tapi bagaimana kita mengkontrol resiko tersebut? Nah, makanya kalau kita ngomongin refactoring, sesuatu yang skill-nya besar, saya saranku start small sih. Start very, very, very small. Untuk ngelakuin istilahnya kelakuan litmus test. Untuk memvalidasi. Jadi kalau istilah itu, kita sebelum refactor, kita lihat sistemnya, lalu oke, ini khusus buat yang gede ya, kita ngelakuin validasi. Apakah kita punya pendapat, opini, kita punya hipotesa itu, hipotesis ini, valid. Anggaplah tadi lebih cepat. Biasanya kalau kita mau ngereread the whole system, dari yang legacy gede ke yang baru, itu dipretelin lah ya. Ada pattern-nya, namanya find. Dan itu dipretelin keluar. Nah, ketika ngepretelin, jangan ngambil, anggaplah kalau saya kemarin, yang saya pretelin keluar pertama kali, bukan order. Karena order management luar biasa. Resikonya gede banget. Dan kalau enggak, resiko ke usernya gede. Yang saya rewrite pertama kali itu simple kok. Cuma kalau nggak salah, search. Jadi bagi itu saya keluarin dikit. Nah, ketika ngeluarin itu, ternyata effort-nya perlu ngelakuin. Jadi itu kelihatan, oke. Jadi buat ngeluarin satu ini, ternyata perlu banyak yang di-rewrite. Nah, habis itu re-estimate lagi. Oh, sekian. Jadi makin lama, makin baik timeline-nya. Kalau pertama sih dari langit aja. Waktu itu saya juga bilangnya 1,5 tahun. 18 bulan, that's it. Jadi memang harus berani kayak gitu. Cuman habis itu, scope-nya 18 bulan itu apa aja, nah itu baru dikeluarkan. Dan biar untuk mengurangi risiko, itu jangan ngambil yang paling, yang gede dulu, kita ambil yang small dulu, kemudian di-rewrite, di-check, apakah improve. Alhamdulillah waktu itu improve. Dari read yang lewat PHP, itu sekitar 500 milisecond, jadi cuma 10 milisecond karena saya re-write pakai golang. Jadi ini benar-benar pindah bahasa, tapi ada gain-nya. Jadi jangan cuma karena ego. Dan informasi ini jangan dipakai buat keluar, nanti kata Mas Judi, nanti dredag aja jadi kurang. Enggak, ada faktor-faktor lain yang bikin itu lebih cepat. Jadi mesti dikuantifikasi dan dicari. Scope yang paling kecil yang bisa dikerjain, kalau istilah saya, setiap kali ada proposal untuk ngerewrite, walaupun bahkan dari produk pun, apa yang bisa dilakukan dalam waktu tiga hari.

Three days.

One week sebenarnya itu. Jadi kata-kata three days itu, ini perlu dua minggu, too long. Jadi kalau sesuatu belum bisa dilakukan dalam tiga hari, it's something that you need to think about again buat ngerewrite satu bagian sistem itu. Untuk melakukan tiga hari itu, berarti ada prerequisite-nya. Ternyata perlu nambah flag, perlu nambah ini, perlu nambah itu. Kediscover semua tuh akhirnya. Yang dibuat pertama kali bukan software-nya, akhirnya monitoring-nya dulu, nge-setup feature flag-nya dulu. Jadi ketika reroute-nya udah mulai, tiga hari udah ada result-nya. Thank you.

Terima kasih. Silakan. Kayaknya komen terakhir aja kali ya. Soalnya gue mau jalan-jalan. Silakan. Gue nambah dikit ya.

Yang tadi kata Mas Ibrahim itu emang setuju ya. Pada dasarnya emang tidak semua namanya prepactoring atau revamp itu sukses, ataupun rewrite itu sukses. Memang ada. Dan tadi seperti yang pernah gue bilang, emang isolasi. Tadi kan diisolasikan dulu di dua lokasi untuk melihat efeknya. Dibilang yang saya juga bilang tadi. Jadi emang... Kalau dari saya sih intinya harus terdata. Bisa ada dokumennya. Apakah ini kemungkinan berhasilnya gede atau enggak. Kalaupun misalnya gagal, emang harus ada rollback yang harus dilakukan dan ready. Harus besar hati. Tapi harapannya enggak sampai segitu juga. Itu aja sih, Mas Ibrahim, kalau saya.

Terima kasih, Mas Etia. Ini ada Mas Muhammad Azam. Boleh dimasukin. Oke. Kita tunggu dulu. Di-connecting. Mas Azam, silakan. Langsung aja, Mas Azam.

Oh. Iya. Sorry, tadi tiba-tiba terputus. Masih ada waktu ini, Mas Imre? Atau udah mau jalan-jalan? Boleh, boleh. Terakhir, Mas. Terakhir. Oke, sebenarnya agak panjang, tapi mungkin saya ini aja ambil yang terakhir aja kali ya. Terkait dengan pertanyaan Mas GoFriendly tadi ya, yang 5, kita mengambil tadi nilai, misalkan dari tadinya 20 kali per minggu untuk deployment jadi 30. Angka 30 itu dari mana? Dan saya setuju dengan pernyataan Mas Ibrahim ya, bahwa kita ngelihatnya itu, ini sebagai sebuah hipotesis sebenarnya. Bahwa tentu untuk mendapatkan angka 30 itu kan sebetulnya estimasi. Dan estimasi itu sesuatu yang susah. Makanya tadi Mas Ari bilang bahwa kita harus, kalau story point gitu ya, mengawang-awang memang susah. Cuma kan tadi, seperti kata Mas Seth Yagus ya, bahwa kan kita paling nggak udah ngelihat dulu tadi, apakah ada bottleneck. Dan misalkan di proses deployment dalam kasus yang tadi dimention sama Mas GoFriendly gitu ya, itu kan kita bisa analisa dari step-step deploymentnya itu, kira-kira yang paling memakan waktu yang lama itu yang mana, kemudian kita lihat apakah ada problem di situ yang sekiranya bisa kita improve gitu. Tapi kan ini tetap estimasi juga jatuhnya gitu. Makanya ke mindset yang hipotesis ini, bahwa kita akan melakukan hipotesis, jika kita improve di bagian ini, di part ini, di step deployment ini, maka kita akan kemungkinan bisa mendapatkan peningkatan. Yang tadinya 20 jadi 30 kali. Dan karena ini sebuah hipotesis, ya betul juga tadi bahwa, mungkin gagal, tapi juga mungkin berhasil. Ya kan? Nah oke, dari sini mungkin masih sama dengan pernyataan Mas Ibrahim. Sebetulnya sebelum ke situ, kita harus tahu dulu nih, kan kita ingin meyakinkan ke stakeholder yang lebih tinggi, dalam tanda kutip gitu ya. Apakah memang dengan proses deployment yang sekarang, yang 20 kali per pekan, apakah itu suatu problem? Maksudnya suatu yang painful banget gitu loh, buat mereka gitu. Karena kalau enggak ya, sebetulnya kita enggak ada landasan kuat, untuk propose bahwa kita akan refactoring gitu, untuk meningkatkan proses deployment tadi. Tapi kalau memang itu suatu yang urgent, dari sudut pandang mereka, nah itu kita bisa maju gitu. Sebagai sedikit cerita juga, saya pernah mendapatkan klien, dan tugas saya hanya untuk refactoring, dan itu saya dikasih waktu sebulan full, untuk menganalisa itu, dan merefactor itu. Nah sebelum proses itu dimulai, karena ini datangnya dari orang klien saya gitu ya, jadi nyambung karena sebenarnya dia sudah merasakan ada pain di situ, bahwa kita harus ada improvement gitu, dengan kondisi yang sekarang, waktu itu kondisinya terkait dengan load performance. Jadi sudah sangat painful banget buat mereka, dan saya tanya ke klien saya, sebetulnya ide ini datang dari mana? Terus dia bilang ini dari orang bisnis. Oh iya, berarti artinya sudah yakin, bahwa dia sendiri sudah sadar ada sesuatu yang salah, dan sangat painful. Makanya dengan kondisi seperti itu, ya tadi saya jelaskan hipotesisnya, oke saya akan bantu analisa, apa yang mungkin menjadi masalah bottleneck-bottleneck yang mana, saya kasih waktu sekitar satu bulan, tapi ini adalah sebuah hipotesis. Refactor ini bisa berjalan, bisa juga gagal. Silakan Anda ambil risiko itu, apakah ingin menghabiskan waktu sebulan dengan risiko yang tadi saya berikan. Kalau memang oke, kemungkinan berhasilnya ada, kemungkinan gagal juga ada, mereka tahu risikonya, ambil lanjut, ya lanjut. Nah, itu sih yang pengalaman dari saya gitu. Untuk mencegah nantinya apakah sampai ke production, malah jadinya regression lebih buruk, sebetulnya kan kalau waktu itu akhirnya ya kita testnya, memang bisa di staging. Jadi di staging sudah tetap bisa kelihatan improvement-nya, dari yang kode sebelumnya dengan kode yang sudah di improve, kelihatan dan dilakukan secara incremental. Jadi oke, ini saya mengubah ini, ternyata berhasil, lanjut, lanjut, lanjut, lanjut, sampai akhirnya pada akhir dari fase itu, dan ya buktinya tetap sebulan diluangkan karena tadi ya, karena memang menyadari si klien yang tadi ada pain di situ. Ya, sorry, kepanjangan itu aja mungkin ya, saya enggak mau memperlama lagi. Terima kasih Mas Andre. Baik, terima kasih Mas Azam.

Jadi, terima kasih untuk teman-teman semua yang sudah berkomentar, kalau boleh gua amati dari diskusi kita adalah sebenarnya, kebanyakan dari kita pun sebenarnya masih mix antara refactoring dengan improvement dan optimasi sebenarnya, kalau menurut pandangan gua ya, dari yang gua amati. Karena kalau gua sendiri berpendapat, mungkin sama kayak yang dibilang Mas Didi tadi, bahwa sebenarnya refactoring itu adalah hal yang sebenarnya bisa kita lakukan terus-terus, dan sebenarnya itu bisa dicicil, daripada kita harus menghabiskan waktu relatif cukup lama, dan kita harus mikirin apakah kita bisa mengoptimalkan performa, dan matriks-matriks lain. Karena menurut gua, bisa jadi kalau kita ngomongin tentang improvement, untuk misalkan latency, itu sebenarnya bukan bagian dari refactoring, kalau pandangan gua. Tapi ya enggak apa-apa, tapi setidaknya yang gua lihat adalah dari semua diskusi itu, baik refactoring ataupun improvement tadi, sebenarnya yang paling penting adalah kita harus bisa memastikan bahwa semua effort itu atau semua changes itu tetap bisa diukur, tetap harus bisa satisfy apa yang udah kita punya sekarang, at least, dan kalau sandainya dapat performance improvement, alhamdulillah, tapi kalau enggak ya kita harus mikir lagi gimana caranya kita bisa mengimprove hal tersebut. Jadi kira-kira seperti itu. Kalau mau ditarik lagi sedikit ke belakang, sebelum kita melakukan itu semua, sebenarnya yang enggak kalah penting itu adalah kita harus punya CICD, monitoring, dan feature flag. Jadi itu aja teman-teman, mungkin teman-teman bisa explore setelah ini, kalau yang belum pernah dengar tentang feature flag itu apa, ada banyak strategi bisa pakai environment variable, bisa pakai feature flag di level runtime juga, dan segala macam. Ada CICD, kemudian ada monitoring, Prometheus, dan segala macam. Mungkin teman-teman bisa explore juga kalau sandainya ada yang masih belum tahu. Segitu aja, terima kasih untuk teman-teman semua yang udah berpendapat. Ada Mas Didit, Mas Goh, Mas Ari, Mas Ibam, Mas Azam, Mas Etia, Mbak Ama, dan tadi mungkin teman-teman yang udah leave juga. Terima kasih sekali lagi, sampai ketemu lagi di Twitter Space berikutnya. Terima kasih. Assalamualaikum warahmatullahi wabarakatuh.

Waalaikumsalam.