Halo, sudah lama aku gak nulis, kepala rasanya bingung nih nyusun kalimat hahaha. Selain alasan perkara karir dan kehidupan, aku tuh nunda-nunda buat ngeblog karena kepengen fokus ke rewrite websiteku ini (sejujurnya sih nggak fokus juga). Yah, saat ini kalau kalian baca tulisan ini berarti website ini udah aku rewrite dan revamp. Semoga tulisan yang nggak bagus-bagus amat ini bisa lebih nyaman untuk dibaca. Sekian basa-basinya, mari kita mulai.

🤔 Apasih rewrite itu? dan kenapa harus direwrite?

Rewrite itu sebuah proses menulis ulang source code dari teknologi satu ke teknologi yang lain. Alasan rewrite itu ya macem-macem sih, diantaranya sebagai berikut:

• Teknologi yang dipake udah obsolete alias kelewat jadul, jadinya ngefek ke banyak hal. Misalnya performa, skalabilitas, keamanan, dan integrasinya ke aplikasi lain ngga sefleksibel dan sebagus teknologi baru. Bisa juga kompatibilitasnya udah berkurang sehingga device sekarang dan/atau library yang menunjang fungsionalitas aplikasinya udah nggak support lagi. Jadinya direwrite untuk meremajakan umur aplikasinya biar gampang dimaintain, juga meningkatkan performa maupun keamananya.

• Pindah platform, misalnya awalnya aplikasinya cuma ada di desktop, mungkin mau dipindah jadi web-based, atau ke mobile sehingga aplikasinya perlu ditulis ulang.

• Ada teknologi lain yang lebih canggih, dan lebih sesuai sama kebutuhan baik ke user ataupun secara bisnis.

• Fomo aja, biar keren.

Nah, website ini aku rewrite karena dia adalah sandbox aku buat i̶k̶u̶t̶a̶n̶ ̶f̶o̶m̶o̶ belajar dan bereksperimen. Jadi ya gak heran kalo website ini udah direwrite berkali-kali. Mulai dari yang dulunya cuma pakai web builder, terus nulis manual static pake HTML dan Tailwind, kemudian pake PHP, terus tiba-tiba NuxtJS, dan sekarang kalian lihat website ini dalam NextJS. Mungkin aku keliatan seperti orang baru keluar dari goa ya udah tahun 2024 tapi baru mulai belajar NextJS, gak pake belajar React dulu lagi (etapi dulu yang NuxtJS juga ga pake belajar Vue ding, jangan ditiru pls).

Tapi ya bukan berarti selama ini nggak belajar apa-apa, yang aku pelajari beberapa tahun belakangan justru malah teknologi yang "kurang beken dan masa kini *anjas" (e.g JPOS, Springboot, OtomaX) karena industri tempat aku kerja sebelumnya masih pake techstack oldschool semacam itu jadinya aku musti tetep relevan. Toh juga pulang kerja bablas kuliah, isi kepalanya juga udah penuh seputaran ilmu komunikasi. Pun demikian, tidak pernah ada kata terlambat buat belajar kok. Jadi ya kapapun waktunya mulai, gak ada yang salah *eak.

🫤 Gimana sih caranya dan rasanya rewrite?

Berdasarkan pengalaman pribadi aku, berikut adalah 3 langkah buat rewrite. NOMOR 4 BIKIN KAGET!!! *lah

1. Lakukan research sedetil dan selengkap mungkin 🔍

Pertama kamu harus tau seberapa butuh aplikasimu untuk direwrite, harus banget direwrite ngga? atau masih bisa ngga diupayakan dengan teknologi yang ada? Kalau cuma project pribadi sih mungkin bukan sesuatu yang penting buat dikonsiderasi, tapi kalau buat perusahaan rewrite itu sebuah project yang mahal. Kenapa? ya karena rewrite tuh makan waktu, dan waktu adalah uang. Sehingga, butuh latar belakang yang kuat untuk rewrite, supaya impact bagusnya ngga cuma terhadap user, tapi juga bagus kepada perusahaan.

Kedua, mau direwrite ke teknologi apa? dan kenapa pake yang itu? Ini penting, biar kita ngga "kesasar" ke penggunaan teknologi yang salah. Cari tau dan bandingin kelebihan dan kekurangan dari teknologi yang mau dipake selengkap mungkin, biar kita bisa tahu teknologi mana yang bisa menunjang kebutuhan kita dan sebisa mungkin biar dalam beberapa tahun kedepan ngga perlu rewrite-rewrite lagi.

Ketiga, breakdown fitur atau modul apa aja yang bakalan direwrite. Kalo aplikasimu mau direwrite semuanya, dan mumpung belum mulai, bedahlah sedalam-dalamnya. Dari fitur, sub-fitur, sedalam dan selengkap-lengkapnya sampe kalo bisa tombol atau printilan kecil-kecil tuh dipikirin. Ini jelas makan banyak waktu, tapi ini sangat worth it untuk dilakukan karena akan nolong kamu ketika nyusun timeline.

Aku pernah kurang detail dalam hal ini, akhirnya aku jadi kesiksa pas implementasi, beneran. Deadlinenya mepet tapi ternyata masih banyak banget printilan ngumpet yang baru ketauan pas dikerjain. Ini sangat menyita waktu dan biar kelar ontime mau gak mau harus lembur deh. Devil is always in the details.

Oh iya, dalam nyusun timeline ini kamu juga harus mastiin dulu. Kamu ngerjain rewrite ini udah ngerti belum sama teknologi baru yang dipake? Kalo kamu udah nyusun timeline tapi pas ngerjain kamu masih butuh waktu banyak buat belajar ya tetep akan berakhir lembur. Tapi kalo udah jago mah ezpz...

