Penggunaan kembali kode adalah ide yang cukup bagus. Bukan yang hebat .
Saya memiliki perspektif yang diambil dari sekitar 30 tahun rekayasa perangkat lunak, mencoba "menggunakan kembali".
Saya mulai menyelidiki "penggunaan kembali kode" sebagai topik penelitian di tahun 80-an, setelah menemukan saya telah menggunakan kembali desain satu OS yang saya bangun pada awal 70-an, untuk OS lain yang saya bangun pada akhir 70-an.
Bagian yang baik dari penggunaan kembali kode adalah kemampuan untuk terkadang menggunakan kembali kode yang sudah ada sebelumnya yang jujur. Tetapi dunia ini penuh dengan kode; bagaimana bisa menemukan yang Anda inginkan? Inilah yang saya sebut Kutukan Penggunaan Kembali :
Saya Santa Claus (ok Open Source), dan saya memiliki 1 miliar komponen perangkat lunak. Anda dapat memiliki salah satu dari mereka.
Semoga beruntung memilih.
Untuk memecahkan masalah penggunaan kembali dengan baik:
- pengguna harus entah bagaimana menentukan apa yang dia butuhkan (fungsional, kinerja, bahasa target, asumsi lingkungan, ...)
- harus ada perpustakaan kode "dapat digunakan kembali" yang telah diindeks dengan berbagai cara oleh kriteria potensial ini
- beberapa mekanisme harus ada untuk memilih elemen kandidat (pada satu miliar elemen, Anda tidak dapat melihat semuanya secara pribadi)
- perlu ada cara untuk menentukan seberapa jauh dari spesifikasi kandidat yang dipilih
- beberapa proses reguler harus ada untuk memungkinkan reuser untuk memodifikasi kode yang dapat digunakan kembali yang dipilih (di sini adalah kontribusi terbesar OOP: Anda dapat mengedit komponen / objek yang ada dengan menimpa slotnya. OOP tidak memberikan bantuan lain).
- semua ini jelas lebih murah daripada hanya pengodean ulang itu
Sebagian besar yang telah ditemukan selama bertahun-tahun adalah bahwa agar kode dapat digunakan kembali, itu semacam harus dirancang untuk tujuan itu, atau mengandung terlalu banyak asumsi implisit. Pustaka penggunaan kembali kode yang paling sukses sebenarnya cukup kecil. Pustaka dan kerangka kerja bisa jadi adalah kode yang "dapat digunakan kembali" dan sangat sukses; Java dan C # berhasil bukan karena mereka adalah bahasa komputer yang cukup bagus, tetapi karena mereka memiliki perpustakaan yang dirancang dengan baik, diimplementasikan dan didokumentasikan. Tetapi orang-orang tidak melihat kode sumber di perpustakaan; mereka hanya memanggil API yang terdokumentasi dengan baik (dirancang agar dapat digunakan secara umum).
Apa yang tidak digunakan kembali oleh kode (OOP) tidak memberikan perintah peningkatan besar dalam kemampuan kami untuk kode sistem.
Saya pikir kuncinya adalah bahwa segala jenis penggunaan kembali kode pada dasarnya terbatas karena kode memiliki terlalu banyak asumsi . Jika Anda membuat kode kecil, Anda meminimalkan asumsi, tetapi kemudian biaya untuk membangun dari awal tidak terlalu besar dan keuntungan penggunaan kembali tidak efektif. Jika Anda membuat potongan kode besar, mereka cukup berguna dalam konteks baru. Seperti Gulliver, mereka diikat ke pantai oleh sejuta string kecil, dan Anda tidak bisa memotong semuanya.
Apa yang harus kita kerjakan adalah penggunaan kembali pengetahuan untuk membuat kode . Jika kita dapat melakukan ini, maka kita dapat menerapkan pengetahuan itu untuk membuat kode yang kita butuhkan, menangani sekumpulan asumsi saat ini.
Untuk melakukan ini, kita masih memerlukan kemampuan spesifikasi yang sama untuk mengkarakterisasi komponen perangkat lunak (Anda masih harus mengatakan apa yang Anda inginkan!). Tetapi kemudian Anda menerapkan pengetahuan "konstruksi" ini pada spesifikasi untuk menghasilkan kode yang Anda inginkan.
Sebagai sebuah komunitas, kami belum begitu pandai dalam hal ini. Tetapi orang-orang melakukannya sepanjang waktu; mengapa kita tidak bisa mengotomatiskannya? Ada banyak penelitian, dan ini menunjukkan hal itu dapat dilakukan dalam banyak keadaan.
Salah satu bagian penting dari mesin yang diperlukan untuk ini adalah alat mekanis untuk menerima "deskripsi komponen" (ini hanya dokumen formal dan dapat diuraikan seperti bahasa pemrograman) dan menerapkan transformasi program pada mereka.
Compiler sudah melakukan ini: -} Dan mereka benar-benar bagus di kelas masalah yang mereka tangani.
Model UML dengan pembuatan kode adalah salah satu upaya untuk melakukan ini. Bukan usaha yang sangat bagus; cukup banyak yang dikatakan dalam kebanyakan model UML adalah "Saya punya data yang terlihat seperti ini". Cukup sulit untuk menghasilkan program nyata jika fungsinya ditinggalkan.
Saya mencoba membangun sistem transformasi program praktis, alat yang disebut DMS . Sudah cukup terganggu dengan menerapkan transformasi program tidak begitu banyak untuk spesifikasi abstrak untuk menghasilkan kode, tetapi lebih ke kode lama untuk membersihkannya. (Ini adalah masalah yang sama dalam abstrak!). (Untuk membangun alat seperti itu membutuhkan banyak waktu; Saya sudah melakukan ini selama 15 tahun dan sementara itu Anda harus makan).
Tetapi DMS memiliki dua sifat utama yang saya jelaskan di atas: kemampuan untuk memproses spesifikasi formal yang sewenang-wenang, dan kemampuan untuk menangkap "pengetahuan pembuatan kode" sebagai transformasi, dan menerapkannya sesuai permintaan. Dan yang luar biasa, kami menghasilkan dalam beberapa kasus khusus, beberapa kode yang agak menarik dari spesifikasi; DMS sebagian besar dibangun menggunakan dirinya sendiri untuk menghasilkan implementasinya. Itu telah mencapai bagi kita setidaknya beberapa janji penggunaan kembali (pengetahuan): peningkatan produktivitas yang sangat signifikan. Saya memiliki tim yang terdiri dari sekitar 7 orang teknis; kami telah menulis mungkin 1-2 MSLOC dari "spesifikasi" untuk DMS, tetapi memiliki 10MSLOC kode yang dihasilkan.
Ringkasan: penggunaan kembali pengetahuan generasi adalah kemenangan, bukan penggunaan kembali kode .