Dokumen ini berisi kumpulan prinsip, konsep, dan istilah penting yang wajib dipahami oleh setiap developer. Prinsip-prinsip ini akan membantu Anda menulis kode yang lebih baik, mudah dipelihara, dan profesional.
Jangan Ulangi Dirimu Sendiri
Prinsip ini mengajarkan untuk menghindari duplikasi kode. Setiap bagian pengetahuan atau logika harus memiliki satu representasi yang jelas dan otoritatif dalam sistem.
Mengapa penting?
- Mengurangi kesalahan saat update (cukup ubah di satu tempat)
- Mempermudah maintenance
- Menghemat waktu dan usaha
Contoh Buruk:
# Menghitung diskon untuk berbagai produk
harga_buku = 100000
diskon_buku = harga_buku * 0.1
harga_akhir_buku = harga_buku - diskon_buku
harga_pensil = 5000
diskon_pensil = harga_pensil * 0.1
harga_akhir_pensil = harga_pensil - diskon_pensilContoh Baik:
def hitung_diskon(harga, persentase_diskon=0.1):
return harga - (harga * persentase_diskon)
harga_akhir_buku = hitung_diskon(100000)
harga_akhir_pensil = hitung_diskon(5000)Buat Sesederhana Mungkin
Kompleksitas adalah musuh dari eksekusi. Selalu pilih solusi yang paling sederhana yang dapat menyelesaikan masalah.
Mengapa penting?
- Kode sederhana lebih mudah dipahami
- Lebih sedikit bug
- Lebih mudah di-debug dan di-maintain
Contoh Buruk:
// Mengecek apakah angka genap
function isEven(num) {
if (num === 0) return true;
else if (num === 1) return false;
else if (num < 0) return isEven(-num);
else return isEven(num - 2);
}Contoh Baik:
function isEven(num) {
return num % 2 === 0;
}Kamu Tidak Akan Membutuhkannya
Jangan tambahkan fungsionalitas sampai benar-benar diperlukan. Hindari over-engineering.
Mengapa penting?
- Menghemat waktu development
- Mengurangi kompleksitas yang tidak perlu
- Fokus pada fitur yang benar-benar dibutuhkan
Contoh: Jangan buat sistem authentication yang super canggih dengan 10 metode login berbeda jika aplikasi Anda hanya butuh login dengan email dan password.
Kumpulan 5 prinsip desain berorientasi objek yang membuat software lebih mudah dipahami, fleksibel, dan maintainable.
Setiap class harus memiliki satu dan hanya satu alasan untuk berubah.
Contoh Buruk:
class User {
void createUser() { /* ... */ }
void deleteUser() { /* ... */ }
void sendEmail() { /* ... */ }
void generateReport() { /* ... */ }
}Contoh Baik:
class User {
void createUser() { /* ... */ }
void deleteUser() { /* ... */ }
}
class EmailService {
void sendEmail() { /* ... */ }
}
class ReportGenerator {
void generateReport() { /* ... */ }
}Software entities harus terbuka untuk ekstensi, tapi tertutup untuk modifikasi.
Objek dari subclass harus bisa menggantikan objek dari superclass tanpa merusak fungsionalitas.
Client tidak boleh dipaksa bergantung pada interface yang tidak mereka gunakan.
Modul high-level tidak boleh bergantung pada modul low-level. Keduanya harus bergantung pada abstraksi.
Tinggalkan kode lebih bersih dari yang Anda temukan
Setiap kali Anda menyentuh kode, perbaiki sedikit demi sedikit. Refactor nama variabel yang buruk, pecah fungsi yang terlalu panjang, atau hapus kode yang tidak terpakai.
Prinsip Kejutan Minimal
Kode harus berperilaku sesuai dengan yang diharapkan. Jangan buat fungsi atau fitur yang mengejutkan pengguna atau developer lain.
Contoh Buruk:
def add_numbers(a, b):
return a * b # Nama fungsi menyesatkan!Pemisahan Kepentingan
Pisahkan program menjadi bagian-bagian yang berbeda, dimana setiap bagian menangani concern/kepentingan tertentu.
Contoh: Model-View-Controller (MVC) memisahkan:
- Model: Logika bisnis dan data
- View: Presentasi/tampilan
- Controller: Mengatur interaksi antara Model dan View
Gagal Cepat
Sistem harus segera melaporkan masalah sedekat mungkin dengan sumbernya. Jangan biarkan error tersembunyi.
def divide(a, b):
if b == 0:
raise ValueError("Cannot divide by zero") # Fail fast!
return a / bKonvensi di Atas Konfigurasi
Framework atau library harus menyediakan default yang masuk akal, sehingga developer hanya perlu mengkonfigurasi hal-hal yang berbeda dari standar.
Contoh: Ruby on Rails otomatis mencari model User di file app/models/user.rb
Komposisi di Atas Pewarisan
Lebih baik membuat objek dari kumpulan komponen kecil daripada membuat hierarki inheritance yang kompleks.
Hutang Teknis
Konsekuensi dari memilih solusi cepat/mudah sekarang dibanding solusi yang lebih baik yang membutuhkan waktu lebih lama. Seperti hutang finansial, technical debt menumpuk "bunga" berupa kerja ekstra di masa depan.
Bau Kode
Indikasi bahwa ada sesuatu yang mungkin salah dengan kode. Bukan bug, tapi tanda bahwa kode perlu di-refactor.
Contoh Code Smell:
- Fungsi terlalu panjang (>20 baris)
- Terlalu banyak parameter (>3-4)
- Komentar yang menjelaskan kode buruk
- Duplikasi kode
- God Class (class yang tahu/melakukan terlalu banyak)
Refaktorisasi
Proses restrukturisasi kode tanpa mengubah perilaku eksternalnya. Tujuannya membuat kode lebih bersih, readable, dan maintainable.
Produk Minimum yang Layak
Versi produk dengan fitur minimal yang cukup untuk memuaskan early adopters dan memberikan feedback untuk development selanjutnya.
Interface yang memungkinkan aplikasi berbeda untuk berkomunikasi satu sama lain. Seperti "kontrak" yang mendefinisikan bagaimana software components berinteraksi.
- CI (Continuous Integration): Praktik menggabungkan perubahan kode ke main branch sesering mungkin
- CD (Continuous Delivery/Deployment): Otomasi proses release software
Pengembangan Berbasis Test
Metodologi dimana Anda menulis test terlebih dahulu, baru kemudian menulis kode untuk membuat test tersebut pass.
Siklus TDD:
- Red: Tulis test yang fail
- Green: Tulis kode minimal untuk membuat test pass
- Refactor: Perbaiki kode tanpa merusak test
Agile: Metodologi pengembangan software iteratif dan incremental Scrum: Framework Agile dengan sprint, daily standup, dan retrospective
Sistem yang merekam perubahan file dari waktu ke waktu. Git adalah contoh paling populer.
- Monolithic: Aplikasi dibangun sebagai satu unit besar
- Microservices: Aplikasi dipecah menjadi services kecil yang independent
Optimasi Prematur
"Premature optimization is the root of all evil" - Donald Knuth
Jangan optimalkan performa sebelum Anda tahu dimana bottleneck-nya. Fokus dulu pada kode yang benar dan readable.
Cara mendeskripsikan kompleksitas waktu/ruang dari algoritma:
- O(1): Constant time
- O(log n): Logarithmic time
- O(n): Linear time
- O(n²): Quadratic time
Menyimpan hasil komputasi untuk digunakan kembali nanti, menghindari kalkulasi ulang yang mahal.
Prinsip Hak Akses Minimal
Berikan user atau proses hanya akses minimum yang diperlukan untuk menyelesaikan tugasnya.
Pertahanan Berlapis
Jangan andalkan satu layer security. Gunakan multiple layers untuk melindungi sistem.
Proses dimana developer lain memeriksa kode sebelum di-merge. Membantu menemukan bug, sharing knowledge, dan menjaga kualitas kode.
Kode yang baik adalah self-documenting, tapi dokumentasi tetap penting untuk:
- API documentation
- Setup instructions
- Architecture decisions
- Complex business logic
Gunakan nama yang deskriptif dan konsisten:
# Buruk
def calc(x, y):
return x * 0.1 + y
# Baik
def calculate_total_with_tax(price, tax_amount):
return price * 0.1 + tax_amountKomentar harus menjelaskan "mengapa", bukan "apa":
// Buruk: Menambah 1 ke counter
counter++;
// Baik: Increment counter untuk menghindari race condition
// saat multiple threads mengakses resource yang sama
counter++;Selalu handle error dengan graceful. Jangan biarkan aplikasi crash tanpa penjelasan.
try:
result = risky_operation()
except SpecificError as e:
log_error(e)
return default_valuePrinsip-prinsip ini bukan aturan kaku, melainkan panduan untuk membantu Anda menjadi developer yang lebih baik. Ingat:
- Konteks adalah raja - Tidak semua prinsip cocok untuk semua situasi
- Belajar terus menerus - Dunia tech selalu berkembang
- Praktik membuat sempurna - Terapkan prinsip-prinsip ini dalam proyek nyata
- Kolaborasi - Diskusikan dengan tim untuk best practices yang sesuai
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." - Martin Fowler
- Clean Code by Robert C. Martin
- The Pragmatic Programmer by David Thomas & Andrew Hunt
- Design Patterns: Elements of Reusable Object-Oriented Software
- Refactoring by Martin Fowler
- The Clean Coder by Robert C. Martin
Dokumen ini adalah living document yang akan terus diperbarui seiring perkembangan best practices dalam dunia software development.