Membedah SOLID Principles di JavaScript Bikin Kode Kamu Anti Ribet
Pernah nggak sih kamu ngerasa coding itu kayak lagi bongkar pasang LEGO raksasa? Awalnya gampang, tapi makin gede, makin ribet, dan kalau salah cabut satu balok, yang lain ikutan ambruk? Nah, itu dia salah satu masalah klasik di dunia programming. Kode yang tadinya kelihatan bersih dan rapi, lama-lama jadi kusut kayak benang layangan. Debugging jadi PR banget, nambah fitur baru bikin deg-degan takut ngerusak yang udah ada, dan kolaborasi sama tim jadi lebih sering ngalamin konflik kode daripada ngopi bareng.
Di sinilah peran penting "SOLID Principles" muncul. Konsep ini bukan cuma sekadar teori keren buat ngisi buku pelajaran doang, tapi beneran pedoman praktis yang bisa bikin kode JavaScript kamu jadi lebih "anti ribet," gampang di-maintain, di-test, dan pastinya scalable. Intinya, SOLID itu kayak panduan desain arsitektur buat software kamu, biar pondasinya kuat dan bisa tumbuh gede tanpa gampang roboh. Yuk, kita bedah satu per satu, biar ngoding kamu makin lancar jaya!
S - Single Responsibility Principle (SRP): Setiap Modul, Satu Alasan Buat Berubah
Bayangin deh, kamu punya satu kantong ajaib yang isinya semua barang. Mau cari kunci mobil, harus ngubek-ubek sampai ketemu pulpen, lipstik, power bank, struk belanja, dan entah apa lagi. Ribet, kan? Nah, di coding, itu namanya modul atau fungsi yang punya terlalu banyak tanggung jawab.
SRP bilang gini: Setiap kelas, modul, atau fungsi itu harus punya SATU dan hanya SATU alasan untuk berubah. Artinya, dia cuma ngurusin satu tugas doang. Kalau suatu hari ada perubahan di kode, cuma ada satu alasan spesifik kenapa kamu perlu ngutak-ngatik bagian itu.
Kenapa Penting di JavaScript?
JavaScript, dengan sifatnya yang fleksibel, seringkali bikin developer tergoda buat bikin fungsi "omnibus" yang ngerjain macem-macem. Contohnya, satu fungsi buat ngambil data dari API, terus langsung validasi data itu, abis itu nge-render ke DOM, dan sekaligus nyimpen ke local storage. Nah, kalau validasi berubah, kamu harus buka fungsi itu. Kalau cara nyimpen ke local storage berubah, buka lagi fungsi itu. Kalau struktur data API berubah, buka lagi. Kebayang kan ribetnya?
Contoh Gampangnya:
Kode yang Kurang SRP (Anti Anti-Ribet):
javascript
class UserProcessor {
constructor(apiUrl) {
this.apiUrl = apiUrl;
}async processAndDisplayUser(userId) {
// 1. Fetch data
const response = await fetch(${this.apiUrl}/users/${userId});
const userData = await response.json();// 2. Validate data
if (!userData || !userData.name || !userData.email) {
console.error("Invalid user data received.");
return;
}// 3. Save to local storage
localStorage.setItem(user_${userId}, JSON.stringify(userData));// 4. Display on UI
const userElement = document.getElementById('user-info');
if (userElement) {
userElement.innerHTML =
${userData.name}
Email: ${userData.email}
ID: ${userData.id}
;
}
}
}Fungsi processAndDisplayUser ini punya empat tanggung jawab sekaligus.
Kode yang Lebih SRP (Bikin Kode Anti Ribet):
javascript
// 1. Tanggung jawab Fetching Data
class UserApi {
constructor(baseUrl) {
this.baseUrl = baseUrl;
}async fetchUser(userId) {
const response = await fetch(${this.baseUrl}/users/${userId});
if (!response.ok) {
throw new Error(HTTP error! status: ${response.status});
}
return response.json();
}
}// 2. Tanggung jawab Validasi Data
class UserValidator {
static isValidUser(userData) {
return userData && userData.name && userData.email && userData.id;
}
}// 3. Tanggung jawab Penyimpanan Data (e.g., Local Storage)
class UserStorage {
static saveUser(userId, userData) {
localStorage.setItem(user_${userId}, JSON.stringify(userData));
}static getUser(userId) {
const data = localStorage.getItem(user_${userId});
return data ? JSON.parse(data) : null;
}
}// 4. Tanggung jawab Rendering UI
class UserView {
static renderUser(userData, targetElementId) {
const userElement = document.getElementById(targetElementId);
if (userElement && userData) {
userElement.innerHTML =
${userData.name}
Email: ${userData.email}
ID: ${userData.id}
;
}
}
}// Orchestrator (koordinator, yang menggabungkan fungsi-fungsi)
class UserWorkflow {
constructor(api, validator, storage, view) {
this.api = api;
this.validator = validator;
this.storage = storage;
this.view = view;
}async execute(userId, targetElementId) {
try {
const userData = await this.api.fetchUser(userId);if (!this.validator.isValidUser(userData)) {
console.error("Invalid user data received.");
return;
}this.storage.saveUser(userId, userData);
this.view.renderUser(userData, targetElementId);
console.log(User ${userId} processed and displayed successfully.);
} catch (error) {
console.error("Failed to process user:", error);
}
}
}// Penggunaan:
const userApi = new UserApi('https://api.example.com');
const userValidator = UserValidator; // Static class
const userStorage = UserStorage; // Static class
const userView = UserView; // Static classDengan SRP, setiap bagian kode punya tujuan yang jelas. Kalau ada perubahan di API, cuma UserApi yang diutak-atik. Kalau validasi nambah, cuma UserValidator yang disentuh. Lebih bersih, lebih gampang dites, dan kalau ada bug, kamu tahu persis di mana harus nyari.
O - Open/Closed Principle (OCP): Buka Buat Diperluas, Tutup Buat Dimodifikasi
Prinsip ini intinya gini: Modul software (kelas, fungsi, atau komponen) seharusnya terbuka untuk diperluas, tapi tertutup untuk dimodifikasi. Maksudnya gimana? Kalau kamu mau nambah fitur baru atau mengubah perilaku, kamu seharusnya bisa melakukannya dengan menambahkan kode baru, bukan dengan mengubah kode yang sudah ada dan sudah bekerja.
Kenapa Penting di JavaScript?
Di JavaScript, yang seringkali bikin kode jadi "anti ribet" adalah kalau setiap ada requirement baru, kita harus ngubah logic di fungsi atau class yang udah ada. Ini rawan bug dan bikin testing jadi lebih kompleks karena setiap perubahan bisa merembet kemana-mana. OCP mendorong penggunaan abstraksi dan polimorfisme.
Contoh Gampangnya:
Bayangin kamu punya sistem diskon untuk e-commerce. Awalnya cuma ada diskon reguler. Terus muncul kebutuhan diskon premium, diskon hari raya, dll.
Kode yang Kurang OCP (Anti Anti-Ribet):
javascript
class PriceCalculator {
calculateTotalPrice(itemPrice, quantity, discountType) {
let finalPrice = itemPrice * quantity;if (discountType === 'regular') {
finalPrice -= finalPrice * 0.10; // 10% diskon
} else if (discountType === 'premium') {
finalPrice -= finalPrice * 0.20; // 20% diskon
} else if (discountType === 'holiday') {
finalPrice -= 50; // Diskon flat 50
}
// Kalau ada tipe diskon baru, fungsi ini harus di-edit terus
return finalPrice;
}
}Setiap nambah tipe diskon baru, kamu harus nambah else if di dalam fungsi calculateTotalPrice. Ini melanggar OCP.
Kode yang Lebih OCP (Bikin Kode Anti Ribet):
javascript
// Interface/Abstraksi Diskon
class Discount {
apply(price) {
throw new Error("Method 'apply()' must be implemented.");
}
}// Implementasi Diskon
class RegularDiscount extends Discount {
apply(price) {
return price * 0.10;
}
}class PremiumDiscount extends Discount {
apply(price) {
return price * 0.20;
}
}class HolidayDiscount extends Discount {
apply(price) {
return 50; // Diskon flat
}
}// Kelas yang menggunakan Abstraksi Diskon
class PriceCalculatorOCP {
calculateTotalPrice(itemPrice, quantity, discountStrategy) {
let finalPrice = itemPrice * quantity;
finalPrice -= discountStrategy.apply(finalPrice);
return finalPrice;
}
}// Penggunaan:
const calculatorOCP = new PriceCalculatorOCP();// Tambah diskon baru? Tinggal bikin class baru, tanpa ubah PriceCalculatorOCP!
const regularDisc = new RegularDiscount();
const premiumDisc = new PremiumDiscount();
const holidayDisc = new HolidayDiscount();Dengan OCP, kalau ada diskon baru (misalnya StudentDiscount), kamu tinggal bikin class StudentDiscount baru yang mengimplementasikan Discount dan nggak perlu ngotak-ngatik PriceCalculatorOCP sama sekali. Ini bikin kode kamu super fleksibel dan gampang di-extend.
L - Liskov Substitution Principle (LSP): Objek Turunan Bisa Gantiin Objek Induk
Prinsip ini bilang: "Objek-objek dalam sebuah program harus bisa digantikan dengan instance dari sub-tipe mereka tanpa mengubah kebenaran program tersebut." Simpelnya, kalau kamu punya class A, dan class B itu turunan dari class A, maka kamu bisa pake objek B di mana pun kamu biasa pake objek A tanpa bikin program jadi error atau ngasih hasil yang aneh.
Kenapa Penting di JavaScript?
Di JavaScript, yang punya prototypal inheritance, LSP ini penting banget biar pewarisan (inheritance) itu bener-bener meaningful. Kalau kamu bikin class turunan yang perilakunya beda banget dari class induknya dan bikin kode yang pakai class induk jadi rusak, itu berarti kamu melanggar LSP. Ini bisa bikin kode jadi susah diprediksi dan memicu bug aneh.
Contoh Gampangnya:
Bayangkan kamu punya class Bird dan class Ostrich yang merupakan turunan dari Bird.
Kode yang Kurang LSP (Anti Anti-Ribet):
javascript
class Bird {
fly() {
console.log("Burung terbang.");
}
layEggs() {
console.log("Burung bertelur.");
}
}class Ostrich extends Bird {
// Masalah: Burung unta nggak bisa terbang, tapi dia turunan dari Bird yang punya method fly()
fly() {
throw new Error("Burung unta tidak bisa terbang!");
}
}function makeBirdFly(bird) {
bird.fly();
}const eagle = new Bird();
const ostrich = new Ostrich();Di sini, Ostrich melanggar LSP karena dia nggak bisa menggantikan Bird sepenuhnya saat dipanggil method fly(). Ini bikin makeBirdFly jadi nggak reliable.
Kode yang Lebih LSP (Bikin Kode Anti Ribet):
Untuk memenuhi LSP, kita harus mendesain hierarki class agar sub-tipe tidak mengubah ekspektasi perilaku super-tipe.
javascript
// Abstraksi yang lebih tepat
class Bird {
layEggs() {
console.log("Burung bertelur.");
}
}class FlyingBird extends Bird {
fly() {
console.log("Burung terbang.");
}
}class NonFlyingBird extends Bird {
// Method ini tidak ada di class induk, tapi tidak masalah
// karena NonFlyingBird memang tidak diharapkan terbang.
walk() {
console.log("Burung berjalan.");
}
}// Contoh implementasi
class Eagle extends FlyingBird {
// ... specific Eagle behavior
}class Penguin extends NonFlyingBird {
swim() {
console.log("Penguin berenang.");
}
}function makeBirdLayEggs(bird) {
bird.layEggs();
}function makeFlyingBirdFly(bird) {
if (bird instanceof FlyingBird) { // Atau lebih baik, buat fungsi yang memang menerima FlyingBird saja
bird.fly();
} else {
console.log("Burung ini tidak bisa terbang.");
}
}const eagle = new Eagle();
const penguin = new Penguin();makeBirdLayEggs(eagle);
makeBirdLayEggs(penguin);makeFlyingBirdFly(eagle);
makeFlyingBirdFly(penguin); // Ini akan mencetak "Burung ini tidak bisa terbang." tapi tidak error,
// karena kita sudah mendesain dengan lebih baik.// Atau, jika fungsi memang hanya untuk burung terbang:
function ensureFlyingBirdFlies(bird) {
// Asumsi di sini bahwa 'bird' pasti adalah FlyingBird atau turunannya
bird.fly();
}const trueEagle = new Eagle();
// const truePenguin = new Penguin(); // Ini tidak bisa masuk ke ensureFlyingBirdFlies tanpa bikin error logisDengan mendesain class Bird agar tidak semua burung harus bisa terbang, kita bisa membuat FlyingBird dan NonFlyingBird sebagai sub-tipe yang lebih spesifik. Ini menjaga konsistensi perilaku dan memastikan LSP terpenuhi. Intinya, kalau sebuah fungsi mengharapkan objek dari tipe tertentu, objek dari sub-tipe-nya juga harus bisa masuk tanpa masalah.
I - Interface Segregation Principle (ISP): Klien Nggak Perlu Tau yang Nggak Dia Pake
ISP bilang: "Klien tidak boleh dipaksa untuk bergantung pada antarmuka yang tidak mereka gunakan." Meskipun JavaScript nggak punya "interface" formal kayak di Java atau TypeScript, prinsip ini tetap sangat relevan. Di JS, "interface" bisa diartikan sebagai kumpulan properti atau method yang diekspektasikan oleh suatu fungsi atau class dari objek lain.
Kenapa Penting di JavaScript?
Masalah "fat interfaces" sering muncul saat kita bikin objek atau fungsi yang punya terlalu banyak method/parameter, padahal nggak semua method/parameter itu dipakai oleh semua "klien" (fungsi lain yang menggunakannya). Ini bikin kode jadi "anti ribet" karena:
- Meningkatkan ketergantungan: Klien jadi bergantung pada hal-hal yang tidak mereka butuhkan.
- Membuat kode jadi kurang fleksibel: Sulit untuk mengganti implementasi karena harus menyediakan semua method, bahkan yang tidak terpakai.
- Susah dibaca dan dipahami: Terlalu banyak pilihan atau parameter yang nggak relevan.
Contoh Gampangnya:
Bayangkan kamu punya sebuah objek MegaPrinter yang bisa melakukan banyak hal: cetak, scan, fax, dan bahkan kirim email.
Kode yang Kurang ISP (Anti Anti-Ribet):
javascript
class MegaPrinter {
printDocument(doc) { console.log(Mencetak: ${doc}); }
scanDocument(doc) { console.log(Memindai: ${doc}); }
faxDocument(doc) { console.log(Mengirim fax: ${doc}); }
sendEmail(to, subject, body) { console.log(Mengirim email ke ${to}: ${subject}); }
}// Klien ini hanya butuh fitur cetak
function printJob(printer, document) {
printer.printDocument(document);
// Padahal printer punya scan, fax, email, tapi kita nggak pakai
}printJob hanya butuh method printDocument, tapi dia dipaksa untuk bergantung pada objek MegaPrinter yang punya banyak method lain yang nggak dia pakai.
Kode yang Lebih ISP (Bikin Kode Anti Ribet):
Daripada satu objek raksasa, kita bisa bikin objek-objek kecil yang lebih fokus pada satu "antarmuka" spesifik.
javascript
class Printer {
printDocument(doc) {
console.log(Mencetak: ${doc});
}
}class Scanner {
scanDocument(doc) {
console.log(Memindai: ${doc});
}
}class FaxMachine {
faxDocument(doc) {
console.log(Mengirim fax: ${doc});
}
}class EmailSender {
sendEmail(to, subject, body) {
console.log(Mengirim email ke ${to}: ${subject});
}
}// Fungsi kini hanya bergantung pada apa yang dia butuhkan
function printJob(printer) {
// Fungsi ini "mengharapkan" objek yang punya method printDocument
// Dia nggak peduli apakah objek itu juga bisa scan atau fax
return (document) => printer.printDocument(document);
}function scanJob(scanner) {
return (document) => scanner.scanDocument(document);
}const myPrinter = new Printer();
const myScanner = new Scanner();const doPrint = printJob(myPrinter);
const doScan = scanJob(myScanner);Dengan ISP, fungsi printJob hanya menerima objek yang punya kemampuan printDocument. Dia nggak perlu tahu ada kemampuan scan, fax, atau email. Ini bikin kode lebih modular, lebih mudah diuji, dan lebih gampang diubah. Kamu bisa ganti implementasi Printer kapan pun tanpa memengaruhi Scanner atau FaxMachine, karena mereka adalah entitas yang terpisah.
D - Dependency Inversion Principle (DIP): Bergantung pada Abstraksi, Bukan Detail
Prinsip ini seringkali paling susah dipahami, tapi paling powerful buat bikin kode JavaScript kamu "anti ribet" dan super fleksibel. DIP punya dua bagian:
- Modul tingkat tinggi (high-level modules) tidak boleh bergantung pada modul tingkat rendah (low-level modules). Keduanya harus bergantung pada abstraksi.
- Abstraksi tidak boleh bergantung pada detail. Detail harus bergantung pada abstraksi.
Kenapa Penting di JavaScript?
Tanpa DIP, modul-modul kamu jadi saling "ngiket" erat (tightly coupled). Misalnya, komponen UI kamu langsung manggil API fetch atau langsung berinteraksi dengan database. Kalau cara ngambil data berubah, atau kamu mau ngetes komponen UI tanpa harus beneran manggil API, kamu bakal kesusahan. DIP bikin kode kamu jadi decoupled, artinya komponen-komponen bisa bekerja mandiri dan lebih gampang diganti.
Contoh Gampangnya:
Bayangkan kamu punya komponen laporan yang perlu data dari database.
Kode yang Kurang DIP (Anti Anti-Ribet):
javascript
// Modul tingkat rendah: Database
class MySQLDatabase {
getData(query) {
console.log(Mengambil data dari MySQL dengan query: ${query});
return [{ id: 1, name: 'Item A' }, { id: 2, name: 'Item B' }];
}
}// Modul tingkat tinggi: Report
class ReportGenerator {
constructor() {
this.database = new MySQLDatabase(); // Ketergantungan langsung pada detail implementasi
}generateReport() {
const data = this.database.getData("SELECT * FROM products");
console.log("Membuat laporan dari data:", data);
}
}ReportGenerator (modul tingkat tinggi) langsung bergantung pada MySQLDatabase (modul tingkat rendah). Kalau besok kamu mau ganti pakai MongoDB atau API, kamu harus ngutak-ngatik ReportGenerator. Ini "anti ribet".
Kode yang Lebih DIP (Bikin Kode Anti Ribet):
Kita butuh abstraksi. Di JavaScript, abstraksi bisa berupa "interface" implisit (objek dengan method tertentu) atau class abstrak (kalau pakai TypeScript lebih jelas).
javascript
// 1. Abstraksi (Interface/Kontrak): Apa yang kita butuhkan dari sumber data
// Di JS, ini bisa direpresentasikan sebagai fungsi/kelas yang diharapkan memiliki method getData()
class DataSource {
getData(query) {
throw new Error("Method 'getData()' must be implemented by concrete data sources.");
}
}// 2. Implementasi Konkret (Detail): MySQLDatabase, APIClient, dsb.
class MySQLDatabase extends DataSource {
getData(query) {
console.log(Mengambil data dari MySQL dengan query: ${query});
// Simulasi pengambilan data
return [{ id: 1, name: 'Produk A' }, { id: 2, name: 'Produk B' }];
}
}class APIDataSource extends DataSource {
async getData(endpoint) {
console.log(Mengambil data dari API: ${endpoint});
// Simulasi fetch dari API
const response = await fetch(https://api.example.com/${endpoint});
return response.json();
}
}// 3. Modul Tingkat Tinggi: Bergantung pada Abstraksi, bukan Detail
class ReportGeneratorDIP {
constructor(dataSource) {
// ReportGenerator bergantung pada 'dataSource' (abstraksi),
// bukan pada MySQLDatabase atau APIDataSource secara spesifik.
this.dataSource = dataSource;
}async generateReport() {
try {
const data = await this.dataSource.getData("products");
console.log("Membuat laporan dari data:", data);
return data;
} catch (error) {
console.error("Gagal membuat laporan:", error);
return [];
}
}
}// Penggunaan (Dependency Injection):
// Kita 'inject' implementasi konkret saat membuat instance ReportGeneratorDIP
const mySqlSource = new MySQLDatabase();
const apiSource = new APIDataSource();const reportFromMySQL = new ReportGeneratorDIP(mySqlSource);
reportFromMySQL.generateReport();const reportFromAPI = new ReportGeneratorDIP(apiSource);
reportFromAPI.generateReport();Ini adalah contoh "Dependency Injection", salah satu cara mengimplementasikan DIP. ReportGeneratorDIP nggak perlu tahu dari mana datanya datang, asalkan objek yang di-pass ke konstruktornya punya method getData. Ini bikin kode kamu sangat decoupled, mudah di-test (kamu bisa inject mock database untuk testing), dan sangat fleksibel. Inilah salah satu kunci untuk bikin aplikasi yang kompleks jadi "anti ribet".
Kenapa SOLID Bikin Kode Kamu Anti Ribet? (Manfaat Secara Keseluruhan)
Setelah kita bedah satu per satu, mungkin kamu udah bisa ngelihat benang merahnya. Menerapkan SOLID itu kayak investasi jangka panjang buat codebase kamu.
- Mudah Dipelihara (Maintainable): Setiap bagian punya tanggung jawab jelas, jadi kalau ada bug atau perlu perubahan, kamu tahu persis di mana harus ngutak-ngatik tanpa takut ngerusak bagian lain. Nggak ada lagi drama "Oh my God, saya cuma nambah spasi, kenapa fitur A jadi rusak?!".
- Gampang Diuji (Testable): Karena setiap modul atau fungsi berdiri sendiri dan punya tanggung jawab yang spesifik, unit testing jadi jauh lebih mudah. Kamu bisa ngetes satu komponen tanpa perlu mengaktifkan seluruh sistem. Ini penting banget buat ngejamin kualitas kode.
- Fleksibel dan Dapat Diperluas (Flexible & Extensible): Kebutuhan software itu dinamis, pasti ada aja perubahan atau penambahan fitur. Dengan SOLID, kamu bisa nambahin fitur baru atau mengubah perilaku tanpa harus memodifikasi kode inti yang sudah stabil. Ini menghemat waktu dan mengurangi risiko.
- Lebih Mudah Dipahami (Readable): Kode yang menerapkan SOLID cenderung lebih bersih, terstruktur, dan mudah dibaca. Setiap komponen punya peran yang jelas, jadi developer baru atau bahkan kamu sendiri di masa depan, nggak pusing saat baca ulang.
- Mengurangi Utang Teknis (Reduced Technical Debt): Kode yang "anti ribet" dan terawat dengan baik akan mengurangi penumpukan utang teknis. Utang teknis ini yang bikin project jadi lambat dan mahal di kemudian hari.
- Mempermudah Kolaborasi: Dengan arsitektur yang jelas dan modular, tim developer bisa bekerja secara paralel pada bagian-bagian berbeda tanpa terlalu sering mengalami konflik atau saling menunggu.
Gimana Cara Mulai Menerapkan SOLID di JavaScript?
- Jangan Over-Engineer dari Awal: Nggak semua project kecil butuh implementasi SOLID yang super ketat. Mulai dari yang basic dulu, seperti SRP. Kadang, fokus pada SRP dan OCP sudah cukup membawa dampak besar.
- Refaktor Secara Bertahap: Kalau kamu punya codebase lama yang "ribet," jangan langsung coba menerapkan semua prinsip SOLID dalam semalam. Identifikasi area-area yang paling sering bikin masalah, lalu refactor secara bertahap menggunakan prinsip yang paling relevan.
- Pikirkan Abstraksi: Sebelum menulis kode, luangkan waktu sejenak untuk memikirkan abstraksi apa yang dibutuhkan. Jangan langsung implementasi detail. Ini kunci penting terutama untuk OCP dan DIP.
- Manfaatkan ES6+ Features: JavaScript modern (ES6 dan seterusnya) punya fitur-fitur seperti
class,module,async/await, yang sangat mendukung penerapan SOLID. Manfaatkan itu! - Code Review: Minta teman developer atau mentor untuk me-review kode kamu. Diskusi tentang penerapan SOLID bisa sangat membantu dalam memahami dan mengimplementasikannya dengan lebih baik.
- Praktik, Praktik, Praktik: Konsep SOLID itu kayak skill, harus terus diasah. Semakin sering kamu mencoba menerapkannya, semakin natural rasanya.
Menerapkan SOLID Principles di JavaScript memang butuh waktu dan latihan, tapi percaya deh, hasilnya setimpal. Kode kamu nggak cuma jadi lebih "anti ribet" buat kamu sendiri, tapi juga buat tim kamu, dan yang paling penting, buat masa depan aplikasi yang kamu bangun. Jadi, yuk mulai bikin kode JavaScript yang bersih, rapi, dan siap berkembang!
