リファクタリングをチームの優先事項にするにはどうすればよいですか？

私が毎日使用しているコードベースには、自動テスト、一貫性のない命名、「なぜこれが必要なのか」、「これが必要かどうかわからない」、「このメソッドに正しい名前が付けられていない」などの大量のコメントがなく、コードが散らかっていますソース管理を使用しているにもかかわらず、「変更ログ」。私たちのコードベースはリファクタリングを使用できると言えば十分です。

バグを修正したり、新しい機能を追加したりするタスクは常にあるため、コードをリファクタリングしてよりモジュール化するための時間は確保されておらず、優先度は高くないと思われます。

タスクリストに追加されるようなリファクタリングの価値をどのように実証できますか？許可ではなく許しを求めて、リファクタリングするだけの価値はありますか？

「許可よりも許しを求める方が良い」というのは本当です。

なぜそれを心配するのですか？最も恐ろしい部分をリファクタリングするだけです。

最もコストのかかるエラーが何であるかを既に知っていますか？

そうでない場合、ステップ1は、最もコストがかかり、複雑で、エラーが発生し、バグが発生した問題コードを明確かつ明確に定義することです。

トラブルチケットの数、デバッグの時間、その他の非常に具体的で非常に測定可能なコストを特定します。

次に、高コスト問題のリストにある何かを修正します。

あなたが許しを求めなければならないとき、あなたはコスト削減を指すことができます。

あなたが気づいていない場合には、リファクタリングが必要と ユニットの前と後の行動が一致することを証明するためのテストを。理想的には、これは自動化されたコード化されたテスト、たとえば単体テストである必要があります。

これは、1つ選択することを意味します。単体テストを作成します。その1つを修正します。2つの改善を行いました。（1）テストを作成し、（2）コードを修正しました。

繰り返します。

ボーイスカウトのルールに従ってください：キャンプ場（コード）は、あなたが見つけたよりも少しだけ良くしてください。「誰かがそこにいた間に」小さなコードの改善をしたことで誰かが書かれたと聞いたことは一度もありません。

多分過度にシニカルな見方をします。

リファクタリングは飲み込むのが難しい薬です。あなたは責任と非難を受け、あなたの労働の成果はしばしばあなたのきれいなコードベースに基づいて構築する他の誰かに行きます。

そのようなエンジニアリングの実践があなたの会社の文化になった場合、より高いレベルで戦う必要があるかもしれません。あなたは本当にリファクタリングのために戦っているのではなく、卓越したエンジニアリングのために戦っているのです。それは、彼らが顔を叩いたときに経営陣にのみ現れる変化のようなものです。そのシナリオでは、彼らはおそらくベストプラクティスを求めて外を見るでしょう。そして、あなたの素晴らしいアイデアはすべてとにかく包摂されます。

別の会社に参加して、エンジニアリングの実践をより真剣に考えてみてください。

ここのポスターの多くは、管理の問題を確信しているように見えますが、質問ではそれについて言及していません。

私はそれよりもさらに先に進みます：私の意見では、お粗末なコードベースは直接管理のせいではありません。開発者は、管理者がそのコードを作成しませんでした（私の会社には、現在の管理者の一部が実際に最初のコードベースを作成したいくつかの例外があります）。したがって、文化の問題は開発者にあります-文化を変更したい場合、開発者自身が変更する必要があります。

私もこの認識と態度の変化を「私の」開発者に伝えようとしています。「いつリファクタリングする時間がありますか？」と尋ねられるたびに、私は驚いて行動し、「すでにリファクタリングしているはずです！」と答えます。コードベースを健全に保つことができる唯一の方法は、次の3つです。

1. 正常なコードのみを追加してください。
2. 正常ではないコードは、表示されたらすぐに修正してください。
3. 締め切りの理由で1または2を実行できない場合は、常に「締め切り直後に修正」問題のリストを用意し、締め切り後にそのリストを処理しないという言い訳を受け入れないでください。

開発者からの次の発言は、常に「しかし、どうすればこれを行うための時間を得ることができますか-今は時間がありませんか？」です。唯一の正しい答えは（再び私見）、「あなたはこれをしない時間がない」です。コードベースの健全性を維持しないと、ターンアラウンドタイムがますます長くなり、スケジュールが予測不能になり、バグが悪化し、価値が低くなります。

