5 tips untuk memilih kode sumber terbuka yang tepat
Studi yang dilakukan oleh Google menunjukkan bahwa bagi banyak pengembang menemukan kode online menghabiskan sebagian besar hari. Menemukan fungsi sederhana, perpustakaan, paket yang berguna, komponen yang dapat digunakan kembali, atau tutorial blog "cara" yang berguna tidak selalu mudah. Mengetahui apakah Anda dapat mempercayai dan menggunakan kode yang Anda temukan dapat menjadi lebih rumit.
Menemukan kode yang tepat biasanya berarti beralih ke dewa Google atau mesin telusur lainnya, mengajukan kueri dan menyilangkan jari untuk menang cepat. Kueri fungsional sederhana seperti “Javascript memiliki properti sendiri” mungkin akan mengarah ke forum dan posting blog yang berbeda, sementara deskripsi tingkat yang lebih tinggi (“React component x”) akan sering mengarahkan Anda ke GitHub atau NPM.
Namun, bahkan setelah menemukan kode yang tepat – mempercayai dan menggunakannya adalah masalah yang sama sekali berbeda. Untuk membantu memahami kode mana yang benar-benar dapat Anda gunakan, saya mengumpulkan 5 parameter yang dapat membantu untuk dipertimbangkan. Membuat keputusan yang tepat harus mempertimbangkan parameter ini (antara lain), serta sifat tugas itu sendiri. Berikut adalah 5 kunci yang dapat Anda pertimbangkan untuk memilih kode yang tepat.
#1. Apakah kode dapat dibaca?
Kode yang dapat dibaca berarti lebih dari sekadar komentar dan dokumentasi yang baik. Itu berarti kode itu sendiri harus dapat dibaca oleh Anda. Parameter yang berbeda untuk keterbacaan dapat berupa konvensi penamaan yang baik untuk pengidentifikasi, spasi yang baik, logika yang dapat dibaca dengan jelas, cakupan yang dipahami dengan baik, dan banyak lagi. Intinya adalah, kode harus dapat dibaca untuk Anda . Saat Anda memilih sepotong kode, bahkan yang berfungsi, tetapi Anda tidak sepenuhnya memahami cara kerjanya – pada dasarnya Anda membawa bom waktu pemeliharaan ke dalam basis kode Anda.
Men-debug, memodifikasi, memperbarui, dan memelihara kode yang tidak dapat Anda baca adalah sesuatu yang harus sangat Anda hindari. Cara terbaik untuk menghindarinya adalah dengan tidak membiarkannya sejak awal jika memungkinkan.
#2. Apakah kode dipelihara secara aktif?
Kami ingin kode yang kami pilih menjadi "hidup". Artinya, kami ingin tahu bug, masalah, dan pembaruan sedang ditangani dan kode ini akan dipelihara secara aktif oleh pengembang yang menulisnya. Contoh yang bagus untuk indikator aktivitas dapat berupa masalah terbuka GitHub, permintaan tarik, dan indikator Pulse. Manajer paket memberikan informasi yang relevan untuk pemeliharaan seperti jumlah dependensi dan proyek dependen, tetapi tetap saja, kesulitan untuk menyajikan metrik yang dapat dipercaya di bidang ini.
Namun, jika proyek besar yang populer bergantung pada paket lain, kita dapat mengasumsikan masalah memiliki kemungkinan besar untuk diperbaiki (namun, kita semua ingat pad kiri). Namun, ketika menyalin kode dari stack overflow (yang merupakan masalah tersendiri), Anda tidak tahu bahwa Anda dapat mempercayai kode ini akan dipertahankan selain memperbaruinya sendiri kapan pun diperlukan (dan di mana pun Anda menduplikasinya).
Fungsionalitas inti kecil tidak banyak berubah. Dalam semangat ini, komponen yang dapat digunakan kembali yang diimpor dari Bit mengandalkan versi inkremental sederhana yang meningkatkan versi komponen sebesar 1 setiap kali pembuatnya mengubah sesuatu. Menjaga komponen Anda dalam versi "terkini diperbarui" berarti, dengan pengujian yang baik, kode Anda dapat dipelihara secara aktif oleh pengelolanya sambil tetap memperbarui bahkan fungsi atau komponen kecil dalam kode Anda tanpa merusak apa pun.
#3. Apakah kode sudah teruji dengan baik?
Memilih kode yang berfungsi mungkin merupakan prioritas pertama kami. Tes adalah cara yang bagus untuk mengetahui apakah kode yang saya gunakan benar-benar melakukan apa yang seharusnya dilakukan. Deskripsi pengujian juga menyajikan kasus penggunaan dan kasus tepi yang berbeda yang membantu kami mengetahui bagaimana kode ini akan berperilaku dalam situasi yang berbeda. Menggunakan komponen yang telah diuji membuat perangkat lunak yang lebih dapat dirawat secara keseluruhan, menghemat waktu dan masalah saat mencoba mengubah barang sebelum bergulir ke produksi.
Cuplikan yang disalin dari seluruh web biasanya tidak disertai tes. Jarang, jika sama sekali, fungsi yang disalin dari forum atau posting blog akan menyertakan tes unit. Paket dan perpustakaan mungkin sangat baik diuji, masalahnya terletak pada kemampuan untuk mengetahuinya dengan cepat. Saat menjelajahi perpustakaan di GitHub, berbagai lencana atau file di repositori dapat menunjukkan seberapa baik dan seberapa banyak kode ini diuji. Kami masih harus menggunakan indikator yang disediakan oleh alat eksternal untuk mengetahui apakah tes lulus atau tidak. Saat mencari paket, sebenarnya tidak ada cara yang dapat diandalkan untuk mengetahui paket mana yang diuji dan apakah pengujian tersebut berhasil lulus. Ini adalah masalah besar dalam hal kemampuan untuk menemukan paket. Dapat digunakan kembali
Saat mencari paket, sebenarnya tidak ada cara yang dapat diandalkan untuk mengetahui paket mana yang diuji dan apakah pengujian tersebut berhasil lulus. Ini adalah masalah besar dalam hal kemampuan untuk menemukan paket. Komponen Bit yang dapat digunakan kembali dapat diuji jika pengujian tersebut ditambahkan oleh developer. Bit Scope menjalankan pengujian sehingga indikator hijau dan deskripsi pengujian dapat ditampilkan secara online sebelum memilih komponen dari hub komunitas Bit (atau melalui CLI saat digunakan pada mesin lokal Anda secara terdistribusi).
#4. Apakah kode tersebut digunakan oleh orang lain?
Popularitas adalah sesuatu yang kita percayai secara evolusioner. Opini publik baik untuk membuat keputusan yang membantu kelangsungan hidup kita. Jika kita melihat semua orang memakan buah tertentu dari pohon, kita tahu itu mungkin tidak akan membunuh kita. Jika kita melihat semua orang lari dari semak-semak, harimau yang lapar mungkin akan segera menyusul. Sampai batas tertentu, hal yang sama berlaku untuk memilih kode di tahun 2017.
Di sekitar forum Pemrograman, kita dapat menggunakan indikasi yang berbeda seperti tanda “V” untuk jawaban yang benar, jumlah upvoted, dan vokal opini pengguna. Ini adalah fitur yang sangat baik dan meyakinkan untuk meningkatkan kemungkinan kode berfungsi dengan baik. Ketika berbicara tentang GitHub, kita dapat mengandalkan bintang, kolaborator, dan metrik sosial lainnya untuk mendapatkan perasaan layak dipercaya. Saat mencari paket, indikator yang baik adalah jumlah unduhan untuk paket ini.
Komponen Bit yang ditemukan di hub komunitas Bit menunjukkan jumlah unduhan, kolaborator (pada tingkat cakupan), “suka” sederhana, dan banyak lagi (seperti yang ditunjukkan dalam Lingkup komponen React ini). Apa pun itu, ingatlah bahwa metrik sosial adalah indikasi yang baik – tetapi ini adalah kebenaran mutlak mengenai kualitas kode. Orang sering salah, dan opini publik bisa berubah lebih cepat dari yang kita kira.
#5. Apakah kode didokumentasikan dengan baik?
Dokumentasi membuat kode lebih mudah dipahami, digunakan, dan dimodifikasi. Ini juga merupakan indikasi yang bagus untuk pemikiran dan kehati-hatian pengembang yang menulis kode yang dimasukkan ke dalamnya. Dokumentasi untuk kode yang ditemukan di Stack Overflow atau posting blog yang berbeda dapat terdiri dari komentar dalam kode itu sendiri serta jawaban aktual atau blog tempat kode tersebut ditemukan. Ketika jawaban forum menyertakan penjelasan yang berguna tentang kode yang disertakan, ini mungkin merupakan dokumentasi yang layak ditambahkan bahkan ketika menyalin-menempelkan kode itu sendiri (sekali lagi, jangan salin kode tempel).
Untuk repositori dan paket GitHub, semuanya sedikit lebih rumit. Biasanya, file readme dan dokumen yang disajikan di GitHub atau NPM akan memberikan indikasi umum mengenai kualitas dokumentasi. Dokumentasi untuk komponen Bit diuraikan dari dalam kode itu sendiri sehingga menunjukkan deskripsi sebenarnya untuk komponen atom, dan juga dapat menyertakan contoh penggunaan dan tanda tangan tertentu termasuk argumen dan pengembalian untuk fungsi dan perilaku yang berbeda untuk komponen React dan lainnya. Bagaimanapun, memilih kode yang terdokumentasi adalah keputusan yang baik bila memungkinkan.
Untuk repositori dan paket GitHub, semuanya sedikit lebih rumit. Biasanya, file readme dan dokumen yang disajikan di GitHub atau NPM akan memberikan indikasi umum mengenai kualitas dokumentasi. Dokumentasi untuk komponen Bit diuraikan dari dalam kode itu sendiri sehingga menunjukkan deskripsi sebenarnya untuk komponen atom, dan juga dapat menyertakan contoh penggunaan dan tanda tangan tertentu termasuk argumen dan pengembalian untuk fungsi dan perilaku yang berbeda untuk komponen React dan lainnya. Bagaimanapun, memilih kode yang terdokumentasi adalah keputusan yang baik bila memungkinkan.
Mengambil keputusan
Pada akhirnya, ingatan manusia terbatas dan tidak ada gunanya menemukan kembali roda setiap saat. Namun, saat menemukan dan menggunakan sepotong kode sumber terbuka, indikator di atas dapat membantu memastikan aplikasi Anda tetap aman, dapat dipelihara, berfungsi, dan dalam kondisi sehat.
Kasus penggunaan yang berbeda berarti memberikan bobot yang berbeda pada parameter yang berbeda. Saat memilih paket, akan sulit untuk mengetahui seberapa teruji, mudah dibaca, didokumentasikan, dan dipelihara secara aktif. Saat menyalin kode dari forum online, kami mungkin memprioritaskan popularitas daripada pengujian, pemeliharaan, dan sebagainya. Komponen bit menggabungkan informasi yang relevan untuk mengimpor dan menggunakan kembali komponen dan fungsionalitas atomik seperti deskripsi, contoh, unduhan, dependensi, deskripsi pengujian, hasil pengujian, dan lainnya. Dengan hati-hati mempertimbangkan parameter yang berbeda ini, kami dapat membuat keputusan yang tepat dan melintasi labirin menemukan dan memilih kode yang tepat untuk pekerjaan itu.
