“Always be closing.” The hard-nosed sales mantra from 同様の精神で(しかし、あまり誓うことなく)、良いエンジニアは、 . Here’s why. グレンガーリー Glen Ross always be refactoring 掃除するか、掃除しないか クリーンコードは理解しやすく、維持しやすく、さらに拡張可能であることが一般的に合意されています。 リファクタリングに対する一般的な異議は、それを実際にする時間がないということです. チームはそれを贅沢だと見ています. 新しい機能への絶え間ないドライブは、特にリファクタリングが外部からの視点から何も変わらないので、リファクタリングを許さないだけです. それはあなたの製品所有者にとって難しい売り物かもしれません. But clean code makes your life easier. Clean code pays for itself and slows the accumulation of technical debt. So sneak it in. それは正しいです。私はちょっとしたサッターフュージーを提案しています. 少しの誤りさえ. なぜすべてのリトルリクエストでいくつかのものをクリアしないのですか? 警戒しろ 良いエンジニアは、コードベースがどこに向かうべきかというビジョンを持っています。そこに到達するにはしばらく時間がかかりますが、混乱した部分、バックロッグ、ロードマップ、技術的負債、セキュリティの穴、および文書のギャップを知っています。 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. 「このチャンスを逃さないで!」 それはあなたの問題ではないと言わないでください. あなたはそれを見逃すことができないふりをしてはいけません. あなたの袖を振ってそれを完了してください。 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 } コピーして挿入する代わりに、最後のログイン計算を再利用したいので、内部変数を選択します。 , 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). It also makes future enhancements easier. For example, it might make sense to make そして methods on the struct instead of being standalone. Likewise, consider replacing the hard-coded value より説明的なものとして、 . IsDormant DaysSinceLastLogin User 8 DormantDaysThreshold これは単純な例ですが、コードのいくつかの行だけです。しかし、それはその美しさです. それは、潜在的なバグを明らかにし、将来の改善を指し示すことによって、小さなリファクターリングが価値を追加することができます。 リファクタリングの芸術についてもっと知り、コードを改善するためのすべての小さな方法を見るには、マーティン・ファウラーの本のリファクタリングカタログやリファクタリング・グゥーラなどのオンラインリソースをご覧ください。 カタログ再構築 改修師 A Refactoring Mindset あなたのコードベースのビジョンを持つことは簡単です。それをどのように取得するかを知ることはより困難です。リファクタリングの機会を発見することは実践を必要とします。始めるための1つの方法は、あなたのコードを変換するために必要なリファクタリングのカテゴリを検討することです。 以下は、考えるためのいくつかの共通の再構築のテーマです。 コピーを崩し、論理を1つの関数に挿入します。 🧹 Remove Duplication 🧰 — Move common logic out of per-service implementations. Normalize integrations (e.g., all services use the same auth client). Extract Shared Utility or Library ↓↓↓ — Introduce observability (logging, tracing, metrics). Centralize error handling or retries. Add Common Infrastructure ️ 緊密に結びついた論理を分割して、依存を嘲笑したり、頑固にしたりできるようにインターフェイスを抽出します。 Make Code More Testable ↓↓↓ — Flatten complex conditionals or nested logic. Reorganize files or classes to fit new responsibilities. Prepare for a Feature Change ️ — Break apart a monolith. Introduce event-driven patterns, dependency injection, or async processing. Support a New Architecture 🚦 巨大なファイルやクラスを論理的、焦点を当てたユニットに分割します。 Reduce Cognitive Load ↓↓↓ — Centralize access control logic. Refactor insecure patterns (e.g., manual SQL concatenation → parameterized queries). Improve Security or Compliance 🚀 — Naive アルゴリズムを最適化したアルゴリズムに置き換える. Reduce memory churn or unnecessary computation in hot paths. Improve Performance ↓↓↓ — Refactor code that only “Pat” understands into something team-readable. Introduce docs/comments/test coverage as part of structural cleanup. Ease Onboarding or Handoff その20% 確かにすべてのリファクタリングがスヌークインできるわけではないと反対する人もいるでしょう。80〜20のルールを適用し、リファクタリングの20%をアップとアップで行う必要があると規定しましょう。 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. リファクトレーションはテストから始まる これはおそらく明らかですが、リファクタリングは、リファクタリングの前と後を通過する同行のテストセットを持っている場合、リファクタリングがはるかに簡単(およびより少ない神経のラッキング)であることを指摘しなければなりません。 . If your project doesn’t have strong testing, then add some tests first to unlock future refactorings. 他の理由のバンド Code Review Considerations この記事の私のアドバイスは、リファクタリング作業と通常の機能開発を混同しないという標準的なガイドラインに反するものであり、コードのレビューが含まれていない場合にチームがコードのレビューを行うのが難しくなるという異議があります。 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. あなたがリファクタリングPRを専用している場合、それを焦点とこのサイズの周りに保つ。時にはPRは、特にリファクタリング全体のリファクタリングで働くとき、コードの500行を超える必要があります。 Make Every Commit Count Every time you touch the codebase, you have a choice: leave it a little better, or leave it a little worse. Refactoring doesn’t have to be a grand event. Small improvements (extracting methods, renaming confusing variables, breaking apart long methods, etc.) add up over time. They prevent technical debt from piling up and make future changes easier and safer. If you see something, fix something. Always be refactoring!
