Apa nama antipattern yang berlawanan dengan “reinventing the wheel”? [Tutup]


101

Antipattern " Reinvent the wheel " adalah yang cukup umum - daripada menggunakan solusi yang siap pakai, tulis sendiri dari awal. Basis kode tumbuh tanpa perlu, antarmuka yang sedikit berbeda yang melakukan hal yang sama tetapi sedikit berbeda, waktu terbuang untuk menulis (dan men-debug!) Fungsi yang sudah tersedia. Kita semua tahu ini.

Tapi ada sesuatu di ujung spektrum yang berlawanan. Ketika alih-alih menulis fungsi Anda sendiri yang merupakan dua baris kode, Anda mengimpor kerangka / API / pustaka, instantiate, mengkonfigurasi, mengubah konteks menjadi tipe data yang dapat diterima oleh kerangka kerja, lalu memanggil satu fungsi tunggal yang melakukan persis apa yang Anda butuhkan, dua baris logika bisnis di bawah satu gigabyte lapisan abstraksi. Dan kemudian Anda perlu memperbarui perpustakaan, mengelola dependensi build, menjaga lisensi tetap sinkron, dan kode instantiasi Anda sepuluh kali lebih lama dan lebih kompleks daripada jika Anda hanya "menciptakan kembali roda".

Alasannya mungkin beragam: manajemen yang secara tegas menentang "reinvention of the wheel" terlepas dari biaya, seseorang mendorong teknologi yang mereka sukai meskipun sedikit tumpang tindih dengan persyaratan, peran yang semakin menipis dari modul utama sistem sebelumnya, atau harapan ekspansi dan lebih luas penggunaan kerangka kerja, yang tidak pernah tiba, atau hanya kesalahpahaman tentang "bobot" beberapa instruksi impor / sertakan / muat membawa "di belakang layar".

Apakah ada nama umum untuk antipattern semacam ini?

(Saya tidak mencoba memulai diskusi ketika itu benar atau salah, atau jika itu adalah antipattern atau pendapat yang berdasarkan apa pun , ini adalah pertanyaan nomenklatur yang sederhana dan obyektif.)

Sunting: pembicaraan "duplikat" yang disarankan tentang overengineering kode sendiri untuk membuatnya "siap untuk segalanya", sepenuhnya terpisah dari sistem eksternal. Hal ini mungkin dalam beberapa kasus berasal dari itu, tetapi umumnya berasal dari "keengganan untuk menciptakan kembali roda" - kode digunakan kembali di semua biaya; jika solusi "siap pakai" untuk masalah kita ada, kita akan menggunakannya, tidak peduli seberapa buruk itu cocok dan berapa biayanya. Dogmatis mendukung penciptaan dependensi baru daripada duplikasi kode, dengan total mengabaikan biaya integrasi dan pemeliharaan dependensi ini bila dibandingkan dengan biaya pembuatan dan pemeliharaan kode baru.


52
Ketergantungan neraka . Itu yang paling dekat yang bisa saya pikirkan.
Machado

5
@Machado: Bagus, meskipun saya akan mengatakan Ketergantungan Neraka adalah akibat langsung dari kelimpahan pola-anti ini; dalam hal sistem yang sangat kompleks, ini mungkin merupakan akibat langsung dari kompleksitas.
SF.

27
Saya akan menyebutnya "dependensi creep" analog dengan Feature_creep atau Scope_creep di mana semakin banyak fitur yang awalnya tidak diinginkan ditambahkan ke produk.
k3b

21
Tle meninggalkan-pad kegagalan adalah contoh nyata dari sindrom ini dalam tindakan.
SF.

13
Saya menyarankan agar kita mulai secara kolektif menyebut ini sebagai LeftPad.
RubberDuck

Jawaban:


9

Tidak. Tidak ada nama anti-pola yang umum digunakan yang mencakup apa yang Anda gambarkan.


4
Tampak dengan banyaknya ide, saran dan diskusi yang dibangkitkannya, ini sebenarnya benar.
SF.

3
Saya merasa kotor melakukan ini.
SF.

Hah? "Tidak ada XXX" adalah pernyataan yang sangat kuat dan sangat sulit untuk dibuktikan, terutama mengingat ada beberapa kandidat yang disebutkan dalam komentar.
AnoE

