Apa poin utama Bekerja Efektif dengan Kode Warisan? [Tutup]


133

Saya telah melihat buku Bekerja Efektif dengan Legacy Code yang direkomendasikan beberapa kali. Apa poin utama dari buku ini?

Apakah ada lebih banyak berurusan dengan kode warisan daripada menambahkan tes unit / integrasi dan kemudian refactoring?



2
Tentu saja intinya adalah menambahkan tes dan kemudian refactor. Buku ini sebagian besar tentang bagaimana Anda mengelola untuk mendapatkan kode berbelit-belit yang sedang diuji, dan ada banyak pembuka mata tentang hal itu. Anggap saja Feathers tidak mengambil tahanan!
Kilian Foth

9
Mungkin Anda sebaiknya membaca buku itu
HLGEM

Jawaban:


157

Masalah utama dengan kode lawas adalah tidak memiliki tes. Jadi, Anda perlu menambahkan beberapa (dan kemudian lagi ...).

Ini dengan sendirinya akan membutuhkan banyak pekerjaan, seperti dicatat @mattnz. Tetapi masalah khusus kode warisan adalah bahwa kode itu tidak pernah dirancang untuk dapat diuji . Jadi biasanya itu adalah kode spaghetti berbelit-belit, di mana sangat sulit atau benar-benar mustahil untuk mengisolasi bagian-bagian kecil untuk diuji unit. Jadi sebelum pengujian unit, Anda perlu memperbaiki kode untuk membuatnya lebih dapat diuji.

Namun, untuk melakukan refactor dengan aman, Anda harus memiliki unit test untuk memverifikasi bahwa Anda belum merusak apa pun dengan perubahan Anda ... Ini adalah tangkapan 22 kode lama.

Buku ini mengajarkan Anda cara keluar dari tangkapan ini dengan membuat perubahan minimal yang paling aman untuk kode hanya untuk mengaktifkan unit test pertama. Ini tidak dimaksudkan untuk membuat desain lebih bagus - hanya untuk mengaktifkan tes unit. Bahkan, kadang-kadang mereka membuat desain lebih jelek atau lebih kompleks. Namun, mereka memungkinkan Anda untuk menulis tes - dan begitu Anda memiliki unit test, Anda bebas untuk membuat desain lebih baik.

Ada banyak trik untuk membuat kode dapat diuji - ada yang agak jelas, ada yang tidak sama sekali. Ada metode yang tidak akan pernah saya pikirkan tentang diri saya, tanpa membaca buku. Tetapi yang lebih penting adalah Feathers menjelaskan apa yang membuat unit kode dapat diuji. Anda perlu memotong dependensi dan memperkenalkan hambatan ke dalam kode Anda, tetapi karena dua alasan berbeda:

  • sensing - untuk memeriksa dan memverifikasi efek dari mengeksekusi sepotong kode, dan
  • pemisahan - untuk mendapatkan bagian tertentu dari kode ke dalam harness uji pertama-tama.

Memotong ketergantungan dengan aman bisa jadi rumit. Memperkenalkan antarmuka, mengolok-olok dan Injeksi Ketergantungan bersih dan bagus sebagai tujuan, hanya belum tentu aman untuk dilakukan pada saat ini. Jadi kadang-kadang kita harus menggunakan subkelas kelas yang sedang diuji untuk mengganti beberapa metode yang biasanya misalnya memulai permintaan langsung ke DB. Di lain waktu, kita bahkan mungkin perlu mengganti kelas ketergantungan / guci dengan yang palsu di lingkungan pengujian ...

Bagi saya, konsep paling penting yang dibawa oleh Feathers adalah jahitan . Jahitan adalah tempat di kode di mana Anda dapat mengubah perilaku program Anda tanpa mengubah kode itu sendiri . Membangun jahitan ke dalam kode Anda memungkinkan memisahkan potongan kode yang sedang diuji, tetapi juga memungkinkan Anda untuk merasakan perilaku kode yang sedang diuji bahkan ketika itu sulit atau tidak mungkin dilakukan secara langsung (misalnya karena panggilan membuat perubahan pada objek atau subsistem lain , yang kondisinya tidak memungkinkan untuk meminta langsung dari dalam metode pengujian).