Yang jelas, dalam tahap perencanaan itu. Seyogyanya (*anjayy) memang disusun selengkap mungkin, karena berkaitan sama yang namanya komitmen. Rewrite tuh mirip kaya ngebelah hutan belantara guys. Akan ada masa dimana kita bakalan tersesat dan bingung mau lewat mana. Dengan perencanaan yang baik, potensi kesasar bisa diminimalisir dengan baik.

2. Lesgo!!! 🏃‍♂️💨

Di fase ini ya sebenernya tinggal ngoding ajasih. Nah tadi kan aku sempet mention tuh soal pemahaman sama teknologi yang dipake. Aku ketika rewrite website ini, posisinya tuh buta total sama ReactJS, tapi langsung lompat aja ke NextJS. Tentunya ini sangat challenging buat aku ya (red: mumet ndhasku Ya Allah) tapi justru menurutku letak serunya disitu guys. Secara nggak sengaja emang kebiasaan belajarnya tuh ya karena langsung nyemplung aja udah, kelelep dan lain sebagainya ya jadi bagian dari pembelajaran. Modalnya cuma dokumentasi, memanfaatkan AI, baca-baca forum, sama rekan sejawat yang bisa diganggu buat nanya-nanya.

Tapi, itu bukan cara yang bagus ya guys, tidak aku rekomendasikan.

Sebisanya sempatkan belajar dari fundamental dan dasarnya dulu, supaya kita tahu alasan kenapa kita nulis code tersebut. Kalo Reactnya udah jago, insyaallah belajar NextJSnya jadi gampang. Begitu juga kalo misal ngerjain pake Nuxt, kalau fundamental Vue nya udah kuat ya belajar Nuxt jadi gampang. Yang sering aku alami, ketika aku ga kuat secara fundamental, yang aku tulis ya cuma meniru pendekatan yang udah ada aja. Aku gatau tuh apa yang sebenernya aku lakukan dan apakah ada pendekatan lain yang lebih baik. Pas aku ngerjain rewrite ini sebenernya juga sampe dibela-belain begadang, menghabiskan waktu weekend buat ngoding, kerap kali migrain karena kurang tidur sampe beberapa temenku tuh nanya "Kamu kok segininya banget dik?" Ya selain karena komitmen yang harus dipegang teguh *asek, menurutku selama yang aku lakukan sampe "at all cost" ini bisa ngasih value ke aku berupa pengetahuan dan wawasan yang luas ya menurutku ini worth it dilakukan. Yang penting asal ngga sampe mati aja sih, kayanya kalo ngorbanin nyawa juga jatohnya kurang sepadan yah...

3. Udah deh 🛳️

Engga dong, masih ada yang perlu dilakuin juga setelah ngoding. Misalnya melewati proses Quality Assurance, ya unit testing lah ya regression testing lah atau sampe stress testing & penetration testing lah, lebih bagus kalau dilakuin orang lain (QA Engineer). Karena kalau kita sendiri yang ngetes, kadang kita udah tau seluk beluknya, tapi kalau orang lain biasanya ketemu tuh case-case aneh yang perlu dibenerin. Jadi sebelum barang baru ini nyampe ke user, udah bisa dipastiin aplikasi kita tuh bebas bug (seringnya sih nggak mungkin, tapi jadi lebih minimal aja), aman dan juga better secara kualitas entah itu performanya, atau UI UX nya, dsb.

Kalo udah QA Passed, terus udah? ya belum! Kan harus dideploy dulu ke Production Environment dan dirilis. Nah metode rilis itu juga macem-macem, ada yang dirilis parsial per fitur atau per modul, ada juga yang dirilis ya ketika aplikasinya udah bener-bener direwrite semua. Rilisnya ke siapa juga ada opsinya, mau langsung kerilis buat semua user, atau ke user-user tertentu.

Sebelum dideploy juga bisa ngelakuin code review dulu sama orang yang lebih senior atau sama peer, biar code kita bersih secara styling, efektif secara kompleksitas, lagi-lagi juga buat meminimalisir bug dan bisa jadi meningkatkan performa atau keamananya. Kalau soal metodenya ini baiknya udah dipikirin dari step satu ya guys, tentunya ya supaya pas eksekusi kita ngga kelimpungan sendiri.

Terus kalo udah rilis? selesai gitu? ya belum lah! go-to-marketnya? testimoni usernya? fitur selanjutnya? kwkwkw itu kerjaan Product Manager ding guys. Sebagai engineer ya setelah rilis kita standby, apakah ada incident atau bug yang dialami user, biar bisa kita fixing. Terus ya secara berkala dimaintain, entah itu dari techstack yang kita pake ada update versi, atau dari librarynya ada update, bisa dikonsider untuk diperbarui. Karena kalau kelamaan ngga diupdate, terus jadi deprecated, nanti rewrite lagi nangis...

•••

Nah demikianlah cerita pengalamanku terkait rewrite aplikasi ini, sebenernya journeynya bisa diceritain lebih panjang tapi aku u̶d̶a̶h̶ ̶c̶a̶p̶e̶k̶ ̶n̶u̶l̶i̶s̶n̶y̶a̶ takut kalian jadi capek bacanya (*oh gaslighting). Kalau mau yang lebih detil bisa ajak ngopi aja. Tlaktir aku ya soale aku lagi tanggal tua *eh.

Jadi gimana, tertarik buat rewrite? 😃