Saat pertama kali belajar Flutter, hampir setiap error terasa seperti bencana kecil. Aplikasi crash, layar merah muncul, dan refleks pertama kita biasanya adalah copy paste error ke Google.

Masalahnya, kebiasaan ini sering membuat kita:

• Lompat ke StackOverflow tanpa paham konteks
• Menyalin solusi yang belum tentu relevan
• Menghabiskan waktu lebih lama dari yang seharusnya

Padahal, Flutter sebenarnya sangat komunikatif lewat error message-nya. Jika kita mau meluangkan waktu untuk membacanya dengan benar, sebagian besar masalah bisa diselesaikan tanpa Googling sama sekali.

Error Flutter Itu Bukan Musuh

Banyak developer menganggap error message sebagai sesuatu yang menakutkan. Padahal di Flutter, error message justru adalah petunjuk terbaik yang kita punya.

Flutter biasanya memberikan:

• Jenis error yang jelas
• Lokasi file dan baris kode
• Penjelasan kenapa error terjadi
• Bahkan saran perbaikannya

Masalahnya bukan pada error-nya, tapi pada cara kita membacanya.

Fokus ke Baris Paling Atas (Bukan yang Terpanjang)

Kesalahan paling umum saat melihat error Flutter adalah langsung scroll ke bawah.

Padahal:

• Baris paling atas biasanya berisi inti masalah
• Baris-baris setelahnya sering hanya stack trace

Contoh pola umum:

════════ Exception caught by widgets library ════════
The following assertion was thrown building MyWidget:

Kalimat setelah itu hampir selalu menjelaskan apa yang salah, bukan sekadar error acak.

Kenali Jenis Error yang Sering Muncul

Dengan sering membaca error, kamu akan mulai mengenali polanya.

Beberapa contoh:

• RenderFlex overflowed → Masalah layout (biasanya Row/Column)
• Null check operator used on a null value → Salah asumsi data tidak null
• setState() called after dispose() → Lifecycle widget bermasalah
• Looking up a deactivated widget's ancestor → Context dipakai di waktu yang salah

Begitu kamu mengenali pola ini, otakmu akan langsung tahu ke mana harus melihat.

Perhatikan File dan Line Number

Flutter hampir selalu memberi tahu:

lib/presentation/pages/home_page.dart:42

Ini bukan hiasan.

Tips penting:

• Buka file tersebut
• Fokus di baris yang disebutkan
• Jangan langsung menyalahkan widget lain

Sering kali bugnya bukan di widget besar, tapi di satu parameter kecil yang salah.

Baca Kalimat, Bukan Hanya Kata Kunci

Error Flutter sering ditulis dalam bahasa yang cukup manusiawi.

Contoh:

“A RenderFlex overflowed by 12 pixels on the right”

Ini bukan sekadar error ini informasi:

• Widget overflow
• Sebesar 12 pixel
• Di sisi kanan

Dari sini, kita sudah bisa menyimpulkan:

• Perlu Expanded, Flexible, atau Wrap
• Atau ukuran widget terlalu besar

Jangan Langsung Googling, Tapi Bertanya ke Diri Sendiri

Sebelum membuka browser, coba tanyakan:

• Widget apa yang sedang dirender?
• Data apa yang masuk ke widget ini?
• Apakah ada kemungkinan null?
• Apakah ini async issue?

Sering kali jawabannya sudah ada di kepala kita error hanya membantu menegaskannya.

Googling Tetap Perlu, Tapi Setelah Paham Masalahnya

Ini bukan berarti Googling itu buruk.

Yang salah adalah:

• Googling tanpa memahami error
• Menyalin solusi tanpa tahu alasannya

Yang benar:

• Baca error sampai paham inti masalah
• Gunakan Google untuk pendalaman, bukan sebagai tebak-tebakan

Dengan begitu, solusi yang kamu temukan akan jauh lebih relevan.

Skill Debugging = Skill Developer Profesional

Perbedaan developer pemula dan berpengalaman sering bukan di seberapa banyak framework yang dikuasai, tapi di cara menghadapi error.

Developer berpengalaman:

• Tenang saat melihat error
• Membaca, bukan panik
• Mengerti pola
• Jarang trial-and-error buta

Dan kabar baiknya: skill ini bisa dilatih, dimulai dari kebiasaan sederhana membaca error message dengan benar.

Debugging Aplikasi Flutter dengan Membaca Error Message (Bukan Asal Googling) was originally published in Udacoding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Saat pertama kali belajar Flutter, fokus saya adalah “UI jadi”.
Button bisa diklik, data tampil, halaman berpindah done.

Tapi setelah terlibat di project nyata dan melihat aplikasi production, saya sadar satu hal penting:

Aplikasi terasa profesional bukan karena fitur besar, tapi karena keputusan UI kecil yang konsisten.

Di artikel ini, saya ingin membagikan beberapa small UI decisions di Flutter yang sering dianggap sepele, tapi sangat berpengaruh pada kesan akhir aplikasi.

1. Konsistensi Padding dan Spacing

Ini kesalahan paling umum.

Padding(
  padding: EdgeInsets.all(16),
  child: ...
)

Lalu di halaman lain:

Padding(
  padding: EdgeInsets.symmetric(horizontal: 20),
  child: ...
)

Secara visual, user bisa merasakan ada yang “tidak rapi”, meskipun tidak tahu alasannya.

Praktik yang lebih profesional:

• Tentukan standar spacing: 8, 12, 16, 24
• Gunakan konstanta

class AppSpacing {
  static const double s = 8;
  static const double m = 16;
  static const double l = 24;
}

👉 UI terasa tenang dan konsisten

2. Memberi Feedback pada Setiap Interaksi