Pengetahuan ini memungkinkan Anda untuk melihat benih-benih testabilitas dalam tumpukan kode paling jahat, dan menemukan perubahan minimal, paling tidak mengganggu, dan teraman untuk sampai ke sana. Dengan kata lain, untuk menghindari membuat refactor "jelas" yang berisiko melanggar kode tanpa Anda sadari - karena Anda belum memiliki unit test untuk mendeteksinya.


5
Catatan ketika jawaban di atas mengatakan "unit test" itu sebenarnya berarti "tes otomatis" . Untuk aplikasi lawas, sebagian besar dari tes otomatis yang awalnya berguna sebenarnya akan menjadi tes integrasi (di mana logika pengujian mengeksekusi lempengan yang lebih besar dari keseluruhan kode dan dapat menghasilkan kegagalan karena cacat di banyak tempat yang berbeda), daripada unit yang benar tes (yang bertujuan untuk menganalisis hanya satu modul dan mengeksekusi masing-masing bagian kode yang jauh lebih kecil).
Lutz Prechelt

99

Cara cepat untuk mendapatkan poin utama Bekerja Secara Efektif dengan Legacy Code


3
Tautan MP3 pada halaman Hanselminutes rusak, tetapi tautan pada hanselminutes.com/165/… tidak - s3.amazonaws.com/hanselminutes/hanselminutes_0165.mp3 .
Peter Mortensen

Terima kasih rosston untuk memperbaiki tautan PDF. Sepertinya objectmentor.com sudah pergi - mungkin "Paman Bob" gulung tikar?
MarkJ

Saya tidak yakin apa yang terjadi pada mentor objek, tetapi hari ini Paman Bob bekerja untuk Cahaya ke-7.
Jules

40

Saya bekerja pada basis kode jutaan baris kode, beberapa berasal dari tahun 1980-an. Ini hanya perangkat lunak, jadi hanya masalah menulis beberapa tes unit, sehingga Anda dapat pergi dan hanya refactor, dan membuatnya jauh lebih baik.

Kata kuncinya di sini hanya - itu adalah kata empat huruf yang tidak termasuk dalam kosakata programmer mana pun, apalagi yang bekerja pada sistem warisan.

Menurut Anda, berapa lama waktu yang dibutuhkan untuk menulis unit test, untuk menguji upaya pengembangan satu jam? Demi diskusi, katakanlah satu jam lagi.

Berapa banyak waktu yang diinvestasikan dalam sistem warisan yang berumur 20 tahun itu? Katakanlah, 20 pengembang selama 20 tahun kali 2000 jam / tahun (mereka bekerja sangat keras). Sekarang mari kita pilih angka - Anda memiliki komputer baru dan alat-alat baru, dan Anda jauh lebih pintar daripada orang-orang yang menulis potongan $% ^^ ini - katakanlah Anda bernilai 10 dari mereka. Sudah 40 tahun masa kerja Anda, ya ...?

Jadi jawaban untuk pertanyaan Anda adalah ada jauh lebih banyak. Misalnya, rutinitas yang 1000 baris (saya punya beberapa yang lebih dari 5000), itu terlalu kompleks dan merupakan sepotong spageti. Hanya (empat kata lagi) akan membutuhkan beberapa hari untuk memasukkannya kembali menjadi beberapa rutinitas 100 baris dan beberapa pembantu 20 baris lagi, bukan? SALAH. Tersembunyi di 1000 baris itu adalah 100 perbaikan bug, masing-masing merupakan persyaratan pengguna yang tidak didokumentasikan atau casing tepi yang tidak jelas. Ini 1000 baris karena rutin 100-line asli tidak melakukan pekerjaan.

Anda perlu bekerja dengan mind set " jika tidak rusak, jangan memperbaikinya ". Ketika rusak, Anda harus sangat berhati-hati ketika memperbaikinya - karena Anda membuatnya lebih baik, bahwa Anda tidak sengaja mengubah sesuatu yang lain. Perhatikan bahwa "rusak" mungkin termasuk kode yang tidak dapat dipelihara, tetapi berfungsi dengan benar, itu tergantung pada sistem dan penggunaannya. Tanyakan "apa yang terjadi jika saya mengacaukannya dan memperburuknya", karena suatu hari Anda akan melakukannya, dan Anda harus memberi tahu bos bos mengapa Anda memilih untuk melakukan itu.

