Apakah Kita Memiliki Tanggung Jawab untuk Memperbaiki Kode Lama?

Saya mencari-cari beberapa kode lama yang saya tulis. Ini berfungsi, tapi itu bukan kode yang bagus. Saya tahu lebih banyak sekarang daripada yang saya lakukan saat itu, sehingga saya bisa memperbaikinya. Ini bukan proyek saat ini, tetapi saat ini, bekerja, kode produksi. Apakah kita memiliki tanggung jawab untuk kembali dan memperbaiki kode yang telah kita tulis di masa lalu, atau apakah sikap yang benar "jika tidak rusak, jangan diperbaiki"? Perusahaan saya mensponsori kelas tinjauan kode beberapa tahun yang lalu dan salah satu hal utama yang bisa diambil adalah kadang-kadang itu cukup bagus; berpindah.

Jadi, pada titik tertentu apakah Anda cukup menyebutnya baik dan terus maju, atau haruskah Anda mencoba mendorong proyek untuk meningkatkan kode lama ketika Anda berpikir itu bisa lebih baik?

Kecuali jika Anda akan membuat perubahan pada "kode lama" ini untuk memperbaiki bug atau menambahkan fitur, saya tidak akan repot memperbaikinya hanya demi itu. Jika pada akhirnya Anda ingin memperbaikinya, pastikan Anda memiliki unit test yang akan menguji kode sebelum Anda mulai melakukan refactoring.

Anda dapat menggunakan "kode lama" untuk mempelajari praktik yang lebih baik. Jika Anda melakukan ini, ini adalah pengalaman belajar paruh waktu dan Anda tidak boleh mengharapkan kode itu untuk menggantikan apa yang saat ini dirilis atau disebarkan oleh klien / pelanggan.

Perbaiki bidang kode yang paling sering Anda perlu modifikasi . Karena Anda sering mengunjungi daerah-daerah ini, refactoring akan meningkatkan pemahaman Anda tentang kode dan keterbacaan ketika Anda harus mengunjungi mereka lagi, sedangkan tidak ada gunanya refactor kode tidak ada yang akan melihat lagi.

Selain itu, jika Anda hanya merefleksikan area kode ketika Anda perlu memodifikasinya, itu memberi Anda alasan yang valid jika refactoring Anda menyebabkan regresi . Tentu saja, cobalah untuk menutupi refactoring Anda dengan unit test, tetapi ini tidak selalu mungkin, terutama dengan kode legacy dan Anda harus mengharapkan refactorings besar untuk membuat regresi setiap sesekali.

Jika Anda perlu menambahkan fitur dan desain Anda memperlambat Anda atau menyebabkan duplikasi maka refactor . Ketika saya mendesain kode, saya hampir tidak pernah memprediksi dengan tepat perubahan apa yang akan dibutuhkan di masa depan. Namun, ketika saya menambahkan fitur baru, saya biasanya berakhir dengan refactoring kode bersama. Pada saat itu, saya telah menambahkan fitur ketiga / siklus refactoring, refactoring saya sudah membayar untuk dirinya sendiri dan kode bersama saya cukup stabil.

TLDR: refactor sesuai kebutuhan, tidak ada kewajiban.

Semua yang Anda lakukan memiliki biaya. Anda memiliki waktu terbatas untuk memprogram. Segala sesuatu yang Anda lakukan dalam pemrograman harus dipandang bertentangan, "Apa manfaatnya melakukan ini?" dan "Apa manfaat melakukan sesuatu yang lain?"

Jika Anda tidak memperhitungkan biaya peluang (Berapa biaya melakukan sesuatu yang lain?) Maka kualitasnya gratis. Lebih baik meningkatkan kode Anda. Anda akan belajar sesuatu. Ini akan berjalan lebih baik. Itu akan menjual lebih banyak.

Pertanyaan sebenarnya adalah apa hal terbaik berikutnya yang bisa Anda lakukan dengan waktu Anda? Dan kemudian Anda telah membuat trade-off.

Apakah akan menjual lebih banyak perangkat lunak?

Apakah ini akan menyebabkan lebih sedikit sakit kepala untuk didukung?

Apa yang akan kamu pelajari?

Apakah ini akan menjadi lebih estetis?

Apakah ini akan meningkatkan reputasi Anda?