Button yang ditekan tapi tidak memberi respon visual terasa “mati”.

Hal kecil seperti:

• InkWell splash
• CircularProgressIndicator saat loading
• Disabled state saat proses berlangsung

ElevatedButton(
  onPressed: isLoading ? null : onSubmit,
  child: isLoading
      ? SizedBox(
          height: 16,
          width: 16,
          child: CircularProgressIndicator(strokeWidth: 2),
        )
      : Text("Simpan"),
)

👉 User merasa aplikasi responsif dan hidup

3. Typografi Lebih Penting dari yang Kamu Kira

Banyak aplikasi Flutter pemula:

• Semua teks Text() default
• Ukuran dan weight acak

Padahal, tipografi adalah fondasi UI.

Minimal yang sebaiknya konsisten:

• Heading
• Body
• Caption

ThemeData(
  textTheme: TextTheme(
    titleLarge: TextStyle(fontSize: 20, fontWeight: FontWeight.bold),
    bodyMedium: TextStyle(fontSize: 14),
    labelSmall: TextStyle(fontSize: 12, color: Colors.grey),
  ),
);

👉 Aplikasi langsung terasa lebih rapi dan “niat”

4. Jarak Antar Elemen Lebih Penting dari Banyak Warna

Pemula sering:

• Menambah warna
• Menambah garis
• Menambah card

Padahal seringkali cukup tambahkan jarak.

Column(
  crossAxisAlignment: CrossAxisAlignment.start,
  children: [
    Text("Nama Produk"),
    SizedBox(height: 4),
    Text("Rp 25.000"),
  ],
)

👉 UI terasa lega dan mudah dibaca

5. Empty State & Error State yang Manusiawi

Data kosong tanpa penjelasan = kesan aplikasi belum jadi.

Bandingkan:

❌ Halaman putih kosong
✅ Pesan sederhana:

“Belum ada data. Silakan tambah item baru.”

Center(
  child: Column(
    mainAxisAlignment: MainAxisAlignment.center,
    children: [
      Icon(Icons.inbox, size: 48, color: Colors.grey),
      SizedBox(height: 8),
      Text("Belum ada data"),
    ],
  ),
)

👉 Terlihat siap production, bukan sekadar demo

6. Animasi Kecil, Bukan Berlebihan

Profesional UI bukan tentang animasi heboh, tapi transisi halus.

Contoh:

• AnimatedContainer
• AnimatedOpacity
• AnimatedSwitcher

AnimatedOpacity(
  opacity: isVisible ? 1 : 0,
  duration: Duration(milliseconds: 200),
  child: ...
)

👉 Perubahan UI terasa alami dan halus

7. Status Bar dan Safe Area Tidak Dilupakan

Hal kecil tapi sering diabaikan:

• Konten ketabrak notch
• Status bar warna tidak cocok

Gunakan:

SafeArea(
  child: Scaffold(
    ...
  ),
);

Dan sesuaikan SystemUiOverlayStyle.

👉 Aplikasi terasa benar-benar diperhatikan

Penutup

Aplikasi Flutter yang profesional jarang terlihat mencolok.
Justru terasa:

• Tenang
• Konsisten
• Mudah digunakan
• Tidak membuat user berpikir

Dan semua itu sering datang dari keputusan UI kecil yang konsisten, bukan dari fitur besar.

Professional apps are built from small decisions done right.

Kalau kamu Flutter intern, junior, atau self-taught fokuslah pada detail-detail kecil ini.
Itu yang membedakan “app bisa jalan” dan “app siap dipakai user.”

Keputusan UI Kecil di Flutter yang Membuat Aplikasi Terasa Lebih Profesional was originally published in Udacoding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Jika kamu pernah mengerjakan aplikasi Flutter yang terhubung ke API, besar kemungkinan kamu pernah merasa frustrasi hanya karena model response.
Field terlalu banyak, struktur JSON berubah, null di mana-mana, dan error muncul entah dari mana.

Di artikel ini, saya ingin berbagi cara berpikir dan pendekatan praktis dalam merancang model response API di Flutter agar tetap rapi, aman, dan yang paling penting tidak bikin stres.

Masalah Klasik Saat Membuat Model API

Biasanya masalah muncul dari hal-hal berikut:

• Struktur JSON terlalu dalam (nested)
• Field opsional tapi diperlakukan wajib
• Backend berubah, frontend ikut rusak
• Satu model dipakai untuk semua kebutuhan
• Terlalu banyak logic di fromJson

Kalau kamu pernah menulis response.data['data']['attributes']['user']['profile'], kita senasib 😄

Prinsip Utama: Model Itu Representasi Data, Bukan Logic

Kesalahan paling umum adalah memasukkan terlalu banyak logic ke dalam model.

Model seharusnya:

• Merepresentasikan data
• Mudah diparse
• Mudah diuji
• Mudah diubah

Model bukan tempat untuk:

• Validasi kompleks
• Conditional logic bisnis
• Formatting UI

Pisahkan API Response dan Domain Model

Ini adalah perubahan mindset paling penting.

❌ Jangan:

class User {
  final String name;
  final String email;
}

langsung dipakai untuk response API dan UI.

✅ Lakukan:

• UserResponse → sesuai struktur API
• User → domain model untuk aplikasi

Contoh

class UserResponse {
  final String? name;
  final String? email;

  UserResponse({this.name, this.email});
  factory UserResponse.fromJson(Map<String, dynamic> json) {
    return UserResponse(
      name: json['name'],
      email: json['email'],
    );
  }
}

Lalu map ke domain model:

class User {
  final String name;
  final String email;

User({required this.name, required this.email});
  factory User.fromResponse(UserResponse response) {
    return User(
      name: response.name ?? '',
      email: response.email ?? '',
    );
  }
}

