Ribuan kesalahan!

Saya ditugaskan ke proyek baru baru-baru ini. Sebenarnya, proyek lama sebenarnya, ditulis dalam ASP klasik. Sekarang versi baru aplikasi sedang ditulis dalam ASP.NET terbaru, tetapi itu tidak diharapkan menjadi RTM dalam beberapa saat (perkiraan tanggal rilis adalah Januari 2017) jadi saya harus melakukan beberapa pemeliharaan pada aplikasi lama hingga dapat dibuang.
Juga, saya merasa bahwa tidak semua pelanggan akan segera beralih ke program baru, jadi versi ini mungkin akan ada untuk sementara waktu.

Dan masalahnya adalah, ini penuh dengan kesalahan. Sebagian darinya berasal dari abad sebelumnya, ketika tidak ada standar web, dan saya tidak terlalu keberatan dengan mode Quirks, dan widthdan heightatribut bukannya CSS, tabel yang digunakan untuk tata letak, frameset dll, tapi oh, semua kesalahan itu! width="20px"di semua tempat,, onchange="javascript:..."dan di tempat-tempat di mana mereka menggunakan css, style="width:20"dan style="width=20px"merupakan hal biasa. Belum lagi banyak garis di mana ada kontradiksi widthdan styleatribut. Dll dll.
Akibatnya, aplikasi web hanya berjalan di bawah IE, dan hanya dalam mode kompatibilitas. Jelas bahwa pengembang tidak pernah melihat validitas kode, hanya jika apa yang keluar tampak seperti apa yang ada dalam benak mereka seharusnya terlihat.

Dan saya tidak tahu bagaimana mengatasinya. Saya merasa tidak mungkin untuk menutup mata terhadap kesalahan-kesalahan itu sambil mencari kode untuk kesalahan lainnya.
Tentu saja saya dapat melakukan pencarian dan penggantian global untuk menyingkirkan sebagian besar masalah, tetapi itu berarti komit pertama saya akan terdiri dari ribuan file .asp yang diubah. Bisakah saya melakukan itu?

Sepertinya Anda membingungkan beberapa hal dalam istilah "kesalahan"

• atribut html lawas
• gaya pengkodean
• kesalahan pengkodean yang tidak menyebabkan bug
• bug yang tidak dilaporkan
• kesalahan yang sekarang menjadi fitur
• bug yang dilaporkan
• bug yang dilaporkan Anda telah ditugaskan untuk memperbaikinya

Pada aplikasi lawas yang akan diganti hanya salah satu dari jenis kesalahan ini yang harus Anda perhatikan. Yang terakhir.

Saya akan mengatakan bahwa Anda bahkan tidak boleh memperbaiki hal-hal lain pada fitur yang Anda perbaiki bug, terutama karena:

• kesalahan yang sekarang menjadi fitur

Anda dapat melihat dari kode bagaimana itu mungkin dimaksudkan untuk bekerja tetapi tidak pernah melakukannya, tetapi semua pengguna telah bergaul dengan elemen lebar yang tidak ditentukan selama 10 tahun terakhir dan mereka tidak akan berterima kasih telah memperbaikinya.

Di sisi positifnya, jika Anda memasang JFDI sinis langsung, Anda dapat membakar bug dengan super cepat dan tim versi baru tidak akan bisa mengikuti fitur versi lama.

Ini akan memberi Anda senyum senang yang goyah dari ironic glee saat Anda merekomendasikan emulator plugin chrome ie6 kepada klien sehingga mereka dapat terus menggunakan 'fitur' tenda yang mereka sukai

Apa yang Anda tanyakan bukanlah pertanyaan teknis, dan tidak ada orang di sini yang dapat menjawabnya.

Anda sedang mengerjakan perangkat lunak dalam mode pemeliharaan, dan Anda mengamati teknologi ketinggalan zaman dan sejumlah besar ketidaksempurnaan dan ketidakkonsistenan. Anda bertanya apa yang harus dilakukan. Haruskah Anda misalnya memperluas upaya untuk membuatnya lintas browser yang kompatibel? Haruskah Anda membawanya sesuai dengan standar modern? Haruskah Anda memperbaiki inkonsistensi sintaksis di seluruh aplikasi? Masalahnya, ini adalah keputusan bisnis . Anda harus bertanya kepada manajer atau pemilik produk Anda masalah apa yang mereka ingin Anda selesaikan dan apa prioritas mereka. Karena sudah ada proyek yang sedang berjalan untuk menulis ulang aplikasi, manajemen kemungkinan besar sudah menyadari masalah yang Anda amati.