開発チームで行う必要がある最大の態度の変化は、「品質」は特定の瞬間（「リファクタリングする時間があるとき」）に行うことではなく、常に行う必要があることです。

最後に、警告の物語。押された場合、私はこれが起こったことを否定します。私が働いていた会社には、10年以上前に作成された大規模なレガシーコードベースを持つ、長年にわたるアプリケーションがありました。私を含む多くの開発者は、このレガシーコードベースが最新のものではなく、悪いか少なくとも時代遅れであると信じていました。そのため、大きなリファクタリングプロジェクトに向けてロビー活動を成功させ、リライトプロジェクトを開始しました。その後、すべてが改善されると考えました。
私たちは、新しいライブラリ、新しい言語機能を使用して、ほぼすべてを新しくモダンな方法で長く一生懸命実装しました。終わり近くに、私たちは、新しく改良されたコードベースを備えた長年のアプリケーションの新しいリリースを可能にするために、すべてを統合するために多大な努力をしました。
予想どおり、新しいリリースには、まだあまり馴染みのない新しいライブラリと、予測していなかったコードの相互作用のために、いくつかの歯が生える問題がありました。しかし、最終的にはリリースを以前のリリースと同じ標準に到達させ、公開しました。「成功」に安reliefのため息をつきました。その後、開発者のサブグループが管理に戻り、新しいリファクタリングプロジェクトを求めました。これは、新しいコードが期待していたように銀の弾丸ではなかったためです。

物語の教訓：物事は見た目ほど壊れていないことが多く、「やり直す」ことは通常、既知の問題を少なくとも毛のない未知の問題と交換することを意味します。一度に1つの部分をリファクタリングします！

かつて誰かが私にインタビューに行ったとき、私も会社にインタビューしていることを忘れてはならないと言った。働きたい場所ですか？彼らはコードレビューをしますか？自動化された統合テストはありますか？ユニットテスト？彼らはペアプログラミングについてどう思いますか？個人的に私は別の仕事を見つけるだろうし、今回もいくつか質問をすることを忘れないでください。

正直に別の会社を見つけてください。このような開発プロセスの改善には、文化的な飛躍的な進歩が必要であり、全員が同じページにアクセスするまでにかなりの時間がかかり、それまではあまり気にしません。

あなたはまだあなたの中にいくつかの戦いがあり、まだ下がっていないように感じるなら、最後のプッシュをしてください。志を同じくするチームメンバーからできるだけ多くのサポートを得て、あなたの幸福、アウトライトバイパスを気にする上司にあなたの疲労を開示し、あなたの信念に反対する可能性のある人を遠ざけ、新しいリファクタリング時間を押して新しい計画を立てましょうプロジェクト/機能。

あなたがあなたの仕事に情熱を傾け、あなたの会社を気遣うなら、それはあなたの側で立派な努力になるでしょう。それが高く評価されていない場合は、虚ろなプログラマーになる前に、自分自身を尊重し、救済してください。

この種のコンテキストで物事を改善するために1つのプラクティスを導入する必要がある場合、それはコードレビューになります。コードレビューは

• 一般的に、コードの改善、バグの減少などの要因として開発者に直感的に受け入れられています。
• 協調的かつ民主的
• 適切にタイムボックスを設定すれば、それほど時間はかかりません
• 「通常の」開発中にリファクタリングを行う時間がなければ、リファクタリングを行うのに適した場所
• コード設計、ユニットテストの観点からあらゆる種類のベストプラクティスを徐々に導入する非常に効果的なトロイの木馬

最初に大規模/複雑なコード部分をコミットする場合にのみ、体系的にコードレビューを行う必要はありません。

もちろん、コードレビューを導入する前に公式の承認が必要だと感じた場合は、まず上司に、物事がそのままになっているとコードベースが崩壊する可能性があることを納得させる必要があります。

このような状況で私がやることは次のとおりです（開発者としての私のキャリアの15年間で、ほぼ毎日このようなコードに出くわしました）

1. 例でリード-触れたコードをリファクタリングします。古いコメントアウトされたコードとコメントの大きな段落を容赦なく削除します。
2. コードの変更を確認するように求められるたびにリファクタリングを要求します。これがないと、コードのレビューを承認しません。
3. コードがよりスリムになり、読みやすくなり、バグが少なくなると、人々はゆっくりと変化を見るようになります。時間がかかりますが、ゆっくりとチーム全体がこのプラクティスを評価し、採用します。

