Pengembang Hebat Tahu Kapan dan Bagaimana Cara Memfaktorkan Refactor Rails Code

Refactor pada skala besar : Mengapa Anda melakukan hal seperti itu?

Jika tidak rusak, jangan perbaiki.

Ini adalah ungkapan yang terkenal, tetapi seperti yang kita ketahui, sebagian besar kemajuan teknologi manusia dibuat oleh orang-orang yang memutuskan untuk memperbaiki apa yang tidak rusak. Khususnya di industri perangkat lunak, orang dapat berargumen bahwa sebagian besar yang kami lakukan adalah memperbaiki apa yang tidak rusak.

Memperbaiki fungsionalitas, meningkatkan UI, meningkatkan kecepatan dan efisiensi memori, menambahkan fitur: ini semua adalah aktivitas yang mudah untuk dilihat apakah aktivitas tersebut layak dilakukan, dan kemudian kami sebagai pengembang Rails yang berpengalaman berdebat untuk atau menentang menghabiskan waktu kami untuk itu. Namun, ada aktivitas, yang sebagian besar termasuk dalam refactoring standar area abu-abu, dan terutama refactoring kode skala besar.

Istilah refactoring skala besar perlu dijelaskan. Persisnya apa yang dapat dianggap "skala besar" akan bervariasi dari kasus ke kasus karena istilahnya agak kabur, tetapi saya menganggap apa pun yang secara signifikan memengaruhi lebih dari hanya beberapa kelas, atau lebih dari satu subsistem, dan antarmukanya menjadi "besar .” Di sisi lain, setiap refactoring Rails yang tetap tersembunyi di balik antarmuka satu kelas pasti akan "kecil." Tentu saja, ada banyak area abu-abu di antaranya. Akhirnya, percayalah pada naluri Anda, jika Anda takut melakukannya, maka itu mungkin "besar".

Refactoring, menurut definisi, tidak menghasilkan fungsionalitas yang terlihat, tidak ada yang dapat Anda tunjukkan kepada klien, tidak ada kiriman. Paling-paling mereka mungkin menghasilkan peningkatan kecepatan dan penggunaan memori yang kecil, tetapi itu bukan tujuan utama. Orang mungkin mengatakan bahwa tujuan utamanya adalah kode yang Anda sukai. Tetapi karena Anda mengatur ulang kode sedemikian rupa sehingga memiliki konsekuensi yang luas di seluruh basis kode, ada kemungkinan bahwa semua neraka akan pecah dan akan ada masalah. Tentu saja dari situlah ketakutan yang kami sebutkan berasal. Pernahkah Anda memperkenalkan seseorang yang baru ke basis kode Anda dan setelah mereka bertanya tentang sepotong kode yang diatur secara khusus, Anda menjawab dengan sesuatu seperti:

Yeeeaahh, ini adalah kode lama yang masuk akal pada saat itu tetapi spesifikasinya berubah dan sekarang terlalu mahal untuk memperbaikinya?

Mungkin Anda bahkan memberi mereka pandangan yang sangat serius dan menyuruh mereka untuk membiarkannya dan tidak menyentuhnya.

Pertanyaan, "Mengapa kita bahkan ingin melakukannya?" adalah yang alami dan mungkin sama pentingnya dengan proses refactoring karena cukup sering ada orang lain yang harus Anda yakinkan untuk mengizinkan Anda menghabiskan waktu mahal untuk refactoring. Jadi mari kita pertimbangkan kasus-kasus ketika Anda ingin melakukannya dan manfaat yang akan diperoleh:

Peningkatan kinerja

Anda senang dengan pengorganisasian kode Anda saat ini dari titik perawatan tetapi masih menyebabkan masalah dengan kinerja. Terlalu sulit untuk mengoptimalkan cara pengaturannya saat ini dan perubahannya akan sangat rapuh.

Hanya ada satu hal yang harus dilakukan di sini dan itu adalah profilnya secara ekstensif. Jalankan tolok ukur dan buat perkiraan tentang berapa banyak yang akan Anda peroleh dan kemudian coba perkirakan bagaimana hal itu akan diterjemahkan menjadi keuntungan nyata. Kadang-kadang Anda bahkan mungkin menyadari bahwa refactoring kode yang diusulkan tidak sepadan. Di lain waktu Anda akan memiliki data keras yang dingin untuk mendukung kasus Anda.

Perbaikan arsitektur

