Minimalkan efek samping (idealnya tidak ada)
Fungsi yang menyebabkan 3 perubahan pada status di luar ruang lingkupnya sendiri jauh lebih sulit untuk dipikirkan dan dipelihara daripada yang hanya memasukkan sesuatu dan mengeluarkan sesuatu yang lain. Anda tidak bisa hanya tahu apa fungsinya, Anda harus mengingat apa yang dilakukannya dan bagaimana itu memengaruhi semua fungsi relevan lainnya.
Untuk OOP meminimalkan efek samping juga berarti kelas dengan anggota lebih sedikit, dan lebih sedikit anggota yang dapat memodifikasi status kelas, karena fungsi anggota dapat memodifikasi keadaan di luar milik mereka dan memiliki efek samping (mereka dapat memanipulasi internal kelas, misalnya). Ini juga berarti kelas dengan anggota data yang lebih sedikit sehingga tidak ada banyak metode untuk merusak dan lebih sedikit efek samping yang dapat ditimbulkannya.
Sebagai contoh sederhana, bayangkan mencoba merancang struktur data mewah yang dapat mempertahankan sorted
status yang digunakannya untuk menentukan apakah akan melakukan pencarian biner atau linear. Dalam kasus seperti itu, mungkin berguna untuk memisahkan desain menjadi dua kelas. Memanggil sorted
kelas yang tidak disortir mungkin akan mengembalikan struktur data kelas lain yang selalu menjaga isinya diurutkan. Sekarang Anda memiliki lebih sedikit efek samping (karena itu lebih sedikit rawan kesalahan dan lebih mudah untuk memahami kode) serta kode yang lebih luas berlaku (desain sebelumnya akan boros baik dalam pemrosesan dan efisiensi intelektual manusia untuk array kecil yang tidak perlu disortir).
Hindari Ketergantungan Eksternal yang Berlebihan
Anda mungkin dapat mengimplementasikan kode yang paling singkat yang bisa dibayangkan dengan penggunaan kembali kode maksimum dengan menggunakan 13 pustaka yang berbeda untuk menyelesaikan tugas yang relatif sederhana. Namun, itu mentransfer overhead intelektual ke pembaca Anda dengan harus membuat mereka mengerti setidaknya bagian dari 13 perpustakaan yang berbeda. Kompleksitas yang melekat ini harus segera dihargai oleh siapa saja yang mencoba membangun dan memahami perpustakaan pihak ketiga yang mengharuskan menarik dan membangun selusin perpustakaan lain agar berfungsi.
Ini mungkin pandangan yang sangat kontroversial tetapi saya lebih suka beberapa duplikasi kode sederhana untuk ekstrem yang berlawanan asalkan hasil akhirnya diuji dengan baik (tidak ada yang lebih buruk daripada kode kesalahan yang tidak terulang yang digandakan berkali-kali lipat). Jika pilihannya adalah antara 3-baris kode duplikat untuk menghitung produk vektor silang atau menarik perpustakaan matematika epik hanya untuk mengurangi 3 baris kode, saya sarankan yang pertama kecuali seluruh tim Anda bergabung dengan perpustakaan matematika ini , pada titik mana Anda mungkin masih mempertimbangkan untuk hanya menulis 3 baris kode daripada 1 jika itu cukup sepele dengan imbalan manfaat decoupling.
Penggunaan kembali kode adalah tindakan penyeimbangan. Menggunakan kembali terlalu banyak dan Anda mentransfer kompleksitas intelektual dengan cara satu-ke-banyak, karena dalam 3 baris kode sederhana yang Anda simpan di atas ada biaya yang mengharuskan pembaca dan pengelola memahami lebih banyak informasi daripada 3 baris kode . Ini juga membuat kode Anda kurang stabil, karena jika perpustakaan matematika berubah, mungkin juga kode Anda. Gunakan kembali terlalu sedikit dan Anda juga melipatgandakan overhead intelektual dan kode Anda berhenti mengambil manfaat dari perbaikan pusat, jadi ini adalah tindakan penyeimbang, tetapi gagasan bahwa itu adalah tindakan penyeimbangan patut disebutkan karena mencoba untuk menghapus setiap bentuk kecil dari duplikasi sederhana dapat menyebabkan untuk hasil yang sama sulitnya untuk dipertahankan, jika tidak lebih, dari ekstrem yang berlawanan.
Tes omong kosong itu
Ini diberikan tetapi jika kode Anda tidak menangani semua kasus masukan dan melewatkan beberapa kasus tepi, lalu bagaimana Anda dapat mengharapkan orang lain untuk mempertahankan kode yang Anda tulis yang bahkan tidak Anda dapatkan sebelum ditransfer ke mata dan tangan mereka? Cukup sulit untuk membuat perubahan pada kode yang berfungsi sempurna, apalagi kode yang tidak pernah benar di tempat pertama.
Selain itu, kode yang lulus tes menyeluruh umumnya akan menemukan lebih sedikit alasan untuk berubah. Itu berkaitan dengan stabilitas yang bahkan lebih dari suci untuk dicapai daripada pemeliharaan, karena kode stabil yang tidak perlu diubah tanpa dikenakan biaya pemeliharaan.
Dokumentasi Antarmuka
Prioritaskan "hal-hal apa yang dilakukan" daripada "bagaimana hal-hal itu lakukan" jika Anda tidak dapat mencurahkan waktu yang sama untuk mendokumentasikan keduanya. Antarmuka yang jelas yang jelas dalam niatnya tentang apa yang akan dilakukan (atau setidaknya, apa yang seharusnya dilakukan) dalam semua kasus input yang mungkin akan menghasilkan kejelasan konteks untuk implementasinya sendiri yang akan memandu dalam memahami tidak hanya bagaimana untuk menggunakan kode, tetapi juga cara kerjanya.
Sementara itu kode yang tidak memiliki kualitas ini di mana orang bahkan tidak tahu apa yang seharusnya dilakukan adalah SOL, tidak peduli seberapa baik didokumentasikan rincian pelaksanaannya. Manual 20 halaman tentang bagaimana kode sumber diimplementasikan tidak berharga bagi orang-orang yang bahkan tidak tahu persis bagaimana seharusnya digunakan dan apa yang seharusnya dilakukan dalam semua skenario yang mungkin.
Untuk sisi implementasi, prioritaskan mendokumentasikan apa yang Anda lakukan secara berbeda dari orang lain. Sebagai contoh, Intel memiliki hierarki volume terbatas untuk kernel raytracing mereka. Karena saya bekerja di bidang ini, saya dapat mengenali sebagian besar dari apa yang dilakukan kode mereka sekilas tanpa menyaring dokumentasi. Namun, mereka melakukan sesuatu yang unik yaitu gagasan melintasi BVH dan melakukan persimpangan secara paralel menggunakan paket ray . Di situlah saya ingin mereka memprioritaskan dokumentasi mereka karena bagian-bagian kode itu eksotis dan tidak biasa dari sebagian besar implementasi BVH historis.
Keterbacaan
Bagian ini sangat subyektif. Saya tidak terlalu peduli tentang keterbacaan dari jenis yang dekat dengan proses pemikiran manusia. Kode yang paling terdokumentasi dengan baik menggambarkan hal-hal di tingkat tertinggi masih sulit bagi saya untuk mengikuti jika penulis menggunakan proses pemikiran aneh dan berbelit-belit untuk memecahkan masalah. Sementara itu kode singkat menggunakan 2 atau 3 nama karakter sering kali lebih mudah bagi saya untuk memahami jika logikanya sangat mudah. Saya kira Anda bisa mengintip ulasan dan melihat apa yang disukai orang lain.
Saya lebih tertarik pada pemeliharaan dan, yang lebih penting, stabilitas. Kode yang tidak menemukan alasan untuk berubah adalah kode yang tidak memiliki biaya perawatan.