сайн програмууд нь үргэлж Refactoring байх

Өнгөрсөн үед “Always be closed”.

Хязгаарлагдмал борлуулалтын мантраGlengarry Glen RossӨнгөрсөн сайжруулахын тулд хязгааргүй хязгаарлагдмал байсан. Өнгөрсөн дуудлагатай (амар ч хязгаарлагдмал), сайн инженерийнүргэлж Refactoring. Here’s why.

Чийг чийг чийг чийг чийг

Тохиромжтой код нь харьцуулахад илүү хялбар, хадгалах илүү хялбар, илүү өргөн хүрээтэй юм. Рефакторинг нь мэдэгдсэн функцийг өөрчилжгүйгээр одоогийн код очиж байна.

Рефакторинг нь ихэвчлэн харьцуулахад хэзээ ч энэ нь хийж чадахгүй байгаа юм. Оюутнууд энэ нь луксуз гэж үздэг. Шинэ шинж чанарыг хайх нь хялбар нь рефакторинг боломжийг олгодоггүй, ялангуяа рефакторинг нь гадаргууг харьцуулахад ямар нэгэн зүйлийг өөрчилж чадна. Энэ нь таны бүтээгдэхүүний эзэмшигчд харьцуулахад хялбар байж болно.

Шинэ код нь таны амьдрал хялбар болгодог. Шинэ код нь тэдгээрийг хуваалцаж, техникийн ачааллыг багасгадаг.

Энэ нь шилжих.

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

Өнгөрсөн цаг хугацаатай байх болно, гэхдээ та зөөлөн эд анги, босоо, гарын авлага, техникийн ачаалал, аюулгүй байдлын хөнгөн, документын хөнгөн мэднэ.

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.

Хэрэв та кодны зуух, эсвэл таны одоогийн төвлөрөлтийн ойролцоогоор ямар нэг зүйлийг мэдэгдэж байгаа бол алармал дулааны дулааны дулааны дулааны дулааны дулааны:“Энэ боломжууд тавихыг хүсч чадахгүй!” 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.

Хязгааргүй пример

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.

Micro-refactoring иллюстрацийг харахын тулд Golang-ийн "экстракт арга" -ийг үзнэ үү.

Хамгийн сүүлийн үеийн хэрэглэгчийн бүртгэгдсэн хойш хэд хэдэн хоногийн мэдэхийг шаарддаг шинж чадварыг шийдэж байна. Та хэрэглэгчийн ямар ч мэдээллийг ашиглаж байгаа эсэхийг тодорхойлохын тулд одоогийн арга хэрэгсэл мэдэхийг хүсэж байна:

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, 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).

It also makes future enhancements easier. For example, it might make sense to make IsDormantНөхцөлDaysSinceLastLoginЗагвар ньUserтусгаарлагдмал байх үед struct. Үүнээс гадна, хатуу шифрлэгдсэн үнэт өөрчилж үзнэ үү8 with something more descriptive like DormantDaysThreshold.

Энэ нь хялбар жишээ юм, зүгээр л кодыг хэд хэдэн шугам юм. Гэхдээ энэ нь сайхан юм. Энэ нь бага refactoring нь үр дүнтэй буцаж, идэвхтэй сайжруулах болно.

Refactoring тухай дэлгэрэнгүй мэдэх, кодг сайжруулах бүх жижиг арга замыг үзэхын тулд Martin Fowler-ийн ном, Refactoring Guru-ийн Refactoring каталог, гэх мэт онлайн эх үүсвэрийг үзнэ үү.

A Refactoring Mindset

Таны код баазын хувьд визийг олж авах нь хялбар юм. Хэрэв та үүнийг олж авахыг мэднэ үү, энэ нь илүү хялбар юм. Refactoring боломжуудыг олж авах нь практик хэрэглэдэг. эхлэхэд нэг арга нь кодыг өөрчлөхын тулд refactoring-ийн бүтэцүүд гэж үзнэ үү.

Энд зарим нийтлэг Refactoring загварууд нь санаа зовох:

🧹 Remove Duplication — Collapse copy and pasted logic into a single function.

🧰 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— Нарийвчлал (логинг, Tracing, метрик) танилцуулах. Хүргэлтийн боловсруулах эсвэл retries төвлөрүүлэх.

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