Mungkin arsitekturnya baik-baik saja tetapi agak ketinggalan zaman, atau mungkin sangat buruk sehingga Anda merasa ngeri setiap kali Anda menyentuh bagian basis kode itu. Ini berfungsi dengan baik dan cepat tetapi sulit untuk menambahkan fitur baru. Dalam rasa sakit itu terdapat nilai bisnis refactoring. "Sakit" juga berarti proses refactoring akan memakan waktu lebih lama untuk menambahkan fitur baru, mungkin lebih lama.

Dan ada keuntungan yang bisa didapat. Buat perkiraan biaya/manfaat untuk beberapa fitur sampel dengan dan tanpa refactoring besar yang Anda usulkan. Jelaskan bahwa perbedaan serupa akan berlaku untuk sebagian besar fitur mendatang yang menyentuh bagian sistem itu sekarang dan selamanya di masa depan saat sistem sedang dikembangkan. Perkiraan Anda mungkin salah karena sering kali dalam pengembangan perangkat lunak tetapi rasio mereka mungkin akan berada di rata-rata.

Membawanya up to date

Terkadang kode awalnya ditulis dengan baik. Anda sangat senang dengan itu. Ini cepat, hemat memori, dapat dipelihara, dan selaras dengan spesifikasi. Mulanya. Tapi kemudian spesifikasi berubah, tujuan bisnis bergeser atau Anda mempelajari sesuatu yang baru tentang pengguna akhir Anda yang membatalkan asumsi awal Anda. Kode masih berfungsi dengan baik, dan Anda masih cukup senang tentang itu, tetapi ada sesuatu yang canggung ketika Anda melihatnya dalam konteks produk akhir. Hal-hal ditempatkan pada subsistem yang sedikit salah atau properti berada di kelas yang salah, atau mungkin beberapa nama tidak masuk akal lagi. Mereka sekarang memenuhi peran yang dalam istilah bisnis diberi nama yang sama sekali berbeda. Namun, masih sangat sulit untuk membenarkan segala jenis refactoring Rails skala besar karena pekerjaan yang terlibat akan berskala dengan contoh lain, tetapi manfaatnya jauh lebih tidak nyata. Kalau dipikir-pikir, merawatnya pun tidak terlalu sulit. Anda hanya perlu ingat bahwa beberapa hal sebenarnya adalah sesuatu yang lain. Anda hanya perlu ingat bahwa A sebenarnya berarti B dan properti Y pada A sebenarnya berhubungan dengan C.

Dan disinilah letak manfaat yang sebenarnya. Di bidang neuro-psikologi ada banyak eksperimen yang menunjukkan bahwa memori jangka pendek atau memori kerja kita hanya mampu menampung 7+/-2 elemen, salah satunya adalah eksperimen Sternberg. Ketika kita mempelajari suatu subjek, kita mulai dengan elemen dasar dan, pada awalnya, ketika kita memikirkan konsep tingkat yang lebih tinggi, kita harus memikirkan definisinya. Misalnya, pertimbangkan istilah sederhana "kata sandi SHA256 asin." Awalnya kita harus menyimpan definisi memori kerja kita untuk "asin" dan "SHA256" dan bahkan mungkin definisi "fungsi hash." Tetapi begitu kita sepenuhnya memahami istilah tersebut, ia hanya menempati satu slot memori karena kita memahaminya secara intuitif. Itulah salah satu alasan mengapa kita perlu sepenuhnya memahami konsep tingkat yang lebih rendah untuk dapat bernalar tentang konsep tingkat yang lebih tinggi. Hal yang sama berlaku untuk istilah dan definisi khusus untuk proyek kami. Tetapi jika kita harus mengingat terjemahan ke arti sebenarnya setiap kali kita membahas kode kita, terjemahan itu menempati salah satu slot memori kerja yang berharga itu. Ini menghasilkan beban kognitif dan membuatnya lebih sulit untuk bernalar melalui logika dalam kode kita. Pada gilirannya, jika lebih sulit untuk bernalar itu berarti ada kemungkinan lebih besar bahwa kita akan mengabaikan poin penting dan memperkenalkan bug.

Dan jangan lupakan efek samping yang lebih jelas. Ada kemungkinan besar terjadi kebingungan saat mendiskusikan perubahan dengan klien kami atau siapa pun yang hanya mengetahui istilah bisnis yang benar. Orang baru yang bergabung dengan tim harus mengenal baik terminologi bisnis maupun rekan-rekannya dalam kode.

