it-swarm-id.com

Apakah menciptakan kembali roda benar-benar seburuk itu?

Pengetahuan umum dalam pemrograman yang menemukan kembali roda buruk atau jahat .

Tapi kenapa begitu?

Saya tidak menyarankan itu bagus. Saya percaya itu salah. Namun, saya pernah membaca sebuah artikel yang mengatakan, jika seseorang melakukan sesuatu yang salah (pemrograman bijaksana) menjelaskan kepada mereka mengapa itu salah, jika Anda tidak bisa, maka mungkin Anda harus bertanya pada diri sendiri apakah itu benar-benar salah.

Itu mengarahkan saya ke pertanyaan ini:

Jika saya melihat seseorang dengan jelas menciptakan kembali roda dengan membangun metode mereka sendiri dari sesuatu yang sudah dibangun ke dalam bahasa/kerangka kerja. Pertama, demi argumen, mari kita asumsikan bahwa metode mereka sama efisiennya dengan metode bawaan. Juga pengembang, menyadari metode bawaan, lebih memilih metodenya sendiri.

Kenapa dia harus menggunakan built in di atas miliknya sendiri?

104
JD Isaacks

Seperti yang pernah saya posting di StackOverflow, reinventing the wheel is seringkali merupakan pilihan yang sangat baik, bertentangan dengan kepercayaan populer. Keuntungan utama adalah bahwa Anda punya kontrol penuh alih perangkat lunak, yang seringkali penting. Untuk diskusi lengkap, lihat posting asli saya .

73
Dimitri C.

Tergantung ..

Seperti halnya segalanya, ini tentang konteks:

Ada baiknya bila:

  • Kerangka atau pustaka terlalu berat, dan Anda hanya memerlukan fungsionalitas terbatas. Menggulung versi Anda sendiri yang sangat ringan yang sesuai dengan kebutuhan Anda adalah pendekatan yang lebih baik.
  • Ketika Anda ingin memahami dan mempelajari sesuatu yang kompleks, penggulungan Anda sendiri masuk akal.
  • Anda memiliki sesuatu yang berbeda untuk ditawarkan, sesuatu yang tidak dimiliki implementasi orang lain. Bisa jadi sentuhan baru, fitur baru dll.

Buruk ketika:

  • Fungsionalitas sudah ada dan dikenal stabil dan terkenal (populer).
  • Versi Anda menambahkan tidak ada yang baru.
  • Versi Anda memperkenalkan bug atau kendala (mis. Versi Anda tidak aman utas).
  • Versi Anda tidak memiliki fitur.
  • Versi Anda memiliki dokumentasi yang lebih buruk.
  • Versi Anda kurang dari unit test dibandingkan dengan apa yang diganti.
83
Darknight

Saya pikir kasus seorang pengembang yang sadar menemukan kembali roda "karena dia lebih suka metodenya sendiri" sangat jarang. Sebagian besar dilakukan karena ketidaktahuan, dan kadang-kadang karena keras kepala.

Apakah semuanya seburuk itu? Iya. Mengapa? Karena roda yang ada kemungkinan besar dibuat dari waktu ke waktu dan telah diuji dalam banyak keadaan dan terhadap banyak jenis data yang berbeda. Pengembang roda yang ada telah menemukan kasus-kasus Edge dan kesulitan-kesulitan yang bahkan tidak bisa dibayangkan oleh reinventor.

56
Dan Ray

Roda persegi harus diciptakan kembali. Upaya menghisap harus digandakan. Mungkin ada kekurangan dokumentasi untuk metode ini, dan programmer lain merasa lebih mudah hanya menulis sendiri daripada mencoba mencari tahu. Mungkin cara metode ini dipanggil canggung dan tidak cocok dengan idiom bahasa pemrograman.

Tanyakan saja apa kekurangannya.

22
user8865

Secara umum, saya menghindari reinventing the wheel jika fungsi yang saya inginkan, atau sesuatu yang mendekati itu, ada di perpustakaan standar dari bahasa yang saya gunakan.

Namun, jika saya harus memasukkan perpustakaan pihak ketiga, itu panggilan penilaian tergantung pada seberapa banyak digunakan dan dihargai perpustakaan itu. Maksud saya, apakah kita berbicara tentang Boost atau Bob's Kick-ass String-Parsing Tools 1.0?

