Gagasan bahwa kode yang dirancang untuk digunakan kembali dapat menjadi obat mujarab untuk semua masalah pemrograman adalah mitos yang berbahaya. Sekarang saya akan menjelaskan alasannya.
Mari kita bayangkan bahwa Anda sedang menulis perpustakaan dan tiba-tiba menangkap ide cemerlang, dari mana solusi umum dapat diperoleh, dapat diterapkan dalam berbagai kasus. Anda sangat meresepkan API yang akan mengalahkan fungsi apa pun dan beradaptasi dengan skenario apa pun. Anda menambahkan semua skrip yang hanya muncul di pikiran Anda. Kode membengkak dan membengkak, tetapi, pada akhirnya, itu benar-benar menjadi digeneralisasi dalam arti kata sepenuhnya. Dia seperti kue panas, dan kamu bahagia.
Tapi suatu hari, API baru muncul di cakrawala. Ini lebih ringkas dan cocok untuk sejumlah besar skenario, dan terlebih lagi, ia menang dalam kecepatan dan kesederhanaan. API Anda terlupakan - semua orang segera beralih ke hal baru yang menggoda. Namun, setelah beberapa waktu, cerita yang sama berulang dengan itu: API menjadi lebih dan lebih berat karena penambahan kode yang konstan, dirancang untuk kondisi baru, sampai pada akhirnya ada sesuatu yang lain untuk menggantikannya. Demikian seterusnya ad infinitum.
Kenapa begitu?
Akar semua masalah dalam hal ini adalah keinginan untuk menulis solusi umum. Jika kode yang dapat direproduksi menggunakan case standar sebagai standar, kode itu menjadi kembung, tidak nyaman digunakan, dan secara bertahap berubah menjadi sakit kepala murni.
Beberapa tingkat generalisasi merupakan prasyarat untuk penggunaan berulang kode apa pun. Tetapi jika Anda melangkah terlalu jauh dengan ini, utilitarianisme mulai menderita. Oleh karena itu, jika saya mengungkapkan pemikiran saya secara singkat, menulis kode yang dapat digunakan kembali tidak turun untuk menjadikannya selengkap mungkin. Semuanya jauh lebih rumit.
Untuk membuat kode yang dapat direproduksi secara praktis, Anda perlu memastikan bahwa itu tidak digunakan secara teratur, tetapi secara spontan, ketika diperlukan. Katakanlah, ketika mengerjakan suatu produk, Anda tiba-tiba menemukan kode yang dapat digunakan untuk kebutuhannya. Anda mengambil cuplikan ini, memodifikasinya sedikit dan menerapkannya dalam aplikasi. Dengan demikian, Anda membayar hanya untuk apa yang benar-benar bermanfaat, dan tepat ketika itu diperlukan.
Kemudian, Anda menemukan bahwa versi revisi ini mungkin berguna di aplikasi lain. Anda lagi mengambil fragmen ini, sedikit memodifikasinya dan menggunakannya di lingkaran ketiga. Jadi, berangsur-angsur meningkatkan reproduktifitas, Anda tidak hanya mendapatkan manfaat maksimal dari fragmen ini, tetapi juga melindungi produk Anda dari kode yang tidak melakukan apa pun untuknya dan umumnya tidak diperlukan di dalamnya.
Hal utama di sini adalah tidak pernah mencoba untuk memprediksi masa depan. Reproduksibilitas harus dibatasi pada batas visibilitas saat ini; di masa depan, Anda akan memperbaiki kode tersebut setiap kali ada peluang baru untuk penerapannya. Ini tidak hanya akan menghemat waktu dan tenaga Anda, tetapi juga menulis kode yang lebih ekonomis, keren dan modern, dipertajam untuk digunakan kembali.
Berikut adalah beberapa saran praktis tentang cara membuat kode dapat digunakan kembali.
Hindari duplikasi
Seperti yang dikatakan Lemony Sinquet dengan benar: “Jangan ulangi. Pertama, Anda ulangi lagi, kedua, Anda mengatakan hal yang sama, dan ketiga, semua orang sudah mendengarnya. ”
Ingat, kita berbicara tentang penggunaan kembali yang terjadi secara spontan? Inilah yang (dan hanya ini) yang harus dibatasi untuk tujuan kode ergonomis. Jadi, tulis kode yang Anda butuhkan saat ini, dan lanjutkan dengan semangat yang sama sampai Anda menyadari bahwa Anda harus menyelesaikan masalah yang sama berulang kali. Kemudian lakukan refactoring, letakkan kode di beberapa lokasi yang dapat diakses dan lihat sesuai kebutuhan. Bertindak dengan cara ini, Anda tidak akan mendapatkan kode umum yang boros, tetapi kode yang tidak memiliki duplikasi.
Bahkan, prinsip yang sama didalilkan oleh prinsip KERING (Jangan ulangi sendiri), yang menyatakan bahwa logika yang sama tidak boleh ditulis berulang kali dalam kode - ini menimbulkan tugas teknis. Pengulangan yang tidak berarti menyumbat sistem, mengurangi kualitas basis kode dan, juga, mengubahnya menjadi mimpi buruk bagi mereka yang memiliki tanggung jawab untuk mempertahankan kode produk. Penting untuk diingat: prinsip KERING adalah sejenis filosofi yang menyerukan untuk meninggalkan ambisi pemrograman pribadi dan melakukan apa yang terbaik untuk proyek. Jika seseorang telah melakukan sesuatu, gunakan itu. Tidak perlu menemukan kembali roda.
Pastikan kelas / metode / fungsi bertanggung jawab untuk satu hal.
Pada kesempatan ini, kita dapat mengingat pernyataan indah Louis Sullivan: "Bentuk berasal dari tujuan." Dalam terjemahan, ini berarti yang berikut: jika suatu fungsi, kelas atau metode melakukan satu-satunya hal, maka Anda akan mengubahnya hanya karena satu alasan. Ya, dengan pendekatan ini Anda sering harus membuat metode yang akan menggunakan metode lain, tetapi mereka akan tetap sederhana dan tidak terlalu koheren.
Setiap sistem dibangun dengan menggunakan bahasa yang berorientasi pada subjek, yang diciptakan oleh programmer dengan tujuan untuk menggambarkan sistem tersebut dengan benar. Fungsi memenuhi peran kata kerja dalam bahasa-bahasa ini, dan kelas memainkan peran kata benda. Bersama-sama mereka, sebagai suatu peraturan, membentuk tingkat dasar organisasi bahasa apa pun; karenanya, jika Anda meresepkannya dengan cara yang berkualitas, maka kode Anda akan berkualitas tinggi.
Ada dua aturan emas untuk membuat fungsi dan kelas yang dapat diterapkan beberapa kali, hanya dua:
- Mereka harus kecil
- Mereka harus melakukan satu hal, dan dengan baik
Ini mengasumsikan bahwa fungsi seharusnya tidak tumbuh cukup untuk mengandung struktur bersarang. Oleh karena itu, level sarang tidak boleh melebihi satu atau dua. Berkat teknik ini, kode menjadi lebih mudah dibaca, diurai dan berasimilasi.
Selain itu, perlu untuk memastikan bahwa semua operator dalam satu fungsi tetap pada tingkat abstraksi yang sama. Tingkat pencampuran selalu membingungkan dan cepat atau lambat akan menyebabkan kerja keras dengan kode. Programmer pro melihat kode yang dapat direproduksi sebagai semacam narasi, bukan hanya sepotong teks. Mereka menggunakan kemampuan bahasa pemrograman yang dipilih untuk membuat blok yang lebih ekspresif, bermakna, dan rapi yang dengan sempurna membangun narasi.
Jangan menyalahgunakan warisan
Terkadang kita, para pengembang, mencoba untuk melihat ke masa depan proyek yang jauh dan mulai melemparkan fungsi tambahan dengan pemikiran "bagaimana jika Anda membutuhkannya" dan "suatu hari nanti berguna". Jangan lakukan itu. Sampai sekarang, ini belum berguna bagi Anda, sekarang Anda tidak membutuhkannya dan dalam kebanyakan kasus ... Anda tidak akan membutuhkannya (untuk memparafrasekan prinsip YAGNI yang terkenal - You Ain't Gonna Need It). Prinsip ini berlaku untuk warisan. Jangan masukkan jika Anda tidak memiliki keyakinan penuh bahwa implementasi akan diulang beberapa kali.
Dengan semua ini, faktor keturunan adalah cara terbaik untuk menambahkan fungsionalitas ke kelas. Tetapi programmer cenderung mengambil alih tepi, membangun hierarki kelas di enam level atau lebih. "Geng Empat" dalam bukunya "Pola Desain" dengan ringkas menggambarkan risiko warisan yang berlebihan:
"Karena subclass memiliki akses ke detail implementasi kelas induk, sering dikatakan bahwa pewarisan melanggar enkapsulasi."
Keturunan menyebabkan kohesi yang kuat dari komponen, karena superclass membuka bagian dalamnya ke subclass, dan mereka, pada gilirannya, sepenuhnya bergantung pada superclass dalam segala hal yang berkaitan dengan operasi yang benar. Dalam situasi ini, superclass kehilangan fleksibilitasnya - menjadi sulit untuk mengubah apa pun dalam fungsinya. Karena alasan inilah, faktor keturunan adalah cara yang buruk untuk mencapai penggunaan kembali kode.
Pendekatan yang lebih masuk akal adalah berpikir dalam paradigma struktur objek, daripada keturunan. Ini akan memungkinkan orang menggunakan kode Anda untuk lebih mudah mengambil fungsionalitas yang mereka butuhkan dan membuat objek sendiri berdasarkan pembatasan yang relevan bagi mereka. Anda bahkan harus mempertimbangkan membuat antarmuka prosedural yang dapat diimplementasikan oleh masing-masing kelas dengan caranya sendiri. Antarmuka seringkali lebih mudah dipahami dan diimplementasikan daripada kelas dengan pewarisan multi-layer.
Untuk meringkas, seseorang harus menggunakan hereditas hanya jika satu kelas merupakan kelanjutan logis dari yang lain dan sebagian besar kode dari kelas pewarisan menggunakan kode dari superclass. Dalam kasus lain, Anda cukup menandatangani hukuman mati untuk diri sendiri dan kemungkinan kode penggunaan kembali.
Kesimpulannya
Secara umum, menulis kode untuk digunakan kembali tidak berarti membuat blok monolitik besar yang digeneralisasi. Kunci untuk menulis kode yang dapat direproduksi adalah dalam elemen-elemen yang ditujukan pada tugas tertentu, yang mudah dirakit, disolder dengan baik dan tidak terlalu saling terhubung dengan kuat.
Dan akhirnya, jangan mengakhiri dengan sendirinya dari penggunaan berulang - itu tidak layak. Lebih baik menetapkan tujuan untuk menghindari duplikasi, bukan untuk menulis fragmen kosong yang tidak perlu, untuk memastikan bahwa kode mudah dibaca dan dipelihara. Ketika Anda mengembangkan pandangan yang benar tentang berbagai hal, reproduktifitas akan datang dengan sendirinya.
Selalu ingat: penggunaan kembali dimulai dengan fakta bahwa Anda telah menemukan solusi yang berhasil untuk tugas tertentu. Segala sesuatu yang lain harus mengalir dari premis ini, dan Anda memiliki hak untuk memilih metode yang paling tepat untuk membawa potongan kode tertentu ke tingkat yang baru. Seperti yang dikatakan Ralph Johnson dengan benar: "Sebelum Anda berpikir tentang menggunakan kembali kode, Anda perlu memastikan bahwa Anda dapat menggunakannya sama sekali."