Prepare for a Feature Change— Хязгаарлагдмал хязгаарлагдмал эсвэл гүнзгий логик. Файлуудыг эсвэл класс шинэ эрх хуулиар хамгаалагдсан.

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

Reduce Cognitive Load — Split giant files or classes into logical, focused units.

Improve Security or ComplianceRefactor insecure загварууд (жишээ нь, гарын авлага SQL concatenation → parameterized асуултууд).

🚀 Improve Performance— Найдвартай алгоритмыг optimized алгоритмыг өөрчилж. Меморийг хязгаарлагч, хязгаарлагдмал компьютерийг халуун замыг багасгах.

👥 Ease Onboarding or Handoff— Refactor код нь зөвхөн "Pat" -ийг багны уншсан зүйл болгон мэддэг. Документы/comments/test coverage-ийг структурын цэвэрлэх хэсэгт танилцуулах.

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.

Гэсэн хэдий ч, энэ нь илүү хялбар борлуулалт байх ёстой, учир нь та бүрэн, найдвартай, найдвартай рефактор хэрэгтэй үед, энэ нь найдвартай ч илүү их зорилготай байх болно.

Жишээлбэл, гүйцэтгэлийн сайжруулах билет дээр ажиллахад өмнө, та одоогийн гүйцэтгэлийн хамгийн шилдэг зургийг бий болгох, халуун томоохон тодорхойлохын тулд сүүлийн үеийн дараах ирдэг, метрикуудыг нэмж хэрэгтэй.

Refactoring Starts with Testing

Энэ нь найдвартай байж болох юм, гэхдээ би refactoring илүү хялбар байдаг гэж үзнэ үү (аж бага нерв-ракинг), Хэрэв таны код бааз нь refactoring өмнө, дараагийн туршид дамжуулан туслах туршид байна.бусад шалтгааны багцХэрэв таны төсөл нь хүчтэй туршилтгүй байгаа бол, дараа нь өмнөх рефакторинг илрүүлэхэд анх удаа зарим туршилт нэмнэ.

Зохиогчийн эрх хуулиар хамгаалагдсан

Энэ нийтлэлд миний зөвлөмж нь рефакторинг ажил, тохиромжтой онцлог хөгжүүлэг нь багасгахын тулд стандарт гарын авлагатай юм. Үзүүлэлт нь энэ нь кодыг өөрчлөгдөж байгаа бол кодыг шалгахын тулд багц нь хялбар болгодог. Энэ нь тохиромжтой зүйл юм. Функцийн ажлын үед рефакторинг үед энэ нь жижиг, (жишээ нь) өөр өөрчилсөн үндсэн даралттай холбоотой байх ёстой.

Ямар ч тохиромжтой нунтаг нь ямар ч нарийвчлал нь кодыг өөрчилж 500 шугам хүртэл хязгаарлах юм. Хоёр дахь нунтаг нунтаг нь тусламжтай рефакторинг өөрчилж PR-ийн 20%-ээс дээш байх ёстой.

Хэрэв та өөрчлөн Refactoring PR-ийг хийж байгаа бол энэ хэмжээгээр төвлөрсөн байх ёстой. Зарим үед PR-ийн код 500-ээс дээш хэлбэртэй байх ёстой, ялангуяа repo-ширээтэй Refactor дээр ажиллаж байгаа үед. Эдгээр тохиолдолд коллежийн тусламжтай байхын тулд өөрчилж авахын тулд ихээхэн тохиромжтой байх.

Бvх эрх хуулиар хамгаалагдсан

Та код суурилуулах үед, та сонголт байна: энэ нь зарим нь илүү сайн байх, эсвэл энэ нь зарим нь богино байх болно. Refactoring нь том үйл явцад байх ёстой биш юм. Жижиг шинэчлэлүүд (хэвлэх арга хэрэгсэл, зөөлөн өөр өөр өөрсдийн нэр, урт арга хэрэгсэл өөрчилж, гэх мэт) цаг хугацааны харьцуулахад нэмж байна. Тэд техникийн ачаалал хамардаг, дараагийн өөрчлөлтийг хялбар, аюулгүй болгодог.

If you see something, fix something.

Өнгөрсөн шинэчлэх!