Refactoring: Bukankah itu hanya kata mewah untuk membersihkan kode Anda? [Tutup]


21

Sebelum buku Martin Fowler "Refactoring: Meningkatkan Desain Kode yang Ada" keluar, kami biasa memanggil perubahan besar untuk kode "rearchitecture" dan perubahan kecil "cleanup". IMO, teknik refactoring adalah semua akal sehat / hal-hal yang sudah jelas kita lakukan selamanya.

Apakah Anda pikir refactoring adalah sesuatu yang baru? Mungkin hanya cara untuk mengelabui manajemen agar mengalokasikan waktu untuk pembersihan kode?


Ketika Anda mengatakan "sebelum buku itu keluar", saya kira Anda merujuk pada buku Martin Folwer apakah ini benar?
AlexC

-1: Apa kegunaan pertanyaan ini?
Jim G.

Ya buku Fowler.
Chuck Stephanski

Jawaban:


43

Refactoring lebih tua dari bukit, jadi tidak, itu bukan sesuatu yang baru.

Dan refactoring tidak membersihkan. Ya, memang bisa, tetapi tidak terbatas pada pembersihan saja.

Ini menyesuaikan arsitektur aplikasi Anda (baik dalam skala besar atau kecil) sambil menjaga perilaku.

Itu berarti bahwa sementara beberapa bagian dari aplikasi Anda mungkin sudah sangat bersih dan baik-baik saja kemarin, fitur baru hari ini memerlukan penyesuaian bagian itu untuk mengakomodasi fitur baru.

Anda tidak ingin merusak fungsionalitas yang ada, jadi Anda menyesuaikan struktur aplikasi Anda sambil menjaga perilaku - yang merupakan refactoring.

Ini mengatakan apa pun perubahan yang dilakukan pada kode, seseorang harus selalu menjalankan tesnya ... untuk berjaga-jaga.


1
Newtopian: itu poin penting. Jika Anda belum menjalankan tes, Anda tidak tahu apakah Anda meretas sesuatu secara acak, atau benar-benar refactored . (Dan tentu saja, Anda memerlukan ruang uji yang memadai!)
Frank Shearar

9

Itu hanya merapikan kode. Pada dasarnya, programmer (terutama Martin Fowler) memperhatikan bahwa mereka cenderung melakukan tugas yang sama setiap kali mereka merapikan kode mereka. Mereka mendefinisikan dan memberi label metode merapikan dan masalah kode terkait dan presto! Refactoring lahir.

Itu sama dengan pola desain - orang-orang memperhatikan bahwa mereka cenderung menggunakan pendekatan yang sama untuk masalah-masalah tertentu berulang kali. Mereka memberi label dan mendefinisikan pendekatan dan sekarang tampaknya Anda bukan programmer yang sebenarnya kecuali Anda hanya menggunakan selusin pola yang sama dalam kode Anda.

Tidak ada keajaiban untuk refactoring; itu hanya seperangkat jargon baru untuk menggambarkan praktik lama.


William Opdyke, 1992: Kerangka Kerja Berorientasi Objek . Fowler & Beck & teman mempopulerkan refactoring. Jon Brant dan Don Roberts menerapkan alat otomatis pertama beberapa waktu sebelum 1999. Jadi "set jargon baru" tidak terlalu akurat.
Frank Shearar

Jika Anda menerima bahwa pemrograman komputer telah berlangsung sejak Ada Lovelace pada pertengahan 1800-an, maka ya - ini adalah kumpulan jargon yang relatif baru.
Semut

1
Saya pikir perbedaannya adalah dengan Pola Desain hampir setiap pengembang mempelajari beberapa pola baru dan karenanya beberapa alat baru perdagangan dari buku ini. Dengan Refactoring saya tidak merasa ada orang yang benar-benar belajar sesuatu. Ada nilai sekunder hanya dengan menempatkan nama pada sesuatu (dan perbandingan pola desain berlaku di sana) tetapi dia bisa melakukannya dengan posting blog.
Chuck Stephanski

Memang, saya menyebutkan bahwa itu adalah jargon baru ... relatif terhadap kalkulus lambda.
Frank Shearar

@Chuck, sudahkah Anda membaca buku, Refactoring? Jika demikian, saya akan sangat terkejut jika Anda tidak belajar sesuatu yang baru darinya.
Marcie

7

