Apakah Kita Memiliki Tanggung Jawab untuk Memperbaiki Kode Lama?


64

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?


Apakah Anda melakukan ini di waktu Anda sendiri atau dengan uang receh perusahaan?
JBRWilkinson

42
kebanyakan tempat, tanggung jawab pertama Anda adalah menambah nilai bagi perusahaan . Jika Anda melakukan sesuatu yang tidak langsung ditambahkan ke garis bawah, hal lain adalah usaha yang sia-sia. Kode kerja yang lama diuji adalah kode kerja yang diuji , sentuh untuk membuatnya lebih baik seperti latihan pelapisan emas dan sekarang kode tersebut menjadi yang baru yang belum diuji dan dengan demikian tidak berfungsi , yang tidak menambah nilai pada intinya.

7
Tanyakan kepada bos Anda apa yang dia ingin Anda lakukan. Anda kemungkinan besar akan disuruh meninggalkannya sendirian. Juga, perubahan kode harus dalam pengalaman saya hanya dilakukan sebagai bagian dari pengiriman yang sebenarnya. Perubahan acak dari waktu ke waktu memiliki kemungkinan terlalu besar untuk memperkenalkan kesalahan, yang membutuhkan waktu terlalu lama untuk diperbaiki karena Anda tidak memiliki perubahan yang segar dalam pikiran.

1
Tambahkan beberapa komentar tentang kemungkinan peningkatan dalam dokumentasi dan biarkan begitu saja?
James P.

2
Tulis tes unit atau regresi. Jangan mengubah kode, tetapi buat seseorang untuk datang nanti dan buat perubahan yang diperlukan dengan percaya diri meskipun tidak terbiasa dengan kode.
James Youngman

Jawaban:


66

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.


4
Apa yang saya pikirkan adalah "busuk perangkat lunak" dan teori jendela yang rusak dari programmer pragmatis dan efek dari entropi perangkat lunak. pragprog.com/the-pragmatic-programmer/extracts/software-entropy
jmq

5
Kecuali jika Anda akan menambah nilai bagi perusahaan dengan kode refactoring yang sudah berfungsi dan sedang dalam produksi, akan sulit untuk membenarkan waktu yang diperlukan untuk menghapus "busuk perangkat lunak" kepada atasan Anda. Hanya lakukan ini jika Anda akan aktif bekerja dalam kode ini, jika tidak ada banyak manfaat selain pengalaman refactoring yang akan Anda peroleh.
Bernard

11
@ jmquigley, perangkat lunak hanya membusuk jika kode sumbernya diubah, dan jendela yang rusak hanya berpengaruh jika terlihat. Basis kode lama, jika tidak perlu menyentuhnya, akan bekerja dengan cara yang sama selama lingkungannya mengizinkannya.
Péter Török

2
Cobalah untuk tidak memasukkan kesalahan ke dalam program kerja dalam proses "memperbaikinya" ;-)
robrambusch

4
Saya pikir kode 'membusuk' adalah metafora yang disayangkan. kode tidak membusuk, jika Anda tidak melakukan apa-apa, kode itu tidak berubah sama sekali. jika ada, kerja kode mengeras - Anda memperkenalkan entropi saat Anda mengerjakannya, dan Anda dapat menghapus entropi ini dengan menghabiskan banyak energi untuk membuatnya kembali (mirip dengan menyusun ulang / menempa)
jk.

32

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.


Bisakah Anda lebih spesifik apa yang Anda maksud dengan 'refactoring menyebabkan regresi'? Apakah tujuan refactoring untuk meningkatkan desain perangkat lunak Anda tanpa mengubah perilakunya? Bisakah Anda memberi contoh?
Manfred

3
@ John: Ya, itu tujuan refactoring: memperbaiki kode tetapi mempertahankan perilaku.
Bernard

@John setiap refactoring non-sepele berisiko mengubah perilaku yang tidak disengaja, terutama ketika tidak ada tes regresi di tempat.
Garrett Hall

14

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. :-)


4
Untuk meminjam dari contoh nyata bukan dalam perangkat lunak, beberapa perusahaan transportasi akan membayar karyawan untuk membersihkan dan memoles rig mereka, karena berbagai alasan, sering kali karena membantu pengemudi / operator membangun kebanggaan pada unit 'mereka', sehingga mereka lebih berhati-hati dari itu, dan perhatikan lebih dekat untuk itu; menghindari masalah dengan cepat dan mudah. Pada saat yang sama, jika ada bermil-mil jauhnya, masuk ke dalam truk dan mengendarainya dan khawatir tentang membersihkannya setelah beberapa ribu mil lagi (pergi dari pantai ke pantai).
JustinC

@justinC - tepatnya! Teladan Anda menangkap kedua alasan lain, dan biaya peluang.
MathAttack