Jika aplikasi akan diganti penuh dalam hitungan bulan, kemungkinan mereka hanya ingin Anda memperbaiki masalah kritis tertentu dan membiarkan sisanya berantakan. Tapi kami tidak tahu.

Anda bertanya apakah Anda dapat melakukan operasi pencarian-dan-ganti di basis kode, mengubah ribuan file. Tentu saja Anda bisa. Pertanyaannya adalah apakah Anda seharusnya . Perubahan besar-besaran seperti ini kemungkinan akan membutuhkan pengujian ekstensif untuk memastikan tidak ada yang rusak. Sekali lagi ini adalah keputusan bisnis jika manfaatnya melebihi biaya dalam waktu dan risiko.

Ketika aplikasi akan diganti dalam 18 hingga 24 minggu (menambahkan penundaan yang diharapkan ke 6 hingga 8 minggu yang diperkirakan disajikan di atas) maka Anda benar-benar perlu bertanya pada diri sendiri nilai apa yang Anda tambahkan ke bisnis dengan tetap menginvestasikan sejumlah besar pekerjaan di versi lama.

Tentu, ketika Anda akan terjebak dengan mendukung aplikasi untuk beberapa tahun yang akan datang, maka menyingkirkan hutang teknis bisa sia-sia dalam jangka panjang. Tapi ketika semua itu akan dibuang, lalu mengapa repot-repot? Cukup tambahkan perbaikan peretasan lainnya di atas semua perbaikan peretasan lainnya untuk memperbaiki masalah apa pun yang tidak bisa menunggu sampai rilis versi baru dan menyebutnya sehari.

Anda mungkin juga bertanya pada diri sendiri apa yang dapat Anda lakukan untuk aplikasi dalam masa kecil yang masih tersisa. Ketika Anda benar-benar bosan sekarang dan tidak punya apa-apa yang lebih baik untuk dilakukan dengan waktu Anda, Anda bisa memberikannya perbaikan besar-besaran dan menghapus semua masalah gaya yang Anda sebutkan, tetapi sangat mungkin bahwa ini pada awalnya akan merusak lebih banyak hal daripada memperbaiki . Anda mungkin bisa menyingkirkan masalah-masalah baru ini pada akhirnya dengan waktu yang cukup, tetapi Anda tidak punya waktu.

Alasan untuk TIDAK melakukan perubahan besar:

Satu: Kode akan hilang dalam beberapa bulan. Apakah benar-benar sepadan dengan waktu perusahaan bagi Anda untuk menghabiskan 5 bulan memperbaiki sistem yang kemudian akan dibuang 1 bulan kemudian? Peringatan: Sistem jarang hilang ketika mereka dijadwalkan untuk pergi. Sistem penggantian hampir selalu terlambat, ada pengguna yang tidak dapat memutakhirkan untuk alasan apa pun, dll. Tapi ini adalah masalah yang kompleks.

Dua: Jika Anda membuat banyak perubahan, terutama pencarian dan penggantian massal, Anda akan memperkenalkan bug. Bukan Anda mungkin memperkenalkan bug: Anda akan melakukannya. Misalkan Anda melakukan S&R dan mengubah "width = 200" menjadi "width: 200px". Apakah ada kode C # atau VB pada ASP ASP Anda? Karena jika Anda memiliki variabel bernama "width" yang Anda atur menjadi 200, Anda baru saja memecahkannya. (Atau dalam hal ini, apakah Anda berpikir untuk membatasi S&R ke halaman ASP?) Atau jika Anda mengubah "width: 200" menjadi "width: 200px", apa yang terjadi jika ada satu tempat dalam kode yang mengatakan "width: 200mm "? Sekarang tertulis "width: 200pxmm". Oke, anggap saja Anda memikirkan hal itu. Bagaimana jika ada tempat yang memiliki spesifikasi lebar yang tidak valid, yang tentu saja diabaikan, dan sekarang meletakkan dengan cukup baik. Anda "memperbaiki" lebar dan sekarang menjabarkan dengan 200px ... dan tampilan kacau, karena 200px sebenarnya adalah lebar yang salah untuk diberikan dan hanya berfungsi karena nilai itu diabaikan? Mass S&R sangat berbahaya, karena Anda hampir pasti tidak mempelajari setiap tempat yang Anda ubah. Anda bahkan mungkin tidak yakin apa yang harus diuji.