Kami melakukan tiga hal terpisah di perusahaan kami, dengan alokasi waktu untuk ketiganya:

  • Refactoring: terdiri dalam mengubah struktur kode, sehingga menjaga perilaku.

Contoh: membelah metode 100 baris yang jelek dan tidak dapat dibaca yang melakukan empat hal menjadi empat metode yang dapat digunakan kembali, masing-masing 25 baris.

  • Pembersihan: terdiri dari melakukan modifikasi kecil untuk membuat kode lebih mudah dibaca tanpa mengubah perilakunya, maupun strukturnya.

Contoh: menghapus kode yang dikomentari setelah memastikan bahwa kode ini tidak diperlukan lagi.

  • Menegakkan aturan StyleCop / FxCop: terdiri dari memeriksa apakah kode cocok dengan set default dari aturan StyleCop atau FxCop, dan jika tidak, modifikasi untuk mencocokkan dengan aturan tersebut.

Contoh: menambahkan Culture.Invariantdalam string.Format(atau budaya lain yang lebih tepat).

Jadi dalam kasus saya, refactoring adalah sesuatu yang sangat berbeda dari pembersihan . Saat melakukan pembersihan, saya tidak perlu menjalankan tes unit lagi: jika kode bekerja sebelumnya, itu akan berfungsi setelah pembersihan. Dengan kata lain, itu bukan karena saya menghapus baris kosong atau menambahkan komentar bahwa kode akan berhenti berfungsi. Di sisi lain, ketika saya refactor bagian rumit dari kode lama, saya bisa melakukan beberapa kesalahan, jadi saya harus menjalankan tes unit setelah refactoring.


4
Meskipun saya setuju bahwa ada perbedaan mendasar antara pembersihan dan anjak piutang, ada banyak kasus di mana garis ini cukup kabur. Menghapus kelas mati dan "membersihkan" semua referensi untuk itu dari tanda tangan metode atau asosiasi yang tersisa akan dianggap pembersihan atau refactoring? Saya juga sangat tidak setuju bahwa menjalankan unit test adalah opsional. Anda tidak tahu bagaimana segala sesuatunya dapat pecah. Saya telah melihat perubahan dalam string pesan dari kode break pengecualian karena seseorang berpikir itu ide yang baik untuk menguraikannya untuk bertindak pada beberapa kesalahan.
Newtopian

Saya harus setuju dengan Newtopian, terutama tentang tidak harus menjalankan kembali tes. Bahkan, harus ada test suite otomatis yang berjalan tidak kurang dari sekali per komit. Terlepas dari apakah itu pembersihan atau refactoring , jika Anda memiliki perubahan kode untuk dikomit ke kontrol versi, tes harus dijalankan.
kojiro

Anda harus selalu melakukan pembangunan penuh setelah melakukan pembersihan apa pun - bahkan jika itu hanya ruang putih dan komentar berubah. Tanyakan penulis Python atau Makefile tentang hal itu.
JBRWilkinson

3

Refactoring menambah pengetahuan ke kode Anda. Jika Anda tahu ada sesuatu yang salah namanya, Anda memberinya nama yang lebih baik. Jika Anda tahu sesuatu dapat dilakukan dengan lebih baik, Anda mengubahnya menjadi sesuatu yang lebih baik.

Banyak langkah - kecil dan besar - yang diharapkan menghasilkan program yang lebih baik.


3

Saya setuju dengan "refactoring adalah kata yang bagus untuk membersihkan kode Anda" tetapi tidak dengan "adil". Orang-orang menggunakan kata-kata mewah karena suatu alasan: kadang-kadang karena mereka ingin terlihat pintar, dan kadang-kadang karena mereka menyampaikan makna yang lebih besar atau lebih tepat, dan refactoring IMHO (bahkan jika kadang-kadang disalahgunakan) umumnya merujuk pada yang terakhir.

"Bersihkan" bisa berarti apa saja dari "memformat ulang sedikit" hingga "menulis ulang potongan besar".

"Refactoring" berarti secara khusus sesuatu seperti "perubahan inkremental kecil pada kode, yang dirancang untuk mempertahankan fungsi yang sama, sambil mengubahnya menjadi desain yang lebih baik". Dan ada kumpulan praktik terbaik tentang hal-hal yang Anda lakukan: beberapa bersifat ad-hoc, tetapi ada prinsip-prinsip umum, seperti menggunakan unit test, mengekstraksi sebagian fungsi ke dalam fungsi atau kelas baru, dll, yang dapat dan harus dipelajari oleh orang-orang. .

