Minggu ini, pengguna Hacker News
memutuskan untuk membahas pertanyaan "Berapa jumlah maksimum kode buruk - tetapi masih berfungsi - yang Anda lihat?" (
pengguna Reddit kemudian
bergabung dengan mereka). Dalam komentar, banyak cerita “lucu” yang diceritakan tentang hal-hal yang kami temui dari waktu ke waktu; tetapi kisah tentang "DBMS canggih yang digunakan oleh sebagian besar perusahaan Fortune 100" menarik perhatian.
Pemenang nominasi Lovecraft Horror sepatutnya
kisah mantan pengembang Oracle yang bekerja pada Oracle Database selama pengembangan versi 12.2. Basis kode DBMS pada saat itu adalah 25 juta baris dalam C - dan segera setelah Anda mengubah hanya satu dari baris-baris ini,
ribuan tes yang ditulis sebelumnya gagal.
Selama bertahun-tahun, beberapa generasi programmer telah bekerja pada kode, yang secara teratur dikejar oleh tenggat waktu yang sulit - dan berkat ini, kode dapat berubah menjadi mimpi buruk yang nyata. Hari ini terdiri dari "potongan-potongan" kode kompleks yang bertanggung jawab untuk logika, manajemen memori, pengalihan konteks, dan banyak lagi; mereka terhubung satu sama lain menggunakan
ribuan bendera yang berbeda. Semua kode saling berhubungan oleh makro misterius yang tidak dapat didekripsi tanpa menggunakan notebook, di mana Anda harus menuliskan apa yang dilakukan bagian makro yang relevan. Akibatnya, pengembang dapat mengambil satu atau dua hari hanya untuk mengetahui apa yang sebenarnya dilakukan makro.
Untuk memprediksi perilaku kode dalam satu atau lain kasus, Anda harus memahami dan mengingat nilai dan konsekuensi apa yang dapat dimiliki 20 (atau bahkan seratus) flag. Situasi ini diperburuk oleh kenyataan bahwa berbagai pengembang menggunakan jenis mereka sendiri, yang pada dasarnya adalah hal yang sama (misalnya, int32) - dan hampir tidak ada orang yang berani menyentuh warisan seperti itu (kita dapat mengatakan dengan pasti bahwa ini adalah kasus di Basis kode Oracle 8i).
Timbul pertanyaan: bagaimana, dengan semua ini, apakah Oracle Database masih bisa berdiri sendiri? Rahasianya ada dalam jutaan tes. Implementasi penuh mereka dapat berlangsung dari 20 hingga 30 jam (pada saat yang sama mereka dilakukan didistribusikan pada kelompok uji 100-200 server).
Tim yang mengerjakan produk di akhir tahun 90-an dan mengikuti ide-ide TDD (pengembangan berbasis tes), memiliki pendapat berikut: "tes otomatis berarti Anda tidak perlu menulis kode yang dapat dipahami - alih-alih, Anda harus pikirkan tes. " Di masa depan, pengembang dipaksa untuk mematuhi prinsip-prinsip yang ditetapkan oleh mereka, dan sekarang kita menyaksikan dalam praktiknya apa ide ini berubah dalam jangka panjang - dengan semua kelebihan dan kekurangannya.
Saat ini, proses memperbaiki bug baru di Oracle Database membutuhkan waktu beberapa minggu hingga beberapa bulan. Pada awalnya, pengembang harus menghabiskan beberapa hari hanya memilah-milah bendera yang ia butuhkan (interaksi misterius yang menyebabkan bug), setelah itu ia sering harus menambahkan benderanya sendiri, yang akan bertanggung jawab untuk memproses skrip khusus yang menyebabkan bug.
Kemudian ia mengirimkan kode untuk pengujian, dan hari berikutnya ia dengan tenang beralih ke tugas lain, menunggu gugus uji untuk merakit perakitan Oracle DB baru dan menjalankan semua tes di atasnya. Jika pengembang beruntung, sekitar 100 tes akan “memerah”; jika tidak (dan opsi ini lebih sering terjadi) - sekitar 1000, dan ia harus memeriksa asumsi mana tentang operasi kode yang ada ternyata salah; sangat mungkin bahwa dia akan menemukan bahwa dia perlu mempelajari selusin bendera yang berbeda, yang dengan cara yang tidak terlihat mengambil bagian dalam pekerjaan kode yang dia ubah.
Dia harus mengulangi proses ini selama beberapa minggu sebelum keberuntungan akhirnya tersenyum padanya dan semua tes akhirnya berlalu. Setelah itu ia harus menulis beberapa lusin tes - untuk memastikan bahwa pengembang, yang akan mengganggu kodenya di masa depan, tidak akan merusak "perbaikan" nya. Kemudian perbaikan akan dikirim ke ulasan, yang bisa memakan waktu dari beberapa minggu hingga beberapa bulan, setelah itu bug akhirnya akan bergabung ke cabang kerja utama.
Karena fakta bahwa setidaknya diperlukan satu hari untuk membangun DBMS dan menjalankan tes, diharapkan setiap pengembang bekerja secara bersamaan pada 2-3 bug dan beralih di antara mereka sambil menunggu hasil pengujian.
Jika Anda berpikir bahwa kehidupan pengembang menambahkan fungsionalitas baru ke DBMS lebih mudah, maka Anda sia-sia. Menambahkan bahkan fitur baru yang kecil seperti mode otentikasi baru dapat memakan waktu dari 6 bulan hingga setahun, dalam kasus-kasus lanjutan khususnya - hingga dua tahun.
Dalam kasus yang dijelaskan, TDD memungkinkan untuk tidak menghancurkan kode "spaghetti", di mana sudah sangat sulit untuk memahami sesuatu, dan memiliki produk yang berfungsi pada output. Pada saat yang sama, biaya terus tumbuh, dan kualitas kode baru sering menyisakan banyak yang diinginkan. Tidak hanya tim pengembang dari AS, tetapi juga tim dari India sedang mengerjakan DBMS, sehingga beberapa pengembang Oracle, menurut tradisi yang ada, menyalahkan kualitas kode pada mereka. Yang lain tidak setuju dengan mereka, dan berdasarkan changelog mereka mengatakan bahwa kualitas kode tidak tergantung pada geografi tim, dan kode yang buruk secara berkala “terbang” dari kedua tim. Masalah yang sangat serius untuk produk ini adalah pengembang yang menganggap proyek “memasuki industri” dan telah bekerja pada DBMS selama tidak lebih dari 1-2 tahun; selama ini tidak mungkin untuk memahami secara signifikan seluk-beluk proyek.
Menurut kesaksian pengembang lain yang memindahkan basis kode Oracle 8i ke salah satu versi Unix di akhir 90-an, kode yang pada waktu itu adalah bola "spageti" yang benar-benar mustahil untuk dipahami sepenuhnya. Pengembang lain yang bekerja dengan kode DBMS di akhir 80-an mengklaim bahwa basis kode pada saat itu adalah kumpulan besar sumber C dan satu set file makefile untuk perakitan - banyak di antaranya jauh lebih rumit daripada kode kernel itu sendiri. Tentu saja, ini layak untuk menjadi realistis - situasi ini tidak lebih baik pada produk serupa, pemimpin industri, yang pengembangannya telah dilakukan selama beberapa dekade.