1
@AnoE "Apakah ada nama umum untuk antipattern semacam ini?" Bukti dalam komentar dan jawaban tersebut sangat menyiratkan bahwa tidak ada. Benar, itu tidak menjawab judul, tetapi menjawab pertanyaan itu sendiri.
Kroltan

@AnoE Anda tidak dapat membuktikan negatif, Sayang. Mungkin istilahnya bersembunyi di bawah batu di Kalimantan di suatu tempat dan kita belum terjatuh? Bahwa ada 10 jawaban, bukan 1, dengan zillion upvotes adalah bukti yang cukup bagi saya.

49

Palu Emas

Palu emas adalah alat yang dipilih hanya karena mewah. Ini tidak hemat biaya atau tidak efisien dalam melakukan tugas yang dimaksud.

sumber: xkcd 801

(Meskipun suara turun, saya mendukung jawaban ini. Mungkin bukan kebalikan dari menciptakan kembali roda secara semantik, tetapi cocok dengan setiap contoh yang disebutkan dalam pertanyaan)


5
Diperbaharui, dan Anda juga dapat sumbernya dari wikipedia: en.wikipedia.org/wiki/Anti-pattern , en.wikipedia.org/wiki/Law_of_the_instrument
Pierre.Sassoulas

3
Saya akan downvote ini jika saya punya perwakilan. Itu tidak menjawab pertanyaan secara keseluruhan, tetapi menawarkan satu istilah (akurat) yang menjawab hanya satu dari skenario yang disarankan.
David

3
Yang sebaliknya diminta. Ini seperti bersikeras bahwa "Becquerel" (radiasi, unit s ^ -1) dapat digunakan untuk musik sebagai gantinya Hertz (hz, unit adalah s ^ -1) karena keduanya berarti "per detik".
Thorbjørn Ravn Andersen

@ ThorbjørnRavnAndersen Saya telah mendengar musik yang cukup berbahaya pada hari saya.

34

Robert Martin menggunakan istilah " Framework Bound " untuk merujuk pada konsekuensi negatif yang paling jelas dari pola-anti ini. Karena saya tidak berpikir ada nama umum untuk pola itu sendiri, referensi untuk konsekuensi ini cukup untuk sebagian besar tujuan.


1
Kerangka kerja ada untuk mempercepat proses pengembangan. Mereka seperti roket pendorong: dikeluarkan segera setelah digunakan. Solusinya adalah - merilis versi satu, sekarang di mana kita? Itu benar, mengembangkan perangkat lunak. Lanjut! Pemeliharaan adalah masalah tersendiri, dan saya pikir, hari ini tidak penting. Ambil kerangka kerja berikutnya untuk solusi berikutnya, setelah tergesa-gesa.

18

Halaman wikipedia ini pada " Diciptakan Di Sini " menggambarkan situasi yang sedikit berbeda tetapi dengan hasil akhir yang sangat mirip. Menjelaskan keengganan tim untuk membuat kode sendiri ketika fungsionalitas yang setara dapat ditemukan di sana.

Saya berpendapat bahwa nama itu agak menyesatkan. Masuk akal ketika dimasukkan ke dalam konteks dengan itu berlawanan Tidak Diciptakan Di sini yang IMHO cukup banyak sinonim untuk Menciptakan Kembali roda.


13

Saya pernah mendengar " Beli Versus Bangun " dan " Diciptakan di Sini " sebagai nama anti-pola untuk bias terhadap pengembangan hal-hal di rumah, bahkan ketika mungkin masuk akal untuk melakukannya. (Dan meskipun frase "beli versus membangun" seharusnya menunjukkan pilihan antara alternatif yang layak, saya menemukan itu biasanya disebutkan ketika seseorang percaya "membeli" adalah pilihan yang benar.)



8

Gembung adalah istilah yang luas, tetapi itu bisa mencakup apa yang Anda gambarkan. Perangkat lunak kami menjadi terlalu rumit (kembung) karena semua transformasi dan abstraksi tambahan yang diperlukan, dan kompleksitas dan dependensi itu sendiri berkontribusi pada kinerja yang lebih rendah / efisiensi yang lebih rendah dan konsumsi sumber daya yang lebih tinggi (disk, bandwidth).