Ajukan pertanyaan-pertanyaan ini (dan yang lainnya yang relevan dengan Anda) untuk ini dan aktivitas lain dalam antrian Anda, dan itu akan membantu menjawab jika perlu diperbaiki. Pertukaran ini adalah alasan mengapa ekonomi penting bagi programmer. Joel mengatakannya sebelum saya melakukannya, dan seorang mentor tua mengatakannya kepada saya bahkan sebelum Joel.

Atau jika Anda menginginkan jawaban yang lebih sederhana, berhentilah menonton TV sampai Anda memperbaiki kodenya. :-)

Saya pikir Anda harus mulai dengan bertanya pada diri sendiri pertanyaan yang tampaknya telah terjawab. Dalam hal apa kode itu buruk? Dan dengan ini Anda benar-benar bertanya pada diri sendiri hal berikut:

• Apakah kode tidak melakukan apa yang seharusnya dilakukan?
• Apakah kode menyebabkan masalah saat Anda memelihara perangkat lunak?
• Apakah kode sepenuhnya mandiri?
• Apakah Anda memiliki rencana untuk memperbarui atau mengganti kode kapan saja dalam waktu dekat?
• Apakah ada kasus bisnis yang dapat Anda buat untuk memperbarui kode yang Anda khawatirkan?

Jika ada satu hal yang saya pelajari selama bertahun-tahun, itu adalah Anda tidak mampu menebak diri sendiri setelah fakta. Setiap kali Anda memecahkan masalah dalam kode, Anda belajar sesuatu dan mungkin akan melihat bagaimana solusi Anda - atau sesuatu yang serupa - mungkin menjadi solusi yang lebih baik untuk masalah yang Anda selesaikan secara berbeda tahun lalu. Ini adalah hal yang baik, karena itu menunjukkan kepada Anda bahwa Anda telah belajar dari pengalaman Anda. Namun pertanyaan sebenarnya adalah apakah kode yang Anda tulis sebelumnya cenderung menjadi masalah warisan yang semakin sulit ditangani seiring waktu.

Apa yang benar-benar kita bicarakan di sini adalah apakah kode yang mengganggu Anda mudah atau sulit untuk dipelihara, dan seberapa mahal pemeliharaan itu mungkin seiring berjalannya waktu. Ini pada dasarnya adalah pertanyaan tentang Utang Teknis, dan apakah layak melunasi utang itu menggunakan sedikit perawatan bedah sekarang, atau apakah utang itu cukup kecil sehingga Anda dapat membiarkannya turun sebentar.

Ini adalah pertanyaan yang benar-benar perlu Anda timbang terhadap beban kerja Anda saat ini dan di masa depan, dan harus dibahas panjang lebar dengan manajemen dan tim Anda untuk mendapatkan pemahaman yang lebih baik tentang di mana menginvestasikan sumber daya Anda, dan apakah kode lama Anda layak waktu yang Anda mungkin perlu habiskan untuk itu - jika sama sekali. Jika Anda dapat membuat kasus bisnis yang bagus untuk memperkenalkan perubahan, maka tentu saja lakukan itu, tetapi jika Anda menghadapi keinginan untuk mengotak-atik kode karena Anda merasa malu dengan cara Anda menulisnya, maka saya sarankan tidak ada ruang untuk kebanggaan pribadi ketika datang untuk mempertahankan kode lama. Entah itu berfungsi, atau tidak, dan itu mudah dipelihara, atau mahal untuk dipelihara, dan itu tidak pernah baik atau buruk hanya karena pengalaman hari ini tidak tersedia untuk Anda kemarin.

Jelas jangan memperbaikinya hanya demi memperbaikinya. Seperti yang dikatakan orang lain (dan masuk akal), kita semua menjadi lebih baik (untuk beberapa nilai "lebih baik") seiring berjalannya waktu. Yang sedang berkata, meninjau kode (baik secara formal atau informal) sering menerangi potongan-potongan ini yang kita mungkin berharap tidak pernah melihat cahaya hari lagi.

Meskipun saya tidak percaya kita memiliki tanggung jawab untuk kembali dan memperbaiki kode yang tidak rusak, tidak aman, atau tergantung fitur pada daftar usang / EOL, berikut adalah beberapa hal yang saya lakukan di masa lalu dalam situasi ini :

