โปรแกรมเมอร์ที่ดีมักจะ refactoring

“Always be closing.”

The hard-nosed sales mantra from Glengarry Glen Rossได้กลายเป็นระยะสั้นสําหรับการปรับปรุงอย่างต่อเนื่อง ในจิตวิญญาณเดียวกัน (แต่มีข้อศอกน้อยลงมาก) นักวิศวกรที่ดีควรalways be refactoring. Here’s why.

ทําความสะอาดหรือไม่ทําความสะอาด

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.

But clean code makes your life easier. Clean code pays for itself and slows the accumulation of technical debt.

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?

ระมัดระวัง

A good engineer has a vision of where the codebase should be heading. It might take a while to get there, but you know the messy parts, the backlog, the roadmap, the technical debt, the security holes, and the documentation gaps.

As you go about your regular feature development, be on the lookout for refactorings that can advance your larger agenda. Like one of those hyper-observant TV show detectives surveying a crime scene, pay close attention to all the code you stumble across.

เมื่อคุณสังเกตเห็นกลิ่นรหัสหรือบางสิ่งบางอย่างเบา ๆ ที่อยู่ใกล้กับจุดมุ่งเน้นปัจจุบันของคุณเตือนภัยควรปิด:“Don’t let this opportunity pass!” Take a few minutes and fix it now, before inspiration fades.

Don’t say it’s not your problem. Don’t pretend you can unsee it. Just roll up your sleeves and get it done.

A Simple Example

Refactoring doesn’t necessarily mean changing thousands of lines of code. It can be just a small chunk of code here and there. These little micro-refactorings add up over time. In fact, the more you get into the habit of constant cleanup, the less you will need to do major refactorings in the future.

To illustrate micro-refactoring, let’s look at an “extract method” Golang example.

แสดงให้เห็นว่าคุณกําลังจัดการกับคุณลักษณะที่ต้องรู้ว่ามีหลายวันตั้งแต่ผู้ใช้เข้าสู่ระบบครั้งล่าสุด คุณสังเกตเห็นวิธีการที่มีอยู่ซึ่งจะระบุว่าผู้ใช้ไม่ได้ใช้งานโดยใช้ข้อมูลเดียวกัน:

func IsDormant(user User, asOf time.Time) bool {
  days := int(asOf.Sub(user.LastLogin).Hours() / 24)
  return days >= 8
}

คุณต้องการใช้การคํานวณการเข้าสู่ระบบล่าสุดแทนที่จะคัดลอกและวางไว้ดังนั้นคุณต้องใช้ตัวแปรภายในdays, and extracting it into a separate method, 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)
}

สิ่งนี้ช่วยให้กลยุทธ์การเข้าสู่ระบบล่าสุดสามารถทดสอบและใช้ซ้ําได้ หากคุณเขียนการทดสอบหน่วยคุณจะสังเกตเห็นกรณีขอบที่ควรได้รับการจัดการ (กลยุทธ์ที่เป็นไปได้หากผู้ใช้ไม่เคยเข้าสู่ระบบ)

It also makes future enhancements easier. For example, it might make sense to make IsDormant and DaysSinceLastLoginวิธีการเกี่ยวกับUserstruct แทนที่จะเป็น standalone เช่นเดียวกับพิจารณาการแทนที่ค่าที่เข้ารหัสอย่างหนัก8 with something more descriptive like DormantDaysThreshold.

นี่เป็นตัวอย่างที่เรียบง่ายเพียงไม่กี่แถวของรหัส แต่นี่คือความงาม มันแสดงให้เห็นว่าการทําซ้ําขนาดเล็กสามารถเพิ่มมูลค่าโดยการเปิดเผยข้อบกพร่องที่เป็นไปได้และแสดงให้เห็นถึงการปรับปรุงในอนาคต

หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับงานฝีมือของ refactoring และดูวิธีเล็ก ๆ น้อย ๆ ในการปรับปรุงรหัสของคุณโปรดดูทรัพยากรออนไลน์เช่น แคตตาล็อก refactoring จากหนังสือของ Martin Fowler หรือ Refactoring Guru

A Refactoring Mindset

Having a vision for your codebase is easy. Knowing how to get it there is harder. Spotting refactoring opportunities takes practice. One way to get started is to consider which categories of refactoring are necessary to transform your code.

