チームにリファクタリングを促す方法
私は非常に大規模な組織の一部である20人以下のチームに所属しています。同じコードベースを5年ほど使用しており、そこから複数の派生プロジェクトをリリースしています。
私はチームメンバーと1対1で会話しましたが、ほとんどのメンバーはさまざまなコードの臭いを認識していて、嫌いですが、常により重要なことがあるので、リファクタリングはほとんど行われません。また、コードベースの計画的またはクリーンアップをさらに行うことができるかどうかを経営陣に尋ねましたが、基本的にノーと言われました。チームの全員が独自の方法でプログラムし、調整はありません。
ここではリファクタリング手法を求めているのではありません。純粋な機能ではなく、保守性のために書く文化を作るのに役立ついくつかの方法を尋ねています。注：私はマネージャーではないので、物事を口述することはできません。
リファクタリングの許可を経営陣に求めないでください。それは彼らのビジネスのどれでもありません。また、鉛筆を削る許可を求めているかもしれません。
経営陣はリファクタリングを理解していません。それはビジネスニーズではありません。経営者はそれを理解する必要はありません。彼らの仕事ではありません。あなたのものです。
リファクタリングは、管理のニーズを満たすために使用するツールです。経営者にこれについて考えてはいけません。私の整備士が私の車で使用するレンチのブランドを尋ねられたら私は非常に心配です。心配は、ツールではなく、メカニックです。
あなたがしなければならないことは、このチームを良い実践に導くことです。それを指示するよう経営陣に要求しないでください。彼らが試みても、彼らはそれを台無しにするだけです。
チームとの信頼関係を築き、メリットとコストを示し、変化がすぐには起こらないことを受け入れる必要があります。
場合によっては、横断的な関心事が多くのクラスを網羅し、リファクタリングが必要になります。時々、あなたは今それをすることを正当化することができないだけです。なぜなら、今あなたはこれがただ一つの小さなことを変える必要があるだけだからです。
それは痛い。時間がないので、がらくたコードで作業を続けなければなりません。したがって、それはますます長くかかり続けます。
安倍リンカーンはしばしば「木を切り倒すために6時間を与えてください、そして私は斧を研ぐために最初の4つの時間を費やすでしょう」と言っていると言われています。
管理に対処するとき、斧を研ぐことを主張しないでください。 6時間議論してください。斧を研ぐための信用を得ることを期待しないでください。管理のためにそれをしないでください。あなたがいまいましい木の戦いに2時間を費やすだけでよいようにそれをしてください。
単純なリファクタリングとリライトの違いを理解してください。 「リファクタリング」という言葉は、本当に対象を絞った書き直しを意味するものである場合が多いです。この違いを次のように考えます（リスクの高い順に）。
- リファクタリングは、機能に影響を与えない小さな、簡単に元に戻せる変更です
- Targeted rewriteは、コードの複数の部分に影響を与えるアプリケーションの1つの側面の集中的な書き換えです
- 全面的な書き換えは、古いソースコードを破棄し、最初からやり直します
ここで区別する理由は、一部のコード修正はスケジュールに実際の影響を与えるためです。スケジュールに影響を与える何かをしたいときはいつでも、賛同が必要です。その賛同を得るための方法はありますが、機会としてそれを販売する必要があります。
リファクタリングは、良い習慣として行うべきものです。ボーイスカウトがキャンプサイトを見つけたときよりも良好な状態で（他の人々の混乱を解消するために）離れるように、それは起こります。多くのJavaおよびC＃IDEには組み込みのリファクタリングツールが付属しているため、パラメーターリストの並べ替えやコードの名前変更などの小さなことは、アプリケーション全体で更新されます。変更するものが内部のものである限り、 API（サードパーティが操作するものではありません）には、実際的な制限はありません。
一連の適切にターゲットを絞ったリファクタリングは、ターゲットを絞ったリライトと同じ効果をもたらしますが、同じレベルのリスクは伴わないことを認識することが重要です。また、リファクタリングと呼んでいる以外の作業をスプリント内で実行できない場合、実際に話しているのはターゲットを絞った書き換えだと思います。プロジェクトマネー（つまり、開発者が何かを行う時間と他の何かを行う時間）を、その影響力が大きいものにコミットすることはできません。リファクタリングは、製品が期限を遅らせることのないタイプの作業です。
ターゲットを絞った書き換えはスコープと計画が必要です。壁を壊さなければならないキッチンを改造するようなものです。ジョブが完了して新しいサポートが追加されるまで、既存のインフラストラクチャをサポートするために行う必要があることがあります。これは通常、これまでにない利点をもたらすリスクの許容範囲です。処理中はコードが乱雑になりますが、コードが完了すると、アプリケーション全体の状態が改善されます。
対象となる書き換えを販売する最良の方法は、書き換えによってチームが実行できるようになる新機能の観点から、それをケージに入れることです。
実際にオプションがない場合を除き、全体の書き換えは避けてください。それは家を完全に別のものに置き換える前に家を破壊するようなものです。その家がどのように使用されたかをよく知らない限り、あなたは新しい家がクライアントのニーズを満たさないというリスクを冒します。
全体の書き換えが実際に必要な場合がありますが、完了時にクライアントの現在のすべてのニーズに対応していることを確認するには、多くの調査が必要です。長い間忘れられていた機能のために書かれた既存のコードには、まだ重要な詳細がたくさんあります。このタイプの作業にも戦略があります。
全体的なスケールの書き換えの1つの概念は、 stranglerpattern を使用することです。基本的に、古いアプリケーションと一緒に新しいアプリケーションを構築し、可能な場合は新しいアプリケーションを使用します。完全に置き換えられるまで、古いアプリケーションの存在はますます少なくなります。これにより、重要な詳細を見逃さないように顧客がフィードバックを提供できます。
リファクタリングは開発の一環として行う必要があります。動作を変更したり、新しい機能を追加したりする場合、影響を受けるコードは、必要に応じて、変更を適切にサポートするようにリファクタリングする必要があります。ボーイスカウトのルールに従ってください。常に、コードを見つけたときよりも良い状態にしてください。
動作の変更を必要としないコードをリファクタリングしないでください。バグ修正や新しい開発に関連しないリファクタリングを実行しないでください。開発とは別にリファクタリングを見積もったり、スケジュールしたりしないでください。単体テストの記述やコードレビューの実行と同様に、個別の交渉可能なオプションではなく、すべての開発の自然に統合される部分である必要があります。
コードレビューの一部としてリファクタリングを奨励します。変更後のコードが、変更前のコードと少なくとも同じくらいきれいかどうか、簡単な質問をしてください。そうでない場合は、コードがコミットされる前に改善してください。
完璧主義者にならないでください-少なくとも最初はそうではありません。すべてのコミットでコードが少し改善される限り、長期的には状況はずっと良くなります。
ビジネスをリファクタリングするように説得することはほとんど不可能です。なぜなら、顧客はリファクタリングの費用を払わないが、開発者はそれをするためにまだ支払われることを望んでいるからです。
質問を投げ返します。 あなたがリファクタリングをしたいのはなぜですか？
最終製品を改善する
定義によるリファクタリングは、最終製品に変更がないことを意味します。これはスターターではありません
開発をスピードアップ
「これをリファクタリングすると、将来の変更が容易になります」という一般的な選択。もちろん、速度が10％向上する場合、戻りが見られるようになるまでに10倍の時間がかかります。合計が正味の勝ちになる数を示すのは難しい。
開発者が最新の方法でプログラミングできるようにしますか？
もちろんこれは、開発者が新しいおもちゃを欲しがっているという経営の恐怖です。しかし、あなたはそれを回転させることができます。 「私たちはハイテク企業です。最新のものを使用して適切な処理を行わない限り、誰も私たちの製品を尊重することはありません。私たちは最先端にいると見なされなければなりません。」
あなたの会社はどのようなビジネスですか？
オーダーメイドのアプリ/ウェブサイト
顧客が具体的にそれを要求しない限り、または技術者が要件を実装するように切り替える必要がある場合を除き、リファクタリングの正当化はありません
社内のコア製品。 eコマースウェブサイト
主な懸念事項は、信頼性と新機能です。信頼性を向上させるため、または機能を追加するための「リファクタリング」「MQのイベントに切り替えた場合、マイクロサービスに加えて機械学習に基づいて製品提案を送信できます」
ITコンサルタント
ここでは、最新のアイデアやテクニックにリファクタリングすることが、セールスピッチの中心となる可能性があります。 「distributed-cloud-agileに切り替えてください！（現在、トラックベースの開発が追加されています）」しかし、必要なすべてのものを手に入れることができるグリーンフィールドまたはPOCプロジェクトを行う可能性が高くなります。
デザインにリファクタリングを含める必要があります。適切ではないと思われる何かを「修正」する必要性を理解していますが、完成した、テストされた、認定された、動作中の（本番環境で）コードのリファクタリングがあなたとあなたの会社に提供するものに関して、正直である必要があります。機能していて、大きなバグやパフォーマンスの問題がなく、利害関係者に価値を提供しているものは変更しないでください。これは彼らにとって非常に目に見えます、そしてそれが彼らが（おそらく）不必要な変更のための時間を決して許さない理由です。
あなたはそれについて賢くなければなりません。あなたは（私が思うに）このソフトウェアのメンテナンスを提供しています。新しい機能にはいくつかの設計が必要になるため、コードを変更する必要がある場合は常に、外科的で実用的な変更を行わず、問題の正しい解決策を構築することを約束してください。これには、既存のクラスのリファクタリングが含まれる可能性があります。
あなたの質問に欠けているもの、それはおそらくあなたが管理者からそれを渡すことができなかった理由である可能性が高いですが、リファクタリングのための必要のデモです。
リファクタリングはリスクであるため、「期待されるリターン」は正の正味であり、事態が南下した場合の被害を軽減できることを示す必要があります。
ただし、期待収益がコストより高いことを証明できれば、誰もあなたに反対しないでしょう。
リファクタリングも経営陣の力の外にある可能性があります。会社/プロジェクトによっては、会社が実際に作業しているコードベースを所有していない場合があります。クライアントが要求していない変更に取り組むことは、契約違反となる場合があります。
純粋な機能ではなく、保守性のために書く文化を作るのに役立ついくつかの方法を尋ねています
20人のチームで、会議と（できれば）コードレビューがあると仮定します。これらは、コーディングスタイル（理想的にはコーディングガイドラインが存在する）とデザインパターンに関する懸念を共有する良い機会です。繰り返しますが、これの利点を示す必要があります！コーディングスタイルを変更するには、すべてのメンバーが変更、維持、施行するための努力が必要ですが、一般的に、あなたが有効な議論をしたことに人々が同意しているのであれば、続けるのは難しくありません。
あなたがあなたのリードを説得する必要がある場合、彼らが検討しているかもしれない何か（あなたが彼らを説得する必要があることは問題にはなりません）：
・コードの複雑さに応じて、リファクタリングの自由な統治は多くの「なぜこれが壊れたのか？」 「おお！その理由が変だとは知らなかった！」 （言い換えれば、それは理想的ではありませんが、時々、事情は彼らがどういうわけか、リードが知っている可能性があり、制御下にあり、人々が突っ込みたくない理由である）
・タスクは予想されるリードよりも長くかかる場合があるため、リードはそのために準備する必要があります（つまり、より多くの時間を費やす）
PS、これはソフトウェアエンジニアリングではなく、stackexchange WorkPlaceにあるように聞こえます
PPS、私はこれらの答えの多くは、ソフトウェアエンジニアリング全般ではなく、自分の作業環境を反映しているように思われます。あなたがコードベースを所有しているかどうかは重要です。製品が生産段階にあるかどうかは重要です。あなたの状況はこれらの答えの多くを無効にするかもしれません。
リファクタリングの経済学
リファクタリング
- 機能面には影響しません（そうでなければ、リファクタリング以上のものです）
- したがって、は機能以外の側面のみに影響します（品質属性とも呼ばれます）。
リファクタリングに関連する固有のコスト/があり、リファクタリングの利点はそのコストを上回らなければなりません。
- リファクタリングには時間がかかります、つまりお金がかかります（商用環境では）
- 機会費用：この時間は、何かより良いものに費やすことができます（機能的価値を追加するか、より早く配信するか、別の方法で品質面を改善します）
- risk ：以前の結果よりも結果が悪化したり、計画よりも時間がかかる可能性があります。したがって、リファクタリングコストに保存マージンを追加する必要があります。
利点は、期待される改善された品質の観点からも同様に定量化する必要があります（ https://en.wikipedia.org/wiki/Non-functional_requirement ）：リファクタリングは
- 将来的に時間を節約できます（したがって、お金も節約できます）（メンテナンスと新機能の迅速な追加のため）
- 品質を大幅に向上させることができる（現在または将来のクライアントが支払う）
したがって、すべてのリファクタリングについて、以下を検討してください。
- 期待されるメリットは何ですか。方法およびいつ払い戻しされますか
- 投資するまでの時間/お金とリスクの増加
悪い状況：コードはリファクタリングを必要とする可能性がありますが、そうすることの利点はわずかであり、プロジェクトの後半にあり、深刻なために継続されない修正価格のワンショットプロジェクトにいますバグの修正。
small refactorings の場合： boyscoutsルールのように、開発者自身がこれらの決定を行うことができます：コード/キャンプ場をより良い状態にしてくださいあなたがそれを見つけたよりも。
大規模なリファクタリングの場合：リファクタリングに貴重な時間を費やす前に、管理者の注意（プロジェクトリーダー）とフィードバック（ピア開発者）に強くアドバイスします。ピア開発者は、関連する入力やリファクタリングに関するアドバイス（通常は複数の方法で実行できます）を取得し、（あなたと他の両方によって）教訓を学ぶことができます。
ここではリファクタリングよりも多くの問題が見られます。
また、コードベースの計画的またはクリーンアップをさらに行うことができるかどうかを経営陣に尋ねましたが、基本的にノーと言われました。
直接のチームリーダーと話しましたか？管理は非常に広義の用語であり、20人以上のチームリーダーから会社全体のCEOまでのあらゆるもの、および他の会社の柱の管理（別名、運用またはビジネス管理）を含めることができます。 Ops/Busも同様です）。
基本的に、あなたが説得しなければならないのはあなたの直属の（ライン）マネージャーです。チームの責任者。それらを納得させることができれば、あなたは正しい道を進んでいます。誰にも通知せずに変更を適用するか、それともさらなる承認を求めるかは、彼らの決定です。また、コーディングの文化を築く責任もあります。
私はチームメンバーと1対1で会話しましたが、それらのほとんどはさまざまなコードのにおいも認識しており、嫌いです
これはあなたが実際に非常に強い基盤を持っていることを意味します。ほとんどの企業ではチームミーティングがあり、そこでコーディングプラクティス全般を改善するポイントを育てることができます。会議であなたをバックアップできるように、あなたもそれに最も関心があると思われる2〜3人の同僚と前もって話します。それはあなたの議論の立場を強化するでしょう。
引数を準備します。適切に記述されていない場合は、コードへの影響、プログラミング効率などの分析を探してください。 「技術的負債」という用語は、他の回答ですでに言及されています。これは、一般的に探す必要があるものです。
あなたやあなたの同僚/チーム全体がそれらの問題のために経験した実際の問題についても考えてください。コードが統一されていれば、時間を短縮できますか？コード統合中のエラーは少なくなりますか？
チームの全員が独自の方法でプログラムし、調整はありません。
これは、リファクタリング自体ではなく、取り組むべき主要かつ最初のことです。さらに2〜3年（せいぜい）で同じコード品質に戻る場合のリファクタリングのポイントは何ですか。実際には、リファクタリングは新しいコードを導入するよりも時間がかかるため、単に労力を浪費するだけです。最初の行で新しいコードの品質を向上させる方法の説明に焦点を当て、従うべきプラクティスに同意し、コーディングの必須部分としてコードレビューを追加して、プラクティスが確実に実行されるようにします。
言い換えれば、より多くの混乱をやめることを停止します（別名、より多くの技術的負債を取得します）。もちろん、これには常に課題があり、標準からの逸脱が生じる場合もありますが、次のプロジェクトに進む前に、各逸脱をすぐに修正する必要があります。
しかし、常にもっと重要なことがあるので、リファクタリングはめったに起こりません。
前のポイントが達成されたら、リファクタリングに移ることができます。実際には、それをコーディングプラクティスの一部としてすぐに使用できますが、標準が確定した後でのみです。
リファクタリングとは、大きな変更を1つ行うことではありません（ここでも、他の回答で既に指摘されています）。それはあなたが現在書いているものに隣接するコードの部分の継続的な改善についてです。使用しようとしているコードまたは関数の行を修正することを習慣にします。一度に1つだけ。ユニットテストを必ず行ってください（作成しない場合は、ユニットテストもリファクタリングの一部です）。
このアプローチを使用すると、リファクタリングを日常の作業に簡単に組み込むことができます。実際のコーディングのワークロードを評価するときは、それを考慮する必要があります。必要な時間を自分に与えた場合のみ、それを行うことができます。そして、あなたが本当に何をしているのかわからないので、おそらく誰も反対しません。もちろん、あなたのマネージャーが同意している限り。
これはチームの問題ではないため、チームの問題ではありません。これは経営上の問題であり、答える必要がある質問は次のとおりです。経営陣は、技術的負債とは何か、そしてなぜそれをサービスすることが重要であるかを理解していますか？さらに重要なことに彼らは気にしていますか？
ソフトウェアが主な焦点ではない大多数の企業では、経営者はソフトウェアを理解していないか、またはソフトウェアを理解することを望んでいません。これがシナリオの場合は、ソフトウェアをリファクタリングする必要がある理由（つまり、リファクタリングしないリスク）を説明するプレゼンテーションをまとめて、関連するマネージャーに売り込む必要があります。彼らはあなたと一緒に参加します、その場合、あなたはそれを徐々に導入し始めることができますか、彼らはそうしません-その場合、あなたは永遠に腐敗しているコードベースに対処し続けるか、他の場所で雇用を見つける必要があります。
ただし、リファクタリングがコアフォーカスではないソフトウェア中心のビジネスで働いている場合は、地獄から抜け出す必要があります。そのようなビジネス（そして、はい、私は1か所で働いた）は、彼らが主張するかもしれないことに関係なく、彼らの慣行を決して変更しないので、他に選択肢はありません。次のクライアントに送信されます。最低入札価格にはリファクタリング時間が含まれていません。
あなたはそれを楽しくて刺激的なことにする必要があります。それを「品質攻勢」と呼んでいます。コードアナライザーは夜間に実行され、より適切に実行できる処理のリストを生成します。これらのタスクはJiraでぶらぶらします。金曜日の午後の仕事は、タスクを取得して自分の仕事をするのに最適です。初心者は、これが1週間フルタイムで行われます。実際にJiraには、チェックインする前に誰かがタスクで気化したバグレットの数を示すテーブルがあります。その小さな塊が赤から黄色に緑に変わったら、あなたはヒーローです。
これをしばらく行った後-これらのifステートメントを結合し、この関数にコメントを付け、この未使用のコードを削除します-コーディング中にとにかくそれを行って、後で誰か他の人をトラブルから救うだけです。そして、「Lintにコード内の不満な点を見つけてほしくない」という少ししつこい考えが常にあります。
かなりのバグを誰も非難しないことが非常に重要です。下水道のネズミのように、彼らはそこにいるだけで、あなたは公益のためにその数を減らしようとしている。
多くの優れたツールのどれを使用するかは重要ではありません。1つ（おそらく30日間の試用版）を入手して、それを試してみてください。有用な出力が得られるまで、パラメーターを調整する必要があります。別のものを試してください。実際には2つの異なるものを実行しています。