Banyak jawaban lain membahas masalah desain yang lebih besar, atau agak abstrak. Jika Anda berpikir tentang apa yang akan terjadi di masa depan, Anda dapat mendefinisikan beberapa teknik yang jelas untuk membantu pembuktian kode di masa depan .
Terutama berpikir bahwa di masa depan seseorang akan mencoba menambahkan fitur ke kode, atau akan mencoba untuk menggunakan kembali kode Anda di tempat lain. Mereka juga dapat mencoba untuk memperbaiki fitur dalam kode. Tentunya hanya memiliki kode bersih yang baik adalah titik awal yang diperlukan, tetapi ada juga beberapa teknik khusus yang dapat dilakukan.
Pemrograman Defensif : Lakukan pengecekan input melebihi apa yang sebenarnya dibutuhkan oleh aplikasi Anda saat ini. Setiap kali Anda menelepon API, pastikan untuk memeriksa bahwa inputnya adalah sesuatu yang Anda harapkan. Di masa depan orang akan mencampur kode versi baru bersama-sama, sehingga cakupan kesalahan dan pengembalian API akan berubah dari apa yang sekarang.
Menghilangkan Perilaku Tidak Terdefinisi : Banyak kode memiliki perilaku yang hanya berevolusi entah dari mana. Kombinasi input tertentu mengarah ke output tertentu yang tidak diinginkan siapa pun, tetapi kebetulan saja. Sekarang pasti seseorang akan bergantung pada perilaku itu, tetapi tidak ada yang akan tahu tentang hal itu karena tidak didefinisikan. Siapa pun yang berusaha mengubah perilaku di masa depan akan secara tidak sengaja merusak sesuatu. Gunakan pemeriksaan keamanan sekarang dan cobalah untuk menghapus / memblokir semua penggunaan kode yang tidak ditentukan.
Suite Uji Otomatis : Saya yakin Anda dapat menemukan volume yang ditulis tentang perlunya tes unit. Mengacu pada pembuktian di masa depan namun ini adalah titik kritis dalam memungkinkan seseorang untuk memperbaiki kode. Refactoring sangat penting untuk menjaga kode bersih, tetapi jika tidak memiliki serangkaian tes yang baik Anda tidak dapat dengan aman melakukan refactor.
Isolasi dan Segregasi : Enkapsulasi dan modularisasi yang tepat adalah prinsip desain yang baik, tetapi Anda harus melampaui itu. Anda akan sering menemukan bahwa Anda perlu menggunakan perpustakaan, atau API, atau produk, yang mungkin memiliki masa depan yang dipertanyakan. Mungkin karena masalah kualitas, masalah perizinan, atau pengembangan berkelanjutan oleh penulis. Dalam kasus ini, luangkan waktu ekstra untuk meletakkan lapisan antara Anda dan kode ini. Potong API sesuai kebutuhan Anda sehingga kopling sangat rendah untuk memungkinkan penggantian yang lebih mudah di masa mendatang.