Bahkan jika perpustakaan secara umum terkenal dan sangat dihargai di seluruh industri, itu masih ketergantungan pihak ketiga . Pemrogram umumnya memberikan penekanan signifikan pada kebajikan penggunaan kembali kode, sementara sering mengabaikan bahaya ketergantungan. Sebuah proyek dengan terlalu banyak ketergantungan pihak ketiga kemungkinan akan hancur dalam jangka panjang karena perlahan-lahan berubah menjadi mimpi buruk pemeliharaan.

Jadi meningkatkan kode yang ada adalah baik - tetapi dependensi buruk . Sayangnya, kedua pernyataan ini bertentangan satu sama lain, jadi triknya adalah mencoba menemukan keseimbangan yang tepat. Itu sebabnya Anda perlu mengidentifikasi dependensi yang dapat diterima . Seperti yang saya katakan, apa pun di Perpustakaan Standar bahasa kemungkinan besar merupakan ketergantungan yang dapat diterima. Beranjak dari sana, perpustakaan yang sangat dihargai di seluruh industri juga dapat diterima secara umum (seperti Boost untuk C++, atau jQuery untuk Javascript) - tetapi masih kurang diinginkan daripada Perpustakaan Standar karena mereka lakukan cenderung kurang stabil daripada perpustakaan standar.

Adapun perpustakaan yang relatif tidak dikenal, (mis. Unggahan terbaru di SourceForge) ini adalah dependensi yang sangat berisiko, dan saya biasanya akan merekomendasikan untuk menghindari ini dalam kode produksi, kecuali jika Anda cukup akrab dengan kode sumber untuk mempertahankannya sendiri.

Jadi itu benar-benar semua tindakan penyeimbangan. Tetapi intinya adalah bahwa secara membabi buta mengatakan "Kode menggunakan kembali baik! Menemukan kembali roda buruk!" adalah sikap berbahaya. Manfaat dari meningkatkan kode pihak ketiga harus ditimbang terhadap kerugian dari memperkenalkan dependensi.

17
Charles Salvia

Jika orang tidak menemukan kembali roda, dunia akan dipenuhi dengan ini .. enter image description here

Ini dialog dari tempat kerja saya:

- I would like to add some colors to the output of this program.
- Oh, there is this library called Colorama ..

Ada dua opsi: reinvent the wheel OR gunakan Colorama. Inilah yang akan dihasilkan setiap opsi:

Menggunakan Colorama

  • Mungkin sedikit lebih cepat untuk berlari
  • Menambahkan ketergantungan pihak ketiga untuk sesuatu yang sepele
  • Anda terus sebodoh sebelumnya menggunakan Colorama

Menemukan kembali roda

  • Anda mengerti bagaimana beberapa program dapat menunjukkan warna
  • Anda belajar bahwa karakter khusus dapat digunakan untuk mewarnai pada terminal apa pun
  • Anda dapat mewarnai dalam bahasa pemrograman apa pun yang mungkin Anda gunakan di masa depan
  • Proyek Anda cenderung rusak

Seperti yang Anda lihat, semuanya tergantung pada konteks. Menemukan kembali roda adalah sesuatu yang saya lakukan sangat sering karena saya ingin dapat dan berpikir untuk diri sendiri dan tidak bergantung pada orang lain yang berpikir untuk saya. Namun jika Anda menjalankan tenggat waktu atau apa yang Anda coba implementasikan sangat besar dan sudah ada, maka Anda lebih baik menggunakan apa yang ada di sana.

14
Pithikos

Salah satu alasan berguna untuk menemukan kembali roda adalah untuk tujuan pembelajaran - tetapi saya akan merekomendasikan melakukannya pada waktu Anda sendiri. Semakin banyak solusi pra-pengalengan tersedia, dan lebih banyak tingkat abstraksi disediakan, kami menjadi jauh lebih produktif. Kita dapat fokus pada masalah bisnis daripada hal-hal umum yang telah diubah berkali-kali. TAPI, untuk alasan itu, Anda dapat mengasah keterampilan Anda dan belajar banyak dengan mencoba mengimplementasikan kembali solusi Anda sendiri. Hanya belum tentu untuk penggunaan produksi.

Satu hal lagi - jika kekhawatiran adalah ketergantungan pada perpustakaan pihak ketiga dari perusahaan yang mungkin hilang, pastikan ada opsi untuk mendapatkan kode sumber, atau setidaknya beberapa pilihan lain di luar sana untuk digunakan kembali.

Omong-omong, jika Anda memang memilih untuk mengimplementasikan milik Anda sendiri, hindari melakukan ini untuk kriptografi atau fungsionalitas terkait keamanan lainnya. Alat yang sudah mapan (dan sudah teruji sepenuhnya) tersedia untuk itu, dan di zaman sekarang ini, terlalu berisiko untuk menggulung sendiri. Itu tidak pernah sepadan, dan menakutkan bahwa saya masih mendengar tentang tim yang melakukan ini.

