Kebanyakan dakwaan prestasi dalam ruang alatan JavaScript mempunyai jangka hayat seperti susu. Seseorang memasang beberapa pakej pada pagi Selasa yang tenang, merakam output terminal, dan menerbitkan carta bar yang dramatik. Menjelang sprint seterusnya, salah satu alatan tersebut telah mengeluarkan tampalan (patch) yang membatalkan kesemuanya. Hantaran tersebut tetap diindeks oleh enjin carian. Carta tersebut terus dikongsi. Walau bagaimanapun, angka-angka tersebut sebenarnya sudah menipu anda.
Inilah kerosakan yang menjangkiti hampir semua penanda aras pengurus pakej. Ia hanyalah seperti fotografi acara, sedangkan apa yang kita perlukan adalah siaran langsung.
Satu projek bernama depjs/canary menganggap masalah ini sebagai tanggungjawab mesin dan bukannya tugasan kalendar kandungan. Ia adalah penanda aras dinamik yang memantau npm, pnpm, Yarn, dan dep, kemudian menjalankan semula keseluruhan siri ujiannya sebaik sahaja mana-mana daripadanya menerbitkan versi baharu. Keputusannya adalah awam, berterusan, dan tidak dapat dielakkan. Apabila sesuatu rosak, repositori akan kekal merah sehingga ia pulih. Tiada pemilihan secara terpilih, tiada persembunyian di sebalik hantaran blog lama, dan tiada andaian bahawa pemenang bulan lepas masih memegang takhta.
Mengapa Dakwaan Kelajuan Memerlukan Tarikh Luput
Pengurus pakej JavaScript tidak pernah statik. Jurang antara versi minor boleh merangkumi algoritma resolusi yang ditulis semula, strategi hoisting yang diubah, atau perubahan pada cara kunci cache global ditetapkan. Penanda aras yang merakam npm 10.2.1 dan pnpm 8.11.0 tidak memberitahu anda apa-apa tentang bagaimana alatan yang sama berkelakuan dua versi kemudian. Namun, web penuh dengan kenyataan muktamad seperti "Alatan X adalah tiga kali lebih pantas" berdasarkan jenis tangkap layar beku seperti itu.
Lebih buruk lagi, banyak ujian mengabaikan keadaan yang menentukan kesukaran sebenar pembangun. Pengurus pakej mungkin memasang dengan sangat pantas dalam persekitaran yang "warm" dan teratur, tetapi menjadi sangat perlahan pada pelari CI yang bermula dengan cakera kosong. Tanpa menguji kedua-dua ekstrem ini, penanda aras tersebut menjadi sekadar siaran akhbar dan bukannya data kejuruteraan yang boleh digunakan.
Bagaimana Canary Mengautomasikan Perbandingan
Setiap dua jam, satu tugasan akan memeriksa daftar npm. Jika versi baharu npm, pnpm, Yarn, atau dep muncul, canary akan "bangun". Ia tidak menunggu manusia untuk menyedari log perubahan (changelog). Ia akan segera melaksanakan matriks ujian penuh yang membandingkan keempat-empat pengurus tersebut dengan lima pakej dunia nyata yang popular. Pemilihan ini termasuk pakej utama seperti React, Next.js, dan Vite, iaitu kod asas yang dipasang oleh pembangun setiap hari. Ini bukan mikro-projek sintetik yang direka untuk memuji satu alatan tertentu.
Pendekatan yang dicetuskan oleh pelepasan ini penting kerana ia mengaitkan pengukuran secara langsung dengan perubahan. Jika penanda aras hanya dijalankan mengikut jadual setiap malam, ia mungkin terlepas hotfix tengah hari atau terlepas kesan regresi selama berjam-jam. Dengan berjalan khusus pada versi baharu, canary mengajukan soalan langsung setiap kali: adakah pelepasan ini menjadikan keadaan lebih baik atau lebih buruk?
Empat Senario yang Menguji Kekuatan Berbeza
Matriks ujian dibina di sekeliling empat tetapan berbeza yang berkait terus dengan aliran kerja yang anda kenali.
- Cache sejuk, tanpa lockfile. Ini adalah klon baharu pada komputer riba baharu, atau pemasangan pertama selepas memadam
node_modules. Tiada apa yang disimpan dalam cache. Tiada apa yang ditetapkan. Pengurus pakej perlu menyelesaikan, mengambil, dan menulis segalanya dari awal. - Cache panas, dengan lockfile. Ini adalah laluan lancar untuk integrasi berterusan apabila semuanya berjalan lancar. Lockfile wujud secara tempatan, dan cache masih menyimpan tarball daripada larian sebelumnya. Alatan tersebut sepatutnya bergerak pantas kerana kebanyakan keputusan telah pun dibuat.
- Cache sejuk, dengan lockfile. Di sini lockfile ada, tetapi cache telah dipadamkan. Pengurus boleh melangkau resolusi kebergantungan, namun ia masih perlu memuat turun setiap bait melalui rangkaian. Ini mengasingkan kelajuan rangkaian daripada kelajuan resolusi.
- Cache panas, tanpa lockfile. Cache sudah sedia, tetapi lockfile telah hilang. Pengurus pakej mesti menyelesaikan semula pokok kebergantungan sebelum ia boleh mula mengekstrak fail. Ini menguji kecekapan penyelesai (solver) dan parser metadata di bawah keadaan rangkaian yang ideal.
Setiap senario dilaksanakan lima kali, dan canary menyimpan keputusan median. Pilihan tunggal itu menghapuskan banyak gangguan (noise). Gangguan rangkaian sementara atau lonjakan kependaman daftar yang singkat tidak dapat mengganggu naratif. Pencilan (outlier) akan diabaikan; pengalaman tipikal akan direkodkan.
Ujian Asap (Smoke Tests) Lebih Baik Daripada Pemasa Kosong
Kelajuan mentah mudah dipalsukan jika anda tidak mengesahkan hasilnya. Pengurus pakej boleh melangkau langkah pasca-pemasangan, merosakkan beberapa symlink, atau memasang versi yang salah dan masih memaparkan cap masa yang mengagumkan. Canary enggan berhenti pada pemasa sahaja. Selepas pemasangan selesai, ia benar-benar menguji kod yang telah dipasang.
Sebagai contoh, ia memulakan aplikasi Express dan mengesahkan bahawa pelayan mula mendengar pada port yang dijangkakan. Jika kod tidak berjalan, penanda aras tersebut akan gagal sepenuhnya. Ujian asap (smoke test) mengubah set ujian tersebut daripada sebuah perlumbaan kepada satu audit. Ia menjawab soalan yang tidak dapat dijawab oleh kelajuan semata-mata: adakah pemasangan itu benar-benar berfungsi?
Kejujuran Radikal sebagai Ciri Utama
Penulis canary tersebut telah menetapkan tiga peraturan ke dalam proses yang biasanya dianggap sebagai pilihan oleh kebanyakan penulis penanda aras.
Padang permainan yang sama. Bendera (flags) digunakan untuk menormalkan tingkah laku merentasi pelbagai alatan. Jika satu pengurus pakej menyembunyikan kecacatan prestasi di sebalik tetapan lalai, penanda aras akan mendedahkannya dan bukannya membiarkan alatan tersebut kelihatan bagus secara tidak sengaja.
Permulaan sejuk (cold starts) yang tulen. Sebelum setiap pengulangan, bukan hanya yang pertama, cache npm dan stor pnpm akan dipadamkan. Perkataan "setiap" itu memainkan peranan yang sangat besar. Banyak penanda aras membersihkan cache sekali sahaja, kemudian menjalankan lima pemasangan berturut-turut. Larian kedua hingga kelima bukanlah benar-benar sejuk, dan angka tersebut akan meningkat secara tidak wajar. Canary bermula dari sifar setiap kali.
Keadaan kegagalan yang terbuka. Apabila versi baharu merosakkan sesuatu, repositori akan kekal dalam keadaan kegagalan merah. Ia akan terpapar di halaman utama, kelihatan buruk dan tidak selesai, sehinggalah pembaikan dihantar. Tiada penyembunyian senyap untuk memastikan papan pemuka kelihatan hijau. Polisi ini memaksa ketelusan. Pengguna yang menilai alatan bukan sahaja dapat melihat yang mana paling pantas, tetapi yang mana kekal boleh dipercayai dari semasa ke semasa.
Kebolehpemeriksaan Adalah Tidak Boleh Dirunding
Penanda aras yang tidak boleh anda replikasi hanyalah sekadar slogan kempen. Canary menangani perkara ini dengan satu skrip bash tunggal yang membolehkan sesiapa sahaja menjalankan mana-mana bahagian set ujian tersebut secara tempatan. Anda tidak perlu mempercayai rangkaian penyedia awan atau persekitaran yang telah diubah suai secara manual oleh penyelenggara. Jika anda mengesyaki angka tersebut tidak tepat, anda boleh menjana angka anda sendiri.
Ketelusan itu juga menjadikan projek ini berguna bagi penyelenggara. Apabila berlaku regresi, pembangun hiliran (downstream) boleh menarik skrip tersebut, melakukan bisect pada versi alatan, dan menyerahkan kepada pasukan huluan (upstream) satu