Saya pikir alasan ini sangat menarik dan membenarkan biaya refactoring dalam banyak kasus. Namun, hati-hati, mungkin ada banyak kasus tepi di mana Anda harus menggunakan penilaian terbaik Anda untuk menentukan kapan dan bagaimana melakukan refactor.

Pada akhirnya, refactoring skala besar bagus untuk alasan yang sama banyak dari kita menikmati memulai proyek baru. Anda melihat file sumber kosong itu dan dunia baru yang berani mulai berputar-putar di benak Anda. Kali ini Anda akan melakukannya dengan benar, kodenya akan elegan, keduanya akan ditata dengan indah serta cepat dan kuat dan mudah diperluas, dan yang terpenting akan menyenangkan untuk bekerja setiap hari. Refactoring, skala kecil dan besar memungkinkan Anda untuk menangkap kembali perasaan itu, menghembuskan kehidupan baru ke dalam basis kode lama dan membayar utang teknis itu.

Akhirnya, yang terbaik adalah jika refactoring didorong oleh rencana untuk membuatnya lebih mudah untuk mengimplementasikan fitur baru tertentu. Dalam hal ini refactoring akan lebih fokus dan banyak waktu yang dihabiskan untuk refactoring juga akan segera diperoleh kembali melalui implementasi fitur itu sendiri yang lebih cepat.

Persiapan

Pastikan cakupan pengujian Anda sangat baik di semua area basis kode yang mungkin Anda sentuh. Jika Anda melihat bagian-bagian tertentu yang tidak tercakup dengan baik, pertama-tama luangkan waktu untuk meningkatkan cakupan pengujian. Jika Anda tidak memiliki tes sama sekali maka Anda harus terlebih dahulu meluangkan waktu untuk membuat tes tersebut. Jika Anda tidak dapat membuat rangkaian pengujian yang tepat, berkonsentrasilah pada pengujian penerimaan dan tulis sebanyak mungkin, dan pastikan untuk menulis pengujian unit saat Anda melakukan refactor. Secara teoritis Anda dapat melakukan refactoring kode tanpa cakupan pengujian yang baik tetapi Anda harus melakukan banyak pengujian manual dan sering melakukannya. Ini akan memakan waktu lebih lama dan lebih rawan kesalahan. Pada akhirnya, jika cakupan pengujian Anda tidak cukup baik, biaya untuk melakukan refactoring Rails skala besar mungkin sangat tinggi sehingga Anda harus, sayangnya, mempertimbangkan untuk tidak melakukannya sama sekali. Menurut pendapat saya, itu adalah manfaat dari tes otomatis yang tidak cukup sering ditekankan. Tes otomatis memungkinkan Anda untuk sering melakukan refactor dan yang lebih penting, menjadi lebih berani tentang hal itu.

Setelah Anda memastikan cakupan pengujian Anda baik, saatnya untuk mulai memetakan perubahan Anda. Pada awalnya Anda seharusnya tidak melakukan pengkodean apa pun. Anda perlu secara kasar memetakan semua perubahan yang terlibat dan melacak semua konsekuensi melalui basis kode serta memuat pengetahuan tentang semua itu ke dalam pikiran Anda. Tujuan Anda adalah untuk memahami dengan tepat mengapa Anda mengubah sesuatu dan perannya dalam basis kode. Jika Anda tersandung mengubah hal-hal hanya karena mereka tampak perlu diubah atau karena sesuatu yang rusak dan ini tampaknya memperbaikinya, Anda mungkin akan berakhir di jalan buntu. Kode baru tampaknya berfungsi, tetapi salah, dan sekarang Anda bahkan tidak dapat mengingat semua perubahan yang telah Anda buat. Pada titik ini Anda mungkin perlu meninggalkan pekerjaan yang telah Anda lakukan pada refactoring kode skala besar, dan pada dasarnya Anda telah membuang-buang waktu. Jadi luangkan waktu Anda dan jelajahi kode untuk memahami konsekuensi dari setiap perubahan yang akan Anda buat. Ini akan membayar mahal pada akhirnya.

