8 Pertanyaan Penting Untuk Ditanyakan Sebelum Menggunaka Laravel Package!

1. Dapatkah Anda Menulis Kode Sendiri?

Saat sebelum menggunakan package, pikirkan apa Anda bisa menulis kode sendiri. Jika kode yang dibutuhkan terlalu sulit atau memakan waktu untuk ditulis dan self controlled, reach package adalah opsi yang baik. Tetapi, Anda perlu assess complications kode dengan sacrifice dan biaya maintenance menggunakan package yang diatur oleh seseorang di luar team Anda.

Misalkan, think you need to make a wish ke Digital Ocean API. lebih masuk akal untuk menggunakan package PHP Digital Ocean, dengan support terbukti untuk feature kompleks seperti autentikasi dan membuat permintaan HTTP yang betul. Coba menulis kode ini sendiri tidak logis.

Tetapi, untuk fitur simpel seperti mengecek satu angka ganjil, lebih bagus menulisnya sendiri, menghindar keterikatan eksternal. Susah dipercayai jika library JavaScript ini mendapatkan 250 ribu+ unduhan sebulan!

2. Apa package Akan Membatasi Anda?

Salah satu hal luar biasa tentang working dengan package adalah Anda merasa seperti sedang membuat program puzzles jigsaw — menjadikan satu beberapa package kecil untuk membuat program besar. Tetapi, karena package biasanya direncanakan menjadi generik dan dipisah dari tersisa basis kode Anda, package itu tidak selamanya sesuai work path yang Anda tujukan.

Misalkan, mengambil package Short URL saya: package Laravel yang memungkinkannya Anda membuat URL singkat dalam program Laravel Anda. Arah khusus saya saat membuat package ini adalah membuat sesederhana mungkin untuk installed dan digunakan dalam project Anda. Bagusnya, perlu beberapa saat untuk memasang, mengonfigurasikan, dan memulai menggunakan.

saya mengetahui tentu jika package itu bekerja dengan baik sekali untuk membuat URL pendek dan menyimpan di database. Tetapi, itu tidak pas untuk suatu hal seperti membuat URL pendek secara massal, karena ini masukkan URL pendek ke database satu demi satu (yakni, membuat 1.000 URL pendek sekalian, memerlukan 1.000 insertion database). Jelas, ini tidak begitu efisien, tapi saya nyaman dengan batas ini.

Menurut pendapat saya, bila Anda membuat program yang betul-betul memerlukan insertion massal 1.000 URL pendek sekalian, Anda harus menggunakan package yang dibikin untuk kasus penggunaan khusus itu. Bila Anda tidak bisa mendapati package yang pas, implementasikan sendiri fitur itu — dan pikirkan untuk release package baru.

Poin khusus di sini yaitu selalu untuk menanyakan pada diri kita apa package itu pas dengan work path yang Anda tujukan atau bila Anda membutuhkan beberapa hack untuk membuat role. Bila Anda tidak percaya, coba instal package di cabang tes git dan bereksperimenlah untuk menyaksikan apa sesuai keperluan Anda. Bila packagenya tidak sesuai, Anda selalu bisa memutar kembali dan menelusuri gagasan lain.

Di saat yang sama, bila Anda menyaksikan problem power dan/atau bug dalam package dan mempunyai beberapa jalan keluar, pikirkan untuk mengirim permintaan penarikan untuk meningkatkan package. Role pada project open source dapat benar-benar berguna, dan membantu pengembang yang lain alami permasalahan yang sama.

3. Apakah package Masih Defended?

Saat Anda melihat sebuah package, penting untuk memeriksa apakah masih Defended.

Jika sebuah package kedaluwarsa atau tidak lagi Defended, itu berisiko untuk digunakan dalam proyek Anda. Misalnya, Anda menggunakan package untuk fitur penting pada PHP 8.2, tetapi sekarang Anda ingin memperbarui proyek Anda ke PHP 8.3. Jika package tidak mendukung PHP 8.3, dan tidak lagi dikelola oleh pemiliknya, Anda terpaksa membuat salah satu dari keputusan difficult berikut:

Tanyakan (atau harap) pengelola package menambahkan dukungan untuk PHP 8.3.
Buat permintaan tarik untuk menambahkan dukungan untuk PHP 8.3 dan berharap mereka menggabungkannya.
Implementasikan ulang fitur dalam aplikasi Anda menggunakan package yang berbeda.
Tulis ulang kode sendiri.
Fork packagenya dan mulai jaga versi Anda sendiri.
Lanjutkan memakai PHP 8.2.

Jujur saja, tidak ada yang terdengar ideal. Kami ingin terus membuat fitur baru yang keren di aplikasi kami, tidak perlu khawatir tentang mempertahankan fitur yang ada.

Jadi bagaimana Anda tahu jika suatu package masih Defended? Berikut adalah beberapa pemeriksaan:

Periksa masalah basi di repositori — masalah yang belum dijawab atau ditutup.
Periksa apakah ada pull request lama, tetapi aktif.
Periksa berapa lama since commit terakhir dibuat ke basis kode.

Catatan: Penting untuk diingat jika minimnya komitmen terkini tidak selamanya buruk. Ini kemungkinan memiliki arti jika package itu telah ripe atau lengkap dengan fitur dan cuma memerlukan penyempurnaan keamanan di periode kedepan (mis. Penyempurnaan PHP/ Laravel). Penilaian tiap package secara individual saat memutuskan apa akan menggunakannya atau mungkin tidak.