Tiga: Kode yang "jelas" salah mungkin sebenarnya adalah apa yang diinginkan pengguna. Saya telah melihat banyak spesifikasi persyaratan yang menyerukan perilaku yang jelas salah dan gila ... dan kemudian saya kembali ke pengguna dan bertanya apa yang mereka BENAR-BENAR inginkan, dan ternyata mereka benar-benar menginginkan perilaku gila ini, karena itulah bagaimana bisnis mereka bekerja atau peraturan pemerintah mensyaratkannya atau apa pun.

Bahkan jika perilakunya benar-benar salah, mungkin pengguna telah mengharapkannya dan mereka secara rutin mengatasinya, dan dengan memperbaikinya, Anda akan merusak solusi mereka. Contoh: Saya bekerja pada sistem di mana kami memiliki tempat di mana Anda menentukan dari dan melalui tanggal bahwa penjualan tersedia untuk umum. Kedua tanggal benar-benar tengah malam yang dimulai hari itu, jadi jika Anda mengatakan "sampai 30 Juli" itu berarti berakhir dengan akhir hari 29 Juli, yaitu satu menit sebelum 12:01 30 Juli, bukan akhir 30 Juli Pada satu titik saya memperbaiki ini, tetapi saya hanya bisa melakukan itu karena ada kurang dari setengah lusin orang dengan wewenang untuk menggunakan layar itu, dan saya hanya bisa memberi tahu mereka semua bahwa saya telah memperbaikinya. Jika ada ratusan pengguna, dan mereka semua sudah tahu sekarang bahwa Anda benar-benar harus memberikan hari setelah tanggal, maka "perbaikan" saya

Tentu saja saya dapat melakukan pencarian dan penggantian global untuk menyingkirkan sebagian besar masalah, tetapi itu berarti komit pertama saya akan terdiri dari ribuan file .asp yang diubah. Bisakah saya melakukan itu?

Saya tidak mengerti mengapa tidak. Komit harus konseptual satu hal, tapi saya tidak melihat alasan mengapa menemukan global dan mengganti dari style="width=20"ke style="width: 20px"tidak akan dihitung sebagai "satu hal", secara konseptual berbicara. Dan jika itu akan membantu Anda tidur lebih baik, menyelamatkan Anda dari gangguan ketika Anda memperbaiki hal-hal lain, dan tidak mengacaukan segalanya , mengapa tidak?

Masalah Anda adalah menetapkan prioritas : Manakah dari masalah tersebut adalah showstoppers (dalam produksi)? Yang mana bom waktu yang berdetak? Dan yang dapat dibiarkan dalam waktu lebih lama (karena itu berfungsi dan telah melakukannya selama bertahun-tahun sekarang, bahkan semacam)?

Apa yang akan saya lakukan dalam situasi Anda adalah membuat daftar kelas masalah yang ingin saya lihat. Misalnya, mengganti style="width=(\d+)"dengan style="width: \1px"(yang mungkin dapat diperbaiki dengan global find / replace menggunakan regexp - maaf jika saya tidak 100%) akan menjadi satu kelas, dan jika hanya ada satu kejadian, biarlah. Untuk setiap kategori daftar prioritas (seberapa mendesak untuk melakukan ini) dan perkiraan pekerjaan (berapa lama untuk melakukan kategori ini).

Tugas pemeliharaan Anda juga akan tercantum dalam daftar ini. Sekarang Anda mulai menerapkan beberapa manajemen, bahkan jika hanya untuk diri sendiri, dan Anda memiliki alat untuk digunakan ketika Anda punya waktu dan tidak ada yang harus dilakukan, atau ketika Anda perlu bernegosiasi dengan manajer Anda tentang pekerjaan yang harus dilakukan (atau meminta waktu yang dialokasikan untuk sesuatu yang mungkin tidak dia sadari). (Proaktif semacam ini mungkin membantu Anda agar diperhatikan untuk promosi, jika dilakukan dengan benar.)

Saya kira Anda menikmati pemrograman karena Anda memiliki kepribadian yang sedikit perfeksionis. TETAPI dalam lingkungan komersial, Anda perlu mulai menyadari bahwa kesempurnaan adalah musuh kebaikan (dan kebaikan mendatangkan uang, kesempurnaan mungkin tidak selalu membawa lebih banyak pekerjaan yang jauh lebih banyak). Pertama lakukan apa yang dibutuhkan, kemudian lakukan apa yang baik untuk dimiliki. Ya, ini mungkin bertentangan dengan keinginan Anda. Hanya menyeringai dan menanggungnya, dan mungkin mendapatkan hobi untuk melatih kesempurnaan Anda dan membuat Anda tetap waras ;-)