Pelanggaran terhadap Prinsip KERING

Saya yakin ada nama untuk pola-anti ini di suatu tempat; namun saya tidak cukup akrab dengan literatur anti-pola untuk mengetahuinya.

Pertimbangkan skenario berikut:

or0adalah fungsi anggota dalam suatu kelas. Baik atau buruk, itu sangat tergantung pada variabel anggota kelas. Programmer A datang dan membutuhkan fungsi seperti or0tetapi alih-alih memanggil or0, Programmer A menyalin dan mengganti nama seluruh kelas. Saya menduga dia tidak menelepon or0karena, seperti yang saya katakan, itu sangat tergantung pada variabel anggota untuk fungsinya. Atau mungkin dia seorang programmer junior dan tidak tahu bagaimana menyebutnya dari kode lain. Jadi sekarang kita punya or0dan c0(c untuk salinan). Saya tidak bisa sepenuhnya menyalahkan Programmer A untuk pendekatan ini - kita semua berada di bawah tenggat waktu yang ketat dan kita meretas kode untuk menyelesaikan pekerjaan.

Beberapa programmer mempertahankannya or0jadi sekarang versi orN. c0sekarang versi cN. Sayangnya sebagian besar programer yang mempertahankan kelas yang mengandung or0tampaknya sama sekali tidak menyadari c0- yang merupakan salah satu argumen terkuat yang dapat saya pikirkan untuk kebijaksanaan prinsip KERING. Dan mungkin juga ada pemeliharaan independen kode di c. Either way tampaknya itu or0dan c0dipertahankan independen satu sama lain. Dan, sukacita dan kebahagiaan, kesalahan terjadi di cNyang tidak terjadi di orN.

Jadi saya punya beberapa pertanyaan:

1.) Apakah ada nama untuk pola-anti ini? Saya telah melihat ini terjadi begitu sering sehingga sulit untuk percaya ini bukan anti-pola bernama.

2.) Saya dapat melihat beberapa alternatif:

a.) Perbaiki orNuntuk mengambil parameter yang menentukan nilai semua variabel anggota yang dibutuhkan. Kemudian, modifikasi cNuntuk memanggil orNdengan semua parameter yang diperlukan diteruskan.

b.) Cobalah untuk port secara manual memperbaiki dari orNke cN. (Pikiran Anda, saya tidak ingin melakukan ini tetapi itu adalah kemungkinan yang realistis.)

c.) Salin orNke - cNlagi, yuck tapi saya daftar demi kelengkapan.

d.) Cobalah untuk mencari tahu di mana cNrusak dan kemudian memperbaikinya secara independen orN.

Alternatif yang tampaknya seperti memperbaiki terbaik dalam jangka panjang tapi aku ragu pelanggan akan membiarkan saya menerapkannya. Tidak pernah ada waktu atau uang untuk memperbaiki hal-hal yang benar tetapi selalu waktu dan uang untuk memperbaiki masalah yang sama 40 atau 50 kali, kan?

Adakah yang bisa menyarankan pendekatan lain yang mungkin tidak saya pertimbangkan?

1. itu hanya disebut kode duplikat - Saya tidak tahu nama-nama mewah untuk ini. Konsekuensi jangka panjangnya seperti yang Anda gambarkan, dan lebih buruk.