13
Mark Freedman

Ada dua jenis efisiensi - pemrosesan/kecepatan (yaitu seberapa cepat dijalankan) yang mungkin cocok dan kecepatan pengembangan yang hampir pasti tidak akan terjadi. Itulah alasan pertama - ntuk masalah kompleksitas yang masuk akal di mana solusi yang ada tersedia, hampir pasti akan lebih cepat untuk meneliti dan mengimplementasikan perpustakaan yang ada daripada kode Anda sendiri.

Alasan kedua adalah perpustakaan yang ada (dengan asumsi sudah matang) diuji dan terbukti berfungsi - mungkin dalam skenario yang jauh lebih luas daripada pengembang dan tim uji akan dapat menempatkan yang baru ditulis rutin melalui dan ini datang pada upaya nol.

Ketiga, cara ini lebih mudah untuk didukung. Tidak hanya orang lain mendukung dan memperbaikinya (siapa pun yang menulis perpustakaan/komponen), tetapi jauh lebih mungkin bahwa pengembang lain akan terbiasa dengan hal itu dan dapat memahami dan memelihara kode maj, yang semuanya meminimalkan biaya yang sedang berlangsung.

Dan semua itu mengasumsikan kesetaraan fungsional, yang biasanya tidak terjadi. Perpustakaan sering menawarkan fungsionalitas yang menurut Anda berguna tetapi tidak pernah bisa membenarkan bangunan, yang semuanya tiba-tiba tersedia secara gratis.

Ada alasan untuk memutar sendiri - sebagian besar di mana Anda ingin melakukan sesuatu fungsi built-in tidak dapat dilakukan dan di mana ada keuntungan asli yang bisa diperoleh dengan melakukannya, atau di mana opsi yang tersedia tidak matang - tetapi mereka Anda kurang umum daripada banyak pengembang yang Anda yakini.

Selain itu, mengapa Anda ingin menghabiskan waktu untuk menyelesaikan masalah yang sudah diselesaikan? Ya itu cara yang bagus untuk belajar tetapi Anda tidak harus melakukan itu dengan mengorbankan solusi yang tepat untuk kode produksi yang saya asumsikan sedang kita bicarakan.

9
Jon Hopkins

Tentu saja menciptakan kembali kemauan, karena ketidaktahuan dan kesombongan bisa menjadi hal yang buruk, tetapi IMHO pendulum telah berayun terlalu jauh. Ada keuntungan luar biasa untuk memiliki roda yang sesuai dengan apa yang Anda inginkan dan tidak lebih .

Seringkali ketika saya melihat roda yang sudah ada, ia melakukan lebih dari yang saya butuhkan, menderita efek platform dalam, dan karenanya rumit, atau kehilangan beberapa fitur utama yang saya lakukan. perlu dan itu akan sulit untuk diterapkan di atas apa yang sudah ada.

Selain itu, menggunakan roda yang ada sering menambah kendala pada proyek saya yang tidak saya inginkan. Sebagai contoh:

  • Roda yang ada membutuhkan bahasa dan/atau gaya pemrograman yang berbeda dari yang saya lebih suka gunakan.
  • Roda yang ada hanya berfungsi dengan versi lawas dari suatu bahasa (misalnya, Python 2 bukannya Python 3).
  • Di mana ada pertukaran antara efisiensi, fleksibilitas dan kesederhanaan, roda yang ada membuat pilihan yang suboptimal untuk use case saya. (Saya telah dikenal untuk menemukan kembali bahkan fungsionalitas dari perpustakaan yang awalnya saya tulis sendiri dalam kasus ini. Biasanya itu karena saya menulis versi perpustakaan dari fungsi menjadi generik dan cukup efisien, ketika saya saat ini membutuhkan sesuatu yang sangat cepat di spesifik saya kasus.)
  • Roda yang ada memiliki ton legacy cruft yang sama sekali tidak berguna dalam kasus kode baru tetapi membuat hidup tetap sulit (misalnya, perpustakaan Java Saya menggunakan itu memaksa saya untuk menggunakan kelas kontainer jeleknya karena itu ditulis sebelum obat generik, dll.).
  • Cara roda model yang ada masalah sama sekali berbeda dari apa yang nyaman untuk kasus penggunaan saya. (Misalnya, mungkin lebih mudah bagi saya untuk memiliki grafik diarahkan diwakili oleh objek node dan referensi tetapi roda yang ada menggunakan matriks adjacency atau sebaliknya. Mungkin lebih mudah bagi saya untuk meletakkan data saya dalam urutan kolom utama, tetapi roda yang ada bersikeras pada baris utama atau sebaliknya.)
  • Perpustakaan menambahkan ketergantungan besar dan rapuh yang akan menjadi masalah besar untuk bangun dan berjalan di mana pun saya ingin menyebarkan kode saya, ketika semua yang saya butuhkan hanyalah sebagian kecil dari fitur-fiturnya. Di sisi lain, dalam hal ini saya kadang-kadang hanya mengekstrak fitur yang saya inginkan ke perpustakaan baru yang lebih kecil atau hanya menyalin/menempel jika perpustakaan itu open source dan basis kode membuatnya cukup sederhana. (Saya bahkan telah melakukan ini dengan perpustakaan yang relatif besar yang saya tulis sendiri, bukan hanya milik orang lain.)
  • Roda yang ada mencoba untuk secara patuh sesuai dengan beberapa standar yang tidak nyaman dan tidak relevan untuk kasus penggunaan saya.
