Pendekatan apa yang bisa saya ambil untuk menurunkan kemungkinan memperkenalkan bug baru di aplikasi warisan yang kompleks?

Di mana saya bekerja, saya sering harus mengembangkan (dan memperbaiki bug) dalam sistem lama (.NET 1) kode whos adalah spaghetti lengkap - dengan sedikit pemikiran diberikan pada nama variabel, struktur program atau komentar.

Karena ini, saya butuh waktu lama untuk memahami bit apa yang perlu diubah, dan saya sering 'memecah' perangkat lunak yang ada karena saya telah membuat modifikasi. Saya benar- benar ingin menghabiskan beberapa bulan (dengan kolega) melewatinya untuk refactor tetapi pengembang yang ada tidak dapat melihat kebutuhan - atau berpikir ada waktu untuk ini (sistemnya masif).

Saya takut harus mengerjakan kodenya karena butuh berhari-hari untuk memperbaiki sesuatu hanya untuk mengetahui bahwa saya telah merusak sesuatu yang lain. Ini jelas membuat saya terlihat tidak kompeten - jadi bagaimana saya bisa mengatasi ini?

Mulailah menulis tes untuk bagian yang sedang Anda kerjakan. Anda dapat mencoba alur kerja yang berlangsung seperti ini:

1. Tulis tes untuk bagian yang akan Anda ubah. Ini juga akan membantu Anda memahami bagaimana kode yang ada berlaku.
   • Kode refactor untuk mendukung pengujian jika diperlukan, tetapi Anda mungkin ingin menulis tes non-unit jika waktunya singkat.
2. Jalankan tes Anda untuk memastikan semuanya berjalan seperti yang Anda harapkan.
3. Buat perubahan Anda. Refactor jika diperlukan dengan semangat perbaikan kode terus menerus, tetapi jangan terbawa suasana.
4. Jalankan kembali tes Anda untuk memastikan Anda mempertahankan fungsi yang sama.

Jika Anda tidak membuang tes Anda, Anda dari waktu ke waktu akan membangun sebuah test suite yang harus mencakup bagian terpenting (dan / atau volatile) dari aplikasi dan membuat perubahan di dalamnya akan menjadi lebih mudah dan lebih aman.

Anda mungkin juga merasa Bekerja Efektif dengan Legacy Code oleh Michael Feathers sangat membantu.

Saya ingin mengikuti Paman Bob Martin 's Boy Scout Rule :

"Ketika Anda memiliki gumpalan warisan besar yang berantakan, apa yang harus Anda lakukan adalah ... Apa yang harus Anda lakukan adalah berhenti membuat kekacauan dan mulai membersihkannya.

Ini tidak berarti Anda memanggil manajer Anda ke ruang konferensi dan memberi tahu mereka bahwa Anda tidak akan menghadirkan fitur selama tiga bulan ke depan saat Anda membuat ulang kode. Jangan lakukan ini! Sebaliknya, itu berarti bahwa Anda akan mengadopsi "Aturan Pramuka" dan memeriksa setiap modul sedikit lebih bersih daripada ketika Anda memeriksanya.

Dari iterasi ke iterasi, dan dari rilis ke rilis, Anda akan membersihkan sistem ini sambil terus menambahkan fitur dan fungsi baru ke dalamnya. Tidak ada jalan lain."

Anda dapat menjelaskan kepada manajer bahwa perbaikan yang akan memakan waktu berjam-jam akhirnya memakan waktu berhari-hari karena kekacauan basis kode. Pengembang lain tidak akan melihat adanya kebutuhan untuk refactoring jika mereka adalah pengembang asli - mereka akan tahu sistem luar, tetapi manajemen harus tahu ada risiko di sana jika para pengembang itu pernah pergi dan membawa pengetahuan mereka dengan mereka.

Melakukan refactoring yang lengkap biasanya tidak layak, jadi sering Anda melakukan refactor pada suatu waktu - beberapa metode atau modul. Heck, jika perlu beberapa hari untuk memperbaikinya, mungkin Anda bisa menyertakan refactoring kecil dari modul yang bermasalah pada waktu yang sama.

Apakah Anda benar-benar perlu menghabiskan waktu berbulan-bulan merevisi kode? Atau bisakah Anda refactor kode saat Anda membuat perubahan. Jadi, misalnya, jika Anda menentukan bahwa metode Foo perlu dimodifikasi, Anda dapat mengambil kesempatan untuk memperbaiki metode Foo. Dan jika Anda harus melangkah melalui selusin metode lain untuk mencari tahu bahwa Foo adalah masalahnya, Anda dapat meninggalkan komentar dalam metode tersebut sehingga Anda atau orang lain di masa depan tahu apa yang seharusnya dilakukan oleh kode tersebut. Tentu saja, itu berarti masih ada setumpuk kode spageti, tetapi Anda setidaknya dapat memindahkan basis kode ke arah yang benar dan membuatnya lebih mudah bagi Anda sendiri. Mendapatkan beberapa bulan waktu untuk memperbaiki kode akan menjadi penjualan besar karena itu berarti Anda tidak memberikan apa pun yang diinginkan pengguna akhir sepanjang waktu itu.

Dan membuat unit test (atau, mudah-mudahan, memperluas test suite yang ada) harus membuat kecil kemungkinan Anda secara tidak sengaja memecahkan sesuatu.

Tip lain. Ketika bug muncul, dan setelah membalutnya, jangan berhenti sampai di situ!

Tanyakan lima mengapa, ambil pil merah dan lihat seberapa dalam lubang kelinci pergi, dan perbaiki akar penyebabnya (dan jalan setapak di sana).

Anda belajar banyak tentang sistem. Ini membantu memprioritaskan apa yang harus diperbaiki & diperbaiki. Dan setelah beberapa perjalanan seperti itu Anda memiliki beberapa "balok penyangga" yang kokoh untuk memperkuat tumpukan spaghetti monolitik.

Anda juga dapat menyimpan kode lama hingga benar-benar yakin bahwa modifikasi Anda kedap suara. Jika semua perubahan Anda terjadi, maka Anda dapat mengaktifkannya saat runtime dan dengan cepat menunjukkan lokasi bug regresi baru:

// old code
...

if (!File.ReadAllText("c:\patch_control.txt").Contains("StrangeUIBugFix=0"))
{
    // new code goes here
    ...
}

// old + new code
int someValue = 
    IsEnabled("StrangeUIBugFix") ? a + b :  // new code
    a * b; // old code

Satu hal: Never change any existing code if you are not sure what effect change would have on complete application.