管理者はコードをリファクタリングする時間を確保しません（十分なリソースがありません！）。したがって、ゆっくりと着実にそれを行うことは正しいアプローチです。

経営者に「技術的負債」に関する調査をしてもらいます。また、「壊れたウィンドウ理論」も参照してください。これらの両方の効果は、効率、品質、および士気に直接影響します。

「清潔な職場は安全で生産的な職場」であり、混乱へのすべての貢献は、直線的なものではなく指数関数的に混乱を悪化させます。

状況が対処されない場合、最終的には利益の反発が起こる前に段階的に対処することにより、経済的に実行不可能になるノーリターンのポイントを通過し、問題に対処するためのより多くの燃料を与えます。

あなたの問題はもっと一般的だと思われます。
リファクタリングの問題は、症状であると同時に、問題の一部が軽減される可能性もあります。

ソフトウェアリードとチームがチームの時間を割り当てます

私の経験から、あなたは私が「誰もがソフトウェア管理者だ」と呼ぶ問題に遭遇していると思います。製品マネージャ、プロジェクトマネージャ、および場合によってはシステムエンジニアやテスターは、おそらく経験豊富なソフトウェアマネージャを既に持っている開発者をマイクロ管理しようとすることで有名です。自分の役割は管理することだと信じているチームのメンバーが数人いることさえあります。

あなたがソフトウェアマネージャーである場合は、希望するリファクタリングの割り当てを行うか、さらに良いことに、チームに承認のためにリファクタリングを提案してもらいます。マイクロ管理を行わないために、リファクタリングするコードの年齢/作成者/サイズ/コンテキストに関するガイドラインがあり、自由にリファクタリングできる場合と承認が必要な場合があります。チームのメンバーが、自分の書いた機能ではない複雑な古いコードの4つの大きなクラスを大量にリファクタリングしたい場合、彼の2週間の転用が問題なので、ノーと言う機会が必要です。

忍び寄ることはできますが、分析、設計、コーディング、複数の形式のテスト（少なくともユニットと統合）、リファクタリング、および歴史的に、そしてタスクに関連する経験または明確さ。チームの働きについてあまりにもオープンである（またはチームのメンバーがいる）場合は、コミュニケーションチャネルを絞り込んで、方法ではなくリソースや結果について話し合うのが賢明かもしれません。

初期のプロジェクト選択により、リファクタリングの悪循環が生じる

ソフトウェアのメンテナンスは大変です。組織内の他の人があなたの費用で選択を行っている場合、それは二重に困難です。これは間違っていますが、新しいものではありません。これは、Theory Wとして説明する管理モデルを提唱する優れたソフトウェアライターの1人であるBarry Boehmによって対処されました。

http://csse.usc.edu/csse/TECHRPTS/1989/usccse89-500/usccse89-500.pdf

多くの場合、ソフトウェア開発者は、労働者は基本的に怠け者であり、提出に打ち込まれない限り実行しないと述べているTheory-X管理アプローチに基づいて作成するようにhammerられます。Boehmは、提案されたモデルを次のように要約して対比します。

「マネジャーを独裁者（理論X）、コーチ（理論Y）、またはファシリテーター（理論Z）として特徴付けるのではなく、セオリーWは、マネージャーのさまざまな支持者とプロジェクトソリューションのパッケージャーとの間の交渉者としてのマネージャーの主な役割を特徴付けますさらに、マネージャーは目標設定者であり、目標に向けた進捗状況のモニターであり、日々の勝ち負けまたは負け負けのプロジェクトの対立を探し出し、それらに立ち向かう活動家です。それらをwin-winの状況に変更します。」

迅速で汚いのはしばしばただの汚い

Boehmは、メンテナンスチームの開発者にとって物事が非常に悲惨な理由を指摘し続けています。

「迅速でずさんな製品を構築することは、ソフトウェア開発者と顧客にとっては低コストで短期的な「勝ち」かもしれませんが、ユーザーとメンテナーにとっては「負け」になります。」Boehmのモデルでは、顧客はエンドユーザーではなく契約管理者に近いことに注意してください。ほとんどの企業では、製品マネージャーを顧客の代理人、またはおそらくその機能リストのために製品を購入する人と考えてください。