9
dsimcha

Seringkali saya menggunakan milik saya sendiri karena saya membangunnya sebelum saya menemukan yang sudah ada sebelumnya, dan saya terlalu malas untuk mencari dan mengganti setiap contoh. Juga, saya sepenuhnya memahami metode saya sendiri sementara saya mungkin tidak mengerti yang sudah ada sebelumnya. Dan akhirnya, karena saya tidak sepenuhnya memahami yang sudah ada saya tidak dapat memverifikasi bahwa itu benar-benar melakukan semua yang saya lakukan saat ini.

Ada banyak yang harus dikodekan, dan saya tidak punya banyak waktu untuk kembali dan mengkode ulang sesuatu kecuali itu berdampak pada produksi.

Bahkan, satu aplikasi web asp yang masih digunakan saat ini memiliki bagan yang berfungsi penuh yang menampilkan data dalam format tabular dan memungkinkan penyortiran/pengeditan, namun itu bukan datagrid. Itu dibangun beberapa tahun yang lalu ketika saya pertama kali belajar asp.net dan tidak tahu datagrid. Saya agak takut pada kode karena saya tidak tahu apa yang saya lakukan saat itu, tetapi bekerja, akurat, mudah dimodifikasi, tidak macet, dan pengguna menyukainya

5
Rachel

Apakah menemukan kembali roda atau tidak merupakan hal biaya/manfaat. Biaya cukup jelas ...

  • Dibutuhkan banyak waktu untuk melakukan reinventing.
  • Bahkan lebih banyak waktu untuk mendokumentasikan apa yang telah Anda temukan.
  • Anda tidak dapat mempekerjakan orang yang sudah mengerti apa yang Anda temukan.
  • Sangat mudah untuk menemukan kembali sesuatu yang buruk, menyebabkan biaya berkelanjutan untuk masalah yang disebabkan oleh desain yang buruk.
  • Kode baru berarti bug baru. Kode lama biasanya sudah menghilangkan sebagian besar bug, dan mungkin memiliki solusi halus untuk masalah yang tidak Anda sadari dan karena itu tidak dapat menyelesaikan masalah dalam desain baru.

Yang terakhir penting - ada posting blog di suatu tempat yang memperingatkan tentang kecenderungan untuk "membuang kode lama dan memulai dari awal" dengan dasar bahwa banyak kesalahan lama yang tidak Anda pahami sebenarnya adalah perbaikan bug yang penting. Ada kisah peringatan tentang Netscape, IIRC.

Keuntungannya bisa ...

  • Kemampuan untuk menambahkan fitur yang tidak dimiliki perpustakaan yang ada. Sebagai contoh, saya memiliki wadah yang "mempertahankan" contoh iterator/kursor mereka. Sisipan dan penghapusan tidak membatalkan iterator. Iterator yang menunjuk ke vektor akan terus menunjuk ke item yang sama (bukan indeks yang sama) terlepas dari sisipan dan penghapusan sebelumnya dalam vektor. Anda tidak bisa melakukannya dengan kontainer C++ standar.
  • Desain yang lebih terspesialisasi yang menargetkan kebutuhan khusus Anda dan menghormati prioritas Anda (tetapi waspadalah dengan kecenderungan ke arah efek dalam-platform).
  • Kontrol penuh - beberapa pihak ketiga tidak dapat memutuskan untuk mendesain ulang API dengan cara yang berarti Anda harus menulis ulang setengah aplikasi Anda.
  • Pemahaman lengkap - Anda telah mendesainnya seperti itu, jadi semoga Anda sepenuhnya memahami bagaimana dan mengapa Anda melakukannya.
  • SUNTING Anda dapat mempelajari pelajaran dari perpustakaan lain tanpa terjebak dalam perangkap yang sama dengan menjadi selektif tentang bagaimana Anda meniru mereka.