2. Tentu saja, menghilangkan duplikasi adalah pilihan ideal jika hanya memungkinkan. Mungkin butuh banyak waktu (dalam kasus baru-baru ini dalam proyek warisan kami, saya memiliki beberapa metode yang digandakan di lebih dari 20 subclass dalam hierarki kelas, banyak di antaranya yang secara evolusioner menumbuhkan sedikit perbedaan / ekstensi mereka sendiri selama bertahun-tahun. saya sekitar 1,5 tahun melalui penulisan unit test dan refactoring berturut-turut untuk menyingkirkan semua duplikasi.

   Dalam kasus seperti itu, Anda mungkin masih memerlukan satu atau lebih opsi lain sebagai perbaikan sementara, bahkan jika Anda memutuskan untuk mulai bergerak ke arah menghilangkan duplikasi. Namun, mana yang lebih baik tergantung pada banyak faktor, dan tanpa konteks kita hanya menebak.

   Banyak perbaikan kecil dapat membuat perbedaan besar dalam jangka panjang. Anda tidak perlu memerlukan persetujuan eksplisit dari pelanggan untuk hal ini - sedikit refactoring setiap kali ketika Anda menyentuh kelas tersebut untuk memperbaiki bug atau mengimplementasikan fitur dapat berjalan jauh dari waktu ke waktu. Cukup sertakan beberapa waktu ekstra untuk refactoring dalam perkiraan tugas Anda. Ini seperti pemeliharaan standar untuk menjaga perangkat lunak tetap sehat dalam jangka panjang.

Ada referensi ke pola WET (We Enjoy Typing) tapi saya tidak tahu apakah itu nama standar.

... Lisensi perangkat lunak adalah pengecualian penting pada praktik KERING (Jangan Ulangi Diri Sendiri) - kode lisensi perangkat lunak harus sama BASAH (Kami Nikmati Mengetik - lawan dari KERING) sebanyak mungkin.

Jika Anda mengisolasi logika lisensi Anda di satu tempat, terpisah dari masalah lain, Anda membuatnya jauh lebih mudah untuk memodifikasi perangkat lunak Anda untuk menonaktifkan lisensi sama sekali. Adalah jauh lebih baik untuk mengulangi logika lisensi berkali-kali di seluruh aplikasi, lebih disukai sehingga ia dieksekusi berkali-kali selama satu kali eksekusi perangkat lunak.

Misalnya, kami menyarankan Anda melakukan pemeriksaan lisensi selama instalasi, saat startup aplikasi, dan kapan pun fitur penting diakses. Jangan periksa lisensi sekali selama startup & sampaikan nilai itu; alih-alih, sebenarnya gandakan cek lisensi di setiap area. Ini merepotkan, tetapi jauh lebih baik daripada merilis produk yang mudah retak ...

Jika saya mengerti Anda dengan benar, ada banyak hal yang terjadi di kelas. Itu menciptakan metode yang tidak mengikuti prinsip tanggung jawab tunggal . Menuju ke kode yang perlu dipindahkan, potongan diambil sementara yang lain ditinggalkan. Ini juga bisa membuat banyak anggota.

Anda juga harus meninjau pengubah aksesibilitas. Memastikan hal-hal yang bersifat publik, sebenarnya harus publik. Konsumen tidak perlu tahu tentang setiap anggota kecil ... gunakan enkapsulasi.

Ini panggilan untuk refactor. Tampaknya juga kode sedang ditulis tanpa desain awal. Lihatlah pengembangan Test Driven. Tulis kode bagaimana itu harus dipanggil daripada kode panggilan namun itu diterapkan. Lihatlah ke TDD untuk beberapa petunjuk tentang cara menyelesaikan tugas.

Jika Anda menyalin kode, Anda akan memperkenalkan hutang teknis pemeliharaan ganda atau lebih khusus: duplikasi kode .

Biasanya ini diperbaiki melalui refactoring. Lebih khusus Anda mengarahkan semua panggilan ke fungsi baru (atau metode baru di kelas baru) yang memiliki kode umum. Cara termudah untuk memulai adalah menghapus semua kode yang disalin dan melihat apa yang rusak, di mana Anda memperbaikinya dengan mengarahkan kembali panggilan ke kode yang umum.

Membuat pelanggan Anda menyetujui kode refactor mungkin sulit karena sulit meyakinkan orang non-teknis untuk memperbaiki hutang teknis. Jadi, lain kali Anda memberikan taksiran waktu, sertakan saja waktu yang dibutuhkan untuk merefleksikan taksiran Anda . Sebagian besar waktu pelanggan menganggap Anda melakukan pembersihan kode selama Anda melakukan perbaikan.

Kedengarannya seperti kode spageti bagiku. Perbaikan terbaik adalah refactor / penulisan ulang.

istilah merendahkan untuk kode sumber yang memiliki struktur kontrol yang kompleks dan kusut, terutama yang menggunakan banyak GOTO, pengecualian, utas, atau konstruksi percabangan "tidak terstruktur" lainnya. Dinamai demikian karena aliran program secara konseptual seperti semangkuk spageti, yaitu bengkok dan kusut ...

Anda mengatakan Anda tidak dapat sepenuhnya menyalahkan A - tetapi menyalin kelas dengan cara ini sebenarnya tidak dapat dimaafkan. Ini adalah kegagalan besar dalam proses peninjauan kode Anda. Ini mungkin kegagalan paling masif, tidak memiliki tinjauan kode sama sekali.

JIKA Anda pernah berpikir Anda harus menghasilkan kode mengerikan untuk memenuhi tenggat waktu, maka permintaan prioritas tertinggi mutlak untuk rilis setelah itu harus memperbaiki kode mengerikan SEKARANG. Jadi masalah Anda hilang.

Prinsip KERING adalah untuk situasi yang tidak cukup sempurna dan dapat ditingkatkan. Duplikasi kelas adalah kaliber baru. Saya pertama kali menyebutnya "kode duplikat", dan seiring waktu akan berubah menjadi yang terburuk dari semua pemboros waktu, "kode duplikat berbeda": banyak salinan dari kode yang sama yang hampir, tetapi tidak cukup identik, dan tidak ada yang tahu apakah perbedaan yang dimaksudkan, kebetulan, atau bug.

Hampir satu dekade terlambat untuk pesta ini, tetapi nama anti-pola ini adalah Divergent Change , di mana banyak kelas menyertakan salinan dari perilaku yang sama tetapi seiring waktu dan pemeliharaan yang meningkat dan beberapa kelas dilupakan, perilaku-perilaku tersebut berbeda.

Bergantung pada apa perilaku bersama dan bagaimana perilaku itu dibagi, itu bisa disebut Bedah Shotgun , perbedaannya adalah bahwa di sini satu fitur logis disediakan oleh banyak kelas daripada satu.