Apa yang dianggap sebagai menciptakan kembali roda?

Apakah skenario berikut ini dihitung sebagai "menciptakan kembali roda" dalam buku Anda?

• Ada solusi, tetapi tidak dalam bahasa yang ingin Anda gunakan, dan solusi yang ada tidak dapat dihubungkan dengan bahasa yang ingin Anda gunakan dengan cara yang bersih dan idiomatis.

• Pada prinsipnya Anda bisa mendapatkan perpustakaan yang ada untuk melakukan apa yang Anda inginkan dengan modifikasi berat, tetapi Anda pikir mungkin akan lebih mudah untuk hanya memulai dari awal.

• Apa yang Anda tulis memiliki deskripsi satu baris yang sama dengan hal-hal yang sudah dilakukan, tetapi Anda menargetkan ceruk yang berbeda. Misalnya, mungkin masalah Anda telah dipecahkan jutaan kali sebelumnya, tetapi dengan cara yang tidak efisien untuk kumpulan data besar dan kode Anda berfungsi dengan baik untuk kumpulan data besar.

Jika ada solusi yang ada di mata Anda akan menjadi solusi praktis , maka tidak menggunakan itu tetapi menciptakan solusi Anda sendiri akan menciptakan kembali roda. Selain itu, sangat subjektif.

Tentang skenario spesifik Anda:

1. Anda selalu ingin kode yang bersih, mudah dipelihara, dan mudah dipahami. Itu berjalan di atas menciptakan kembali roda, IMHO. Kendala waktu mungkin membuat Anda ingin memecahkan ini.
2. Jika lebih mudah untuk memulai dari awal, lakukanlah. Anda juga mungkin akan mendapatkan hasil yang lebih baik jika kode tersebut disesuaikan dengan kebutuhan tertentu.
3. Jika solusi adalah solusi buruk untuk masalah Anda, itu bukan menciptakan kembali roda untuk membuat yang baru, itu membuat roda yang lebih baik .

Menemukan kembali roda adalah apa yang orang lain tuduh ketika analisis Anda menunjukkan Anda harus menulis sesuatu sendiri dan mereka tidak.

Saya pikir menciptakan kembali roda dapat didefinisikan dengan cukup sederhana: ketika, dalam jangka panjang, Anda lebih banyak bekerja menulis sendiri daripada menggunakan perpustakaan. Perhatikan bahwa tidak selalu jelas berapa banyak pekerjaan dalam jangka panjang . Anda mungkin dapat meretas prototipe sendiri lebih cepat daripada Anda dapat memperbaiki kode yang ada untuk memasukkan pustaka, tetapi, dalam jangka panjang, ketika Anda menambahkan lebih banyak kemampuan atau harus mendukung kode, pustaka akan bekerja lebih baik.

Intinya adalah, Anda perlu melakukan beberapa pemikiran cermat tentang situasi Anda saat memutuskan apakah akan menggunakan perpustakaan atau tidak. Anda perlu memutuskan apakah perpustakaan lebih mudah untuk apa yang ingin Anda lakukan sekarang dan lebih mudah untuk apa yang akan Anda lakukan di masa depan . Mengetahui apa yang akan Anda lakukan di masa depan tidak selalu lurus ke depan, tetapi jika Anda memiliki rencana yang baik, Anda harus memiliki ide kasar. Yang mengatakan, kadang-kadang ramalan tidak akurat - Anda biasanya tidak menyadari Anda telah menciptakan kembali roda sampai setelah Anda melakukannya.

Terlalu luas dan subyektif untuk dapat menjawab dengan akurasi hanya karena setiap kasus berbeda.

Sangat dapat diterima untuk menemukan kembali roda jika perlu, kuncinya adalah menggunakan penilaian Anda untuk memutuskan kapan roda sebelumnya merupakan solusi yang dapat diterima dan ketika itu tidak cukup bulat untuk memberikan perjalanan yang mulus.

