Bad Code terbesar yang pernah kalian lihat sejauh ini apa?

"Kode Oracle Database 12.2 yang berjumlah 25 juta baris"

Jawaban dari seorang mantan karyawan Oracle pada pertanyaan yang pernah muncul di HN

"Itu kengerian yang tak terbayangkan. Mustahil menulis bahkan satu baris kode pun tanpa melewati 1.000 pengujian yang sudah ada.

Ada makro misterius yang tidak bisa dipahami kecuali diurai sambil dicatat tangan di buku, dan butuh sekitar satu sampai dua hari hanya untuk benar-benar memahami fungsi makro itu.

Kadang, untuk memprediksi bagaimana kode akan bekerja dalam situasi yang berbeda, Anda harus memahami nilai dan efek dari 20 flag.

Kadang jumlahnya bisa lebih dari 100. Ini bukan lebay.

Satu-satunya alasan produk ini masih bertahan hidup dan tetap berjalan adalah karena, secara harfiah, ada jutaan pengujian."

Kehidupan developer Oracle DB

1. Mulai mengerjakan bug baru

2. Menghabiskan 2 minggu untuk memahami 20 flag berbeda yang saling berinteraksi dengan cara misterius dan menyebabkan bug ini

3. Menambahkan satu flag lagi untuk menangani skenario khusus yang baru. Menulis beberapa baris kode lagi untuk memeriksa flag ini, lalu menambahkan beberapa baris kode untuk menyelesaikan situasi bermasalah dan mencegah bug

4. Submit perubahan kode ke test farm yang terdiri dari 100~200 mesin. Lalu build Oracle DB baru dan jalankan jutaan pengujian secara terdistribusi

5. Pulang. Datang lagi besok dan mulai tugas lain. Pengujian butuh 20~30 jam sampai selesai

6. Pulang. Datang lagi besok dan periksa hasil pengujian. Pada hari yang bagus, sekitar 100 pengujian gagal. Pada hari yang buruk, sekitar 1.000 gagal. Pilih beberapa pengujian ini untuk mencari tahu asumsi mana yang salah. Mungkin masih ada sekitar 10 flag lain yang perlu dipertimbangkan untuk memahami inti bug ini

7. Menambahkan beberapa flag lagi untuk menyelesaikan isu ini. Submit lagi perubahan ke test farm. Tunggu lagi 20~30 jam

8. Selama 2 minggu, perbaiki dan ulangi agar kombinasi flag ini bekerja dengan baik

9. Akhirnya, pada "suatu hari yang baik", semua pengujian tidak lagi gagal

10. Tambahkan lebih dari seratus pengujian untuk perubahan yang saya buat, agar developer sial berikutnya tidak merusak perbaikan ini

11. Submit lagi untuk pengujian terakhir. Lalu submit untuk review. Review bisa memakan waktu 2 minggu sampai 2 bulan, jadi pindah ke bug lain dan mulai kerja lagi

12. Setelah 2 minggu sampai 2 bulan, kalau semuanya selesai, kodenya di-merge ke main branch

Seperti itulah kehidupan programmer Oracle yang memperbaiki bug. Tanpa lebay.

Sekarang bayangkan seperti apa kengeriannya mengembangkan fitur baru.

Mengembangkan satu fitur kecil butuh waktu 6 bulan sampai 1 tahun, kadang sampai 2 tahun. (Misalnya menambahkan autentikasi baru seperti autentikasi Active Directory)

Bahwa produk ini bisa berjalan adalah sebuah keajaiban.

Sekarang saya sudah tidak bekerja di Oracle, dan saya tidak akan pernah bekerja di Oracle lagi

[neocoin]

Siklus test adalah

1. Tulis kode

2. Tulis test

3. Refactor kode, kembali ke 1

Namun karena langkah 1 dan 2 memakan terlalu banyak waktu, hasil akhirnya adalah langkah 3 terus terlewat.

[kunggom]

Ceramah Martin Fowler yang layak ditonton lagi saat ini. Sepertinya Oracle Database memang tidak punya ‘kualitas internal’ (Internal Quality) yang baik.

https://id.news.hada.io/topic?id=2752

[kbumsik]

Yah, dari sudut pandang Oracle sih mungkin itu terlihat wajar, malah sampai terasa seperti, "ah, software ini memang untuk enterprise ya..." sehingga jadi terkesan bisa dipercaya.

Tapi saya sendiri tidak ingin bekerja di tempat seperti itu seperti yang diceritakan di tulisan tersebut.

[exitmusic]

Saya justru jadi berpikir jangan-jangan proses pengembangannya rusak karena budaya development yang terlalu berpusat pada testing.

Pengembangannya dilakukan dengan pola pikir pokoknya asal semua test lolos, lewat jalur apa pun tidak masalah... mungkin di lingkungan seperti itu, refactoring pun cuma jadi angan-angan.

[sduck4]

Menurut saya, alih-alih masalah utamanya ada pada testing, bukankah yang lebih besar adalah masalah desain yang membuat kita harus mempertimbangkan 20~100 flag untuk memodifikasi/menambahkan fitur?

Meski begitu, sepertinya ini juga sulit dihindari karena kompleksitas DBMS.

[kunggom]

Bagaimanapun juga, tes pada akhirnya adalah kode yang ditulis oleh pengembang. Jadi sekalian teringat, saya memperkenalkan satu tulisan tentang tes.

https://id.news.hada.io/topic?id=2883

[ffdd270]

Kalau skalanya belum sebesar itu, menurut saya justru pengujian bisa terus menjamin bahwa meskipun antarmuka dirombak, perilakunya tetap sama seperti sebelumnya, jadi kita lebih berani melakukan refactoring. Belakangan ini saya sempat mengubah parameter di emulator yang sedang saya buat dari nilai BYTE menjadi Enum Value. Build berhasil, tapi tes gagal, jadi saya sempat merinding membayangkan apa jadinya kalau tidak ada tes.

Kalau codebase-nya sudah sebesar itu, bahkan saat mempertimbangkan refactoring pun mungkin akhirnya menyerah karena terlalu besar, lalu kode baru terus ditumpuk di atasnya... Saya menduga dengan hati-hati, mungkin mereka sudah terjebak dalam lingkaran tak berujung seperti itu.

[xguru]

Saya paham juga bahwa orang itu pasti sangat kesulitan,

namun ironisnya ini juga tulisan yang membuat saya berpikir, "ternyata testing memang sepenting ini," jadi saya terjemahkan.

Di postingan pertanyaan asli untuk jawaban ini, ada total 578 balasan.

Ask HN: What's the largest amount of bad code you have ever seen work?

https://news.ycombinator.com/item?id=18442637

Bahkan hanya melihat balasan level 1 saja sudah menarik. Jadi terasa bahwa hidup orang-orang di mana pun sebenarnya sama saja..