Menggunakan pola berbeda untuk fitur serupa


10

Saya adalah satu-satunya pengembang di proyek yang, seperti proyek perangkat lunak apa pun, dapat diambil oleh orang lain di masa mendatang.

Katakanlah saya menggunakan pola X untuk mengimplementasikan fitur A. Setelah mengembangkan dan menyelesaikan fitur, saya menyadari bahwa saya dapat mengimplementasikan fitur yang sama menggunakan pola Y, yang baru saja saya pelajari. Tetapi fitur A bekerja dengan baik, dan refactoring dari X ke Y memakan waktu dan memberi sedikit manfaat.

Maka saatnya untuk mengimplementasikan fitur B. Ini mirip dengan A, tapi kali ini saya ingin mengambil kesempatan ini untuk bermain dengan pola Y. Saya senang dengan hasil akhirnya, lebih baik daripada ketika melakukan fitur A, tapi sekarang kode saya menggunakan dua pola yang berbeda, X dan Y, untuk fitur serupa.

Tapi tidak ada alasan nyata untuk menggunakan pola yang berbeda, kecuali kenyataan bahwa ketika membangun fitur AI tidak cukup terampil untuk menggunakan pola yang sama seperti untuk fitur B.

Perhatikan bahwa pertanyaan ini bukan tentang memilih pola yang tepat untuk masalah yang diberikan ; ini tentang dua pola yang ada bersama dalam basis kode untuk memecahkan masalah yang sama, yang dapat dikurangi menjadi satu waktu yang cukup untuk melakukan refactor.

  • Apakah itu bau kode?
  • Apa kerugian dari menjaga kode sumber seperti ini?
  • Haruskah saya tetap menggunakan satu pola saja? yaitu refactor A untuk menggunakan Y atau tetap menggunakan X saat menulis B?
  • Bagaimana, di sumbernya, saya bisa berkomunikasi bahwa alasan mengapa ada dua pola berbeda untuk fitur serupa pada dasarnya tidak ada alasan?
  • Apakah saya terlalu khawatir tentang apa yang dipikirkan pengembang selanjutnya tentang kode saya?

Kemungkinan rangkap dari Memilih Pola Desain yang tepat
agas

Jawaban:


7

Jika pola X dan Y menyelesaikan masalah yang sama dan tidak ada yang lebih baik secara objektif, maka Anda harus memutuskan satu dan tetap menggunakannya. Jika memungkinkan, Anda harus berusaha untuk memecahkan masalah yang sama dengan cara yang sama secara konsisten.

Anda tidak terlalu khawatir, melainkan bau kode serius yang harus Anda tangani dan bersihkan.

Kerugian untuk memiliki solusi berbeda untuk masalah yang sama dalam basis kode:

  • akan butuh dua kali lebih lama untuk memahami kode
  • itu akan memakan waktu dua kali lebih lama untuk mengubah kode ketika Anda mengubah beberapa perilaku yang melibatkan pola
  • Anda akan memiliki bug dua kali lebih banyak
  • kolega saat ini dan di masa depan akan membencimu

2

Saya setuju dengan jawaban JacquesB . Saya akan menambahkan, menjawab pertanyaan Anda yang lain, bahwa jika saat ini Anda memiliki dua pola hidup berdampingan, dan belum punya waktu (belum) untuk memperbaiki aplikasi Anda untuk menggunakan yang Anda temukan sebagai yang terbaik, Anda harus meletakkan yang ada di komentar Anda di kelas "menyinggung" (yang akan di refactored). Dengan cara ini, jelas bagi pengembang masa depan (Anda atau orang lain) bahwa masih ada hutang yang harus dibayar.

Akhirnya, kerugian utama mempertahankan basis kode seperti ini adalah kompleksitas yang ditambahkan, tetapi tidak perlu. Anda pasti ingin menghindari kompleksitas yang tidak dibutuhkan di semua biaya!


Saya lebih suka melihat ini di semacam todo list atau setidaknya sebagai tambahan catatan dalam kode.
JeffO

@ Jeff saya setuju. Meskipun hanya mengandalkan daftar agenda bukan tanpa masalah tambahan, karena sebagian besar waktu ini bersifat pribadi (tidak dibagi), berlawanan dengan komentar di dalam basis kode bersama. Tetapi sekali lagi, saya setuju dan kemungkinan ide yang baik untuk memiliki keduanya (ketika mereka secara pasti tidak dapat dihindari untuk memulai).
carlossierra

Itu poin yang bagus. Itu harus menjadi sesuatu yang lebih dari sekadar daftar Todo untuk memasukkan berbagi, kolaborasi, komunikasi dan semua hal menyenangkan lainnya;
JeffO

1

Jangan bermain dalam basis kode. Tulis prototipe untuk itu Anda dapat menemukan kelebihan dan kekurangan dari satu pola / desain di atas yang lain.

Mungkin ternyata apa yang secara intuitif terasa dapat dikurangi, sebenarnya mungkin lebih kompleks daripada memiliki 2 pola yang berbeda.

Berharap untuk membuang banyak kode yang dikembangkan untuk prototipe.


1

Apakah ini bau kode atau tidak, sangat tergantung pada seberapa mirip masalah A dan masalah B. Jawaban JacquesB tampaknya menganggap mereka sangat mirip, dan bahwa jika Anda mengubah masalah A (untuk memperbaiki bug misalnya) Anda juga harus mengubah masalah B pada saat yang sama. JaqueB mungkin benar, tetapi bisa juga kasus A dan B berubah secara independen karena mereka tidak semua sama. Dalam situasi itu Anda tidak mungkin memiliki kelemahan yang dijelaskan.

Berdasarkan deskripsi Anda, itu terdengar seperti sedikit bau kode (Duplikasi) tetapi sulit untuk mengatakan seberapa bau itu. Sebagai contoh jika A menggunakan Metode Templat dan B menggunakan Strategi dua masalah bisa sangat berbeda meskipun pola mirroring digunakan. Saya akan menunggu dan melihat pendekatan. Jika masalah C muncul dan itu seperti A dan B, maka saya akan refactor A agar konsisten dengan B dan kemudian membuat C harus sangat sederhana. Jika ada bug di A Saya juga ingin refactor untuk mencocokkan B, lalu perbaiki bug. Jika tidak ada yang berubah maka .... tidak masalah kan?

Memiliki banyak cara untuk memecahkan masalah yang sama dalam basis kode adalah fakta kehidupan. Bahkan dalam kasus di mana Anda adalah satu-satunya pengembang Anda akan mempelajari hal-hal baru dan memiliki wawasan baru, sehingga solusi Anda akan berubah. Saat Anda mengenali dengan benar, Anda perlu memperbaiki ketidaksempurnaan ini sambil memberikan nilai. Mendesain ulang (yang sebenarnya Anda lakukan ketika Anda mengubah suatu pola) kode yang tidak akan pernah berubah lagi tidak memberikan nilai. Satu-satunya cara nyata untuk mengetahui itu akan berubah adalah benar-benar harus melakukan perubahan, itulah sebabnya saya menunggu masalah C.


1

Tidak, Anda dapat memiliki beberapa pola yang digunakan dalam basis kode tunggal.

Namun, jika Anda menerapkan komponen dan Anda mengekspos cara menggunakannya yang mengikuti pola, maka mungkin yang terbaik adalah tetap menggunakan yang itu. Katakanlah, misalnya, saya menggunakan pola pembangun untuk klien kueri REST saya, tetapi kemudian saya menerapkan salah satu sumber daya secara berbeda. Itu akan membingungkan orang.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.