Lessons Learned

Dari Kode "Asal Jalan" ke Scalable App: Pelajaran dari 8+ Tahun sebagai Mobile Developer

29 September 2026ยท4 menit bacaยทMuchamad Buchori
CareerMobile DevelopmentFlutterEngineeringGrowthReact Native

Dari Kode "Asal Jalan" ke Scalable App: Pelajaran dari 8+ Tahun sebagai Mobile Developer

Dulu: Asal Jalan, Fitur Lengkap, Siap Rilis

Delapan tahun lalu, saat pertama kali membuat aplikasi secara profesional, mindset saya sederhana sekali: yang penting aplikasi bisa jalan, fitur lengkap, dan siap rilis ke store.

Dulu, Stack Overflow dan dokumentasi resmi adalah tempat bergantung utama, tanpa terlalu pusing memikirkan best practice. Fast forward ke hari ini, sudut pandang saya berubah total.

Sekarang, sebelum menulis kode, fokus utama saya adalah dampaknya ke pengguna: fitur ini harus benar-benar sesuai dengan hasil brainstorming bersama tim UI/UX agar rencana yang dibuat bisa memberikan impact yang tepat dan pengguna merasa terbantu. Dari sisi teknis pun sama, pertanyaannya adalah: "Bagaimana agar kode ini tetap mudah di-maintain dan punya struktur yang solid saat menjadi legacy nanti?".

Evolusi Mindset
8+ Tahun Perjalanan
โณ 2018 ยท Junior MindsetAsal Jalan
  1. 01Fokus fitur bisa di-klik & jalan di layar
  2. 02Copas solusi cepat dari Stack Overflow
  3. 03Testing ala kadarnya di 1 emulator
  4. 04Langsung build APK/IPA & rilis ke store ๐Ÿš€
โš ๏ธ Maintenance diabaikan, rentan crash di production
โœฆ Sekarang ยท Senior MindsetScalable & Impactful
  1. 01Pahami problem bisnis & kebutuhan user riil
  2. 02Brainstorming mendalam dengan UI/UX & Product
  3. 03Desain arsitektur modular & mudah di-maintain
  4. 04Siapkan skenario mitigasi & error fallback
โœจ Mudah dirawat tim, minim insiden, user-centric

Antusias Tapi Lupa Maintenance: Pelajaran dari Kode yang Berantakan

Di awal karier, rasa antusias karena berhasil membangun hybrid app sering kali membuat saya lupa pada satu hal yaitu kemudahan pemeliharaan (maintenance). Karena saat itu belum paham betul pentingnya struktur yang rapi, alhasil jadi berantakan.

Setiap class memiliki gaya penulisan yang berbeda-beda, sehingga begitu muncul bug, saya malah kebingungan sendiri mencari letak masalahnya dan proses refactoring pun jadi tidak terkontrol.

Puncaknya adalah saat ada bug yang lolos hingga ke lingkungan produksi. Paniknya bukan main, karena jujur saja saat itu saya belum menyiapkan langkah mitigasi jika terjadi masalah di live environment.

Anatomi Masalah: Dari Kode Berantakan ke Insiden
Cascade Effect
A

Gaya Koding Berbeda

Tiap class punya pattern berbeda tanpa kesepakatan tim

B

Tight Coupling

Perubahan di satu screen memicu kerusakan di screen lain

C

Bug Tembus ke Live

Edge case lolos hingga ke lingkungan produksi pengguna

D

Panik & Tanpa Mitigasi

Tidak ada fallback handling atau observability yang siap

๐Ÿ’ก

Pelajaran Kunci: Mitigasi bukan pelengkap, melainkan tanggung jawab developer sebelum kode dirilis ke tangan pengguna.

Ketika Aplikasi Makin Besar: Saatnya Benahi Arsitektur

Lama-kelamaan, seiring aplikasi bertambah besar, saya mulai merasa lelah secara teknis. Secara gambaran, aplikasi ini ibarat mobil yang tampilannya sangat sporty dari luar, tetapi saat kap mesinnya dibuka... kabel kelistrikannya berantakan dan tidak tersusun rapi.

Dampaknya, memperbaiki bug kecil saja membutuhkan waktu dan effort yang sangat tricky. Dari sana saya sadar bahwa situasi ini tidak bisa dibiarkan.

Setelah mendapat beberapa rekomendasi, saya mulai berbenah dan mempelajari arsitektur yang scalable, modular, serta maintainable. Tujuannya agar mempermudah seluruh anggota tim saat harus menangani bug atau menambah fitur baru, sekaligus memastikan standar kodingan seragam dan terdokumentasi dengan baik.