Satu hal - menggunakan perpustakaan pihak ketiga dapat dihitung sebagai menciptakan kembali roda. Jika Anda sudah memiliki perpustakaan kuno, bekas, dan teruji dengan baik, pikirkan dengan cermat sebelum membuangnya untuk menggunakan perpustakaan pihak ketiga. Ini mungkin merupakan ide yang bagus dalam jangka panjang - tetapi mungkin ada banyak pekerjaan dan banyak kejutan buruk (dari perbedaan semantik antara perpustakaan) sebelum Anda sampai di sana. Sebagai contoh, pertimbangkan efek saya beralih dari wadah saya sendiri ke yang perpustakaan standar. Terjemahan naif dari kode panggilan tidak akan memungkinkan fakta bahwa kontainer perpustakaan standar tidak mempertahankan iteratornya. Kasus di mana saya menyimpan iterator untuk nanti sebagai "bookmark" tidak dapat diimplementasikan menggunakan terjemahan sederhana sama sekali - saya memerlukan beberapa cara alternatif non-sepele untuk menunjukkan posisi bookmark.

4
Steve314

Menemukan kembali roda adalah cara yang bagus untuk belajar bagaimana roda bekerja, tetapi itu bukan cara yang baik untuk membangun mobil.

4
Dima

Saat ini saya bekerja untuk sekelompok pelit.

Ketika keputusan dibuat antara "membangun atau membeli", alih-alih membuat keputusan rasional berdasarkan ekonomi, para manajer memilih untuk "membangun." Ini berarti bahwa alih-alih membayar beberapa ribu dolar untuk komponen atau alat, kita menghabiskan waktu berbulan-bulan untuk membangun sendiri. Membeli roda dari perusahaan lain membutuhkan biaya yang keluar dari anggaran - yang dihitung dengan bonus akhir tahun yang tidak dikelola dengan baik. Waktu pemrogram gratis dan karenanya tidak dihitung terhadap bonus akhir tahun (dengan manfaat tambahan dari pemrogram untuk tidak menyelesaikan semuanya "tepat waktu"), oleh karena itu roda yang diciptakan kembali adalah roda gratis .

Dalam perusahaan yang rasional, biaya vs manfaat dari pembelian roda yang dibuat oleh orang lain vs menciptakan kembali roda sendiri akan didasarkan pada biaya jangka pendek dan jangka panjang, serta biaya peluang yang hilang karena seseorang tidak dapat membuat widget baru ketika satu menciptakan kembali roda. Setiap hari Anda menghabiskan menciptakan kembali roda adalah hari lain Anda tidak dapat menulis sesuatu yang baru.

Presentasi tentang build vs beli .
Artikel tentang build vs buy .

Jika saya melihat seseorang dengan jelas menciptakan kembali roda dengan membangun metode mereka sendiri dari sesuatu yang sudah dibangun ke dalam bahasa/kerangka kerja. Pertama, demi argumen, mari kita asumsikan bahwa metode mereka sama efisiennya dengan metode bawaan. Juga pengembang, menyadari metode bawaan, lebih memilih metode sendiri.

Mengapa ia harus menggunakan built in di atas miliknya sendiri?

Versi built-in akan memiliki lebih banyak orang yang menggedornya - sehingga menemukan dan memperbaiki lebih banyak bug daripada yang bisa dilakukan oleh kode homebrew Anda.

Akhirnya, ketika pengembang lokal Anda pergi, dan orang lain harus mempertahankan kode yang ia tulis, kode itu akan benar-benar diperbarui dan diganti dengan apa yang ada. dalam kerangka itu. Saya tahu ini akan terjadi karena majikan saya saat ini memiliki kode yang telah dimigrasi ke versi yang lebih baru dari VB selama bertahun-tahun (produk tertua telah ada di pasaran selama sekitar 20 tahun) dan inilah yang telah terjadi, pengembang dengan pekerjaan terlama di kantor saya sudah 17 tahun di sini.

4
Tangurena