• Identifikasi orang-orang di tim yang benar-benar menggali kembali dan meningkatkan kode, sebagai semacam tugas membersihkan otak atau menyenangkan, berukuran gigitan yang memberikan rasa pencapaian, dan menemukan waktu dalam jadwal bagi mereka untuk melakukannya secara teratur. Saya selalu memiliki setidaknya satu dari orang-orang ini dalam sebuah tim, dan pendekatan ini juga dapat meningkatkan moral (atau setidaknya suasana hati) jika kita semua dalam masa jeda atau turun.

• Gunakan itu sebagai dasar untuk latihan belajar. Untuk peserta magang, siswa, atau anggota baru / junior tim, refactoring kode lama dengan bimbingan dari anggota senior tim memberi mereka kesempatan untuk berkomunikasi dengan anggota tim baru, memahami lebih banyak tentang sistem, dan membiasakan diri menulis / memperbarui tes unit dan bekerja dengan integrasi terus menerus. Penting untuk dicatat bahwa latihan ini dilakukan dengan panduan, dan dibingkai dengan jelas sebagai latihan untuk membuat kode lebih baik karena tidak sesuai dengan standar / norma saat ini.

Jadi, tidak ada tanggung jawab untuk memperbaikinya, tetapi barang lama itu bisa sangat berguna. Dan unit test dan CI adalah teman Anda!

Belum tentu. Namun jika Anda melakukan pemeliharaan kode dan kebetulan menemukan sesuatu yang bisa lebih baik, Anda bisa mengubahnya asalkan Anda memiliki unit test yang sesuai untuk memastikan Anda tidak membuat regresi.

Jika tidak ada tes seperti itu dan Anda tidak dapat memastikan itu akan berperilaku seperti seharusnya, Anda lebih baik membiarkannya sendiri.

Dari sudut pandang seorang insinyur, tentu saya sangat ingin bekerja pada kode lama sampai tidak dapat diperbaiki lagi. Tetapi apakah ada kasus bisnis untuk itu? Pada akhirnya, kode itu ada untuk berkontribusi pada garis bawah, profitabilitas tempat kerja Anda. Jika tidak, tinggalkan saja.

Ada peringatan besar, jika dengan meningkatkan kode, Anda akan menghindari bug dari terjadi, (memikirkan bola Y2K besar di sini ..) Saya pasti akan membawanya ke atas dengan seseorang yang lebih tinggi, mungkin manajer unit bisnis Anda, dan diskusikan konsekuensi peningkatan kode.

Bagi saya, pertanyaan itu dapat diulang dan digeneralisasi: "Mengapa seseorang harus menghabiskan sumber daya tambahan (waktu, uang, mental, dll.) Jika potongan kode yang konkret itu bekerja dengan baik sekarang? Bukankah itu membuang-buang sumber daya (s) ? "

Setiap kali saya menemukan kode warisan, saya memikirkan beberapa hal yang tampaknya penting.

1. Untuk apa saya akan melakukan perubahan?
2. Apakah saya perlu mendukung kode ini? Seberapa cepat itu bisa terjadi (dekat / jauh di masa depan)?
3. Apakah kode ini cukup nyaman untuk digunakan? (Sekarang juga)
4. Bisakah saya yakin bahwa semua perubahan yang saya lakukan aman? Tes yang berbeda biasanya membantu menjawab pertanyaan ini.
5. Konsekuensi apa yang dapat saya temui jika saya akan membuat kesalahan selama modifikasi kode? Apakah mungkin untuk mengembalikan perubahan saya dengan cepat? Apakah ini akan membuang-buang waktu?
6. ...

Sebenarnya, Anda harus banyak bertanya pada diri sendiri. Tidak ada daftar lengkap dan final dari mereka. Hanya Anda dan mungkin rekan tim Anda yang dapat menemukan jawabannya.

PS Saya perhatikan bahwa saya cenderung sering menulis ulang kode, sedangkan teman dan rekan satu tim saya cenderung tidak menyentuhnya. Itu karena kami menjawab pertanyaan yang disebutkan secara berbeda. Dan saya harus mengatakan bahwa kita sering salah menjawab ... karena kita tidak dapat memprediksi masa depan.

Apakah Microsoft perlu memperbarui windows? Apakah semua Distro * nix harus terus berkembang? Atau contoh yang lebih praktis apakah semua orang masih mengendarai mobil tahun 1970-an?

