Saya memperluas komentar saya menjadi sebuah jawaban karena saya pikir beberapa aspek dari masalah khusus diabaikan atau digunakan untuk menarik kesimpulan yang salah.
Pada titik ini, pertanyaan apakah refactor masih prematur (walaupun mungkin akan dijawab dengan bentuk spesifik 'ya').
Masalah utama di sini adalah bahwa (sebagaimana dicatat dalam beberapa jawaban) komentar yang Anda kutip sangat menunjukkan bahwa kode memiliki kondisi ras atau masalah konkurensi / sinkronisasi lainnya, seperti yang dibahas di sini . Ini adalah masalah yang sangat sulit, karena beberapa alasan. Pertama, seperti yang Anda temukan, perubahan yang tampaknya tidak terkait dapat memicu masalah (bug lain juga dapat memiliki efek ini, tetapi kesalahan concurrency hampir selalu terjadi.) Kedua, mereka sangat sulit untuk didiagnosis: bug sering memanifestasikan dirinya di tempat yang jauh dalam waktu atau kode dari penyebabnya, dan apa pun yang Anda lakukan untuk mendiagnosisnya dapat menyebabkannya hilang ( Heisenbugs). Ketiga, bug konkurensi sangat sulit ditemukan dalam pengujian. Sebagian, itu karena ledakan kombinatorial: itu cukup buruk untuk kode sekuensial, tetapi menambahkan interleaving yang mungkin dari eksekusi bersamaan meniupnya ke titik di mana masalah sekuensial menjadi tidak signifikan dibandingkan. Selain itu, bahkan uji kasus yang baik hanya dapat memicu masalah sesekali - Nancy Leveson menghitung bahwa salah satu bug mematikan di Therac 25terjadi di 1 dari sekitar 350 kali berjalan, tetapi jika Anda tidak tahu apa bug itu, atau bahkan ada bug, Anda tidak tahu berapa banyak pengulangan membuat tes yang efektif. Selain itu, hanya pengujian otomatis yang layak pada skala ini, dan ada kemungkinan bahwa penguji memaksakan batasan waktu halus sehingga tidak akan pernah benar-benar memicu bug (Heisenbugs lagi).
Ada beberapa alat untuk pengujian concurrency di beberapa lingkungan, seperti Helgrind untuk kode menggunakan pthreads POSIX, tetapi kami tidak tahu secara spesifik di sini. Pengujian harus dilengkapi dengan analisis statis (atau apakah itu sebaliknya?), Jika ada alat yang sesuai untuk lingkungan Anda.
Untuk menambah kesulitan, kompiler (dan bahkan prosesor, saat runtime) sering bebas mengatur ulang kode dengan cara yang kadang membuat alasan tentang keamanan utasnya sangat kontra-intuitif (mungkin kasus yang paling terkenal adalah pemeriksaan ulang). idiom kunci , meskipun beberapa lingkungan (Java, C ++ ...) telah dimodifikasi untuk memperbaikinya.)
Kode ini mungkin memiliki satu masalah sederhana yang menyebabkan semua gejala, tetapi kemungkinan besar Anda memiliki masalah sistemik yang dapat membuat rencana Anda untuk menghentikan fitur baru. Saya harap saya telah meyakinkan Anda bahwa Anda mungkin memiliki masalah serius di tangan Anda, mungkin bahkan ancaman eksistensial terhadap produk Anda, dan hal pertama yang harus dilakukan adalah mencari tahu apa yang terjadi. Jika ini mengungkapkan masalah konkurensi, saya sangat menyarankan Anda untuk memperbaikinya terlebih dahulu, bahkan sebelum Anda mengajukan pertanyaan apakah Anda harus melakukan refactoring yang lebih umum, dan sebelum Anda mencoba menambahkan lebih banyak fitur.