Artikel Pengenalan Wulin.com (www.vevb.com): Kata refactoring awalnya didefinisikan oleh Martin Fowler dan Kent Beck. Ini adalah modifikasi yang membuat struktur internal perangkat lunak lebih mudah dipahami dan membuat perangkat lunak lebih mudah diubah tanpa mengubah perilaku perangkat lunak yang terlihat ... Ini adalah cara yang terkendali untuk mengatur kode dan meminimalkan kemungkinan pembuatan bug.
Kadang -kadang, programmer mendatangi saya dan mengatakan bahwa mereka tidak menyukai desain sesuatu, dan kita perlu memberikannya rekonstruksi yang komprehensif untuk memperbaiki kesalahan di dalamnya. oh oh. Ini tidak terdengar seperti ide yang bagus. Dan ini tidak terdengar seperti refactoring ...Kata refactoring awalnya ditentukan oleh Martin Fowler dan Kent Beck. Ini adalah modifikasi yang membuat struktur internal perangkat lunak lebih mudah dipahami dan membuat perangkat lunak lebih mudah diubah tanpa mengubah perilaku perangkat lunak yang terlihat ... Ini adalah cara yang terkendali untuk mengatur kode dan meminimalkan kemungkinan pembuatan bug.
Hasil rekonstruksi adalah bahwa metode pintasan dirujuk, duplikat dan kode mati dihapus, membuat desain dan logika lebih jelas. Ini menggunakan bahasa pemrograman lebih baik dan lebih pintar. Ini adalah keuntungan menggunakan informasi yang Anda ketahui sekarang, tetapi pengembang pada waktu itu tidak tahu - atau tidak menggunakannya. Terus menyederhanakan kode untuk membuatnya lebih mudah dipahami. Terus membuat perubahan masa depan mereka lebih mudah dan lebih aman.
Selama proses ini, bug ditemukan dan bug dimodifikasi, yang bukan rekonstruksi. Optimalisasi bukanlah rekonstruksi. Memperkuat pengecualian menangkap dan menambahkan kode pencegahan tidak refactoring. Membuat kode lebih mudah diuji bukan refactoring - meskipun refactoring dapat mencapai efek yang sama. Semua hal ini bermanfaat. Tapi tidak satu pun dari ini yang refactoring.
Pemrogram, terutama mereka yang melakukan pekerjaan pemeliharaan, membersihkan kode adalah salah satu tugas harian mereka. Ini adalah pekerjaan dasar dan harus dilakukan. Kontribusi Martin Fowler et al. adalah untuk memformat metode praktik terbaik dari kode refactoring dan untuk mengarsipkan pola refactoring yang umum dan terbukti efektif - tujuan refactoring dan langkah -langkah refactoring - untuk klasifikasi arsip.
Refactoring sederhana. Menulis tes sebelum menulis kode sebanyak mungkin dapat mencegah Anda melakukan kesalahan. Penyesuaian struktural skala kecil, independen dan aman untuk kode, dan mengujinya setelah setiap penyesuaian untuk memastikan bahwa Anda tidak mengubah karakteristik perilaku kode - fungsinya sama seperti sebelumnya, tetapi kode terlihat berbeda. Mode refactoring dan alat refactoring IDE modern membuat refactoring mudah, aman dan murah.
Jangan refactor demi refactoring
Refactoring dapat dianggap sebagai ukuran yang dapat membantu perubahan kode Anda. Refactoring kode harus dilakukan sebelum Anda membuat perubahan kode, yang akan memungkinkan Anda memastikan bahwa Anda memahami kode dan membuatnya lebih mudah dan lebih aman untuk memasukkan perubahan ke dalam kode. Lakukan tes regresi pada tindakan refactoring Anda. Kemudian buat koreksi atau perubahan. Uji lagi. Kemudian, lebih banyak kode dapat direfaktor untuk membuat niat mengubah kode Anda lebih jelas. Lengkapi tes lagi. Merekonstruksi dan berubah lagi. Atau berubah, dan kemudian refactor.
Anda tidak refactoring demi refactoring, Anda refactoring karena Anda ingin melakukan hal -hal lain, dan refactoring dapat membantu Anda menyelesaikan hal -hal ini.
Ruang lingkup refactoring harus ditentukan oleh perubahan kode atau koreksi kode yang perlu Anda terapkan - apa yang harus Anda lakukan untuk membuat perubahan kode lebih aman dan lebih ringkas? Dengan kata lain: Jangan refactor demi refactoring. Jangan refactor kode yang tidak ingin Anda ubah atau tidak akan berubah.
Goresan refactoring untuk pemahaman (goresan refactoring)
Buku Michael Feather "Bekerja Secara Efektif dengan Kode Legacy" menyebutkan konsep refactoring awal; Martin Fowler menyebutnya refactoring untuk pemahaman. Ini digunakan untuk menangani (atau tidak dapat bertahan) kode yang tidak Anda mengerti, bersihkan sehingga Anda dapat memiliki pemahaman yang lebih baik tentang apa yang mereka lakukan sebelum Anda benar -benar memodifikasinya, dan itu juga akan membantu Anda men -debug kode -kode ini. Setelah Anda dapat memahami niat sebenarnya dari variabel atau metode, mengganti nama mereka, beri mereka nama yang lebih tepat, hapus kode yang tidak Anda sukai untuk dibaca (atau menemukan tidak berguna), membongkar pernyataan bersyarat yang kompleks, dan memecah program panjang menjadi beberapa program mini yang mudah dipahami.
Jangan khawatir tentang meninjau atau menguji perubahan ini. Ini untuk membuat kemajuan rekonstruksi Anda dengan cepat - ini memungkinkan kode -kode ini dan bagaimana mereka berlari untuk menghasilkan prototipe yang cepat namun tidak lengkap di otak Anda. Belajar darinya dan membuangnya. Rekonstruksi singkat juga dapat memungkinkan Anda untuk mencoba berbagai metode rekonstruksi dan mempelajari lebih banyak teknik rekonstruksi. Michael Feathers menyarankan agar Anda memperhatikan hal -hal yang tampaknya tidak berguna atau sangat berguna dalam prosesnya, sehingga Anda dapat melakukan hal -hal dengan benar setelah Anda menyelesaikan latihan ini dan benar -benar memodifikasinya - buat sedikit demi sedikit saat memodifikasi, perhatikan metode, dan memodifikasi dan menguji.
Apa itu rekonstruksi skala besar?
Rekonstruksi kode yang sederhana namun jelas: menghilangkan duplikasi, memodifikasi dan mengubah variabel dan nama metode untuk membuatnya lebih bermakna, memperbaiki metode untuk membuat kode lebih mudah dipahami dan digunakan kembali, menyederhanakan logika bersyarat, mengganti angka yang tidak berarti dengan variabel bernama, dan menyatukan kode yang sama. Melalui refactorings ini, Anda bisa mendapatkan hadiah besar dalam hal kelengkapan kode dan pemeliharaan.
Dibandingkan dengan rekonstruksi in -line yang lebih kecil ini, rekonstruksi desain yang lebih signifikan secara signifikan berbeda dari mereka - inilah yang disebut Martin Fowler sebagai rekonstruksi besar. Perubahan besar dan mahal datang dengan banyak risiko teknis. Ini bukan kode pembersihan dan peningkatan desain dalam proses pemrograman Anda: ini adalah desain ulang mendasar.
Beberapa orang suka menyebut desain ulang atau menulis ulang atau membangun kembali sistem atau mengerjakan ulang sistem yang disebut rekonstruksi skala besar. Karena secara teknis, ini tidak mengubah karakteristik fungsional perangkat lunak - logika bisnis, input dan output perangkat lunak masih sama seperti sebelumnya, tetapi implementasi desain dan kode telah berubah. Perbedaan antara TI dan rekonstruksi konvensional tampaknya: satu adalah untuk menulis ulang sepotong kode, dan yang lainnya adalah menulis ulang sistem. Selama Anda melakukannya langkah demi langkah, Anda dapat menyebutnya rekonstruksi - apakah Anda terjebak dalam mengganti sistem lama dengan kode baru selama bertahun -tahun atau transformasi skala besar dari arsitektur sistem.
Refaktor skala besar akan sangat buruk. Mungkin butuh berminggu -minggu, berbulan -bulan (atau bahkan bertahun -tahun) untuk diselesaikan, dan Anda perlu membuat perubahan pada banyak bagian perangkat lunak. Perangkat lunak tidak akan berjalan sebagai hasilnya, dan perubahan ini perlu dirilis dalam beberapa kali. Anda perlu melakukan perancah dan solusi sementara - terutama ketika Anda menggunakan metode pengembangan siklus pendek. Pada saat ini, metode praktis seperti cabang dengan abstrak berguna, yang dapat membantu Anda mengelola perubahan dalam kode Anda dalam jangka waktu yang lama.
Dan saat mengembangkan kode baru, Anda juga harus mempertahankan kode lama, yang membuat kontrol kode kontrol sangat merepotkan dan tidak nyaman untuk berubah, membuat kode sangat rapuh dan mudah membuat kesalahan - ini bertentangan dengan tujuan rekonstruksi yang dimaksudkan. Kadang -kadang situasi ini berlanjut - proses ini bergantian kode baru dan lama ini tidak akan pernah bisa diselesaikan karena manfaat terbaik dilakukan terlebih dahulu, atau karena konsultan yang awalnya membawa ide telah melakukan sesuatu yang lain, atau anggaran telah berkurang, dan Anda benci mempertahankan proyek penundaan seperti itu.
Ini refactoring-yang tidak
Adalah salah untuk menggabungkan konsep rekonstruksi dalam pengembangan proyek tugas berat tersebut. Mereka pada dasarnya adalah jenis pekerjaan lain, dengan biaya dan risiko pengembangan yang sama sekali berbeda. Ini membingungkan pemahaman orang tentang apa itu rekonstruksi dan apa yang dapat dilakukan rekonstruksi.
Refactoring dapat dan harus diintegrasikan ke dalam proses penulisan Anda atau memelihara kode Anda - sebagai bagian integral dari pengembangan harian/manajemen kualitas, seperti halnya tes penulisan dan ulasan kode. Refactoring harus diselesaikan dengan tenang, terus menerus dan meremehkan. Ini mengharuskan kita untuk membagi energi kerja kita ke dalamnya, dan perlu memperhitungkan keberadaannya dalam penilaian periode konstruksi dan penilaian risiko. Jika dilakukan dengan benar, Anda tidak perlu menjelaskan atau memverifikasi bagian pekerjaan ini kepada orang luar.
Mengambil beberapa menit atau satu atau dua jam ke refactor seperti modifikasi dalam proses pengembangan Anda dan merupakan bagian dari pekerjaan. Jika Anda membutuhkan waktu berhari -hari, atau lebih lama, itu bukan refactoring; Ini penulisan ulang, atau desain ulang. Jika Anda perlu menyisihkan sebagian waktu secara eksplisit (atau seluruh siklus sprint) untuk refactor kode, jika Anda perlu mengajukan permohonan persetujuan untuk membersihkan kode, atau menggunakan membersihkan kode sebagai persyaratan pengembangan, maka Anda tidak refactoring - bahkan jika Anda menggunakan teknik dan alat refactoring, Anda masih melakukan pekerjaan lain.
Beberapa programmer percaya bahwa itu adalah hak dan kewajiban mereka untuk membuat modifikasi mendasar dan signifikan terhadap kode, dan mereka akan mendesain ulang dan menulis ulang mereka atas nama refactoring, sehingga mereka tidak akan mengecewakan keterampilan mereka di masa depan. Mendesain ulang dan penulisan ulang terkadang adalah hal yang benar untuk dilakukan. Tapi karena kejujuran dan kejelasan, tolong jangan berikan kegiatan ini nama rekonstruksi.