Hal tentang menciptakan kembali roda adalah bahwa kadang-kadang tidak ada roda standar yang tersedia untuk melakukan apa yang Anda butuhkan. Ada banyak roda bagus di luar sana, dalam banyak ukuran, warna, bahan, dan mode konstruksi. Tetapi beberapa hari Anda hanya perlu memiliki roda yang benar-benar ringan yang terbuat dari aluminium anodized hijau, dan tidak ada yang membuatnya. Dalam hal ini, Anda HARUS membuatnya sendiri.

Nah, itu bukan untuk mengatakan bahwa Anda harus membuat roda sendiri untuk setiap proyek - kebanyakan hal dapat menggunakan bagian standar dan lebih baik untuk itu. Tetapi setiap sekarang dan kemudian, Anda menemukan bahwa bagian standar tidak berfungsi, sehingga Anda membuat bagian Anda sendiri.

Yang paling penting adalah mengetahui KAPAN membuat milik Anda sendiri. Anda harus memiliki gagasan yang baik tentang apa yang dapat dilakukan bagian standar, dan apa yang tidak bisa dilakukan, sebelum Anda mulai mendesain sendiri.

4
Michael Kohne

Menjadi "buruk" atau bahkan "jahat" adalah kata-kata yang agak kuat.

Seperti biasa, selalu ada alasan untuk memilih implementasi pribadi daripada implementasi internal. Di masa lalu program C mungkin menemukan bug di pustaka runtime, dan karena itu cukup harus menyediakan implementasinya sendiri.

Ini tidak berlaku untuk program Java karena JVM didefinisikan dengan sangat ketat, tetapi beberapa algoritma masih sangat sulit untuk diperbaiki. Misalnya Joshua Bloch menjelaskan bagaimana algoritma pencarian biner sederhana yang menipu di Java perpustakaan runtime berisi bug, yang butuh sembilan tahun untuk muncul:

http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

Itu ditemukan, diperbaiki dan didistribusikan di masa depan Java distribusi.

Jika Anda menggunakan pencarian biner bawaan, Anda hanya menghemat waktu dan uang dengan meminta Sun melakukan kerja keras untuk menemukan, memperbaiki, dan mendistribusikan perbaikan bug ini. Anda dapat memanfaatkan pekerjaan mereka hanya dengan mengatakan "Anda membutuhkan setidaknya Java 6 pembaruan 10").

Jika Anda menggunakan implementasi Anda sendiri - yang kemungkinan besar akan mengandung kesalahan ini juga - Anda pertama-tama membutuhkan bug untuk memanifestasikan dirinya. Mengingat bahwa yang satu ini hanya menunjukkan pada dataset BESAR, itu pasti terjadi dalam produksi di suatu tempat, yang berarti setidaknya satu dari pelanggan Anda akan terpengaruh dan kemungkinan besar kehilangan uang sungguhan saat Anda menemukan, memperbaiki, dan mendistribusikan perbaikan bug.

Jadi, sangat sah untuk memilih implementasi Anda sendiri, tetapi alasannya lebih baik benar-benar baik, karena itu pasti lebih mahal daripada meningkatkan pekerjaan orang lain.

3
user1249

Jika ada komponen yang berfungsi yang melakukan apa yang Anda butuhkan lalu mengapa menghabiskan waktu menulis dan men-debug versi Anda sendiri? Demikian pula, jika Anda sudah menulis kode untuk memenuhi fungsi yang sama sebelumnya, mengapa menulis ulang?

Joel menulis sebuah artikel pada Tidak-ditemukan-di sini yang berbicara banyak tentang kapan menulis ulang kode dan perangkat lunak tidak dan tidak berguna.

3
Dave

Menciptakan kembali roda dapat menjadi cara yang bagus untuk belajar bagaimana sesuatu bekerja - dan saya sarankan menciptakan kembali untuk tujuan itu pada waktu Anda sendiri - tetapi ketika menulis aplikasi mengapa menemukan kembali jika ada solusi mapan yang sudah melakukan hal yang sama?

Misalnya, saya tidak akan pernah menulis kode JavaScript dari awal; sebaliknya saya akan mulai dengan jQuery dan membangun aplikasi saya di atas kerangka itu.

3
Justin Ethier

Aturan praktis saya:

Menciptakan kembali roda adalah hal yang baik ketika Anda baru belajar. Jika Anda memiliki tenggat waktu, Anda mungkin ingin menggunakan roda yang ada.

3
John