Ini adalah pertanyaan yang perlu ditanyakan hampir secara retoris pada waktu-waktu tertentu untuk memastikan bahwa pendekatan terbaik sedang digunakan. Anda sering dapat menemukan algoritme yang lebih baik dalam sebuah buku daripada yang bisa ditulis oleh kebanyakan programmer dalam waktu yang dibutuhkan untuk menemukannya.

Semakin besar dan semakin kompleks masalahnya, semakin kecil kemungkinan ada roda yang sesuai dengan kebutuhan Anda, dan semakin sah Anda untuk membangunnya kembali.

Saya pikir kita hanya harus menerapkan "jangan menemukan kembali roda" untuk elemen dasar (fungsi yang sudah dibangun di platform, pola desain terkenal ...) atau jika solusi tepat untuk masalah Anda tersedia - tetapi itu adalah jarang terjadi.

3 poin Anda tidak dihitung sebagai menciptakan kembali roda kepada saya.

Itu tergantung ...

Untuk dua yang pertama:

• Ada solusi, tetapi tidak dalam bahasa yang ingin Anda gunakan ...
• Pada prinsipnya Anda bisa mendapatkan perpustakaan yang ada untuk melakukan apa yang Anda inginkan dengan modifikasi berat ...

Dalam kedua kasus ini, masuk akal untuk menulis kode Anda sendiri. Tetapi pertimbangkan ini: apakah solusi yang ada mengandung teknik, algoritma atau rutinitas apa saja yang dapat Anda pelajari? Mengabaikan ini akan menciptakan kembali roda.

• Apa yang Anda tulis memiliki deskripsi satu baris yang sama dengan hal-hal yang sudah dilakukan ... mungkin masalah Anda telah diselesaikan jutaan kali sebelumnya, tetapi dengan cara yang tidak efisien untuk kumpulan data besar ...

Tiga pertanyaan:

1. Miliaran banyak. Sudahkah Anda benar-benar melihat semua implementasi yang ada?
2. Apakah efisiensi adalah masalah utama Anda?
3. Apakah Anda perlu kode solusi optimal sekarang (dan tulis ulang nanti)?

Jika jawaban untuk semua ini adalah "Tidak", Anda menciptakan kembali kemudi.

Yang mengatakan, saya tidak yakin bahwa menciptakan kembali roda selalu merupakan hal yang buruk:

1. Ini adalah cara yang bagus untuk belajar , dan satu-satunya cara untuk benar-benar memahami solusi yang ada.
2. Roda orang lain mungkin tidak baik . Ini adalah satu-satunya cara untuk membuat roda yang lebih baik.
3. Sekalipun roda orang lain hebat, terkadang Anda bisa membuat bisnis yang bagus dengan membuat roda yang lebih baik .

Skenario pertama Anda, memang berlaku untuk menemukan kembali roda, itu menjelaskan sendiri.

Skenario kedua, TIDAK berlaku jika kode yang ada hanya membutuhkan sedikit modifikasi, tetapi jika ya, ide yang baik untuk mencoba menggunakan properti, metode, dan penggunaan yang serupa dari kode yang ada, sehingga pengembang lain tidak mengalami kesulitan dalam menggunakan "roda".

Hati-hati dengan pendekatan "selalu lebih baik untuk memulai dari kemarahan", mungkin butuh lebih banyak waktu daripada yang Anda harapkan.

Skenario ketiga yang Anda sebutkan, itu pendekatan "praktis". "Roda yang diberikan" dapat melakukan pekerjaan itu, tetapi, pada kenyataannya, menghabiskan terlalu banyak sumber daya, memori, kecepatan, dll.

Saya pernah bekerja di aplikasi yang perlu menampilkan data hierarki dalam kontrol treeview dari tabel tunggal. Kami sudah memiliki kontrol yang bisa melakukan itu, tetapi mendukung beberapa tabel, per item.