Anda akan membutuhkan bantuan untuk proses refactoring. Anda mungkin lebih suka sesuatu yang lain tapi saya suka selembar kertas kosong dan pena. Saya mulai dengan menulis perubahan awal yang ingin saya buat di kiri atas kertas. Kemudian saya mulai mencari semua tempat yang terpengaruh oleh perubahan dan saya menuliskannya di bawah perubahan awal. Penting di sini untuk menggunakan penilaian Anda. Pada akhirnya, catatan dan diagram di atas kertas ada untuk Anda sendiri, jadi pilihlah gaya yang paling sesuai dengan ingatan Anda. Saya menulis potongan kode pendek dengan tanda titik di bawahnya dan banyak panah yang mengarah ke catatan lain yang menunjukkan hal-hal yang bergantung padanya secara langsung (panah penuh) atau tidak langsung (panah putus-putus). Saya juga membubuhi keterangan panah dengan tanda steno sebagai pengingat untuk beberapa hal tertentu yang saya perhatikan di basis kode. Ingat, Anda hanya akan kembali ke catatan itu selama beberapa hari ke depan saat Anda melakukan perubahan yang direncanakan di dalamnya dan sangat baik untuk menggunakan pengingat yang sangat singkat dan samar sehingga mereka menggunakan lebih sedikit ruang dan lebih mudah untuk ditata di atas kertas . Beberapa kali saya membersihkan meja saya berbulan-bulan setelah refactoring Rails dan saya menemukan salah satu kertas itu. Itu benar-benar omong kosong, saya sama sekali tidak tahu apa arti dari kertas itu, kecuali bahwa itu mungkin ditulis oleh seseorang yang sudah gila. Tetapi saya tahu bahwa selembar kertas sangat diperlukan ketika saya sedang mengerjakan masalah itu. Juga, jangan berpikir Anda perlu menulis setiap perubahan. Anda dapat mengelompokkannya dan melacak detailnya dengan cara yang berbeda. Misalnya pada makalah utama Anda, Anda dapat mencatat bahwa Anda perlu "mengganti nama semua kemunculan Ab ke Cd" dan kemudian Anda dapat melacak secara spesifik dalam beberapa cara berbeda. Anda dapat menulis semuanya pada selembar kertas terpisah, Anda dapat merencanakan untuk melakukan pencarian global untuk semua kemunculannya sekali lagi, atau Anda dapat membiarkan semua file sumber di mana perubahan perlu dibuat terbuka di editor pilihan Anda dan buat catatan mental untuk membacanya kembali setelah Anda selesai memetakan perubahannya.

Ketika Anda memetakan konsekuensi dari perubahan awal Anda, karena sifatnya yang berskala besar, kemungkinan besar Anda akan mengidentifikasi perubahan tambahan yang memiliki konsekuensi lebih lanjut itu sendiri. Ulangi analisis untuk mereka juga, catat semua perubahan yang bergantung. Bergantung pada ukuran perubahan, Anda dapat menuliskannya di selembar kertas yang sama atau memilih kertas kosong yang baru. Hal yang sangat penting untuk dicoba dan dilakukan saat memetakan perubahan adalah mencoba dan mengidentifikasi batasan di mana Anda benar-benar dapat menghentikan perubahan percabangan. Anda ingin membatasi refactoring ke set perubahan terkecil yang masuk akal, bulat,. Jika Anda melihat titik di mana Anda bisa berhenti dan membiarkan sisanya apa adanya, lakukan itu meskipun Anda melihatnya harus difaktorkan ulang, meskipun konsepnya terkait dengan perubahan Anda yang lain. Selesaikan putaran pemfaktoran ulang kode ini, uji secara menyeluruh, terapkan, dan kembali lagi untuk mendapatkan lebih banyak lagi. Anda harus secara aktif mencari poin-poin itu agar ukuran perubahan dapat dikelola. Tentu saja, seperti biasa, lakukan penilaian. Cukup sering saya sampai pada titik di mana saya bisa memotong proses refactoring dengan menambahkan beberapa kelas proxy untuk melakukan sedikit terjemahan antarmuka. Saya bahkan mulai menerapkannya ketika saya menyadari bahwa mereka akan bekerja sebanyak mendorong refactoring sedikit lebih jauh ke titik di mana akan ada titik "penghentian alami" (yaitu hampir tidak diperlukan kode proxy). Saya kemudian mundur, mengembalikan perubahan terakhir saya dan memfaktorkan ulang. Jika semuanya terdengar seperti memetakan wilayah yang belum dipetakan, itu karena saya merasa seperti itu, kecuali peta wilayah hanya dua dimensi.

Eksekusi