Saya baru-baru ini blog saya pikir saya pada topik ini. Untuk meringkas:

  1. Ini hampir selalu jahat untuk membangun Anda sendiri, terutama benar jika fungsi yang dibangun ke dalam bahasa. Tetapi jika Anda mengevaluasi kerangka kerja yang belum matang/dipelihara dengan buruk/tidak terdokumentasi dengan baik yang Anda temukan di Internet terhadap kemungkinan menulis sendiri, itu bisa jadi tidak ada gunanya.

  2. Saya pikir reinventing the wheel adalah analogi yang cukup mengerikan untuk anti-pola perangkat lunak. Ini menyiratkan bahwa solusi asli tidak pernah dapat diperbaiki. Itu omong kosong. Roda yang disebut bisa menjadi usang dalam semalam, atau pemiliknya bisa berhenti memeliharanya. Roda memiliki nilai berbeda di setiap sistem tempat ia digunakan. Jadi, seringkali sangat mungkin untuk menciptakan roda yang lebih baik.

  3. Salah satu manfaat utama membuat kerangka kerja Anda sendiri adalah Anda tidak perlu bertanggung jawab atas bug orang lain. (Ini filosofi Amazon .) Pikirkan seperti ini: yang mana yang lebih baik untuk diceritakan pada pelanggan? -

    "Situs web kami rusak. Itu adalah kesalahan orang lain, dan kami telah mencatat bug dengan penciptanya. Tidak ada yang bisa kami lakukan selain menunggu. Kami akan terus mengabari Anda."

    "Situs web kami rusak, dan kami dapat segera memperbaikinya."

3
realworldcoder

Mungkin sama efisiennya, tetapi apakah kuat? Saya pikir alasan paling menarik untuk menggunakan pustaka daripada menggulirkan pustaka Anda sendiri adalah bahwa kerangka kerja ini memiliki begitu banyak orang yang menggunakannya sehingga mereka dapat menemukan dan memperbaiki bug dengan cepat. Pustaka yang dikembangkan in-house, sementara mereka dapat menyediakan fungsionalitas sebanyak (atau lebih), tidak dapat bersaing dengan perpustakaan dengan jutaan pengguna untuk menyediakan pengujian di hampir setiap kasus penggunaan. Anda tidak bisa mengalahkan pengujian semacam itu di rumah.

0
Michael K

Yah, metodenya sendiri yang seefisien kerangka kerja akan sangat jarang karena sebagian besar kerangka kerja masih memiliki bug dan tidak ada kerangka kerja yang dapat memberi Anda solusi out of the box. Sebagian besar programmer yang tidak dapat berpikir tidak akan pernah mencoba menulis apa pun di tingkat kerangka kerja; mereka hanya akan mencari Google untuk solusi yang sudah jadi. Setiap programmer yang bijak akan terlebih dahulu melihat apakah ada kerangka kerja gratis yang memiliki fungsi yang dia butuhkan, dan kemudian menulis solusinya sendiri jika tidak ada. Terkadang terlalu sulit untuk menjelaskan situasi proyek saat ini dan pengembang adalah juri terbaik.

Menemukan kembali roda tidak buruk, itu adalah pernyataan yang dibuat oleh orang-orang malas untuk menghindari kerja keras. Bahkan penulis kerangka kerja pun menemukan kembali; seluruh kerangka .Net diciptakan kembali untuk melakukan apa yang COM tawarkan.

0
Akash Kava

Meskipun mungkin tidak sopan bagi sebagian orang, saya selalu menganggap istilah ini tidak paham ketika digunakan oleh segala bentuk insinyur atau merujuk pada topik membuat atau merancang sesuatu. Kenyataannya, saya tidak dapat menahan diri untuk melihatnya sebagai sesuatu yang tidak jujur ​​ketika mempertimbangkan tekanan untuk berinovasi di dunia yang serba cepat saat ini. Mengulangi diri Anda sendiri (atau mengabaikan solusi yang sudah ada sebelumnya) tidak pernah bijaksana, tetapi sungguh, ada alasan mengapa kita tidak semua masih menatap layar hitam penuh dengan huruf hijau.

Saya mengerti "Jika tidak rusak jangan memperbaikinya", meskipun saya kira kalimat seperti itu mungkin terdengar bodoh bagi sebagian orang. Namun dengan upaya saat ini untuk menemukan kembali roda untuk kebutuhan perjalanan ruang angkasa, balap, pengiriman, dll, "jangan menemukan kembali roda" juga cukup bodoh, dan tidak ada yang dekat sepintar kedengarannya.