Anda mengatakan "hanya menipu manajemen agar mengalokasikan waktu untuk pembersihan kode". Tetapi jika mengatakan "refactoring" dengan benar menyampaikan konsep bahwa investasi yang mantap dalam kejelasan sekarang akan membayar dividen dalam efisiensi di masa depan, maka itu bukan "trik", itu komunikasi yang jelas dan efektif.


2

Refactoring adalah kode karena Normalisasi adalah data relasional. Ini adalah proses abstrak konsep menjadi representasi yang lebih bersih, lebih jelas dan lebih efisien dari peran mereka dalam aplikasi.


1
Itu cara yang menarik untuk melihatnya. Mungkin itu berasal dari latar belakang basis data saya, tetapi ada sesuatu yang mengganggu saya tentang tekanan pada refactoring, dan Anda telah membantu saya meletakkan jari saya di atasnya. Itu dalam database yang tidak Anda perbaiki dalam desain membutuhkan waktu 10x lebih lama untuk diperbaiki dalam pengujian dan mungkin 1000x lebih lama dalam produksi. Jadi DBA yang baik adalah anal tentang memperbaiki segala sesuatunya dalam tahap sedini mungkin. Perasaan saya adalah bahwa terlalu banyak waktu refactoring pada tahap selanjutnya merupakan indikasi terlalu sedikit waktu yang dihabiskan untuk mendesain.
user21007

@ user21007: Kode jauh lebih rumit daripada skema basis data, tetapi jauh lebih mudah untuk diubah dan digunakan.
kevin cline

1

Itu tergantung bagaimana Anda memahami istilah refactoring. Bagi kebanyakan orang ini adalah proses meningkatkan struktur tanpa mengubah perilaku. Jika Anda setuju, maka ya itu dilakukan jauh sebelum buku ini keluar. Saya tahu, karena saya (di antara banyak hal lain) mengubah nama kelas, mengekstraksi kelas dan mengekstraksi metode sebelum buku itu ditulis. Saya tidak menyebutnya refactoring, tetapi pada dasarnya saya melakukan hal yang persis sama.

Bagi saya pribadi refactoring adalah apa yang sekarang orang sebut "refactoring kode otomatis" yaitu: dukungan untuk berbagai teknik refactoring di dalam IDE. Ini adalah peningkatan nyata dari apa yang saya lakukan sebelumnya (yang memang sangat menyakitkan). Saya dapat melakukan perubahan dalam satu kelas dan tidak khawatir bagaimana ini akan mempengaruhi sisa perangkat lunak. Saya pikir Martin memformalkan teknik refactoring hingga titik di mana ia dapat direpresentasikan sebagai algoritma dan dengan demikian diimplementasikan dalam berbagai IDE di luar sana.

Jadi jika Anda memahami refactoring sebagai suatu proses, maka itu bukan hal baru. Jika Anda melihatnya sebagai otomatisasi, maka ya ini adalah peningkatan besar. Cobalah mengganti nama beberapa kelas inti (secara harfiah, bukan melalui opsi refactoring IDE Anda) dalam proyek yang cukup besar untuk mengetahui alasannya :)


0

Refactoring memang kode "pembersihan", tetapi juga merestrukturisasi kode. Dalam tim saya, refactoring biasanya yang terakhir. Ketika kami memiliki kasus "refactor", kami mengalokasikan waktu untuk merestrukturisasi kode kami, misalnya untuk membuatnya selaras dengan arsitektur baru, atau model informasi, atau membuatnya lebih efisien.

Kode "pembersihan" adalah sesuatu yang kita lakukan terus menerus tanpa alokasi waktu khusus untuk itu. Bagi saya "pembersihan" biasanya berganti nama, membersihkan komentar, dll.


1
penggantian nama adalah teknik refactoring standar!
Chuck Stephanski

0

Saya akan mengatakan tidak

Mungkin ada pembersihan dalam proses refactoring tetapi itu bukan esensi.

Pembersihan datang dengan asumsi bahwa kode sebelumnya tidak bersih. Pada kenyataannya, pengembang memperbaiki kode mereka bahkan kode aslinya sudah bersih.