Setelah Anda menyelesaikan persiapan refactoring, inilah saatnya untuk mengeksekusi rencana tersebut. Pastikan konsentrasi Anda meningkat dan amankan lingkungan yang bebas gangguan. Saya kadang-kadang pergi sejauh benar-benar mematikan koneksi internet pada saat ini. Masalahnya, jika Anda sudah mempersiapkan diri dengan baik, siapkan satu set catatan yang bagus di atas kertas di sebelah Anda, dan konsentrasi Anda sudah habis! Anda sering dapat bergerak sangat cepat melalui perubahan dengan cara ini. Secara teori, sebagian besar pekerjaan dilakukan sebelumnya, selama persiapan.

Setelah Anda benar-benar memfaktorkan ulang kode, perhatikan potongan kode aneh yang melakukan sesuatu yang sangat spesifik dan mungkin tampak seperti kode yang buruk. Mungkin mereka kode yang buruk, tetapi cukup sering mereka benar-benar menangani kasus sudut aneh yang ditemukan saat menyelidiki bug dalam produksi. Seiring waktu, sebagian besar kode Rails menumbuhkan "rambut" atau "kutil" yang menangani bug kasus sudut yang aneh, misalnya, kode respons aneh di sini yang mungkin diperlukan untuk IE6 atau kondisi di sana yang menangani bug waktu yang aneh. Mereka tidak penting untuk gambaran besar tetapi masih detail yang signifikan. Idealnya, mereka secara eksplisit ditutupi dengan unit test, jika tidak mencoba untuk menutupinya terlebih dahulu. Saya pernah ditugaskan untuk mem-porting aplikasi berukuran sedang dari Rails 2 ke Rails 3. Saya sangat akrab dengan kodenya tetapi agak berantakan dan ada banyak perubahan yang perlu dipertimbangkan, jadi saya memilih untuk mengimplementasikannya kembali. Sebenarnya, itu bukan implementasi ulang yang nyata, karena itu hampir tidak pernah merupakan langkah yang cerdas, tetapi saya mulai dengan aplikasi Rails 3 yang kosong dan saya memfaktorkan ulang irisan vertikal dari aplikasi lama menjadi yang baru, secara kasar menggunakan proses yang dijelaskan. Setiap kali saya menyelesaikan irisan vertikal, saya menelusuri kode Rails lama, melihat setiap baris dan memeriksa ulang apakah ada pasangannya dalam kode baru. Saya pada dasarnya, memilih semua "rambut" kode lama dan mereplikasinya di basis kode baru. Pada akhirnya, basis kode baru telah menangani semua kasus sudut.

Pastikan untuk melakukan pengujian manual cukup sering. Ini akan memaksa Anda untuk mencari "jeda" alami dalam proses refactoring yang memungkinkan Anda menguji bagian dari sistem serta memberi Anda keyakinan bahwa Anda tidak merusak apa pun yang tidak Anda harapkan akan rusak dalam proses. .

Bungkus itu

Setelah Anda selesai memfaktorkan ulang kode Rails Anda, pastikan untuk meninjau semua perubahan Anda untuk terakhir kalinya. Lihatlah seluruh perbedaan dan lanjutkan. Cukup sering, Anda akan melihat hal-hal halus yang Anda lewatkan pada awal refactoring karena Anda tidak memiliki pengetahuan yang Anda miliki sekarang. Ini adalah manfaat bagus dari refactoring skala besar: Anda mendapatkan gambaran mental yang lebih jelas tentang organisasi kode, terutama jika Anda awalnya tidak menulisnya.

Jika memungkinkan, mintalah seorang rekan untuk meninjaunya juga. Dia bahkan tidak harus sangat akrab dengan bagian yang tepat dari basis kode, tetapi dia harus memiliki keakraban umum dengan proyek dan kodenya. Memiliki pandangan baru tentang perubahan dapat banyak membantu. Jika Anda benar-benar tidak bisa membuat pengembang lain melihatnya, Anda harus berpura-pura menjadi pengembang lain. Dapatkan tidur malam yang baik dan tinjau dengan pikiran segar.

Jika Anda kekurangan QA, Anda harus memakai topi itu juga. Sekali lagi, istirahatlah dan jauhkan diri Anda dari kode lalu kembali untuk melakukan pengujian manual. Anda baru saja mengalami hal yang sama dengan masuk ke lemari kabel listrik yang berantakan dengan banyak alat dan memilah semuanya, mungkin memotong dan memasang kembali barang-barang, jadi perlu sedikit lebih berhati-hati daripada biasanya.

