Seorang programmer yang baik harus bisa menggabungkan keahliannya dengan akal sehat. Ini semua tentang pragmatisme dan keterampilan memilih solusi terbaik untuk masalah Anda. Saat Anda dihadapkan pada masalah dalam pengembangan perangkat lunak, Anda dapat menggunakan prinsip-prinsip dasar untuk membantu Anda memilih pendekatan yang tepat.
Teks ini memberikan sekumpulan prinsip yang harus diketahui oleh setiap pengembang dan yang harus diperbarui secara berkala. Anggap saja sebagai senjata pemrograman rahasia Anda.
Menerapkan prinsip-prinsip ini secara konsisten akan membuat transisi Anda dari menengah ke senior lebih mudah. Anda mungkin menemukan bahwa beberapa (mungkin) Anda gunakan secara intuitif.
Ada banyak prinsip. Kami akan fokus pada tujuh yang paling penting. Menggunakannya akan membantu Anda tumbuh dan menjadi programmer yang lebih baik.
1. YAGNI
Anda Tidak Akan MembutuhkannyaPrinsip ini sederhana dan jelas, tetapi tidak semua orang mengikutinya. Jika Anda menulis kode, pastikan Anda membutuhkannya. Jangan menulis kode jika menurut Anda akan berguna nanti.
Prinsip ini berlaku untuk refactoring. Jika Anda memfaktorkan ulang metode, kelas, atau file, jangan takut untuk menghapus metode yang tidak perlu. Meskipun sebelumnya berguna, sekarang tidak diperlukan.
Akan tiba saatnya mereka dibutuhkan lagi - lalu Anda dapat menggunakan repositori git untuk menghidupkannya kembali dari kematian.
2. KERING
Don't Repeat YourselfKonsep ini pertama kali diartikulasikan dalam buku Andy Hunt dan Dave Thomas The Pragmatic Programmer: The Journey from Apprentice to Master.
Idenya berkisar pada satu sumber kebenaran (SSOT). Apa ini sih?
Dalam desain dan teori sistem informasi, Single Source of Truth (SSOT) adalah praktik penataan model informasi dan skema data, yang menyiratkan bahwa semua bagian data diproses (atau diedit) hanya di satu tempat ... SSOT menyediakan andal, data yang relevan dan dapat digunakan.
- Wikipedia
Menggunakan SSOT akan membuat basis kode yang lebih kuat dan dapat dipahami.
Menduplikasi kode hanya membuang-buang waktu dan sumber daya. Anda harus mempertahankan logika yang sama dan menguji kode di dua tempat sekaligus, dan jika Anda mengubah kode di satu tempat, Anda perlu mengubahnya di tempat lain.
Dalam banyak kasus, duplikasi kode terjadi karena ketidaktahuan sistem. Sebelum Anda menulis apa pun, bersikaplah pragmatis: lihat-lihat. Mungkin fungsi ini diimplementasikan di suatu tempat. Mungkin logika bisnis ini ada di tempat lain. Penggunaan kembali kode selalu merupakan keputusan cerdas.
3. Cium
Keep It Simple, StupidPrinsip ini dikembangkan oleh US Navy pada tahun 1960. Prinsip ini menyatakan bahwa sistem sederhana akan bekerja lebih baik dan lebih andal.
Prinsip ini memiliki banyak kesamaan dengan penemuan kembali roda, yang dilakukan pada tahun 1970-an. Kemudian kedengarannya seperti metafora bisnis dan periklanan.
Berkenaan dengan pengembangan perangkat lunak, itu berarti berikut - jangan datang dengan solusi yang lebih kompleks untuk masalah daripada yang dibutuhkan.
Terkadang keputusan paling cerdas ternyata paling sederhana. Menulis kode yang efisien, efisien, dan sederhana itu bagus.
Salah satu kesalahan paling umum di zaman kita adalah menggunakan alat baru semata-mata karena alat itu bersinar. Pengembang harus termotivasi untuk menggunakan teknologi terbaru, bukan karena itu baru, tetapi karena itu tepat untuk pekerjaan itu.
4. Desain Besar Di Muka
Desain Global PertamaPendekatan pengembangan perangkat lunak ini sangat penting dan sering diabaikan. Pastikan semuanya telah dipikirkan dengan baik sebelum melanjutkan ke implementasi.
… . , . , . , BDUF, , . , .
—
Banyak pengembang percaya bahwa jika mereka tidak menulis kode, maka mereka tidak membuat kemajuan. Ini adalah pendekatan yang salah. Dengan membuat rencana, Anda tidak akan kesulitan memulai dari awal lagi dan lagi.
Terkadang orang lain harus terlibat dalam kekurangan dan proses pembangunan arsitektur. Semakin cepat Anda mendiskusikan semua ini, semakin baik untuk semua orang.
Sebuah argumen tandingan yang sangat umum adalah bahwa biaya untuk memecahkan masalah seringkali lebih kecil daripada biaya waktu perencanaan. Semakin sedikit kesalahan yang ditemui pengguna, semakin baik pengalamannya. Anda mungkin tidak memiliki kesempatan lagi untuk menangani kesalahan ini.
5. PADAT
Ini adalah prinsip pengembangan perangkat lunak yang paling terkenal. Solid adalah singkatan dari:
S) Prinsip tanggung jawab tunggal.
Arti pentingnya tidak dapat terlalu ditekankan. Setiap objek, kelas, dan metode harus bertanggung jawab hanya untuk satu hal. Jika objek / kelas / metode Anda terlalu banyak, Anda akan mendapatkan kode spaghetti. Berikut contohnya:
const saveTodo = async () => {
try {
response = await saveTodoApi();
showSuccessPop('Success');
window.location.href = '/successPage';
} catch (error) {
showErrorPopup(`Error: ${error} `);
}
}
Metode ini tampaknya tidak berbahaya, tetapi sebenarnya terlalu banyak:
- Menyimpan objek
- Menangani notifikasi di UI
- Melakukan navigasi
Efek samping lain dari kode ini adalah masalah pengujian. Fungsionalitas yang rumit sulit untuk diuji.
O) Prinsip terbuka-tertutup
Objek program harus terbuka untuk ekstensi, tetapi ditutup untuk modifikasi. Intinya adalah Anda tidak dapat mengganti metode atau kelas, cukup menambahkan fungsi tambahan sesuai kebutuhan.
Cara yang baik untuk mengatasi masalah ini adalah dengan menggunakan warisan. JavaScript memecahkan masalah ini dengan komposisi.
Aturan praktis sederhana: jika Anda mengubah entitas agar dapat diperluas, Anda melanggar prinsip ini untuk pertama kalinya.
L) Prinsip substitusi Liskov
Prinsip ini menyatakan bahwa objek dari kelas yang lebih tinggi harus diganti dengan objek subkelas, dan aplikasi harus bekerja seperti yang diharapkan ketika penggantian tersebut dilakukan.
I) Prinsip pemisahan antarmuka Prinsip
ini dirumuskan oleh Robert Martin ketika dia berkonsultasi dengan Xerox, dan itu jelas.
Objek tidak harus bergantung pada antarmuka yang tidak mereka gunakan
Perangkat lunak harus dibagi menjadi beberapa bagian independen. Efek samping harus diminimalkan untuk memastikan kemandirian.
Pastikan Anda tidak memaksa objek untuk mengimplementasikan metode yang tidak mereka perlukan. Berikut contohnya:
interface Animal {
eat: () => void;
walk: () => void;
fly: () => void;
swim: () => void;
}
Tidak semua hewan dapat terbang, berjalan, atau berenang, jadi metode ini tidak boleh menjadi bagian dari antarmuka atau harus opsional.
D) Prinsip inversi ketergantungan Prinsip
ini tidak bisa terlalu ditekankan. Kita harus mengandalkan abstraksi, bukan implementasi konkret. Komponen perangkat lunak harus memiliki kohesi rendah dan konsistensi tinggi.
Anda tidak perlu khawatir tentang cara kerja sesuatu, tetapi tentang cara kerjanya. Contoh sederhananya adalah menggunakan tanggal dalam JavaScript. Anda dapat menulis lapisan abstraksi Anda sendiri untuk mereka. Kemudian jika Anda mengubah sumber memperoleh tanggal, Anda perlu membuat perubahan di satu tempat, dan bukan di seribu.
Terkadang dibutuhkan upaya untuk menambahkan lapisan abstraksi ini, tetapi pada akhirnya akan terbayar.
Lihat date-io sebagai contoh , pustaka ini memiliki lapisan abstraksi yang memungkinkan Anda menggunakannya dengan sumber tanggal yang berbeda.
6. Hindari Optimasi Dini
Hindari Pengoptimalan DiniPraktik ini mendorong pengembang untuk mengoptimalkan kode mereka sebelum pengoptimalan terbukti perlu. Saya pikir jika Anda mengikuti KISS atau YAGNI, Anda tidak akan jatuh ke dalam pengait ini.
Lakukan dengan benar, itu baik untuk mengantisipasi bahwa sesuatu yang buruk akan terjadi. Namun sebelum Anda mendalami detail penerapan, pastikan pengoptimalan ini benar-benar berguna.
Contoh yang sangat sederhana adalah penskalaan. Anda tidak akan membeli 40 server dengan asumsi bahwa aplikasi baru Anda akan menjadi sangat populer. Anda akan menambahkan server sesuai kebutuhan.
Pengoptimalan prematur dapat menyebabkan penundaan dalam kode dan, oleh karena itu, meningkatkan waktu yang dibutuhkan untuk menghadirkan fungsi ke pasar.
Banyak yang menganggap pengoptimalan prematur sebagai akar dari segala kejahatan.
7. Pisau Cukur Occam
Brithva Okkama (terkadang Lezvie Okkama) adalah prinsip metodologis yang secara singkat menyatakan: “Anda tidak boleh menggandakan hal-hal yang tidak perlu” [1] (atau “Anda tidak boleh menarik entitas baru kecuali benar-benar diperlukan”).
- Wikipedia
Apa artinya ini dalam dunia pemrograman? Jangan membuat entitas yang tidak perlu tanpa perlu. Bersikaplah pragmatis - pertimbangkan apakah mereka diperlukan karena dapat memperumit basis kode Anda.
Kesimpulan
Prinsip-prinsip ini tidak terlalu sulit. Faktanya, kesederhanaan itulah yang membuat mereka cantik. Jika Anda bingung, jangan coba menerapkan semuanya sekaligus. Cobalah untuk bekerja dengan kesadaran dan cobalah untuk secara bertahap memasukkan prinsip-prinsip ini ke dalam alur kerja Anda.
Menggunakan prinsip dasar namun kuat akan memungkinkan Anda menjadi programmer yang lebih baik dan memiliki pemahaman yang lebih jelas tentang mengapa Anda melakukan sesuatu.
Jika Anda menerapkan sebagian besar prinsip secara intuitif, ada baiknya untuk berpikir dan memahami mengapa Anda melakukan sesuatu dengan cara tertentu.
Semua yang terbaik.
- Sistem kontrol serial pertama Rusia untuk mesin bahan bakar ganda dengan pemisahan fungsi pengontrol
- Di mobil modern, ada lebih banyak baris kode daripada ...
- - Automotive, Aerospace, (50+)
- McKinsey: automotive