Untuk menggunakannya, saya harus belajar banyak hal, menetapkan terlalu banyak properti, mengeksekusi terlalu banyak metode, dan ITU LAMBAT. Seorang rekan kerja bersikeras untuk menggunakannya, agar "tidak menemukan kembali roda".

Saya melakukan kontrol baru, dari nol, membaca satu tabel, memprogram hanya beberapa properti yang mudah dipelajari. Dan sebelum saya menyadarinya, ada rekan kerja lain yang mengambilnya dari repositori kode bersama, dan menggantikan kontrol sebelumnya.

Bonus:

Ketika roda yang sudah Anda miliki adalah "kuadrat". Dengan "kuadrat", maksud saya di permukaan, sepertinya itu memang terlihat seperti solusi untuk masalah Anda, tetapi setelah melihat dengan baik, Anda sampai pada kesimpulan, itu tidak.

Itu tergantung jika Anda memiliki keterampilan, dan waktu, (dan otorisasi perusahaan Anda), untuk menemukan kembali roda.

Pertama-tama baca artikel hebat ini oleh Joel Spolsky: Defence of Not-Invented-Here Syndrome

Maka semua alasan teknis menjadi nuansa yang sangat kecil. Jika Anda merasa perangkat lunak ini penting untuk pekerjaan Anda, tulis ulang. Ya itu "menciptakan kembali roda" tetapi mungkin perlu menghabiskan waktu untuk menulis dan memelihara. Jika tidak kritis, gunakan saja apa yang tersedia.

... jika Anda pernah melakukan outsourcing fungsi bisnis penting, Anda menyadari bahwa outsourcing adalah neraka. Tanpa kontrol langsung terhadap layanan pelanggan, Anda akan mendapatkan layanan pelanggan yang buruk - seperti yang ditulis orang di weblog mereka ketika mereka mencoba membuat seseorang, siapa saja , dari perusahaan telepon untuk melakukan hal yang paling mendasar sekalipun. Jika Anda memasang iklan pemenuhan, dan mitra pemenuhan Anda memiliki gagasan berbeda tentang apa yang dimaksud dengan pengiriman cepat, pelanggan Anda tidak akan bahagia, dan tidak ada yang dapat Anda lakukan tentang hal itu, karena butuh 3 bulan untuk menemukan mitra pemenuhan di pertama tempat, dan pada kenyataannya, Anda bahkan tidak akan tahubahwa pelanggan Anda tidak bahagia, karena mereka tidak dapat berbicara dengan Anda, karena Anda telah mendirikan pusat layanan pelanggan outsourcing dengan tujuan eksplisit untuk tidak mendengarkan pelanggan Anda sendiri. Mesin e-commerce yang Anda beli? Tidak mungkin itu akan sefleksibel apa yang dilakukan Amazon dengan obidos, yang mereka tulis sendiri. (Dan jika ya, maka Amazon tidak memiliki keunggulan dibandingkan pesaing mereka yang membeli hal yang sama). Dan tidak ada server web off-the-shelf yang akan secepat secepat apa yang Google lakukan dengan kode tangan mereka, server yang dioptimalkan dengan tangan.

Prinsip ini, sayangnya, tampaknya secara langsung bertentangan dengan ideal "kode menggunakan kembali baik - menciptakan kembali roda buruk."

Saran terbaik yang bisa saya tawarkan:

    Jika ini adalah fungsi bisnis inti - lakukan sendiri, tidak peduli apa

Pilih kompetensi dan sasaran bisnis inti Anda, dan lakukan itu ...

Jika Anda mengembangkan game komputer yang plotnya merupakan keunggulan kompetitif Anda, tidak apa-apa menggunakan perpustakaan 3D pihak ketiga. Tetapi jika efek 3D yang keren akan menjadi fitur pembeda Anda, Anda sebaiknya menggulung ...