KERING adalah penggerak utama di balik refactoring.

Saat menambahkan kode baru ke basis kode yang ada, refactoring dilakukan secara alami karena prinsip KERING.

Hanya 0,02 saya


0

Membersihkan kode Anda seperti merapikan rumah Anda, refactoring seperti merobohkan dinding dan mungkin meletakkannya di tempat lain


0

Ketika orang lain membersihkan rumah Anda, Anda tidak dapat menemukan apa pun karena tujuannya adalah membereskan segala sesuatunya. Refactoring akan membangun dan memberi label kamar, lemari, lemari, rak, tempat sampah, dll. Itu masih menyimpan sebagian besar barang yang sama (Anda masih bisa membuat sandwich keju panggang di dapur dan memakannya di ruang tamu), tetapi harus membuatnya lebih mudah untuk menemukan dan mungkin memiliki tempat yang efisien untuk meletakkan hal-hal baru.


Saya bukan fanatik kata kunci, tetapi terkadang tugas umum perlu diberi label dan diformalkan sehingga semua orang tahu apa yang Anda bicarakan. Seorang klien melaporkan bug dan manajer berteriak, "Bersihkan kode Anda!" Anda tahu mereka tidak berbicara tentang refactoring.
JeffO

0

Istilah 'refactoring' secara elegan dipinjam dari aljabar. Ini berarti menyederhanakan ketentuan untuk menghasilkan hasil yang sama. Tidak hanya elegan, itu revolusioner - itu memerlukan pendekatan yang sulit hingga kode Anda, pada tingkat yang mengejutkan banyak orang. Dan istilah itu sendiri sangat penting dan bermanfaat.


-1

Tidak. Refactoring memperbaiki struktur tanpa mengubah perilaku. Refactoring dalam arti ketat memerlukan disiplin tes yang baik. Itu belum tentu diperlukan ketika Anda "membersihkan".


2
sikap berbahaya. Menghapus seluruh petak kode mati dan konfigurasi mati membersihkan dan mengubah tanda tangan metode tunggal menjadi refactor. Namun dalam kedua kasus saya ingin mendapatkan tes disiplin yang baik untuk memastikan bahwa saya tidak melanggar apa pun.
Newtopian

Saya tidak mengatakan bahwa itu baik / aman / diinginkan untuk membuat perubahan besar tanpa uji disiplin. Saya mengatakan bahwa refactoring sebagai metodologi melibatkan uji disiplin, sedangkan "membersihkan segalanya" bukanlah metodologi sama sekali.
Willie Wheeler

Jadi jika saya mengerti dengan benar jika itu tidak memiliki nama mewah yang tepat maka kami baik untuk pergi !! : -O hanya bercanda, saya melihat apa yang Anda coba katakan, benar bahwa membersihkan sesuatu hampir tidak bisa disebut metodologi tetapi sekali lagi tidak ada yang refactoring. Itu hanya kata mewah yang menyatakan Anda mengubah kode tanpa mengubah perilaku itu. Dengan sendirinya, tidak memiliki implikasi pada pengujian apa pun. Mengikuti praktik pengkodean yang baik akan menyatakan bahwa jika kode diubah maka harus diuji terlepas dari bagaimana Anda memanggil tindakan yang menghasilkan perubahan.
Newtopian

1
Tentu, saya bisa membelinya. Disiplin uji lebih tentang bagaimana seseorang melakukan refactoring, tetapi itu tidak melekat dalam definisi. (Yaitu saya bisa merefleksikan kode tanpa tes sama sekali.) Saya tidak tahu apakah saya bisa setuju bahwa refactoring bukan metodologi - ada banyak buku yang ditulis dengan pola langkah-demi-langkah dan sebagainya.
Willie Wheeler

-1

Keduanya tumpang tindih sedikit di tepi, tetapi bagi saya itu perbedaan antara membersihkan rumah dan renovasi rumah. Pembersihan, bagi saya, tidak menyiratkan perubahan struktural, sedangkan refactoring tidak.


-2

"Refactoring" benar-benar sama dengan "rearchitecture", tetapi dengan konotasi yang lebih kuat "tidak ada perubahan fungsi". Ini juga lebih jelas dalam hal tujuan arsitektur ulang, yang sering kali "faktor keluar" kode umum menjadi potongan yang dapat digunakan kembali.

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.