Anda biasanya dapat menulis kode dengan lebih baik pada putaran kedua, Anda belajar lebih banyak tentang domain dengan menulisnya terlebih dahulu.

Tidak ada jawaban sederhana untuk apakah itu layak untuk diolah kembali. Secara umum Anda tidak boleh kecuali a) itu adalah pembelajaran yang baik untuk Anda atau b) Anda akan menghemat waktu dalam jangka panjang dengan kode yang lebih baik. Ingat, setiap perubahan berisiko menimbulkan bug.

Sebagai catatan saya akan sangat menganjurkan tes unit. Sangat mudah untuk membersihkan refracoring terutama jika Anda tidak memiliki perilaku saat ini ditandai dengan istirahat otomatis.

Saya percaya bahwa kita memiliki tanggung jawab untuk menulis kode sebaik mungkin yang kita bisa hari ini. Itu berarti menggunakan semua yang telah kita pelajari di masa lalu dan menolak mengambil jalan pintas dalam desain kita. Jika tekanan jadwal menyebabkan sesuatu untuk dipotong, saya tidak percaya kualitas perangkat lunak kami bahkan harus dipertimbangkan, klip kertas animasi kecil yang rapi, di sisi lain ...

Sekarang jika Anda bekerja dan menemukan bahwa kode yang Anda butuhkan untuk berinteraksi tidak ditulis hingga tingkat yang saat ini dapat Anda tulis, maka masuk akal untuk memperbaikinya JIKA Anda dapat melakukannya dengan cara metodis yang terkontrol. Saya pribadi memiliki pengalaman yang sangat minim dengan jenis Refactoring ini, seperti semua orang (hampir semua orang?) Saya mencoba keseluruhan "mari kita ubah semuanya dan berdoa itu bekerja" dan mendapat gigitan yang cukup buruk. Saya sarankan melihat ke diskusi Martin Fowler (baik bukunya atau salah satu dari banyak artikel ) tentang masalah ini. Dia tampaknya telah menginspirasi sebagian besar pemikiran saat ini tentang proses tersebut.

Tentu saja kadang-kadang Anda mungkin tidak dapat membersihkan kode yang Anda inginkan. Joel Spolsky menulis sebuah artikel tentang mengapa Anda mungkin ingin mencurahkan beberapa minggu untuk sekadar Refactor kode Anda. Bacalah di sini dan ya itu agak lama, tetapi saya pikir informasinya masih relevan.

saya harap itu membantu

Saya merasa bahwa refactoring / meningkatkan kode lama mendefinisikan programmer itu sendiri. Ingin meningkatkan kode yang Anda tulis setahun yang lalu hanya menunjukkan kemajuan Anda, dan jika itu membuat aplikasi lebih baik dan Anda memiliki kemampuan, waktu, dan persetujuan untuk memperbaikinya, lakukanlah.

Lebih baik / ditingkatkan adalah perbandingan multi-sumbu. Apakah Anda pikir Anda dapat membuatnya lebih cepat, lebih kecil, lebih efisien sumber daya, lebih mudah dibaca, informasi yang lebih bermanfaat, hasil yang lebih tepat, lebih fleksibel, lebih umum, dapat berjalan pada lebih banyak sistem, menghilangkan ketergantungan pada produk yang terpisah?

Mengapa perusahaan Anda harus membayar Anda untuk menghabiskan waktu menulis ulang kode ini, alih-alih menulis kode baru atau menulis ulang sepotong kode lainnya?

Anda harus melakukan peningkatan saat peluang muncul, tetapi peluang berarti bahwa Anda telah mengerjakan kode, atau Anda telah mengidentifikasi alasan bisnis untuk melakukan perubahan.

Mendorong perubahan produksi menghasilkan peluang yang tidak nol untuk memecahkan sesuatu (pengujian unit dan fungsional hanya mengurangi peluang ini, mereka tidak menghilangkannya), dan hanya boleh dilakukan ketika manfaat yang diharapkan melebihi risiko.

