Menamai Bukan Menemukan
Kamu sekarang tahu tujuh pola MOAD. Mengetahui nama penting: itu memungkinkan kamu mengenali pola saat melihatnya. Tapi pengenalan dalam les yang terkontrol berbeda dengan deteksi di codebase yang belum pernah kamu buka.
Sebuah codebase tidak menandai kerusakannya. MOAD endapan tidak datang dengan komentar yang mengatakan // O(N²) — fix this. Gelombang petir tidak mengumumkan diri mereka sebagai stempel kehilangan cache. Kamu menemukannya dengan membaca kode dengan pertanyaan khusus di dalamnya: apa data struktur yang menampung nilai-nilai ini, dan apa operasi yang dijalankan terhadapnya di dalam loop?
Deteksi adalah keterampilan terpisah dari pengenalan. Pengenalan mengatakan: ya, pola itu MOAD-0001. Deteksi mengatakan: biarkan saya menemukan semua tempat di codebase ini di mana pola tersebut mungkin ada, baik saya bisa melihat kode penuh atau hanya nama simbol.
Sken Pertama
Langkah pertama menggunakan grep. Setiap MOAD memiliki substrat: data struktur atau API yang keberadaannya, dekat dengan operasi tertentu, merupakan sinyal layak diinvestigasi.
MOAD-0001 (Endapan): .contains di dalam loop
# Sinyal: pengujian anggota pada variabel list di dalam loop
grep -rn '.contains(' src/ | grep -v HashSet | grep -v TreeSet
grep -rn 'visited =' src/ | grep -v set | grep -v Set
MOAD-0002 (Intertangle): flag mutable bersama antar fase
# Sinyal: bidang mutable statis yang ditulis oleh satu subsystem, dibaca oleh yang lain
grep -rn 'static ' src/ | grep -v final | grep -v class | grep -v void
MOAD-0003 (Leaked Context): ThreadLocal di executor pooled
# Sinyal: ThreadLocal.set() tanpa ThreadLocal.remove() yang dijamin
grep -rn 'ThreadLocal' src/
grep -rn 'ThreadLocal.set' src/ -l
MOAD-0004 (Logged Secret): header HTTP di output log
# Signal: log panggilan dengan variabel header di dekat endpoint autentikasi
grep -rn 'log.*header' src/
grep -rn 'Authorization' src/ --include='*.log'
MOAD-0005 (Thundering Herd): kesalahan cache tanpa sinkronisasi
# Signal: cache.get() + pengecekan null + cache.put() tanpa kunci
grep -rn 'cache.get' src/ -A4 | grep 'cache.put'
Polanya menghasilkan calon, bukan defek yang dikonfirmasi. Setiap calon membutuhkan triase: baca kode sekitar, verifikasi tipe data struktur, konfirmasi operasi yang berjalan skala.
Membaca Kode untuk Kompleksitas
Grep menemukan calon. Membaca mengkonfirmasinya. Ketika Anda membuka file calon, Anda membaca dengan satu pertanyaan: apakah biaya operasi ini tumbuh dengan ukuran input?
Untuk MOAD-0001, protokol konfirmasi:
1. Temukan loop luar. Apa yang mengendalikan hitungan iterasinya?
2. Temukan operasi dalam (contains, indexOf, 'in'). Struktur data apa yang dijalankannya?
3. Apakah struktur data tersebut tumbuh dengan input yang sama yang menggerakkan loop luar?
4. Jika ya: biaya tersebut adalah O(N²) di mana N = ukuran input. Dikonfirmasi.
5. Jika tidak: struktur dalam terbatas (konfigurasi, enum, konstanta kecil). Salah positif.
Traversing graf yang mengunjungi N node, memeriksa daftar 'visited' pada setiap langkah: baik loop maupun struktur data dalam tumbuh dengan N. Dikonfirmasi.
Pengelola permintaan yang memeriksa daftar izinkan 5 IP admin: daftar izin tidak pernah tumbuh dengan volume permintaan. Salah positif.
Protokol yang sama berlaku untuk setiap MOAD: identifikasi driver luar, identifikasi struktur dalam, tanyakan apakah keduanya tumbuh bersama-sama.
Skor Surge: Prioritaskan Temuan Anda
Semua kerentanan yang dikonfirmasi tidak selalu memerlukan perbaikan segera. MOAD di library dengan 10.000 dependen turunannya memiliki skor lonjakan yang lebih tinggi daripada MOAD yang sama di alat internal pribadi.
Skor lonjakan = cepat x derajat masuk. Cepat: berapa kali lebih cepat fix berjalan di skala produksi yang biasa? Derajat masuk: berapa banyak paket atau layanan turunan yang secara otomatis mengadopsi perbaikan saat upstream menggabungkannya?
MOAD-0001 yang dikonfirmasi di resolver dependensi Apache Maven, berjalan di grafik 50.000 node, dengan +1.000 plugin Maven turunan yang secara otomatis mengadopsi perubahan: skor lonjakan sangat tinggi. Fix ini harus berada di depan antrian Anda.
MOAD-0001 yang dikonfirmasi di alat CLI tunggal tanpa dependen: skor lonjakan dekat nol. Layak diperbaiki, tetapi tidak mendesak.
Karyawan vs. node pemuja makan. Node dengan tingkat kehadiran tinggi & cepat adalah karyawan: itu menangani aliran kritis & akan mengosongkan antrian turunannya saat diblokir. Perbaiki hanya setelah mengonfirmasi kapasitas turunan. Node dengan derajat keluar tinggi & cepat adalah pemuja makan: itu mengonsumsi segala yang diberikan kepadanya dan tidak merasa sakit. Mengganti karyawan tanpa mengatur kapasitas turunan menciptakan MOAD-0005 (bala tentara petir) pada skala infrastruktur.
Scan to Merge: Pipa MOAD
Sebuah kerusakan yang disahkan dengan skor lonjakan tinggi melewati pipa. Setiap tahap menghasilkan artefak. Tidak ada tahap yang opsional.
scan → daftar calon (output grep, hasil analisis statis)
ticket → deskripsi kerusakan (nomor MOAD, analisis kompleksitas, lokasi)
patch → perubahan kode (penukaran struktur data, adaptasi primitif)
test → unit test (bukti O(1): waktu perbaikan pada N=100 dan N=10,000)
UNDF → publikasi pengungkapan pasca (undefect.com, domain umum)
disclose → referensi CVE atau CWE jika relevan keamanan
PR → permintaan tarik upstream dengan patch + test + tautan UNDF
merge → penerimaan pengembang; perbaikan menyebar melalui kenaikan versi
Setiap artefak mengalir ke tahap berikutnya. Sebuah patch tanpa test tidak dapat diverifikasi. Sebuah test tanpa pengungkapan tidak dapat menyebar ke instance yang sama lainnya. Sebuah pengungkapan tanpa PR upstream mengunci perbaikan dalam cabang.
Pos MOAD pasca (UNDF) adalah tahap yang sering diabaikan oleh insinyur. Mereka memperbaiki kerusakan, mengirimkan PR, dan menganggap diri mereka selesai. Tapi, sebuah perbaikan tanpa pos pasca yang diberi nama berarti setiap insinyur masa depan yang menemukan pola yang sama harus menemukan masalah dan perbaikan secara independen. Sebuah pos MOAD menutup lingkaran pengetahuan: menggali pola, menunjukkan metode deteksi, dan menghubungkan ke patch. Peneliti masa depan menemukan perbaikan dengan mencari nama pola.
Penguncian planet skala. Sebuah perbaikan MOAD-0001 dalam sebuah library yang sering digunakan menyebar ke setiap proyek yang mengimpornya. Sebuah pos MOAD memastikan bahwa insinyur di proyek yang akan tidak pernah mengupgrade library tersebut masih belajar perbaikan tersebut. Kedua jalur berjalan secara paralel.
Menulis Tiket Kerusakan
Tiket kerusakan yang baik menjawab lima pertanyaan:
1. Di mana: file, kelas, fungsi, dan rentang baris yang tepat
2. Apa: tipe struktur data dan operasi terhadapnya
3. Mengapa: analisis kompleksitas (O(N²) atau lebih buruk, dengan N didefinisikan)
4. Dampak: input yang menimbulkan perilaku terburuk, dan pada skala apa
5. Solusi: struktur data atau primitif untuk digantikan
Tiket yang menjawab semua lima adalah diri sendiri: pengembang yang pernah membaca analisis Anda dapat mengulangi penemuan Anda dan memverifikasi perbaikan Anda. Tiket yang melewatkan (3) atau (4) membutuhkan pengembang untuk mengulangi analisis kompleksitas Anda sebelum mereka bisa merge. Friction tersebut mengurangi kemungkinan merge.
Kredibilitas berkembang. PR pertama yang mencakup tiket jelas, patch yang ditargetkan dengan baik, & tes benchmark berhasil diterapkan. PR kedua dari penulis yang sama mendapatkan review dengan sedikit gesekan. PR ketiga diperiksa oleh pemelihara yang menggabungkan dua PR pertama. Reputasi di open source adalah buku besar dari artifact: setiap patch yang diterima mengumpulkan kepercayaan untuk yang berikutnya.
Membaca Kandidat Nyata
Ini adalah kandidat MOAD-0001 nyata di Python. Baca dan lengkapi protokol triase.
class DependencyResolver:
def resolve(self, package, resolved=None, seen=None):
if resolved is None:
resolved = []
if seen is None:
seen = []
if package in seen:
return
seen.append(package)
for dep in self.registry.get_dependencies(package):
self.resolve(dep, resolved, seen)
resolved.append(package)
return resolved
Pertanyaan triase:
1. Apa struktur data `seen`?
2. Operasi apa yang dijalankan terhadapnya pada baris 6?
3. Apakah `seen` tumbuh dengan ukuran input?
4. Apakah loop yang mengendarai panggilan rekursif juga tumbuh dengan ukuran input?
5. Apakah ini konfirmasi MOAD-0001 atau penipuan palsu?
Patch Anda
Kecacatan yang dikonfirmasi dengan skor ledakan tinggi membutuhkan patch yang lengkap: perbaikan kode, tes yang membuktikan peningkatan, & kerangka MOAD pasca.
Tes harus adalah tes performa, bukan tes kelengkapan. Tes kelengkapan melewati sebelum dan sesudah perbaikan - itu adalah titik; output tidak berubah. Tes performa pada dua ukuran input membuktikan peningkatan:
import time
def build_graph(n):
# n paket, masing-masing tergantung pada paket sebelumnya
return {f'pkg{i}': [f'pkg{i-1}'] if i > 0 else [] for i in range(n)}
for n in [100, 1000, 5000]:
registry = build_graph(n)
resolver = DependencyResolver(registry)
start = time.perf_counter()
resolver.resolve(f'pkg{n-1}')
elapsed = time.perf_counter() - start
print(f'n={n}: {elapsed:.4f}s')
Sebelum perbaikan, waktu terlewati tumbuh kuadrat dengan n. Setelah perbaikan, itu tumbuh linear. Cetak kedua dan sertakan angka-angka dalam deskripsi PR.
Garis besar posting MOAD mencakup: nama pola, substrat (penyelesaipenggantungan Python), metode deteksi (grep untuk in seen di mana seen dimulai sebagai []), perbaikan, & tautan ke PR Anda. Posting tersebut pergi ke undefect.com sebagai domain publik. Insinyur masa depan yang mencari 'Python list membership in loop slow' akan menemukannya.