Dengan ini:

• API berubah → hanya Response yang terdampak
• UI tetap aman

Jangan Takut dengan Nullable

Banyak developer “takut” melihat String?, int?, dan akhirnya memaksa semuanya non-null.

Padahal API tidak pernah bisa dijamin 100% stabil.

Lebih baik:

• Terima kenyataan → API bisa null
• Tangani null di mapping layer
• UI hanya menerima data yang sudah aman

Gunakan freezed atau json_serializable (Kalau Sudah Siap)

Kalau project sudah mulai besar, menulis fromJson manual akan melelahkan.

Tools seperti:

• json_serializable
• freezed

akan sangat membantu:

• Mengurangi boilerplate
• Lebih konsisten
• Lebih aman saat refactor

Tapi ingat: tool bukan solusi desain yang buruk
Struktur tetap harus dipikirkan dengan baik.

Jangan Jadikan Satu Model untuk Semua Endpoint

Satu endpoint ≠ satu model universal.

Lebih baik:

• UserListResponse
• UserDetailResponse
• CreateUserResponse

Daripada:

• UserResponse super besar dengan 30 field opsional

Model kecil lebih:

• Mudah dipahami
• Mudah dirawat
• Lebih aman

Taruh Model di Tempat yang Tepat

Struktur folder juga berpengaruh ke kewarasan.

Contoh sederhana:

data/
 ├─ models/
 │   ├─ user_response.dart
 │   └─ post_response.dart
domain/
 ├─ entities/
 │   ├─ user.dart
 │   └─ post.dart

Dengan ini:

• Layer jelas
• Tidak bingung model mana untuk apa
• Lebih scalable

Penutup

Merancang model response API di Flutter bukan soal cepat selesai, tapi soal:

• Mudah dirawat
• Mudah diubah
• Tidak menyiksa diri sendiri di masa depan

Sedikit usaha di awal akan menghemat banyak waktu debugging di kemudian hari.

Kalau kamu merasa model API-mu sekarang “berantakan”, tenang kita semua pernah di sana.
Yang penting, pelan-pelan perbaiki cara berpikirnya. 💙

Merancang Model Response API di Flutter Tanpa Kehilangan Kewarasan was originally published in Udacoding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Saat pertama kali belajar Flutter, saya sering berpikir bahwa selama aplikasinya jalan, berarti kodenya sudah benar. Tapi semakin lama mengerjakan proyek nyata. Saya sadar bahwa pertanyaan yang jauh lebih penting bukan hanya “apakah ini bekerja?”, melainkan “apakah logic ini diletakkan di tempat yang tepat?”.

Menentukan di mana logic seharusnya hidup di aplikasi Flutter ternyata sangat berpengaruh terhadap keterbacaan kode, kemudahan maintenance, performa, dan scalability. Artikel ini adalah rangkuman cara berpikir saya sekarang dalam memutuskan hal tersebut.

Kesalahan Awal yang Pernah Saya Lakukan

Di awal, hampir semua logic saya taruh di dalam Widget.

onPressed: () {
  setState(() {
    isLoading = true;
  });

  final result = await api.getData();
  data = result;
}

Sekilas terlihat sederhana. Tapi ketika:

• logic makin panjang
• widget makin kompleks
• satu fitur dipakai di banyak halaman

Kode mulai terasa berantakan dan sulit dirawat.

Dari sini saya mulai belajar memisahkan tanggung jawab.

Prinsip Utama: Widget Hanya untuk UI

Sekarang saya memegang satu prinsip sederhana:

Widget seharusnya fokus pada tampilan dan interaksi UI, bukan logic bisnis.

Artinya:

• Widget boleh memanggil logic
• Widget tidak seharusnya menyimpan aturan bisnis

Jika saya merasa sebuah widget:

• terlalu panjang
• sulit dibaca
• banyak if-else dan proses data

Itu tanda logic-nya salah tempat.

Jenis Logic dan Tempat yang Tepat

1. Logic UI → Tetap di Widget

Logic ringan yang berkaitan langsung dengan UI masih wajar diletakkan di widget, seperti:

• toggle visibility
• animasi sederhana
• validasi tampilan

Contoh:

bool isPasswordVisible = false;

Logic ini tidak berdampak ke data atau bisnis, jadi aman.

2. State & Event Logic → Bloc / Cubit / Riverpod

Kalau logic mulai berkaitan dengan:

• fetch API
• loading state
• error handling
• transform data

Saya pindahkan ke state management.

Contoh di Cubit:

class UserCubit extends Cubit<UserState> {
  Future<void> fetchUser() async {
    emit(UserLoading());
    try {
      final user = await repository.getUser();
      emit(UserSuccess(user));
    } catch (e) {
      emit(UserError(e.toString()));
    }
  }
}

Widget jadi bersih:

context.read<UserCubit>().fetchUser();

3. Business Logic → Use Case / Service

Kalau logic sudah berupa aturan bisnis, misalnya:

• perhitungan harga
• validasi khusus
• keputusan berdasarkan role user

Saya pisahkan ke service atau use case.

Contoh:

class CalculateDiscount {
  double execute(double price, UserRole role) {
    if (role == UserRole.admin) {
      return price * 0.8;
    }
    return price;
  }
}

Dengan ini:

• logic bisa dites tanpa UI
• reusable
• tidak tergantung Flutter

4. Data Logic → Repository & Data Source

Untuk urusan:

• API
• database
• local storage

Saya selalu gunakan Repository Pattern.

abstract class UserRepository {
  Future<User> getUser();
}

Cubit/Bloc tidak peduli data datang dari mana API atau local.

Cara Saya Memutuskan Logic Harus Pindah

Saya biasanya bertanya pada diri sendiri:

• Apakah logic ini akan dipakai ulang?
• Apakah logic ini bisa dites tanpa UI?
• Apakah widget jadi terlalu “pintar”?
• Apakah perubahan logic akan memaksa saya mengubah banyak widget?

Jika jawabannya ya, maka logic itu harus keluar dari widget.

Dampak Positif yang Saya Rasakan

Setelah mulai disiplin soal ini:

• kode lebih rapi
• debugging lebih mudah
• perubahan fitur tidak merusak UI lain
• onboarding ke project jadi lebih cepat

Dan yang paling penting: saya lebih paham struktur aplikasi, bukan sekadar menulis widget.

Penutup

Menentukan di mana logic seharusnya hidup di Flutter bukan soal benar atau salah secara mutlak, tapi soal tanggung jawab dan kejelasan struktur.

Semakin cepat kita belajar memisahkan:

• UI
• state
• business logic
• data

Semakin siap kita menghadapi proyek Flutter di dunia nyata.

Kalau kamu juga pernah bingung soal ini, percayalah itu tanda kamu sedang naik level 🚀

Bagaimana Saya Menentukan di Mana Logic Seharusnya Diletakkan di Aplikasi Flutter was originally published in Udacoding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Refactor.
Satu kata yang terdengar “dewasa” di dunia software development, tapi jujur saja cukup menakutkan saat pertama kali saya melakukannya di aplikasi Flutter yang sudah berjalan.

Awalnya, aplikasi ini baik-baik saja. Tidak ada error fatal, fitur berjalan, dan user bisa menggunakannya. Tapi di balik layar, kodenya mulai terasa berantakan, sulit dibaca, dan makin susah dikembangkan. Di titik itulah saya sadar: refactor tidak bisa dihindari.

Kenapa Saya Memutuskan untuk Refactor?

Beberapa tanda bahaya yang saya rasakan:

• Satu file widget bisa ratusan baris
• Logic API bercampur dengan UI
• setState() ada di mana-mana
• Takut menyentuh kode karena takut rusak

Setiap kali ada request fitur baru, waktu pengerjaan terasa makin lama. Bukan karena fiturnya sulit, tapi karena kodenya tidak bersahabat.

Akhirnya, saya memutuskan: lebih baik capek sekarang daripada menderita selamanya.

Apa yang Salah Saat Refactor Pertama Kali

1. Terlalu Banyak Mengubah Sekaligus

Kesalahan terbesar saya adalah ingin merapikan semuanya sekaligus:

• Struktur folder
• State management
• Penamaan class
• Pemisahan logic

Hasilnya?
Saya sendiri bingung dengan perubahan yang saya buat.

Dari sini saya belajar:
👉 Refactor sebaiknya bertahap, bukan revolusi.

2. Tidak Paham Sepenuhnya Alur Aplikasi

Saya refactor sebelum benar-benar memahami:

• Alur data dari API ke UI
• Dependency antar file
• State mana yang dipakai di mana

Akibatnya, beberapa fitur sempat rusak dan saya harus rollback perubahan.

Pelajaran penting:
👉 Pahami dulu sebelum merapikan.

3. Kurang Percaya Diri dengan Perubahan Sendiri

Setelah refactor, saya sering berpikir:

“Ini bener nggak ya?”
“Kenapa jadi begini?”

Karena tidak ada testing otomatis, setiap perubahan terasa berisiko. Saya jadi sadar betapa pentingnya:

• Testing
• Atau minimal manual testing yang disiplin

Apa yang Justru Berhasil dan Membuat Refactor Layak Dilakukan

1. Memisahkan UI dan Logic

Langkah terbaik yang saya lakukan:

• UI fokus ke tampilan
• Logic pindah ke Cubit / Bloc / Provider
• API dipisah ke service

Hasilnya:

• Widget lebih pendek
• Kode lebih mudah dibaca
• Debugging lebih cepat

Ini adalah titik di mana Flutter saya mulai terasa “profesional”.

2. Membuat Widget Reusable

Dulu saya sering copy-paste widget yang mirip.
Setelah refactor, saya mulai membuat:

• Custom button
• Custom text field
• Reusable card

Selain kode lebih rapi, perubahan UI jadi jauh lebih cepat.

3. Struktur Folder Lebih Jelas

Saya mulai mengikuti pola:

• presentation
• logic / state
• data / service
• model

Tidak harus sempurna, tapi konsisten.
Dan itu sudah sangat membantu.

4. Aplikasi Jadi Lebih Mudah Dikembangkan

Ini bagian paling memuaskan.

Setelah refactor:

• Menambah fitur lebih cepat
• Bug lebih mudah dilacak
• Saya tidak lagi takut membuka file lama

Refactor memang tidak terlihat oleh user, tapi sangat terasa oleh developer.

Refactor Mengubah Cara Saya Melihat Kode

Sebelum refactor, kode hanyalah alat agar fitur jalan.
Setelah refactor, kode adalah:

• Dokumentasi
• Komunikasi antar developer
• Investasi jangka panjang

Saya belajar bahwa kode yang rapi bukan soal gaya, tapi soal tanggung jawab.

Penutup

Refactor pertama saya jauh dari sempurna. Banyak salah, banyak ragu, dan cukup melelahkan. Tapi justru dari situlah saya belajar paling banyak tentang Flutter dan software development secara nyata.

Jika kamu merasa aplikasimu “jalan tapi menyakitkan”, mungkin itu tanda bahwa sudah waktunya refactor pelan-pelan, satu bagian kecil dulu.

Karena refactor bukan tentang membuat kode terlihat keren, tapi membuat hidup developer lebih waras.