๐ŸŽ๏ธAnalogi: Tampilan Sporty vs Kap Mesin
System Architecture
Tampak Luar (Yang Dilihat User & Stakeholder)Tampak Keren & Cepat

Desain UI modern, transisi halus, fitur lengkap. Dari kacamata luar, aplikasi terlihat seperti mobil balap yang siap melaju.

โš ๏ธ Kap Mesin: Tanpa ArsitekturKusut (Spaghetti)
  • โœ•Kabel kelistrikan campur aduk (tightly coupled)
  • โœ•Fix bug kecil butuh bongkar setengah aplikasi
  • โœ•Developer baru butuh waktu lama untuk paham alur
โœฆ Kap Mesin: Scalable & ModularRapi & Terisolasi
  • โœ“Layer terpisah: Presentation โ†’ Domain โ†’ Data
  • โœ“Standar koding seragam & mudah di-refactor
  • โœ“Penambahan fitur baru cepat tanpa efek samping

Lebih dari Kode: Ketika Diskusi dan Kolaborasi Jadi Pekerjaan Utama

Setelah berhasil membenahi sisi teknis, apakah semuanya langsung selesai? Ternyata belum.

Saya baru menyadari bahwa porsi pekerjaan saya bukan lagi menulis kode seharian dan buat daily report. Ada proses lain yang memakan waktu lebih lama tetapi jauh lebih krusial, yaitu brainstorming bersama tim UI/UX dan Product.

Di tahap ini, kami tidak hanya membahas "Bagaimana cara membuat fiturnya?", melainkan "Apakah effort tim developer sebanding dengan dampak yang akan diterima user?". Jadi, sekarang saya jauh lebih selektif dan berhati-hati sebelum mengeksekusi sesuatu, demi meminimalisasi desain UI yang sia-sia atau user experience yang kurang nyaman.

โš–๏ธMatriks Keputusan: Effort Developer vs Impact User
Product Alignment
โšก Quick Wins (Prioritas Tinggi)High Impact ยท Low Effort

Perubahan UX sederhana yang langsung menghilangkan friction pengguna.

๐ŸŽฏ Investasi StrategisHigh Impact ยท High Effort

Core feature atau refactoring arsitektur demi skalabilitas jangka panjang.

โณ Nice-to-Have / BacklogLow Impact ยท Low Effort

Polesan minor yang dikerjakan saat ada sisa kapasitas sprint.

๐Ÿšซ Jebakan / Evaluasi UlangLow Impact ยท High Effort

Fitur kompleks yang jarang dipakai user โ€” wajib didiskusikan ulang bersama PM & Designer!

๐ŸŽจ UI/UX Design+๐Ÿ“Š Product Strategy+๐Ÿ“ฑ Mobile Engineering

Apa yang Saya Bawa dari Perjalanan 8+ Tahun Ini

Jika diringkas, ada beberapa pelajaran penting yang saya petik dari perjalanan 8+ tahun ini:

Aplikasi yang baik bukan cuma tentang kode yang jalan, tapi tentang kemudahan maintenance: Code yang bagus adalah yang mudah dibaca, dipahami, dan dikembangkan oleh anggota tim lainnya.

Proses di luar kodingan sama pentingnya dengan kodingan itu sendiri: Brainstorming, diskusi dengan tim UI/UX dan Product, serta pemahaman business logic sering kali menyelamatkan kita dari effort kodingan yang sia-sia.

Mitigasi adalah kunci di lingkungan produksi: Jangan menunggu bug muncul di produksi baru panik. Menyiapkan alur handling dan mitigasi sejak awal adalah bentuk tanggung jawab profesional.

Teknologi terus berubah, tapi problem-solving mindset itu abadi: Framework atau tool bisa berganti kapan saja, namun pola pikir kritis dan terstruktur dalam menyelesaikan masalah adalah aset utama seorang developer.

Penutup

Perjalanan 8+ tahun di dunia mobile development ini mengajarkan saya bahwa menjadi senior developer bukan sekadar tentang seberapa canggih code yang ditulis, melainkan seberapa besar impact yang diberikan, baik untuk pengguna aplikasi maupun untuk kemudahan tim dalam bekerja. Perjalanan ini tentu masih panjang dan selalu ada hal baru untuk dipelajari setiap harinya.

Terima kasih telah membaca cerita saya :)

P.S. Ini adalah artikel pertama yang saya publikasikan di blog ini. Senang rasanya bisa mulai berbagi dan mendokumentasikan refleksi perjalanan berkarier. Jika ada tanggapan, masukan, atau ingin sekadar bertukar cerita seputar mobile engineering, jangan ragu untuk berdiskusi!

Ditulis oleh Muchamad Buchori ยท Senior Mobile Engineer
Artikel lainnyaโ†’