Jika kita mau, kita bisa mengklarifikasi dengan istilah seperti dependensi yang membengkak .


5

Saya pikir Menggunakan palu godam untuk memecahkan kacang cukup dekat. Ini adalah sesuatu yang mungkin, tetapi perlu banyak sekali pekerjaan untuk memecahkan satu mur dengan cara itu, tanpa banyak kemungkinan efek samping yang tidak diinginkan terjadi. (Dan ada sekantong kacang untuk dipecahkan ...)

Ungkapan ini juga memiliki keuntungan bahwa itu bukan komputasi jargon, jadi mungkin sangat membantu dalam memberikan petunjuk kepada seseorang yang tidak memilikinya.

Ngomong-ngomong, ada perbedaan yang bisa ditarik dengan neraka ketergantungan . Jika seseorang telah membungkus semua kompleksitas di dalam enkapsulasi yang menciptakan antarmuka yang sederhana, jelas, mudah digunakan, dan memberikan hukuman dalam siklus CPU atau penggunaan memori tidak berlebihan, dan memberikan modifikasi di masa depan dari kode enkapsulasi tidak mungkin diperlukan, maka argumen yang tersisa untuk tidak menggunakannya adalah neraka ketergantungan yang mungkin menyebabkannya.


5

Saya tidak berpikir ada analog yang tepat, tapi saya akan mengatakan bahwa desain yang berlebihan atau rekayasa yang paling dekat.

Setidaknya, saya berpendapat bahwa inilah yang sebenarnya terjadi ketika saya menemukan sesuatu yang mirip dengan yang Anda gambarkan.

Menggunakan perpustakaan alih-alih menulis kode Anda sendiri untuk mengimplementasikan fungsi yang sama hampir tidak pernah berbahaya.

Bahkan dalam contoh hipotetis Anda, menggunakan perpustakaan untuk mengganti "dua baris kode" mungkin tidak diperlukan, tetapi tidak mungkin menyebabkan Anda sangat sedih - jika perpustakaan benar-benar dimaksudkan untuk melakukan hal yang sama dengan dua baris kode Anda .

Perpustakaan untuk melakukan hal yang sederhana juga akan sederhana. Sepertinya tidak akan membuat Anda sakit kepala seperti yang disiratkan oleh pertanyaan Anda.

Menggunakan pustaka yang rumit untuk melakukan sesuatu yang sederhana mungkin menyiratkan bahwa Anda mencoba melakukan lebih dari sekadar mengimplementasikan fungsionalitas yang diperlukan.

Seperti membangun fitur yang tidak diperlukan, mempersiapkan masa depan yang mungkin tidak akan pernah datang, dll.

Masalahnya di sini bukanlah kegagalan untuk menemukan kembali roda itu sendiri .


4

Jika Anda belum menemukan kembali roda, kemungkinan besar seseorang menggunakan set roda yang ada yang disediakan oleh vendor atau pihak ke-3.

Jika ini anti-pola, maka biasanya disebut vendor lock-in.


6
Saya tidak merasa itu hal yang sama. Penguncian vendor adalah salah satu akibat negatif tergantung pada solusi vendor, terlepas dari apakah penggunaan vendor itu hemat biaya atau tidak ketika pilihan dibuat. OP lebih bertanya tentang istilah untuk memilih solusi pihak ketiga ketika biaya integrasi lebih tinggi daripada biaya hanya mengembangkan solusi baru dari awal (dan vendor lock-in mungkin bahkan tidak terjadi, dalam kasus di mana ia akan menjadi murah untuk mengembangkan solusi baru alih-alih mengandalkan vendor).
Ben

@ Ben - Ok, saya suka Framework terikat sebagai lawan kunci vendor lebih baik. Pertanyaan ini berdasarkan jenis pendapat dan ini adalah hal pertama yang muncul di kepala saya.
Jon Raynor

0

Keamanan kerja?
Anda menyebutkan semua upaya untuk menjaga sinkronisasi, dll. Beberapa orang lebih suka mengelola kode orang lain daripada menulis sendiri. Manajer, khususnya.

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.