Sistem ini selalu dapat dibuat lebih baik. Anda akan memiliki anggaran untuk bekerja, timeline, apa pun. Jika Anda tidak - pergi dan buat satu. Berhentilah menjadikannya lebih baik ketika uang / waktu telah habis. Tambahkan fitur, beri diri Anda waktu untuk membuatnya sedikit lebih baik. Perbaiki bug - lagi, habiskan sedikit waktu ekstra dan buat lebih baik. Jangan pernah mengirimkannya lebih buruk daripada saat Anda mulai.


2
terima kasih untuk tipsnya! Apakah ini milik Anda atau dari buku?
Armand

3
Mungkin sedikit dari keduanya - saya membaca buku setelah beberapa tahun melakukan pekerjaan ini, dan mungkin harus membacanya lagi. Seperti buku apa pun yang bagus, buku ini akan membuat Anda menantang sebagian dari apa yang Anda lakukan saat ini, menegakkan kembali sebagian besar dari apa yang Anda lakukan, tetapi tidak memiliki semua jawaban untuk serangkaian masalah spesifik Anda.
mattnz

7
"Ini 1000 baris karena 100line rutin asli tidak melakukan pekerjaan." Jadi, sangat jarang hal ini benar-benar terjadi. Lebih sering daripada tidak 1000 baris hanya karena pengembang asli menyingsingkan lengan bajunya dan mulai coding sebelum menghemat waktu untuk perencanaan atau desain.
Stephen Touset

3
Tidak. Saya mengatakan bahwa dalam sebagian besar kasus (secara pribadi saya temui), 1.000 rutinitas baris adalah indikasi yang jelas bahwa orang mulai menulis kode sebelum berpikir tentang cara menulis abstraksi yang tepat. Ribuan rutinitas garis menurut definisi terlalu rumit - apakah Anda mengatakan bahwa rutinitas seribu baris dengan ratusan perbaikan bug yang tersembunyi dan tidak diomentari adalah ciri khas pengembang yang bertanggung jawab?
Stephen Touset

16
Jika Anda percaya setiap posting di situs ini, semua orang harus berurusan dengan kode spageti 1000 baris, namun tidak ada yang pernah menulisnya. Dalam pengalaman saya, 1000 (dan 10000) garis rutin adalah tanda aula pengembang yang melakukan yang terbaik yang mereka bisa dengan apa yang mereka miliki, untuk memberikan apa yang diminta dari mereka oleh bos yang membayar upah mereka. Saya menemukan itu menghina dan sombong cara banyak pengembang merasa bebas untuk berkomentar dari sela-sela tanpa mengetahui situasinya, sementara tidak pernah harus mengekspos ada pekerjaan sendiri kepada masyarakat untuk kritik.
mattnz

19

Ada dua poin utama yang bisa diambil dari buku ini.

  1. Kode lama adalah kode apa pun yang tidak memiliki jangkauan pengujian.
  2. Setiap kali Anda harus mengubah kode lawas, Anda harus memastikan kode itu memiliki jangkauan.

Seperti yang ditunjukkan oleh responden lain, mencoba memperbarui secara pre-emptive kode lama Anda adalah tugas orang bodoh . Alih-alih, setiap kali Anda harus membuat perubahan ke kode lawas (untuk fitur baru atau perbaikan bug), luangkan waktu untuk menghapus status lawasnya.


6
+1 Poin luar biasa: "Setiap kali Anda harus membuat perubahan ke kode lawas, luangkan waktu untuk menghapus status lawasnya."
John

3
Menghapus status Legacy, dapatkan suara saya :)
Rachel

7

Dalam shell nut itu benar - menambahkan tes dan refactoring adalah semua tentang itu.

Tetapi buku ini memberi Anda banyak teknik berbeda untuk melakukannya dengan kode yang sangat sulit untuk diuji dan diperbaiki dengan aman.

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.