Akhirnya, nikmati hasil kerja Anda dengan mempertimbangkan semua perubahan yang direncanakan yang sekarang akan jauh lebih bersih dan lebih mudah untuk diterapkan.

Kapan Anda tidak akan melakukannya?

Meskipun ada banyak manfaat untuk melakukan refactoring skala besar secara teratur untuk menjaga kode proyek tetap segar dan berkualitas tinggi, itu masih merupakan operasi yang sangat mahal. Ada juga kasus di mana tidak disarankan:

Cakupan tes Anda buruk

Seperti yang telah disebutkan: cakupan tes yang sangat buruk mungkin menjadi masalah besar. Gunakan penilaian Anda sendiri, tetapi mungkin lebih baik dalam jangka pendek untuk fokus pada peningkatan cakupan saat mengerjakan fitur baru dan melakukan sebanyak mungkin pemfaktoran ulang skala kecil yang dilokalkan. Itu akan banyak membantu Anda setelah Anda memutuskan untuk mengambil risiko dan menyortir bagian yang lebih besar dari basis kode.

Refactoring tidak didorong oleh fitur baru dan basis kode tidak berubah dalam waktu yang lama

Saya menggunakan bentuk lampau alih-alih mengatakan "basis kode tidak akan berubah" dengan sengaja. Dilihat dari pengalaman (dan menurut pengalaman saya sering salah), Anda hampir tidak pernah bisa mengandalkan prediksi Anda tentang kapan bagian tertentu dari basis kode perlu diubah. Jadi, lakukan hal terbaik berikutnya: lihat ke masa lalu dan anggap masa lalu akan terulang kembali. Jika sesuatu tidak berubah untuk waktu yang lama maka Anda mungkin tidak perlu mengubahnya sekarang. Tunggu sampai perubahan itu datang dan kerjakan sesuatu yang lain.

Anda terdesak waktu

Pemeliharaan adalah bagian paling mahal dalam siklus hidup proyek dan refactoring membuatnya lebih murah. Sangatlah penting bagi bisnis apa pun untuk menggunakan refactoring untuk mengurangi hutang teknis agar perawatan di masa depan lebih murah. Jika tidak, ia berada dalam bahaya memasuki lingkaran setan di mana penambahan fitur baru menjadi semakin mahal. Saya harap sudah jelas mengapa itu buruk.

Yang mengatakan, refactoring skala besar sangat, sangat tidak terduga dalam hal berapa lama waktu yang dibutuhkan, dan Anda tidak boleh melakukannya setengah jalan. Jika karena alasan internal atau eksternal apa pun Anda terdesak waktu dan Anda tidak yakin dapat menyelesaikannya dalam jangka waktu itu, maka Anda mungkin perlu meninggalkan refactoring. Tekanan dan stres, terutama jenis yang diinduksi waktu, mengarah ke tingkat konsentrasi yang lebih rendah, yang mutlak diperlukan untuk refactoring skala besar. Berusahalah untuk mendapatkan lebih banyak "pembelian" dari tim Anda untuk menyisihkan waktu untuk itu dan melihat kalender Anda untuk periode di mana Anda akan punya waktu. Tidak perlu bahwa itu adalah rentang waktu yang terus menerus. Tentu saja Anda akan memiliki masalah lain untuk dipecahkan, tetapi jeda itu tidak boleh lebih dari satu atau dua hari. Jika demikian, Anda harus mengingatkan diri sendiri tentang rencana Anda sendiri karena Anda akan mulai melupakan apa yang telah Anda pelajari tentang basis kode dan di mana tepatnya Anda berhenti.

Kesimpulan

Saya harap saya telah memberi Anda beberapa pedoman yang berguna dan meyakinkan Anda tentang manfaatnya, dan berani saya katakan perlu, melakukan refactoring skala besar dalam kesempatan tertentu. Topiknya sangat kabur, dan tentu saja tidak ada yang dikatakan di sini adalah kebenaran yang pasti dan keterangan akan bervariasi dari proyek ke proyek. Saya mencoba memberikan saran, yang menurut saya, berlaku secara umum, tetapi seperti biasa, pertimbangkan kasus khusus Anda dan gunakan pengalaman Anda sendiri untuk beradaptasi dengan tantangan spesifiknya. Semoga berhasil refactoring!