Pengalaman Pertama Saya Melakukan Refactor Aplikasi Flutter: Apa yang Gagal dan Apa yang Berhasil was originally published in Udacoding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Saat pertama kali belajar Flutter secara otodidak, saya merasa cukup percaya diri. Saya bisa membuat UI, menghubungkan API, dan menjalankan aplikasi tanpa error. Namun, semuanya berubah ketika saya mulai bergabung dengan sebuah software house dan mengerjakan real production project, bukan sekadar project latihan atau tutorial.

Di sinilah saya menyadari bahwa bisa jalan dan siap produksi adalah dua hal yang sangat berbeda.

1. Dari “Yang Penting Jadi” ke “Harus Bisa Dirawat”

Dulu, fokus saya hanyalah:

UI tampil, fitur jalan, selesai.

Di software house, cara berpikir ini langsung berubah. Kode tidak hanya harus berjalan hari ini, tapi juga:

• Mudah dipahami developer lain
• Mudah di-maintain
• Aman untuk diubah tanpa merusak fitur lain

Saya mulai terbiasa:

• Memberi penamaan variabel dan class yang jelas
• Menghindari logika berlebihan di dalam widget
• Menulis kode seolah-olah orang lain akan membacanya besok

Karena memang… orang lain benar-benar akan membacanya.

2. UI Bukan Lagi Segalanya

Sebagai pemula Flutter, saya sangat fokus pada UI:

• Padding rapi
• Animasi halus
• Layout responsif

Tapi di dunia kerja, UI hanyalah lapisan terluar. Yang lebih penting justru:

• Struktur project
• Alur data
• State management
• Error handling

Saya belajar memisahkan:

• UI layer
• Logic / state
• Service / API
• Model

Hasilnya? Kode terasa lebih bersih dan scalable.

3. Mulai Serius dengan State Management

Dulu, setState() terasa cukup untuk segalanya.
Sekarang? Tidak lagi.

Di software house, saya mulai memahami pentingnya:

• Predictable state
• Flow data yang jelas
• Kemudahan debugging

Saya belajar menggunakan:

• Cubit / Bloc
• Riverpod
• Pola loading, error, dan empty state

State management bukan lagi “ribet”, tapi justru penyelamat saat aplikasi mulai kompleks.

4. Lebih Sering Membaca Kode daripada Menulis Kode

Hal yang tidak saya duga:

Saya lebih banyak membaca kode orang lain daripada menulis kode sendiri.

Dari sini saya belajar:

• Coding style tim
• Best practice yang tidak ada di tutorial
• Cara menulis kode yang masuk akal untuk konteks bisnis

Saya juga mulai sadar pentingnya:

• Konsistensi
• Clean code
• Mengikuti standar project, bukan ego pribadi

5. Error Bukan Musuh, Tapi Bagian dari Proses

Dulu, error terasa menakutkan.
Sekarang, error adalah teman sehari-hari.

Saya jadi terbiasa:

• Membaca stack trace dengan tenang
• Mencari akar masalah, bukan hanya menutup error
• Memahami kenapa bug terjadi

Debugging bukan lagi panik, tapi proses belajar.

6. Kode Saya Sekarang Lebih “Tenang”

Jika dibandingkan dengan kode saya sebelum masuk software house:

• Lebih sedikit print()
• Lebih sedikit widget besar
• Lebih banyak reusable component
• Lebih banyak pemisahan tanggung jawab

Aplikasi terasa lebih stabil, dan saya pun lebih percaya diri saat melakukan perubahan.

Penutup

Masuk software house mengubah cara saya melihat Flutter bukan lagi sekadar alat untuk membuat UI, tapi sebagai alat membangun produk nyata yang dipakai banyak orang.

Perubahan gaya ngoding ini tidak terjadi dalam semalam. Ia tumbuh dari:

• Code review
• Bug production
• Diskusi dengan senior
• Kesalahan yang berulang

Dan menurut saya, itulah proses belajar yang sesungguhnya.

Bagaimana Gaya Ngoding Flutter Saya Berubah Setelah Masuk Software House was originally published in Udacoding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Saat pertama kali belajar Flutter, semuanya terasa rapi dan menyenangkan.
Tutorial demi tutorial mengajarkan cara membuat UI, mengatur state, memanggil API, dan menjalankan aplikasi tanpa error.

Namun, semua itu berubah ketika saya mulai mengerjakan project Flutter yang benar-benar dipakai oleh pengguna.

Di sinilah saya sadar:
tutorial hanya mengajarkan cara “membuat aplikasi berjalan”, bukan cara “bekerja di dunia nyata”.

Berikut beberapa hal penting tentang Flutter di project nyata yang tidak pernah saya temui di tutorial.

1. Kode yang Berjalan ≠ Kode yang Siap Digunakan di Tim

Di tutorial, selama aplikasi bisa dijalankan, maka dianggap selesai.
Di project nyata, kode Anda akan dibaca oleh orang lain.

Hal-hal seperti:

• penamaan file
• struktur folder
• konsistensi style
• pemisahan UI dan logic

menjadi jauh lebih penting daripada sekadar membuat aplikasi tampil.

Saya pernah membuat satu file Flutter dengan ratusan baris kode, dan itu “berjalan”.
Tapi ketika code review, saya sadar: kode seperti ini sulit dirawat dan berbahaya untuk jangka panjang.

2. UI Tidak Pernah Sepenuhnya Sesuai Figma

Di tutorial, desain biasanya sempurna.
Di dunia nyata:

• ukuran font berubah
• spacing tidak konsisten
• warna sedikit berbeda
• aset belum lengkap

Sebagai Flutter developer, kita sering harus:

• menyesuaikan desain tanpa merusak UX
• membuat keputusan kecil tanpa arahan jelas
• berdiskusi dengan designer atau PM

