Apakah "jangan menemukan kembali roda" mengabaikan batas ingatan manusia?

Satu hal yang diajarkan di Haskell dan F # kepada saya adalah bahwa seseorang di universitas yang lebih pintar daripada saya mungkin sudah menemukan abstraksi atas apa yang saya lakukan. Demikian juga dalam pemrograman C # dan berorientasi objek, mungkin ada perpustakaan untuk "itu", apa pun yang saya lakukan.

Ada penekanan pada penggunaan kembali abstraksi dalam pemrograman sehingga saya sering merasakan dilema antara: 1) hanya mengkode sesuatu yang pendek dan kotor sendiri atau 2) menghabiskan waktu yang sama untuk menemukan perpustakaan / solusi orang lain yang lebih kuat dan hanya menggunakannya.

Seperti baru-baru ini salah satu coders di sini menulis serializer (de) untuk file CSV, dan saya tidak bisa tidak berpikir bahwa sesuatu seperti itu mungkin sangat mudah ditemukan online, jika belum datang dengan standar .NET Lebah.

Saya tidak menyalahkannya, beberapa kali bekerja di. NET Saya telah menambal solusi berdasarkan apa yang saya tahu, hanya untuk menyadari bahwa ada beberapa metode pemanggilan atau objek atau sesuatu , sering di perpustakaan yang sama, yang melakukan apa Saya ingin dan saya tidak tahu tentang itu.

Apakah ini hanya pertanda pengalaman kurang, atau apakah selalu ada unsur pertukaran antara menulis baru dan menggunakan kembali yang lama? Yang paling saya benci adalah ketika saya menemukan solusi yang sudah saya ketahui dan lupakan. Saya merasa seperti satu orang saja yang tidak mampu mencerna jumlah kode yang dikemas dengan sebagian besar bahasa saat ini.

Pertama, Anda perlu belajar mengidentifikasi "komponen" yang cukup umum / dapat digunakan kembali sehingga perpustakaan atau solusi pihak ke-3 kemungkinan sudah ada. Setelah Anda melakukannya, sadari bahwa, bahkan jika Anda adalah pengembang yang baik, pengalaman kolektif dari banyak pengembang yang menghabiskan waktu berjam-jam untuk masalah yang sama kemungkinan telah menghasilkan solusi yang lebih baik daripada yang bisa Anda lakukan. Itu tidak berarti Anda tidak boleh "menemukan kembali roda", tetapi jika Anda memilih untuk melakukannya, Anda sebaiknya memiliki DAMN pembenaran yang baik untuk melakukannya.

Ada penekanan pada penggunaan kembali abstraksi dalam pemrograman sehingga saya sering merasakan dilema antara: 1) hanya mengkode sesuatu yang pendek dan kotor sendiri atau 2) menghabiskan waktu yang sama untuk menemukan perpustakaan / solusi orang lain yang lebih kuat dan hanya menggunakannya.

Itu layak disebut bahwa bahkan jika itu membawa Anda jumlah yang sama waktu untuk menemukan sebuah perpustakaan / solusi yang ada seperti halnya untuk menulis sendiri, ingatlah bahwa melakukannya sendiri juga berarti Anda harus mempertahankannya selamanya . Anda tidak hanya menciptakan kembali roda, tetapi juga seluruh kru pit agar tetap berjalan. Tentu saja, beberapa perpustakaan bermasalah atau tidak dirawat dengan baik, tetapi ini adalah hal yang harus Anda ingat ketika memilih solusi pihak ke-3.

Kadang-kadang ini merupakan pertanda dari kurang pengalaman, apakah dengan bahasa tertentu atau dengan pemrograman pada umumnya. Kadang-kadang, meskipun, jika cocok tidak jelas itu hanya baik untuk roll kode Anda sendiri yang tidak persis apa yang Anda inginkan dan tidak lebih . Perpustakaan umum, walaupun sering bermanfaat, dapat dibangun untuk persyaratan yang tidak Anda miliki, dan dalam beberapa kasus tingkat kedermawanan ini dapat membuatnya lebih banyak masalah daripada nilainya.

Contoh: Untuk proyek one-man kecil saya, saya tidak pernah menggunakan perpustakaan logging "nyata". Saya menggunakan printpernyataan plus sedikit konfigurasi ad-hoc. Saya tidak ingin diganggu dengan pengaturan dan konfigurasi pustaka logging yang memiliki lebih banyak fitur daripada yang pernah saya gunakan, ketika printpernyataan berfungsi dengan baik untuk tujuan saya. Saya juga belum menginginkan dependensi lain yang mungkin tidak kompatibel dengan versi kompiler / juru bahasa yang ingin saya gunakan, harus didistribusikan, dll.

Selamat datang di dunia pemrograman. Masalah ini akan menjadi subjek dari banyak perselisihan antara Anda dan kolega Anda di masa depan. Anda memiliki dua opsi:

1. Gulung sendiri.
2. Bangun sesuatu di atas solusi orang lain.

Saya pikir ada saat-saat di mana kedua solusi itu tepat. Sebagai contoh, saya lebih suka untuk tidak memutar parser CSV saya sendiri dari ORM jika saya bisa menghindarinya karena itu pekerjaan yang cukup membosankan. Di sisi lain, perpustakaan sering dibatasi. Saya akan mengatakan bahwa untuk setiap proyek yang saya kerjakan, saya telah menemukan perpustakaan yang akan menyelesaikan masalah saya dengan sempurna jika bukan karena kekurangan yang satu ini. Atau kadang-kadang perpustakaan adalah persis apa yang Anda butuhkan saat pertama kali mulai melakukan sesuatu, tetapi lebih berbahaya daripada bantuan begitu Anda perlu melakukan perubahan.

Namun secara umum, saya menyarankan untuk tidak mencoba menemukan jawaban yang "benar" karena tidak ada. Jika ragu, pergilah dengan ususmu. Saya pernah mendengar seseorang berkata bahwa pengalaman ditentukan oleh berapa banyak kesalahan bodoh yang Anda lakukan. Jadi biasanya, Anda akan belajar sesuatu atau membuat sesuatu yang berhasil. Either way, itu tidak semuanya buruk.

Ini (atau hal serupa) sering terjadi pada saya di pekerjaan sebelumnya di mana kerangka kerja itu menderita Efek Platform Dalam yang parah.

Pada dasarnya, basis kode mereka berevolusi dari hari-hari awal Windows C / C ++, kemudian mulai dikompilasi di bawah MFC - dan para pemelihara mulai mencampur MFC dan struktur data lama di rumah dan komponen windowing. Platform dalam tidak didokumentasikan dengan baik, tetapi seharusnya "The Way" untuk melakukan sesuatu pada produk itu, karena beberapa fasilitas internal yang disediakannya. Saya sering merasa lebih mudah dan lebih cepat untuk menulis barang-barang saya sendiri dari awal (dari dasar-dasar MFC), daripada mencari tahu bagaimana melakukannya dengan kerangka kerja internal perusahaan.

(Oke, jadi ini tampaknya hampir kebalikan dari poin awal Anda - tetapi prinsipnya sama, hehe! Ya, kadang-kadang lebih cepat melakukan hal Anda sendiri daripada menghabiskan waktu dan upaya untuk menemukan yang ada dapat digunakan kembali. larutan.)