“Saya sentiasa tutup. The hard-nosed sales mantra from Dalam semangat yang sama (tetapi dengan lebih sedikit bersumpah), seorang jurutera yang baik harus Berikut ialah mengapa. Tajuk : Glen Ross Sentiasa membina semula To Clean or Not to Clean It’s generally agreed that clean code is easier to understand, cheaper to maintain, and much more extensible. At its core, refactoring is cleaning up existing code without altering its perceived functionality. A common objection to refactoring is that there isn’t time to actually do it. Teams see it as a luxury. The relentless drive for new features simply doesn’t allow for refactoring, especially because refactoring changes nothing from an external point of view. That can be a hard sell to your product owner. Tetapi kod bersih membuat hidup anda lebih mudah. kod bersih membayar untuk diri sendiri dan melambatkan pengumpulan hutang teknikal. So sneak it in. That’s right. I’m suggesting a slight bit of subterfuge. A little misdirection even. Why not clean up a few things in every pull request? Be Vigilant Seorang jurutera yang baik mempunyai visi di mana pangkalan kod hendaklah diarahkan.Ia mungkin mengambil masa untuk sampai ke sana, tetapi anda tahu bahagian-bahagian yang berantakan, rintangan, peta jalan, hutang teknikal, lubang keselamatan, dan jurang dokumentasi. Apabila anda pergi tentang pembangunan ciri biasa anda, waspada untuk refactorings yang boleh memajukan agenda yang lebih besar anda.Sebagai salah satu daripada detektif acara TV hiper-pengawasan yang menyiasat adegan jenayah, berhati-hati dengan semua kod yang anda terjejas. Apabila anda melihat bau kod atau sesuatu yang sedikit keluar berhampiran fokus semasa anda, bunyi amaran harus dimatikan: Ambil beberapa minit dan perbaiki sekarang, sebelum inspirasi hilang. “Don’t let this opportunity pass!” Jangan katakan bahawa ia bukan masalah anda.Jangan berpura-pura bahawa anda tidak dapat melihatnya.Sedikit menggelengkan lengan anda dan melakukannya. Contoh yang mudah Refactoring tidak semestinya bermakna mengubah beribu-ribu baris kod. Ia boleh menjadi hanya sebahagian kecil kod di sini dan di sana. mikro-refactorings kecil ini menambah dengan masa. To illustrate micro-refactoring, let’s look at an “extract method” Golang example. Katakanlah anda menangani ciri yang memerlukan mengetahui berapa hari telah berlalu sejak pengguna terakhir log masuk. anda melihat kaedah yang sedia ada yang menentukan sama ada pengguna sedang tertidur menggunakan maklumat yang sama: func IsDormant(user User, asOf time.Time) bool { days := int(asOf.Sub(user.LastLogin).Hours() / 24) return days >= 8 } You want to re-use the last login calculation instead of copying and pasting it, so you take the internal variable, , and extracting it into a separate method, : days DaysSinceLastLogin func IsDormant(user User, asOf time.Time) bool { return DaysSinceLastLogin(user, asOf) >= 8 } func DaysSinceLastLogin(user User, asOf time.Time) int { return int(asOf.Sub(user.LastLogin).Hours() / 24) } This allows the last login logic to be tested and reused. If you write a unit test, you’ll spot an edge case that should be handled (a potential panic if a user has never logged in). Ia juga menjadikan peningkatan masa depan lebih mudah. Sebagai contoh, ia mungkin masuk akal untuk membuat and kaedah pada struct instead of being standalone. Likewise, consider replacing the hard-coded value Dengan sesuatu yang lebih deskriptif seperti . IsDormant DaysSinceLastLogin User 8 DormantDaysThreshold This is a simple example, just a few lines of code. But that’s the beauty. It shows a small refactoring can add value by revealing a potential bug and pointing towards future improvements. Untuk mengetahui lebih lanjut mengenai kerajinan refactoring dan melihat semua cara kecil untuk meningkatkan kod anda, semak sumber dalam talian seperti katalog refactoring dari buku Martin Fowler atau Guru Refactoring. refactoring catalog Pembaharuan Guru Pemikiran Reflektif Mempunyai visi untuk pangkalan kod anda mudah. Mengetahui bagaimana untuk mendapatkannya adalah lebih sukar. Menemui peluang refactoring mengambil amalan. Salah satu cara untuk memulakan adalah untuk mempertimbangkan kategori refactoring yang diperlukan untuk mengubah kod anda. Berikut ialah beberapa tema refactoring biasa untuk dipertimbangkan: - Runtuhkan salinan dan logik yang dilampirkan ke dalam fungsi tunggal. 🧹 Remove Duplication 🧰 Mengalih keluar logik biasa daripada pelaksanaan per-perkhidmatan. menormalkan integrasi (contohnya, semua perkhidmatan menggunakan klien auth yang sama). Extract Shared Utility or Library 🧱 — Introduce observability (logging, tracing, metrics). Centralize error handling or retries. Add Common Infrastructure ⚙️ — Break apart tightly coupled logic. Extract interfaces so dependencies can be mocked or stubbed. Make Code More Testable 🔄 — Flatten complex conditionals or nested logic. Reorganize files or classes to fit new responsibilities. Prepare for a Feature Change ️ Memperkenalkan corak yang dipandu oleh peristiwa, suntikan ketergantungan, atau pemprosesan async. Support a New Architecture 🚦 — Split giant files or classes into logical, focused units. Reduce Cognitive Load — Centralize access control logic. Refactor insecure patterns (e.g., manual SQL concatenation → parameterized queries). Improve Security or Compliance 🚀 — Replace naive algorithms with optimized ones. Reduce memory churn or unnecessary computation in hot paths. Improve Performance — Kode Refactor yang hanya "Pat" faham kepada sesuatu yang boleh dibaca oleh pasukan.Masukkan docs/comments/test coverage sebagai sebahagian daripada pembersihan struktural. Ease Onboarding or Handoff The 20% Some might object that surely not all refactorings can be snuck in. I’ll grant you that. Let’s apply the 80–20 rule and stipulate that 20% of refactorings need to be done on the up-and-up. Ini harus menjadi jualan yang lebih mudah, bagaimanapun, kerana apabila anda mencapai titik di mana anda memerlukan refactor yang lengkap, jujur kepada kebaikan, ia pasti akan berkhidmat kepada beberapa matlamat yang lebih besar. For example, before working on a performance improvement ticket, you first need to add tracing and metrics so you can develop a finer picture of current performance and identify hotspots. Refactoring bermula dengan ujian Ia mungkin jelas, tetapi saya mesti menunjukkan bahawa refactoring adalah lebih mudah (dan kurang saraf-racking) jika kod base anda mempunyai satu set ujian yang disertai yang lulus sebelum dan selepas refactoring. . If your project doesn’t have strong testing, then add some tests first to unlock future refactorings. bunch of other reasons Code Review Considerations Nasihat saya dalam artikel ini bertentangan dengan garis panduan standard untuk tidak mencampurkan kerja refactoring dan pembangunan ciri biasa. pertikaian adalah bahawa ia membuatnya lebih sukar bagi pasukan untuk melakukan tinjauan kod jika perubahan yang tidak berkaitan disertakan.Ini merupakan perkara yang adil. A peraturan yang baik untuk mana-mana permintaan tarik adalah untuk mengehadkannya kepada 500 baris perubahan kod. A peraturan kedua ialah perubahan refactoring tambahan tidak boleh melebihi 20% daripada PR. When you do have dedicated refactoring PRs, keep it focused and around this size. Sometimes a PR has to be greater than 500 lines of code, especially when working on a repo-wide refactor. In those cases, coordinate well with your colleagues to prepare them for the change and to minimize merge conflicts. Make Every Commit Count Setiap kali anda menyentuh pangkalan kod, anda mempunyai pilihan: biarkan ia sedikit lebih baik, atau biarkan ia sedikit lebih buruk. Refactoring tidak perlu menjadi peristiwa besar. Perbaikan kecil (mengekstrak kaedah, menamakan semula variabel yang membingungkan, memisahkan kaedah yang panjang, dan lain-lain) menambah seiring dengan masa. Mereka mengelakkan hutang teknikal daripada bertumpuk dan membuat perubahan masa depan lebih mudah dan lebih selamat. Jika anda melihat sesuatu, pastikan untuk memperbaiki sesuatu. Always be refactoring!