Biaya (atau nilai , dll) memang kata kunci untuk jawaban yang benar. Seharusnya menambah nilai dalam jumlah keseluruhan, juga mempertimbangkan bahwa menyentuh kode lama dapat merusak barang-barang (menghilangkan nilai) tidak peduli berapa banyak lebih dioptimalkan kelihatannya.
cregox

6

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.


5

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!


4
memberikan kode buruk kepada seorang pemula adalah anti-pola terburuk dari manajemen proyek yang ada, mereka melihatnya dan menganggapnya benar dan hanya menduplikasinya, kode buruk menyebar seperti kanker karena saran buruk seperti ini.

1
@JarrodRoberson Terima kasih telah menunjukkan apa yang seharusnya saya jelaskan; Saya telah mengedit jawaban saya untuk mencatat bahwa saya melakukan ini secara khusus sebagai bagian dari pengalaman belajar, dan mereka bekerja dengan seorang mentor. Ini bukan situasi melempar mereka dalam-dalam-akhir.
jcmeloni

Saya masih berpikir itu ditulis dengan cara yang orang akan membaca "Berikan kepada pemula - magang dan siswa, terutama." dan berhenti membaca untuk pemahaman di sana. Jika diucapkan di mana itu dimulai dengan anggota senior dan pasangan anggota junior memprogram gaya XP atau sesuatu seperti itu mungkin tidak terlalu buruk. Saya memiliki masalah dengan aspek pelapisan emas dan menambahkan risiko mengubah hal-hal demi mengubah mereka dari titik peluru pertama juga.

1
Ulasan kode adalah untuk mencegah kode buruk memasuki kontrol versi, bukan untuk mengidentifikasi kode yang buruk setelah fakta, itu adalah cara untuk terlambat.

@JarrodRoberson Terima kasih telah menunjukkan masalah yang Anda miliki dengan bahasa saya yang kabur dan sayangnya berpotensi menyesatkan; Saya telah membuat lebih banyak pengeditan dan menunggu apa yang ada di sana sekarang.
jcmeloni

2

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.


4
Saya akan menambahkan "dan jika mengubahnya tidak akan menambah banyak waktu untuk jadwal yang direncanakan"
HLGEM

2

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.


2

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.


2

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?


1

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.


1

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


1

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.


1

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.


Perubahan kode produksi yang tidak dimaksudkan untuk didorong ke dalam produksi? Tetapi apakah disimpan di cabang pengembangan? hmm Jangan berpikir saya akan menerimanya. Ini hanya akan berfungsi untuk membingungkan dan menambah pengembangan kemudian karena tidak ada yang akan yakin apakah itu harus diubah (lagi) atau tidak untuk mematuhi perubahan lain yang dimaksudkan untuk produksi.
Marjan Venema

@MarjanVenema: ketika pengembangan berhenti, semua cabang harus identik. Jika nanti Anda melihat sesuatu yang dapat diperbaiki, tetapi tidak HARUS ditingkatkan, perbaiki di cabang pengembangan, dan biarkan di sana menunggu pengembangan dilanjutkan dan dorongan baru dibuat.
jmoreno

Ah, oke, saya mengerti. Bagi saya itu berarti masih dimaksudkan untuk produksi, baru nanti. Dan itu adalah risiko yang cukup kecuali Anda memastikan bahwa ada masalah yang menyertai dalam sistem pelacakan masalah Anda sehingga departemen penguji / qa juga menusuk "perbaikan" Anda. Kalau tidak, mereka akan membuatnya menjadi produksi yang belum diuji saat naik bersama perubahan lainnya.
Marjan Venema

@ Marsjanen: mungkin saya seharusnya mengatakan bermaksud untuk mendorongnya ke produksi segera. Jika Anda yakin bahwa perubahan tidak akan pernah terdorong ke arah, maka jangan lakukan perubahan. Jika OTOH, Anda tidak pasti, tetapi perubahan itu mudah dilakukan dan Anda sudah ada di sana ... lakukan perubahan. Adapun pelacakan dan pengujian, itu dimaksudkan untuk dicakup oleh "ditinjau sesuai kebutuhan".
jmoreno

hmm, saya kira saya akan memilih untuk tidak melakukan perubahan kecuali itu terkait langsung dengan apa yang saya kerjakan. Dan, karena kami memiliki branche per masalah, saya selalu tahu kapan (rilis mana) sesuatu akan diproduksi. Juga, saya benar-benar merasa perubahan yang dibuat perlu diuji, bukan "hanya" ditinjau sesuai kebutuhan. Penilaian orang tentang apa yang merupakan risiko berbeda dan sepasang mata kedua tidak pernah tersesat. Kemudian lagi, saya bekerja sebagian besar pada kode sisi server di mana perubahan secara halus dapat mempengaruhi hasil yang dikembalikan ke klien. Penilaian risiko untuk perubahan pada kode sisi klien mungkin jauh lebih mudah.
Marjan Venema

1

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."


1

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.


0

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.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.