Here are some common refactoring themes to think about:

🧹 Remove Duplication— คัดลอกและวางกลยุทธ์ลงในฟังก์ชั่นเดียว

Extract Shared Utility or Library — Move common logic out of per-service implementations. Normalize integrations (e.g., all services use the same auth client).

🧱 Add Common Infrastructure— นําเข้าความสามารถในการสังเกต (บันทึกการติดตามการวัด) การจัดการข้อผิดพลาดหรือการแก้ไข

⚙️ Make Code More Testable — Break apart tightly coupled logic. Extract interfaces so dependencies can be mocked or stubbed.

Prepare for a Feature Change — Flatten complex conditionals or nested logic. Reorganize files or classes to fit new responsibilities.

🏗️ Support a New Architecture — Break apart a monolith. Introduce event-driven patterns, dependency injection, or async processing.

🚦 Reduce Cognitive Load- แบ่งไฟล์หรือคลาสขนาดใหญ่เป็นหน่วยเชิงล็อกที่มุ่งเน้น

🔐 Improve Security or Compliance — Centralize access control logic. Refactor insecure patterns (e.g., manual SQL concatenation → parameterized queries).

🚀 Improve Performance — Replace naive algorithms with optimized ones. Reduce memory churn or unnecessary computation in hot paths.

Ease Onboarding or Handoff — Refactor code that only “Pat” understands into something team-readable. Introduce docs/comments/test coverage as part of structural cleanup.

The 20%

บางคนอาจปฏิเสธว่าแน่นอนไม่สามารถทํา refactorings ทั้งหมดได้ ฉันจะยอมรับคุณว่า ลองใช้กฎ 80-20 และกําหนดว่า 20% ของ refactorings จะต้องทําบน up-and-up

These should be an easier sell, however, because when you get to the point where you need a full, honest-to-goodness refactor, it is most definitely going to be in service of some larger goal.

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 Starts with Testing

It is probably self-evident, but I must point out that refactoring is much easier (and less nerve-racking) if your codebase has an accompanying suite of tests that pass before and after the refactoring. Having tests is also valuable for a bunch of other reasons. If your project doesn’t have strong testing, then add some tests first to unlock future refactorings.

Code Review Considerations

My advice in this article runs counter to the standard guideline to not mix refactoring work and regular feature development. The objection is that it makes it harder for the team to do code reviews if unrelated changes are included. That’s a fair point. When refactoring during feature work, keep it small and (ideally) related to the main thrust of the change.

A good rule of thumb for any pull request is to limit it to 500 lines of code changes. A second rule of thumb is that ancillary refactoring changes should be no more than 20% of the PR.

เมื่อคุณมี PRs refactoring ที่เฉพาะเจาะจงให้มุ่งเน้นและรอบ ๆ ขนาดนี้ บางครั้ง PR ควรมีโค้ดมากกว่า 500 บรรทัดโดยเฉพาะอย่างยิ่งเมื่อทํางานบน repo-wide refactor ในกรณีเหล่านี้ให้มีการประสานงานอย่างดีกับเพื่อนร่วมงานของคุณเพื่อเตรียมความพร้อมสําหรับการเปลี่ยนแปลงและเพื่อลดความขัดแย้งในการรวมกัน

ทําให้ทุกความมุ่งมั่นนับ

ทุกครั้งที่คุณสัมผัสรหัสฐานคุณมีทางเลือก: ปล่อยให้ดีขึ้นเล็กน้อยหรือเลิกไม่ดีขึ้นเล็กน้อย Refactoring ไม่จําเป็นต้องเป็นเหตุการณ์ที่ยิ่งใหญ่ การปรับปรุงขนาดเล็ก (การสกัดวิธีการเปลี่ยนชื่อตัวแปรที่ทําให้สับสนการทําลายวิธีการที่ยาวนาน ฯลฯ ) เพิ่มขึ้นตามเวลา พวกเขาป้องกันไม่ให้ภาระทางเทคนิคเพิ่มขึ้นและทําให้การเปลี่ยนแปลงในอนาคตง่ายขึ้นและปลอดภัยยิ่งขึ้น

If you see something, fix something.

Always be refactoring!