Saya belajar bahwa Flutter developer bukan hanya “penerjemah desain”, tapi juga problem solver UI.

3. State Management Itu Bukan Sekadar Pilihan Library

Di tutorial, sering muncul pertanyaan:

“Pakai Bloc, Cubit, atau Riverpod?”

Di project nyata, pertanyaannya berubah menjadi:

• Apakah state ini perlu disimpan lama?
• Siapa saja widget yang butuh state ini?
• Bagaimana dampaknya ke performa?
• Apakah mudah dites dan dirawat?

Saya belajar bahwa state management adalah tentang arsitektur dan kebiasaan tim, bukan sekadar trend.

4. Error Itu Datang dari Hal-Hal Kecil

Bukan error kompleks yang sering menghabiskan waktu, tapi:

• null value yang terlewat
• context digunakan di tempat yang salah
• async yang tidak ditunggu
• rebuild widget yang tidak perlu

Di tutorial, error jarang dibahas secara mendalam.
Di project nyata, debugging adalah skill utama.

Saya belajar membaca stack trace, memahami log, dan tidak panik saat aplikasi crash.

5. API Tidak Selalu Ramah

Tutorial biasanya menggunakan API yang:

• response-nya konsisten
• datanya selalu lengkap
• jarang error

Di dunia nyata:

• API bisa lambat
• response bisa berubah
• field bisa null tanpa pemberitahuan
• error message tidak jelas

Hal ini mengajarkan saya pentingnya:

• handling loading
• handling error
• handling empty state

UI yang baik bukan hanya saat data ada, tapi juga saat data tidak ada.

6. Komunikasi Sama Pentingnya dengan Koding

Ini yang paling jarang dibahas di tutorial.

Di project nyata, kita harus:

• menjelaskan kode ke senior
• bertanya dengan cara yang tepat
• menerima kritik dari code review
• mengakui jika belum paham

Saya belajar bahwa developer yang baik bukan yang paling jago, tapi yang paling bisa bekerja sama.

Penutup

Tutorial Flutter sangat membantu untuk memulai.
Namun, pengalaman mengerjakan project nyata adalah guru terbaik.

Dari sana saya belajar bahwa Flutter bukan hanya tentang widget dan state, tapi tentang:

• struktur
• konsistensi
• komunikasi
• dan tanggung jawab terhadap kode

Jika Anda merasa “tidak jago” saat pertama kali masuk project Flutter, itu normal.
Justru di situlah proses belajar yang sesungguhnya dimulai.

Hal-Hal Tentang Flutter di Dunia Nyata yang Tidak Pernah Diajarkan di Tutorial was originally published in Udacoding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Dalam ekosistem pengembangan perangkat lunak yang bergerak cepat, kita sering kali dihadapkan pada dilema klasik: kecepatan vs kualitas. Ketika tenggat waktu mendesak dan kita membutuhkan fitur yang sama di dua tempat berbeda, jalan pintas “Copy-Paste” sering menjadi godaan terbesar. Solusi ini cepat, instan, dan secara visual terlihat berfungsi.

Namun, pengalaman saya dalam menyelesaikan proyek E-Learning berbasis Laravel mengajarkan pelajaran berharga: jalan pintas ini pada akhirnya menciptakan “hutang teknis” (technical debt) yang bunganya harus dibayar mahal di masa depan.

Kompleksitas di Balik Layar

Kasus ini bermula dari pengembangan fitur Sidebar Navigasi. Sekilas, ini terlihat seperti komponen antarmuka biasa. Namun, di balik layar, sidebar ini adalah komponen yang padat logika bisnis (business logic). Ia tidak sekadar menampilkan menu statis, melainkan data personal yang dinamis:

1. Analisis Statistik: Sistem harus menghitung grafik progres belajar siswa dalam 30 hari terakhir.
2. Rekomendasi Mentor: Sistem harus melakukan query ke database untuk mencari guru yang tersedia.
3. Jejaring Sosial: Sistem harus memfilter daftar teman sekelas berdasarkan status langganan (Free vs Pro).

Awalnya, logika kompleks ini hanya hidup di Dashboard. Namun, seiring berkembangnya kebutuhan produk, fitur ini diminta hadir di setiap lini aplikasi: saat siswa membuka materi, saat mengerjakan kuis, hingga saat melihat riwayat nilai.

Jebakan Duplikasi dan Pelanggaran Prinsip DRY

Tanpa strategi arsitektur yang matang, saya melakukan kesalahan fatal: saya menduplikasi blok logika tersebut ke dalam empat Controller berbeda (

Dashboard, Materi, Kuis, Progres).

Saya melanggar prinsip fundamental rekayasa perangkat lunak: DRY (Don’t Repeat Yourself).

Dampaknya mulai terasa ketika terjadi perubahan kebutuhan bisnis. Manajemen meminta perubahan kecil pada algoritma perhitungan statistik. Apa yang seharusnya menjadi tugas ringan selama 5 menit berubah menjadi sesi “berburu kode” (code hunting) yang melelahkan. Saya harus:

1. Membuka empat file berbeda.
2. Mencari baris kode spesifik yang tersebar di ratusan baris lainnya.
3. Memastikan setiap perubahan identik.
4. Melakukan pengujian ulang di empat halaman berbeda.

Risiko human error meningkat drastis. Jika satu file terlewat, aplikasi menjadi tidak konsisten. Kode menjadi rapuh (fragile) dan sulit dirawat (unmaintainable).

Transformasi Arsitektur: Mengadopsi Traits

Saya menyadari bahwa pendekatan prosedural ini tidak lagi relevan. Saya membutuhkan solusi berorientasi objek yang elegan. Dalam PHP dan Laravel, solusi ini adalah Traits.