私の解決策は、コードが少なくともコーディング標準を満たすようにリファクタリングされるまで、元の開発チーム（または少なくとも元のリード）をリリースしないことです。

顧客にとっては、製品マネージャーを顧客の代理として数えることは合理的だと思います。迅速で汚れたものを提供したことで報われる人々のグループは確実に拡大することができます。

リファクタリングは交渉できません

ソフトウェアマネージャーとしての役割を引き下げないでください。プロセスと製品の改善にチームの時間を使用する権限と裁量権が必要です。その役割では、チームをより専門的にするために選択を交渉する必要があるかもしれません。ただし、プロセスに関しては、マーケティングと交渉しないでください。私の経験では、それは負けゲームです。エンジニアリング管理と交渉します。ビジョンがあることを示しています。プロのソフトウェアチームを構築することは、彼らの役割の延長であり、Win-Winと見なされる可能性がはるかに高いです。

いつでも待つことができます。最終的に、チームは十分な期限を逃し、バグの多いソフトウェアを作成します。その管理者は手を挙げて、神によって何か良い変化があったと言います！

さて、それは危険な命題です。しかし、実際には数年前に私たちの店で起こったことであり（難しさの一部は期限に関する管理者とのコミュニケーションでしたが、それは別の話です）、私たちが現在何万もの自動テスト、共有コードの所有権、リファクタリングの自由、デッドコードを削除する意欲、これまでにない最高品質のリリース。

おそらく最も驚くべきことには、その過程で誰も仕事を失いませんでした-私たちの上司が私たちのためにやって来たと信じているもの、そして私たちに代わってリファクタリングと継続的な統合のケースを主張したコンサルタント。外部の誰かがそれを言っているとき、それは常により説得力があるように聞こえます。

時間を見つける方法への答えは、コードをリファクタリングする理由に依存すると思います。

それが機能する場合、特別なリファクタリングの必要はなく、コードのその部分に触れるときにそれを行うことができます。そのため、特別な時間は必要ありません。

チームの開発が遅くなる場合は、チームリーダーにそのことについて話し、リファクタリングのための特別なタスクを作成する必要があり、時間があることになります。

実行速度やその他の場合も同じです。リファクタリングにより、「見栄えの良いコード」やコードの見方だけでなく、コードの外観だけでなく、何かを改善でき、真のメリットを提供したり、タスクを作成したり、その責任者と話したりできます。

私が取り組んでいるコードベースにかなり似ているように聞こえるので、あなたが物事を説明する方法を少し笑ったので、私たちの状況はかなり似ていると思います。幸いなことに、私の状況では、コードベース全体をリファクタリングするのではなく、最新のWeb開発フレームワークを使用してモジュール化することで、コードベースを改善する最良の方法を決定した先進的なマネージャーがいます。このようにして、メインアプリケーションの面倒な箇所を個別のモジュールとして書き直して、メインアプリに統合できます（ただし、本質的に独立しています）。これは、作業している（おそらく大規模な？）コードベース全体をリファクタリングする必要がないため、提起したいアプローチかもしれません。

もちろん、おそらくあなたのコードベースは私が作業しているものほど悪くないので、私はあなたが言っていることから少し離れているかもしれません。その場合、あなたが進むにつれて少し最適化しないのはなぜでしょうか？私のチームの開発者は、馬鹿げたコメントや古いコメントやその性質のものを削除しても問題はありません。通常、開発者には必要に応じて最適化する権限が与えられるため、管理者からの入力が必要になるとは思いません。

コードベースが本当に壊れやすい場合は注意する必要があり、これが大きなリファクタリングを追求したくない理由になる可能性があります。これは最終的に数ヶ月のプロジェクトになり、プロジェクトの分岐と開発者の配置が必要になる可能性があるためですプロジェクトを作成し、顧客を失う可能性のある即時のバグ修正など、他の開発タスクから除外する

他の人があなたがやめるべきだと言っている限り、すべてのものが考慮されます。状況を理解し、なぜあるものが彼らが最適に必要以上に時間がかかるかもしれないかを理解するならば、それは経営者が物事をどのように見るかに依存すると思います作業環境に限りますが、彼らが作業の滞りについて絶えずあなたに近づいているなら、それは時間とともに有害になる可能性があります。私は、アプリケーションが基本的にはがらくたであることに基本的に気付く管理者がいることを幸運に思っていますが、それは多くの顧客を持ち、お金を持ち込むので、短期的であってもバグ修正を行う価値があり、価値があります。