4. Apakah package Mempunyai Pengetesan?

Faktor penting yang lain perlu diperhitungkan saat memutuskan akan menggunakan sebuah package adalah apa package itu mempunyai pengetesan.

Saat Anda memasang sebuah package, itu jadi sisi dari base code Anda. Karena Anda tidak menulis code apa saja sendiri tanpa menulis test, penting untuk pastikan package itu mempunyai suite test kualitas. Serangkaian pengetesan yang bagus meminimalisir resiko package mengenalkan bug baru yang bisa menghancurkan program Anda.

Catatan: Minimnya test tidak selamanya memiliki arti ada bug. Kenyataannya, jika package relatif baru, pengurus mungkin mengerjakan pengetesan. Secara pribadi, saat saya membuat package baru, saya menambah test close to release, karena kodenya kerap berbeda. Saya belajar keutamaan menulis test sesudah membuat package pertama saya.

5. Apakah package Memiliki Dokumentasi Yang Baik?

Dokumentasi yang baik adalah bagian dari sebuah package yang sangat diremehkan, tetapi sangat penting.

Tidak ada yang lebih buruk daripada terjebak pada suatu masalah dan tidak dapat menemukan dokumentasi apa pun secara online. Saya terpaksa bekerja dengan beberapa API dan package dengan dokumentasi usang (atau tidak ada), dan itu tidak menyenangkan. Ini memperlambat Anda, memaksa Anda untuk menghabiskan lebih banyak waktu mempelajari kode package daripada membuat fitur baru.

Dokumentasi yang baik membantu Anda memahami cara kerja package.

6. Apa Kualitas Kode Baik?

Kadang sebaiknya mempelajari kode package dan mengecek kualitas umumnya.

Sama seperti yang saya sebut awalnya, saat Anda memasang sebuah package, itu menjadi bagian dari basis kode project Anda. Apa Anda akan menerima permintaan mengambil dari anggota tim bila kodenya berkualitas buruk, mempunyai bug, atau berpotensi kerentanan keamanan? Anda harus berpikiran secara sama saat weigh package pihak ketiga.

Kode tidak harus sempurna, tapi Anda ingin menghindar masuknya bug yang light or vulnerability keamanan ke mekanisme Anda dengan memasukkan.

7. Apa packagenya Terkenal atau Reputasi?

Pada umumnya, package terkenal dari pengembang terpenting memungkinkan untuk supported and maintained di periode kedepan, membuat lebih kecil resikonya untuk digunakan.

Metrik ini, bila digabungkan, akan memberikan Anda deskripsi mengenai popularitas package:

Unduhan total (atau bulanan).
Jumlah kontributor
Jumlah proyek yang menggunakannya
Pengembang memelihara package
Jumlah Fork di GitHub
Jumlah bintang di GitHub
Jumlah observer di GitHub

Sebagai contoh, mari kita lihat metrik untuk package Izin Laravel Spatie pada saat penulisan ini:

25 juta total unduhan
176 kontributor
54,7k proyek menggunakannya (menurut GitHub)
Fork 1,7k
10,9 ribu bintang GitHub
199 observer

Saya tidak paham tentang Anda, tapi ini kelihatannya package yang paling terkenal untuk saya. Beberapa angka ini membuat saya percaya jika package itu tidak hilang demikian saja dalam waktu dekat dibanding dengan package yang mempunyai satu kontribusi dan tanpa bintang.

Catatan: Ingat-ingatlah jika tiap orang harus mengawali dari satu tempat. Kemungkinan Anda mendapati package yang paling pas untuk project Anda, tapi diatur oleh seorang yang baru mengawali. Saat saya pertama kalinya membuat Laravel Exchange Rates, perlu waktu untuk memulai mendapatkan unduhan yang berarti — dan saya benar-benar mengerti. Minat pada akhirnya naik saat package itu dibagi oleh Laravel News . Maka bila Anda menemukan package berkualitas tinggi, tapi kurang terkenal, tidak selamanya memiliki arti package itu buruk; Anda kemungkinan tiba lebih cepat.

8. Apakah Anda Senang dengan Pengelola Mempunyai Keputusan Terakhir?

Paling akhir, ingat-ingatlah jika package pihak ketiga dibuat dan dikelola oleh pengembang atau perusahaan lain — memberikan mereka keputusan akhir mengenai fitur baru, peralihan yang bisa dipecahkan, dan peta jalan project.

Saat memilih untuk menggunakan sebuah package, pikirkan dampak potensial pada program Anda bila mereka stop memelihara package atau released switch besar yang bisa menghancurkan. Tergantung pada project Anda, itu dapat minimum atau agreement breaker. Terlepas dari itu, meyakinkan untuk menyempatkan diri considering this scenario.

Kesimpulan

Jadi sisi dari komunitas pengembang yang semangat, dengan demikian banyak package berkualitas tinggi, semacam menjadi little boy in the candy shop. Tapi penting untuk meluangkan waktu dan pikirkan opsi package Anda, menimbang semua biaya dan manfaatnya. Mudah-mudahan delapan pertanyaan ini membantu Anda membuat opsi yang pas untuk project Anda.

Jika Anda nikmati membaca posting ini, saya ingin dengarnya. Demikian pula, bila Anda mempunyai feedback untuk meningkatkan kedepannya, saya akan suka dengarnya.

Jika Anda berminat untuk memperoleh pembaruan saat saya menerbitkan posting baru, daftar ke buletin saya berikut ini.

Tetaplah membangun beberapa hal yang luar biasa!