Berbeda dengan pewarisan kelas (inheritance) yang kaku secara vertikal, Traits menawarkan fleksibilitas penggunaan ulang kode secara horizontal (horizontal code reuse).

Saya menstandarisasi ulang kode saya dengan langkah-langkah berikut:

1. Ekstraksi Logika: Saya memindahkan seluruh logika perhitungan statistik, query mentor, dan filter teman dari Controller ke dalam satu unit terisolasi bernama HasSidebarData.
2. Sentralisasi: Unit ini menjadi “Satu Sumber Kebenaran” (Single Source of Truth). Jika ada pertanyaan tentang bagaimana data sidebar diproses, jawabannya hanya ada di satu file ini.
3. Implementasi Modular: Di Controller (Materi, Kuis, dll), saya menghapus ratusan baris kode duplikat dan menggantinya dengan satu baris deklarasi penggunaan Trait.

Dampak Jangka Panjang

Keputusan untuk melakukan refactoring ini bukan sekadar soal kerapian kosmetik, melainkan investasi strategis:

• Efisiensi Codebase: Saya berhasil memangkas redundansi secara signifikan. File Controller kini kembali ke fungsi utamanya: mengatur alur HTTP, bukan menampung logika bisnis yang berulang.
• Kecepatan Iterasi: Ketika ada ide fitur baru untuk sidebar, saya bisa mengimplementasikannya dalam hitungan detik untuk seluruh aplikasi, tanpa menyentuh file Controller satu per satu.
• Stabilitas Sistem: Potensi bug akibat ketidakkonsistenan kode duplikat hilang sepenuhnya.

Penutup

Pelajaran terpenting dari proses ini adalah bahwa “selesai” bukan berarti sekadar “berjalan”. Kode yang baik adalah kode yang siap untuk tumbuh dan berubah. Meninggalkan kebiasaan copy-paste dan beralih ke desain modular seperti Traits adalah langkah kecil bagi programmer, namun lompatan besar bagi siklus hidup aplikasi yang sehat.

Stop Copy-Paste Kode! Cara Menggunakan PHP Traits untuk Merapikan Controller Laravel was originally published in Udacoding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Saat pertama kali belajar Flutter, fokus saya hanya satu: aplikasi bisa jalan. Selama UI tampil dan fitur bekerja, rasanya sudah cukup. Namun ketika mulai magang di software house dan mengerjakan aplikasi yang dipakai banyak user, saya sadar satu hal penting: performa itu krusial.

Aplikasi yang lambat, sering rebuild, atau terasa “berat” akan langsung terasa oleh pengguna. Menariknya, banyak masalah performa Flutter sebenarnya bisa dicegah dengan kebiasaan-kebiasaan kecil. Di artikel ini, saya ingin berbagi beberapa tips sederhana yang saya pelajari sebagai Flutter intern.

1. Jangan Asal setState()

Sebagai pemula, setState() sering jadi senjata utama. Setiap ada perubahan data, langsung setState(). Masalahnya, setState() akan me-rebuild seluruh widget di dalam build().

Pelajaran yang saya dapat:

• Jangan taruh logika berat di dalam build()
• Gunakan setState() hanya saat benar-benar perlu
• Pisahkan widget kecil agar rebuild lebih terkontrol

Contohnya, jika hanya satu bagian UI yang berubah, jadikan bagian tersebut widget terpisah.

2. Biasakan Menggunakan const

Awalnya saya menganggap const hanya soal gaya penulisan. Ternyata, const punya dampak ke performa.

Widget yang menggunakan const:

• Tidak akan di-rebuild ulang
• Lebih hemat memori
• Lebih optimal untuk UI statis

Contoh sederhana:

const Text('Hello Flutter');

Kelihatannya sepele, tapi di aplikasi besar, kebiasaan ini sangat membantu.

3. Hindari Rebuild yang Tidak Perlu

Salah satu kesalahan saya dulu adalah menaruh terlalu banyak logika di dalam build().

Contoh yang perlu dihindari:

• Perhitungan data
• Pemanggilan fungsi berat
• Parsing atau mapping data

Solusinya:

• Pindahkan logika ke initState()
• Gunakan state management (Cubit, Bloc, Riverpod)
• Gunakan FutureBuilder atau StreamBuilder dengan bijak

4. Gunakan ListView.builder, Bukan ListView Biasa

Saat menampilkan list data, terutama data yang panjang, ini penting.

❌ Kurang optimal:

ListView(
  children: data.map((e) => ItemWidget(e)).toList(),
);

✅ Lebih optimal:

ListView.builder(
  itemCount: data.length,
  itemBuilder: (context, index) {
    return ItemWidget(data[index]);
  },
);

ListView.builder hanya merender item yang terlihat di layar, sehingga jauh lebih ringan.

5. Perhatikan Penggunaan Gambar

Gambar sering jadi penyebab aplikasi terasa berat.

Beberapa pelajaran yang saya dapat:

• Gunakan resolusi gambar sesuai kebutuhan
• Hindari gambar terlalu besar untuk icon kecil
• Jangan lupa placeholder dan errorWidget

Gambar yang tidak dioptimalkan bisa bikin scrolling patah-patah.

6. Jangan Takut Pakai State Management

Awalnya saya berpikir state management itu “ribet”. Tapi setelah aplikasi mulai membesar, saya sadar justru tanpa state management, performa dan struktur jadi berantakan.

State management membantu:

• Mengontrol rebuild
• Memisahkan UI dan logic
• Membuat aplikasi lebih scalable

Sebagai intern, saya mulai dari Cubit, lalu perlahan belajar Bloc dan Riverpod.

7. Aktifkan Performance Overlay

Flutter menyediakan tools bawaan untuk mengecek performa.

Gunakan:

MaterialApp(
  showPerformanceOverlay: true,
)