あなたの主な問題は、コードが十分な可視性を得ていないことです。

Jenkinsのような継続的統合ツールと、循環的複雑度、命名基準、コード長などを測定する静的コードアナリシスツールを使用して提案します。

プログラマーが変更をコミットすると、ジェンキンスはユニットテストを実行し、その上で静的コードアナリシスツールを実行し、交通信号のような色の状態で誰もが見ることができるWebレポートを生成します。

コードの品質が全員（特にチームのライダーとボス）に見えるようになり、バージョン管理と単体テストがあなたの背中を得るためにあるとき...人々はリファクタリングすることを奨励されていると感じます。

コードは、多くの小さな変更でゆっくりとこのようになりました。その方法も修正する必要があります。

まず、これを行うことができます-すべての見積もりを10％増やして、コードの強化と長期的なメンテナンスを可能にします。苦情があれば、車のエンジンのオイルを毎週チェックするか、エンジンが完全にロックするまで待つかどうかを尋ねます。

会議を開き、一貫したコーディング標準を決定します。

進むにつれて使用する基本的なルールを紹介します。

クラスに新しいコードが導入されるたびに、クラスが機能することを証明するために自動テストを作成する必要があります（新しいコードだけでなく）。

バグが修正されるたびに、クラスが機能することを証明するために、自動化されたテストを作成する必要があります（修正されたコードだけでなく）。

プログラマーがファイルを変更するたびに、そのファイル内のすべてのコンパイラー警告を修正し、新しいコーディング標準を満たすようにコードを更新する必要があります。

しばらくすると、最も使用されるコードが最新になり、自動テストの対象になります。古いコードは、変更されると更新されます。変更されない場合、心配する必要はありません。

重要なのは、これらのハビットを標準のコーディングタスクに組み込むことです。これにより、これらのハビットが「実際の」作業から膨大な時間をかけずに、どれも本当のメリットをもたらします。古いコードをリファクタリングしてプロジェクトを作成しようとしないでください。それは、技術者以外の人に多くの時間を浪費するように見える恐ろしく退屈で厄介な痛みです！

必要なリソース（時間）を取得する方法は、能力と欲求の調整に集中することです。上司はターゲット（通常は新機能の利益や納期）に左右され、エンジニアは時間を無駄にしてそれらのターゲットに食い込んでいるとリファクタリングを考えています。リファクタリングに時間を費やすと、ターゲットが満たされ、超えられることを彼に納得させる方法を見つける必要があります。

最初のステップは、上司がどのような痛みを感じているかを調べることです。彼の最大の問題を特定します。次に、あなたがやりたいことを彼の問題の解決とどのように連携させるかを考え、それを行うための強力なビジネスケースを提示します。欠陥追跡およびプロジェクト計画システム（時間超過）を使用して、問題の所在の証拠を提供します。感情ではなく、事実が必要です。メトリック（バグカウント/モジュール、これらを修正するためのコスト）がなければ、リファクタリングは、プログラマーが誰かの費用で遊びをするだけです。上司は、それを行うための強力なビジネスケースを示すことができる場合にのみ、必要なリソースを提供します。

がらくたコードは、修正するにはあまりにも高価ではありません。自動回帰テストがないため、リファクタリングされたコードをテストするコストは非常に高くなります。

ほとんどの場合、リファクタリングを実際に必要とする悪いコードを見てきましたが、文書化されていない機能が多数あり、最初から理解できない要件が複雑でした。それはささいな仕事ではなく、私の経験では、リファクタリングジョブのコストを推定するのは、新しい機能を追加するよりも桁違いに困難です。

私は先に行くことをやめ、ボスの後ろにそれをすることを控えます（壊れていない場合、あなたがそれを壊したなら、それはどのように見えますか）-とにかく変更する必要があるコードを修正しますが、壊れていない場合はしないでください修正します。

奇妙なことに、誰もこれに言及していません。

物事を優先するために、それらを簡単にします：優れたリファクタリングツールを入手します。

（少なくとも.NET afaikには）優れたリファクタリングツールがあります。ああ、事前に単体テストを書くことを忘れないでください（他の人がすでに指摘したように）。

幸運を！