Mana poin lain yang perlu dipertimbangkan - apakah Anda bermaksud mendorong perubahan ini ke produksi, atau hanya ke cabang pengembangan? Bilah untuk dua skenario sama sekali berbeda. Jika itu hanya terjadi di cabang pengembangan, dan mungkin tidak pernah masuk ke produksi, maka peluang pada dasarnya berarti Anda melihat kode untuk beberapa alasan, dan tidak memakan waktu untuk melakukannya. Hal ini dapat ditinjau sebagai diperlukan jika push harus pernah terjadi, dan ditinggalkan jika dianggap tidak beralasan pada yang waktu. Jika di sisi lain, ini akan diproduksi sekarang, seperti yang saya katakan di atas, Anda perlu mempertimbangkan apakah perubahan ini sepadan dengan biayanya: dalam hal waktu yang dihabiskan untuk melakukan push, dan manfaat menggunakan kode baru.

Salah satu aturan praktis yang baik adalah bahwa jika Anda butuh waktu untuk memahami apa yang dilakukan kode, dan jika kali ini dapat dikurangi maju dengan beberapa refactor yang dipilih dengan baik, maka Anda melayani kebutuhan bisnis dan tim Anda dengan mengambil langkah-langkah ini.

Jika kode tidak mendapat manfaat dari analisis Anda, jika nama bidang belum menjadi ekspresif dari maksud kode dan metode belum dipecah menjadi potongan yang dapat dibaca, maka bisnis telah kehilangan sesuatu yang bernilai: keadaan pemahaman Anda. Dengan alat-alat seperti Visual Studio dan ReSharper, jenis refactoring ini aman, netral secara logika, dan berpotensi besar dalam produktivitas dan kepercayaan diri pengembang di masa depan.

Seperti yang dikatakan Paman Bob Martin, "Selalu tinggalkan perkemahan lebih bersih daripada yang Anda temukan."

Ini adalah pertanyaan untuk diajukan kepada manajemen di perusahaan Anda.

Apakah Anda punya waktu dan sumber daya yang diperlukan untuk kembali dan melakukan perubahan pada kode lama?

Apakah Anda punya waktu dan sumber daya untuk memiliki tim QA TEST apa yang telah Anda ubah untuk memastikan tidak rusak?

Saya telah jatuh ke dalam perangkap ini sebelumnya di mana saya akan berada dalam modul memperbaiki bug, dan melihat kode saya atau orang lain menulis yang tidak efisien atau tidak elegan, mengubahnya, dan berakhir dengan lebih banyak masalah untuk ditangani daripada jika saya hanya memperbaiki bug yang ditugaskan untuk saya perbaiki.

Tergantung.

Jika kode tersebut benar-benar rusak, sehingga mengandung bug yang mau tidak mau akan muncul pada satu titik (misalnya, beberapa penghitung yang pada titik tertentu akan meluap dan menyebabkan masalah yang tidak menyenangkan), maka memperbaiki itu mungkin sepadan dengan usaha - tetapi jika Anda lakukan, taruh semua kemungkinan perlindungan di tempat pertama untuk menghindari memperkenalkan bug baru: pastikan Anda memiliki tes unit yang bermakna yang mencakup semua yang Anda sentuh, minta semua perubahan Anda ditinjau oleh seseorang yang kompeten, bersikeras untuk menguji secara menyeluruh, pastikan Anda dapat kembali ke yang lama versi kapan saja, buat cadangan data apa pun sebelum mulai berproduksi, taruh ke lingkungan penerimaan terlebih dahulu dan uji dulu oleh pengguna sebenarnya, dll. Anda juga ingin mendapatkan persetujuan sebelum melanjutkan: jika bug benar-benar merupakan bom waktu , dan manajer Anda agak kompeten,Anda akan dapat meyakinkan dia untuk membiarkan Anda memperbaikinya (dan jika Anda tidak mendapatkan persetujuan, maka mungkin itu pertanda bahwa Anda salah).

OTOH, jika keluhan Anda hanyalah kurangnya keanggunan kode, maka jangan Anda berani menyentuhnya. Sudah melakukan layanan yang setia dalam produksi selama beberapa waktu sekarang, mengubah kode hanya akan memuaskan Anda, tetapi tidak menambah nilai, dan seperti setiap perubahan, ada risiko Anda memecahkan sesuatu. Bahkan jika Anda tidak melakukannya, waktu Anda sangat berharga (secara harfiah: Anda dibayar untuk apa yang Anda lakukan, jadi setiap menit waktu Anda membutuhkan uang), dan karena Anda tidak menambahkan nilai aktual, perubahan seperti itu akan menjadi kerugian bersih untuk perusahaan dan proyek.