Latar belakang saya terdiri dari memimpin banyak proyek dan saya harus bekerja dengan banyak pekerja magang dan bentuk-bentuk pengembang hijau lainnya, dan saya harus menangani banyak pertanyaan naif yang beberapa orang sebut 'bodoh', dan juga harus mengalihkan orang dari mengejar kelinci. keutuhan di luar lingkup tugas mereka. Namun, saya akan tidak pernah mencegah inovasi atau kreativitas, dan telah melihat hal-hal besar datang dari 'menciptakan kembali roda'.

Jawaban aktual saya atas pertanyaan: Hanya ada dua situasi yang membuat penemuan kembali roda adalah hal yang buruk:

  1. Jika tidak benar-benar dibutuhkan
  2. Jika orang lain yang melakukannya ketika Anda bisa melakukannya

Sunting: Saya dapat melihat dengan suara turun drive-by bahwa saya pasti telah menyinggung beberapa. Satu hal yang ingin saya tambahkan adalah frasa ini selalu mengesalkan saya. Saya mengerti bahwa dua sen saya mungkin terdengar agak trollish, tetapi saya tidak punya niat untuk troll, menyebabkan kebakaran, atau menyinggung.

0
JSON

Argumen tentang "reinventing a wheel" sering digunakan dalam konteks yang salah memilih untuk menggunakan perpustakaan tetapi itu hampir tidak sama.

Katakanlah saya sedang mengevaluasi perpustakaan 'formulir-plus', yang baru saja populer baru-baru ini dan membantu menangani formulir. Ini memiliki halaman arahan yang bagus, grafik keren modern, dan -cult- (komunitas maksudku) di sekitarnya yang bersumpah bagaimana membuat bentuk menjadi hebat lagi. Tetapi "bentuk-plus" adalah abstraksi di atas "bentuk". "Bentuk" itu mungkin tetapi rumit untuk dihadapi, jadi abstraksi yang membuatnya lebih mudah menjadi populer.

Abstraksi baru terjadi setiap saat. Sulit untuk membandingkannya dengan roda. Ini lebih seperti perangkat kontrol baru dan manual baru untuk perangkat apa pun yang sudah sangat rumit yang harus Anda jalankan.

Penilaian perangkat baru ini "formulir-plus" akan terlihat berbeda tergantung pada pengalaman pribadi. Jika saya tidak pernah membuat formulir sebelumnya maka "formulir-plus" akan sangat menarik karena lebih mudah untuk memulai. Kelemahannya adalah jika "bentuk-plus" ternyata abstraksi bocor saya masih perlu belajar "bentuk". Jika saya sedang membangun formulir tanpa "formulir-plus" maka saya harus memperhitungkan waktu bahwa saya perlu mempelajari alat baru. Terbalik adalah bahwa saya sudah tahu "bentuk" jadi saya tidak takut abstraksi di atasnya. Manfaat jangka pendek akan lebih besar untuk pemula baru karena mungkin tidak akan ada perpustakaan baru jika tidak memperbaiki sesuatu. Manfaat jangka panjang akan sangat bervariasi pada kualitas abstraksi, tingkat adopsi, dan faktor-faktor lain yang sudah dibahas dalam jawaban lain.

Setelah mengevaluasi dengan hati-hati manfaat dan negatif dari menggunakan abstraksi baru "formulir-plus" vs menggunakan "bentuk" tulang kosong saya membuat keputusan. Keputusan sangat didasarkan pada pengalaman pribadi saya dan orang yang berbeda akan membuat keputusan yang berbeda. Saya mungkin telah memilih untuk menggunakan "bentuk" tulang kosong. Mungkin nanti dalam bentuk waktu-plus telah mendapatkan lebih banyak gerakan di belakangnya dan menjadi standar de facto. Dan mungkin implementasi saya sendiri dari waktu ke waktu menjadi berbulu dan mulai mencakup banyak apa bentuk-plus sekarang lakukan. Orang-orang yang datang pada saat ini akan tertarik untuk mengkritik bahwa saya ingin menciptakan kembali roda dan saya seharusnya menggunakan perpustakaan yang ada. Tetapi juga mungkin bahwa pada saat saya harus membuat keputusan tentang "bentuk-plus" ada juga beberapa alternatif lain untuk "bentuk-plus", kebanyakan dari mereka adalah proyek mati sekarang, dan mungkin saya memperolehnya dengan tidak memilih yang salah. satu.

Pada akhirnya memilih alat yang tepat adalah keputusan yang rumit untuk dibuat dan "reinvention of wheel" bukanlah perspektif yang sangat membantu.

0
Ski