Dari sini saya belajar:

• Mana animasi yang terlalu berat
• Kapan UI mulai drop frame
• Bagian mana yang perlu dioptimasi

Penutup

Sebagai Flutter intern, saya belajar bahwa performa bukan soal trik rumit atau optimasi ekstrem. Justru, kebiasaan-kebiasaan kecil yang konsisten sangat berpengaruh:

• Widget lebih rapi
• Rebuild lebih terkontrol
• Aplikasi terasa lebih smooth

Flutter sudah sangat powerful. Tugas kita sebagai developer adalah menggunakan kekuatannya dengan bijak.

Kalau kamu juga masih intern atau baru belajar Flutter, tidak apa-apa membuat kesalahan. Yang penting, pelan-pelan belajar memperbaikinya 🚀

Meningkatkan Performa Aplikasi Flutter: Tips Kecil dari Seorang Intern was originally published in Udacoding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Debugging adalah bagian yang tidak terpisahkan dari kehidupan seorang Flutter developer. Tapi jujur saja di awal belajar Flutter, setiap kali aplikasi error, rasanya seperti dunia runtuh. Layar merah, log panjang, dan pesan error yang terlihat menakutkan sering kali bikin panik sebelum sempat berpikir jernih.

Seiring waktu (dan cukup banyak error), saya mulai menyadari satu hal penting: panik tidak pernah menyelesaikan error. Yang ada justru memperlambat proses debugging. Artikel ini saya tulis untuk berbagi bagaimana cara saya menghadapi error Flutter dengan lebih tenang dan sistematis.

1. Tarik Napas, Jangan Langsung Scroll Log

Ketika error muncul, refleks pertama saya dulu adalah langsung scroll log ke atas dan ke bawah tanpa arah. Hasilnya? Tambah bingung.

Sekarang, hal pertama yang saya lakukan adalah berhenti sejenak dan membaca error dari baris paling atas. Biasanya Flutter sudah memberikan hint yang cukup jelas tentang:

• Jenis error
• Lokasi file
• Baris kode yang bermasalah

Tenang dulu, error itu cuma pesan bukan hukuman.

2. Fokus ke Error Pertama, Bukan Efek Domino

Satu error Flutter sering memicu banyak error lanjutan. Kesalahan umum adalah mencoba memperbaiki semuanya sekaligus.

Saya belajar untuk:

• Fokus ke error pertama yang muncul
• Abaikan error turunan di bawahnya
• Perbaiki satu masalah inti terlebih dahulu

Sering kali, setelah satu error utama diperbaiki, error lainnya ikut hilang.

3. Baca Pesan Error Seperti Membaca Instruksi

Flutter termasuk framework yang “ramah” dalam urusan error message. Tapi hanya kalau kita benar-benar membacanya.

Contoh:

• setState() called after dispose()
• RenderFlex overflowed by XX pixels
• Null check operator used on a null value

Pesan-pesan ini sebenarnya sudah menjelaskan:

• Apa yang salah
• Kapan terjadinya
• Arah solusi yang mungkin

Saya mulai membiasakan diri membaca error kata per kata, bukan sekilas.

4. Cek Perubahan Terakhir yang Saya Lakukan

Kalau aplikasi error tiba-tiba, hampir selalu penyebabnya adalah:

kode terakhir yang saya ubah

Maka langkah standar saya:

• Ingat file apa yang terakhir diedit
• Fokus debugging di area itu
• Jika perlu, comment sementara kode tersebut

Ini jauh lebih efektif daripada mencari error ke seluruh project.

5. Gunakan print, log, dan Debugger Tanpa Rasa Bersalah

Dulu saya merasa print() itu “tidak profesional”. Sekarang? Itu salah satu senjata utama saya.

Beberapa kebiasaan yang membantu:

• print() untuk cek alur data
• log() untuk data yang lebih kompleks
• Breakpoint di IDE untuk melihat state secara real-time

Debugging bukan soal gaya, tapi soal menemukan masalah secepat mungkin.

6. Pahami Error yang Sering Muncul

Semakin lama menggunakan Flutter, saya mulai mengenali pola:

• Error async (Future, await)
• Error lifecycle widget
• Error null safety
• Error layout (overflow, constraint)

Daripada takut, saya mulai mencatat:

“Oh, error ini pernah muncul. Dulu solusinya begini.”

Pengalaman adalah debugger terbaik.

7. Google & Stack Overflow Itu Bagian dari Proses

Debugging bukan ujian hafalan. Tidak ada salahnya mencari error di Google, GitHub Issues, atau Stack Overflow.

Yang penting:

• Pahami solusinya
• Jangan sekadar copy-paste
• Tahu kenapa error itu bisa terjadi

Dengan begitu, error yang sama tidak akan membuat panik di kemudian hari.

8. Terima Fakta: Error Itu Normal

Ini mungkin poin paling penting.

Error bukan tanda kamu:

• Tidak pintar
• Tidak cocok jadi developer
• Gagal belajar Flutter

Error justru tanda kamu sedang benar-benar ngoding.

Semakin sering error, semakin cepat kamu belajar asal kamu menghadapinya dengan kepala dingin.

Penutup

Sekarang, setiap kali Flutter menampilkan layar merah, saya tidak lagi panik. Saya melihatnya sebagai:

“Oke, ada yang perlu dibereskan.”

Debugging bukan musuh, tapi bagian dari perjalanan menjadi Flutter developer yang lebih matang.

Kalau kamu sedang sering error dan merasa frustrasi — tenang. Kamu sedang berada di jalur yang benar.

Cara Saya Debug Error Flutter Tanpa Panik was originally published in Udacoding on Medium, where people are continuing the conversation by highlighting and responding to this story.