Cukup sering Anda harus memenuhi rekomendasi "jangan menemukan kembali roda." Kadang-kadang dengan pengabaian yang dilafalkan dan penegasan diri, kadang-kadang, seolah-olah , nasihat yang baik. Namun, bahkan jika itu disebut sebagai saran yang disarankan, dalam sejumlah konteks itu hanya menunjukkan ketidakmampuan pembicara.
Tujuan kalimat ini adalah untuk menyelamatkan Anda dari pekerjaan yang tidak berguna, panggilan untuk menggunakan solusi siap pakai untuk tugas tersebut, dan dari sudut pandang pengamat luar, itu benar - benar terlihat masuk akal.
Tetapi pada saat yang sama, faktor kunci yang menjadi karakteristik tidak hanya untuk pengembangan perangkat lunak, tetapi juga untuk memecahkan masalah tidak terjawab : ketika mengubah konteks di mana tugas diatur, solusinya juga berubah .
Kehilangan prinsip ini sama dengan mengakui ketidakmampuan Anda sendiri untuk menyelesaikan masalah yang diterapkan.
Pertimbangkan beberapa kasus.
Sumber
API melalui API
Salah satu kasus umum tuduhan bersepeda adalah bungkus API tulisan sendiri dari beberapa layanan, yang implementasinya sudah tersedia.
Sebuah kasus dari tempat praktik saya.
Itu perlu untuk mengimplementasikan pengunggahan data dari Facebook ke layanan kami. Bahasa utama dan perpustakaan dari Facebook sendiri di-google-kan dalam 2 menit.
Dokumentasi perpustakaan tidak sesuai dengan antarmuka program saat ini , banyak tindakan yang tidak perlu dilakukan di setiap manipulasi. Perpustakaan itu ternyata berkualitas sangat buruk .
Hasil: setelah 1,5 jam bekerja dengannya, bahkan tidak mungkin untuk masuk.
Seorang kolega mengimplementasikan bungkus web-api Facebook-nya sendiri. Secara total, butuh sekitar satu jam untuk membuat pembungkus dan fungsionalitas terkait di sisi layanan. Untuk pertanyaan "mengapa kamu bersepeda di sini," jawabnya beberapa hari berikutnya.
Ini sangat jelas dalam bahasa umum dengan komunitas besar: ada kecenderungan tidak sehat untuk menerbitkan pembungkus API di atas API lain, di bawah slogan "Untuk manusia" dan "Dengan cara sederhana". Pembungkus seperti itu menjadi usang segera setelah antarmuka yang dibungkus diperbarui, dan penulis meninggalkan "proyek" tersebut, membuat kode yang menggunakannya tidak dapat digunakan.
Pertanyaan yang bagus : dan apa, setiap kali menulis pembungkus seperti itu secara manual?
Jawaban: Solusi yang jauh lebih kuat untuk pembungkus besar adalah dengan menggunakan generator kode yang menginterpretasikan spesifikasi.
Kontrol atas basis kode dan penolakan untuk menjawab kesalahan orang lain
Dalam lingkaran wannabe dalam pengembangan game komputer, frasa ini ditujukan kepada siapa saja yang berani menerapkan mesin mereka. "Mengapa menemukan kembali kemudi? Bersatu!" . Atau Pembuat Game, atau, Tuhan melarang, Defold.
Tampaknya konstruktor dviglo \ menyediakan semua alat yang diperlukan untuk pengembangan, banyak dari mereka adalah lintas platform dan umumnya menyederhanakan kehidupan.
Bagaimana konteksnya harus berubah di sini sehingga menjadi perlu untuk membuat mesin Anda sendiri?
Paling tidak, ini adalah kontrol atas basis kode dan fungsi mesin (misalnya, pada sejumlah model pengontrol pembuat game secara konsisten buggy, dan memperbaiki ini bisa sangat bermasalah). Artinya, perlu untuk mengurangi kemungkinan menemukan "bug asing" , yang tidak mungkin atau sangat sulit untuk diperbaiki sendiri.
Ini terutama diucapkan dalam permainan yang tidak jenuh dengan lonceng dan peluit grafis dan / atau fisik - klise, tidak begitu banyak mesin bersyarat mengambil sendiri.
Selain itu, tidak perlu menambah jumlah total basis kode jika sebagian kecil fungsinya digunakan dari mesin / konstruktor, dan alat yang diperlukan masih perlu ditambahkan secara independen , sekaligus mengendalikan kebenaran pekerjaan mereka dengan mesin.
Misalnya, berdasarkan tempat tersebut, Tommy Refenes menulis mesinnya sendiri untuk Super Meat Boy .
Seseorang akan keberatan: "Tapi di gudang \ penyimpanan lain, ada segunung preset \ tools \ ekstensi!" .
Ya, ini luar biasa, dan memberikan beberapa poin di depan, tetapi pada mesin dengan basis pengguna aktif yang besar, efek "die young" yang sama yang dijelaskan pada bagian sebelumnya cukup diperhatikan. Tanpa konteks dan tugas tertentu, tidak dapat dengan tegas menyatakan bahwa, de, kelimpahan ekstensi khusus di toko akan dimainkan.
Identitas imajiner. Menarik tugas dengan telinga.
Terkadang, setelah merumuskan masalah, ternyata solusi yang ada dalam pikiran ... tidak cocok. Karena "kandungan lemak" atau ketidakpuasan terhadap salah satu syarat utama tugas ( ya, ada beberapa ).
Contoh yang bagus: CluNet.
Cluster dalam artikelnya menggambarkan sepenuhnya alasan keputusan yang dibuat olehnya ketika mengembangkan protokol rumah pintar. Contohnya sangat terbuka dan dijelaskan dengan baik, saya sarankan untuk membongkar sendiri.
Kesimpulan
Saat mencari solusi untuk masalah , konteks dan semua kondisi yang diberikan harus dipertimbangkan .
Bahkan dalam kasus-kasus sederhana, detail kecil dari konteks membalikkan solusi, dan keterampilan memecahkan masalah yang diterapkan sebagian besar didasarkan pada kemampuan untuk melihat dan mengevaluasi premis awal .
Jadi, apakah ungkapan "jangan menemukan kembali roda" katakan tentang ketidakmampuan penasihat untuk menyelesaikan masalah? Jika penasihat menyebutkan sepeda sebelum ragu-ragu setelah beberapa menit, kemungkinan besar ya.
Atau, dalam generalisasi kapten:
Pikirkan Sebelum Memutuskan.
Berpikirlah sebelum berbicara.
Dan secara umum - pikirkan.