チームのリファクタリングを優先する方法を教えてください。
私が毎日作業しているコードベースには、自動テスト、一貫性のない命名、「なぜここにあるのか」、「これが必要かどうかわからない」、「このメソッドの名前が正しくない」などの大量のコメントがなく、コードが散らかっていますソース管理を使用しているという事実にもかかわらず、「変更ログ」。言うまでもありませんが、コードベースではリファクタリングを使用できます。
私たちは常にバグを修正したり、新しい機能を追加したりするタスクを持っているので、コードをリファクタリングしてモジュール化するための時間を割くことはなく、優先度は高くないようです。
タスクリストに追加されるようにリファクタリングの価値を示すにはどうすればよいですか？許可ではなく許しを求めて、私が行くときにリファクタリングするだけの価値はありますか？
「許可より許しを求める方がいい」というのは本当です。
なぜそれを心配するのですか？最も恐ろしい部分をリファクタリングするだけです。
（最もコストがかかるエラーが何であるか知っていますよね？
そうでない場合、ステップ1は、最もコストがかかり、複雑で、エラーが多く、バグが蔓延している問題コードを明確かつ明確に定義することです。
トラブルチケットの数、デバッグの時間、およびその他の非常に具体的で測定可能なコストを特定します。
次に、そのリストの高コスト問題を修正します。
あなたが許しを求める必要があるとき、あなたはコスト削減を指摘することができます。
気付いていない場合は、リファクタリング必須 単位 前後の動作が一致することを証明するテスト。理想的には、これは自動化されたコード化されたテスト、たとえば単体テストである必要があります。
これは、ピックone事を意味します。単体テストを作成します。その1つを修正します。 2つの改善を行いました。 （1）テストを作成し、（2）コードを修正しました。
繰り返す。
ボーイスカウトのルールに従います。キャンプサイト（コード）を、あなたが見つけたよりも少し良い場所に置いてください。 「誰かがそこにいる間に」小さなコードの改善をするために誰かが書かれたことを一度も聞いたことがありません。
私はおそらくあまりにも皮肉な見方をします。
リファクタリングは飲み込むのが難しい薬です。あなたは責任と責任を負い、あなたの労働の成果はしばしばあなたのクリーンなコードベースで構築する他の誰かに行きます。
もしそのようなエンジニアリング慣行があなたの会社の文化になったなら、あなたはより高いレベルで戦う必要があるかもしれないと私は言うでしょう。あなたは本当にリファクタリングを求めて戦っているのではなく、エンジニアリングの卓越性を求めて戦っています。それは、彼らが顔をぶつけたときにのみ管理に気づくような変化です。そのシナリオでは、彼らはおそらくベストプラクティスのczarを探しに行くでしょう、そしてあなたのすべての素晴らしいアイデアはとにかく包含されます。
エンジニアリングの実践をより真剣に受け止めている別の会社への参加を検討してください。
ここのポスターの多くは管理上の問題を確信しているように見えますが、質問にはそれが言及されていません。
私はそれよりもさらに進んでいきます。私の意見では、お粗末なコードベースが直接管理のせいになることはほとんどありません。管理者はそのコードを記述せず、開発者が記述しました（私の会社には、現在の管理者の一部が最初のコードベースを実際に記述したいくつかの例外があります）。したがって、文化の問題は開発者にあります。文化を変更したい場合、開発者自身も変更する必要があります。
私はこの認識と態度の変化を「私の」開発者にも伝えようとしています。 「いつリファクタリングする時間はありますか？」と尋ねられると、私は驚いて「いつもリファクタリングしているはずです！」と答えます。私があなたがコードベースを健全に保つことができると私が信じる唯一の方法は3つあります：
- 正常なコードのみを追加してください。
- 正常に表示されないコードは、すぐに修正してください。
- 締め切りの理由で1または2を実行できない場合は、常に「締め切り直後に修正する」問題のリストを用意し、締め切り後にそのリストを処理しないことの言い訳は受け入れないでください。
常に開発者からの次の発言は、「しかし、これを行うにはどうすれば時間を得ることができますか-現在、時間がないのですか？」唯一の正しい答え（ここでも私見）は、「これを行う時間がない」です。コードベースの健全性を維持しないと、ターンアラウンド時間が長くなり、スケジュールが予測不可能になり、バグが悪化し、価値が低下します。
開発チームで行う必要のある最大の態度の変化は、「品質」は特定の瞬間（「リファクタリングする時間があるとき」）に行うことではなく、常に行う必要があるということです。
最後に、警告の物語。押された場合、私はこれが起こったことを否定します。私が働いていた会社で、10年以上前に大規模なレガシーコードベースを作成していた長年のアプリケーションがありました。私を含む多くの開発者は、このレガシーコードベースは最新のものではなく、悪いか、少なくとも時代遅れであると信じていました。そこで、大規模なリファクタリングプロジェクトにロビー活動を成功させ、リライトプロジェクトを開始しました。
私たちは、新しいライブラリ、新しい言語機能を使用して、ほとんどすべてを新しくモダンな方法で長くハードに実装しました。終わり近くに、私たちはすべてを統合して、新しく改良されたコードベースを備えた長年のアプリケーションの新しいリリースを可能にするために多大な努力をしました。
予想に反して、新しいライブラリにはまだ慣れていなかった新しいライブラリと、コード内で予期していなかった相互作用があったため、問題が発生しました。しかし、ようやくリリースを以前のリリースと同じ標準にしてドアを開けることができました。私たちは「成功」に安堵のため息をついた。その後、開発者のサブグループが管理に戻り、新しいリファクタリングプロジェクトを求めました。これは、私たちの新しいコードは予想していたほどの特効薬ではなかったためであり、完全に書き直す機会がいくつかありました...
物語の教訓：物事は見た目ほど壊れていないことがよくあります。「最初からやり直す」とは、通常、既知の問題のセットを、少なくとも毛並み不明の問題のセットと交換することを意味します。一度に1つのパーツをリファクタリングします！
面接に行くときは、会社にも取材していることを忘れてはいけない、と言われたことがあります。働きたい場所ですか？彼らはコードレビューをしますか？自動統合テストはありますか？ユニットテスト？彼らはペアプログラミングについてどう思いますか？個人的には別の仕事を見つけるので、今回も質問をすることをお忘れなく。
正直に別の会社を見つけてください。開発プロセスのこのような改善には、大きな文化的飛躍が必要であり、全員が同じページにアクセスするまでにはかなりの時間がかかり、それまでにそれほど気にかけることはありません。
まだ戦いが続いていて、まだ終わっていないように思われる場合は、最後のプッシュを行ってください。志を同じくするチームメンバーからできるだけ多くのサポートを得て、自分の健康を心配する上司に徹底的に説明し、自分の信念に反対する可能性のある人を遠ざけ、新しい計画にいくつかの必須のリファクタリング時間を費やそうとします。プロジェクト/機能。
あなたがあなたがしていることに情熱を持ち、あなたの会社を気にかけているなら、それはあなたの側で立派な努力になるでしょう。それが評価されていない場合は、自分を尊重して救済してから、中空のプログラマに変身してください。
このような状況で状況を改善するための1つの実践を紹介する必要がある場合、それはコードレビューになります。コードレビューは
- 一般的に、より良いコード、より少ないバグなどの要因として、開発者によって直感的に受け入れられています。
- 協力的で民主的な
- 適切にタイムボックス化すれば、時間がかかりすぎない
- 「通常の」開発中にリファクタリングを行う時間がない場合に適した場所
- コード設計、ユニットテストの観点からあらゆる種類のベストプラクティスを徐々に導入するかなり効果的なトロイの木馬...
最初に大規模/複雑なコード部分をコミットする場合にのみ、体系的にコードレビューを行う必要はありません。
もちろん、コードレビューを導入する前に公式の承認が必要だと感じた場合は、まず上司に、現状のままにしておくとコードベースが崩壊する可能性があることを納得させる必要があるかもしれません。
これが私がそのような状況で行うことです（開発者としての私のキャリアの15年間で、私はそのようなコードにほぼ毎日出会ってきました）。
- 模範を示す-私が触れるコードは必ずリファクタリングしてください。古いコメントアウトされたコードとコメントの大きな段落を容赦なく削除します。
- コードの変更を確認するように求められるたびにリファクタリングを要求します。これを行わないと、コードレビューを承認しません。
- コードがスリムになり、読みやすくなり、バグが少なくなると、ゆっくりと変化がわかります。時間はかかりますが、ゆっくりとチーム全体がこの練習を評価し、採用します。
管理者はコードをリファクタリングするための時間を確保することはありません（十分なリソースがないためです！）。そのため、ゆっくりと着実にそれを行うことは正しいアプローチです。
経営陣に「技術的負債」に関する調査を行わせる。 「ブロークンウィンドウ理論」も参照してください。これらの効果はどちらも効率、品質、士気に直接影響します。
「クリーンな作業現場は安全で生産的な作業現場」であり、混乱へのあらゆる貢献は、線形的なものではなく、指数的な方法で混乱を悪化させます。
状況が処理されない場合、最終的には利益が反発する前に段階的に処理することにより、経済的に実行不可能になるポイントを越えて戻り、利益が回復し、問題に対処するためにより多くの燃料を提供します。
あなたの問題はより一般的なようです。
リファクタリングの問題は症状であり、問題の一部からの潜在的な救済です。
ソフトウェアリーダーとチームがチームの時間を割り当てます
私の経験から、私は「誰もがソフトウェアマネージャーです」と呼ぶ問題に直面していると思います。プロダクトマネージャー、プロジェクトマネージャー、および場合によってはシステムエンジニアやテスターは、おそらくすでに経験豊富なソフトウェアマネージャーがいる開発者をマイクロ管理しようとすることで悪名高くなります。あなたのチームには、彼らの役割が管理することであると信じている数人のメンバーがいるかもしれません。
あなたがソフトウェアマネージャーである場合は、必要なリファクタリングの割り当てを行うか、またはさらに良いことに、承認を得るためにチームにリファクタリングを提案してもらいます。マイクロマネージメントではないため、リファクタリングするコードの年齢/作成者/サイズ/コンテキストに関するガイドラインがあり、自由にリファクタリングできる場合と、承認が必要な場合があります。チームのメンバーが、自分の書いたものではない、彼の機能の一部ではない4つの大きなクラスの複雑な古いコードを大規模にリファクタリングしたい場合、2週間の転換が問題なので、ノーと言う機会が必要です。
回り込むことはできますが、分析、設計、コーディング、複数の形式のテスト（少なくともユニットと統合）、リファクタリング、および歴史的に判断されたリスクと、タスクに関連する経験または明快さ。チームの働きにあまりにもオープンである（またはチームにメンバーがいる）場合は、コミュニケーションチャネルを狭めて、メソッドではなくリソースと結果について話し合うのが賢明かもしれません。
初期のプロジェクト選択はリファクタリングのための悪循環を作り出します
ソフトウェアのメンテナンスは大変です。組織内の他の人があなたの費用で選択をしている場合、それは二重に困難です。これは間違っていますが、新しいことではありません。これは、彼がTheory Wとして説明する管理モデルを提案する、優れたソフトウェアライターの1人であるバリーベームによって取り上げられました。
http://csse.usc.edu/csse/TECHRPTS/1989/usccse89-500/usccse89-500.pdf
多くの場合、ソフトウェア開発者は、労働者は基本的に怠惰であり、提出に強打されない限り機能しないと言うTheory-X管理アプローチのもとで生産するように仕込まれます。ベームは彼の提案されたモデルを以下のように要約して対比します：
「マネージャーを独裁者（理論X）、コーチ（理論Y）、またはファシリテーター（理論Z）として特徴付けるのではなく、理論Wはマネージャーの主要な役割を、さまざまな支持者とプロジェクトソリューションのパッケージャーとの間の交渉者として特徴付けます。さらに、マネージャーは目標設定者であり、目標に向けた進捗状況のモニターであり、日々の勝敗のプロジェクトの競合を見つけて直面する活動家でもあります。そしてそれらを双方にとって有利な状況に変える。」
迅速で汚いことはしばしばただ汚い
ベームはさらに、メンテナンスチームの開発者にとって物事が悲惨である理由を指摘します。
「手早くずさんな製品を作ることは、ソフトウェア開発者と顧客にとって低コストで短期的には「勝つ」かもしれませんが、ユーザーとメンテナにとっては「失う」ことになるでしょう。」ベームのモデルでは、顧客はエンドユーザーではなく契約管理者であることに注意してください。ほとんどの企業では、製品マネージャーを顧客の代理人、またはおそらく機能リストの製品を購入する人と考えます。
私の解決策は、コードが少なくともコーディング標準を満たすようにリファクタリングされるまで、元の開発チーム（または少なくとも元のリード）をリリースしないことです。
顧客にとっては、製品マネージャーを顧客代理として数えることは合理的だと思います。迅速かつ汚いものを提供することに対して報酬を与えられる人々のグループは確かに拡大することができるので、物事を間違って行うための大きな支持者がいます。
リファクタリングは交渉可能ではありません
ソフトウェアマネージャーとしてのあなたの役割から後退しないでください。チームのプロセスと製品の改善に時間を費やすには、権限と裁量権が必要です。その役割では、チームをより専門的にするために選択を交渉する必要があるかもしれません。ただし、プロセスに関しては、マーケティングと交渉しないでください。私の経験では、それは負けゲームです。エンジニアリング管理と交渉します。それはあなたがビジョンを持っていることを示しています。プロのソフトウェアチームを構築することは、彼らの役割の延長であり、双方にとって有利なものと見なされる可能性がはるかに高くなります。
あなたはいつでもそれを待つことができます。結局、チームは十分な期限を逃し、バグの多い十分なソフトウェアを作成します。そのため、経営陣は手を挙げて、神様の言うsomethingの方が良い変更があったと言います。
さて、それは危険な命題です。しかし、それは実際に数年前に当店で起こったことであり（困難の一部は経営者とのコミュニケーションにありましたabout締め切りですが、それは別の話です）、今や私たちが数万人になっている理由の多くは自動テスト、共有コードの所有権、リファクタリングの自由、不要なコードを削除する意欲、これまでにない最高品質のリリース。
おそらく最も驚くべきことに、その過程で誰も仕事を失いませんでした-私たちの上司、そして私たちのためにリファクタリングと継続的統合の主張を主張したコンサルタントに私が貢献したことを私は信じています。外から誰かがそれを言っているとき、それは常により説得力があるように聞こえます。
時間を見つける方法への答えは、なぜコードをリファクタリングしたいかによります。
それが機能する場合、特別なリファクタリングの必要はなく、コードのその部分に触れるときにそれを行うことができます。したがって、そのための特別な時間は必要ありません。
チームの開発が遅れる場合は、チームリーダーと話し合い、リファクタリングのための特別なタスクを作成する必要があります。
実行速度やその他の場合も同じですが、リファクタリングによって何かが改善され、「見栄えのよいコード」やユーザーの意見だけでなく、コードがどのようになり、実際のメリットが得られるか、タスクを作成するか、その責任者と話し合うことができます。
コードは、多くの小さな変更でゆっくりとこのようになりました。その方法でも修正する必要があります。
最初に、これを行うことができます。まず、すべての見積もりを10％増やして、コードの拡張と長期的なメンテナンスを可能にします。誰かが不平を言うなら、毎週自動車のエンジンのオイルをチェックするほうが良いのか、それともエンジンが完全にロックするまで待つのが良いのか尋ねます。
ミーティングを行い、一貫したコーディング標準を決定します。
進むにつれて使用する基本的なルールを紹介します。
新しいコードがクラスに導入されるときはいつでも、クラスが機能することを証明するために、自動テストを作成する必要があります（新しいコードだけではありません）。
バグが修正された場合は常に、クラスが機能することを証明するために、自動テストを作成する必要があります（修正されたコードだけではありません）。
プログラマーがファイルを変更するときはいつでも、そのファイルのすべてのコンパイラー警告を修正し、コードを更新して、新しいコーディング基準を満たす必要があります。
しばらくすると、最も使用されるコードが最新になり、自動テストの対象になります。古いコードは、変更されると更新されます。変更されない場合は、心配する必要はありません。
重要なことは、これらのハビを標準のコーディングタスクに組み込むことです。これにより、「実際の」作業から膨大な時間を費やすことはできませんが、すべて実際の利点を提供します。古いコードをリファクタリングしてプロジェクトを作ろうとしないでください。それは、技術者ではない多くの時間を浪費しているように見える、恐ろしく、退屈で手間のかかる痛みです。
私が取り組んでいるコードベースとかなり似ているように聞こえるので、私はあなたが物事を説明する方法を少し笑ったので、私たちの状況はかなり似ていると思います。幸いなことに、私の状況では、コードベース全体をリファクタリングするのではなく、最新のWeb開発フレームワークを使用してモジュール化することによってコードベースを改善する最善の方法を決定する前向きなマネージャーがいます。このようにして、メインアプリケーションの問題のある部分を個別のモジュールとして書き直し、メインアプリに統合できます（ただし、本質的には独立しています）。これは、作業している（おそらく大きい？）コードベース全体をリファクタリングする必要がないので、あなたが持ち出したいアプローチかもしれません。
もちろん、私があなたの言っていることから少し離れているかもしれません。おそらくあなたのコードベースは私が扱うものほど悪くはないのです。その場合、私はあなたが進むにつれて少し最適化をしないのはなぜでしょうか？私のチームの開発者は、愚かなコメントや古いコメントやその性質のものを削除しても問題ありません。通常、開発者には必要に応じて最適化する権限が与えられているため、管理者からの入力を必要とするものではありません。
コードベースが本当に壊れやすい場合は注意する必要があります。これは、彼らが大規模なリファクタリングを追求したくない理由になる可能性があります。プロジェクトを実施し、顧客を失う可能性があるバグの即時修正など、他の開発タスクを排除する
考えるべきすべてのこと、他の人があなたがやめるべきだと言っている限り、私はそれが経営者がどのように見ているかに依存していると思います作業環境としては、しかし、もし彼らが絶えずあなたの仕事のバックログについてあなたに取り掛かっているなら、それは時間とともに有害になるかもしれません。基本的にアプリケーションががらくたであることに気づく経営者がいることは幸運ですが、それは多くの顧客を抱えており、お金をもたらします。そのため、たとえ短期的であっても、バグ修正を行う価値はあります。 。
あなたの主な問題は、コードが十分な可視性を得ていないことです。
Jenkins のような継続的インテグレーションツールと、それに統合されて、循環的複雑度、命名基準、コード長などを測定する静的コード分析ツールを使用することをお勧めします。
プログラマーが変更をコミットすると、Jenkinsはユニットテストを実行し、静的コード分析ツールを実行して、誰もが見ることができるWebレポートを信号のような色のステータスで生成します。
コードの品質がすべての人（特にチームのライダーとボス）に見えるようになり、バージョン管理とユニットテストが利用できるようになると、人々はリファクタリングするように促されます。
不思議なことに誰もこれについて言及していません：
物事を優先させるには、簡単にする：優れたリファクタリングツールを入手してください。
そこには優れたリファクタリングツールがあります（少なくとも.NET Afaikの場合）。ああ、そして事前に単体テストを書くことを忘れないでください（他の人がすでに指摘したように）。
幸運を！
必要なリソース（時間）を取得する方法は、能力と欲求の調整に集中することです。あなたの上司は目標（通常、新機能の利益または納期）によって動かされ、エンジニアは時間を浪費してそれらの目標に食い込むエンジニアとしてリファクタリングを考えています。リファクタリングに時間を費やした場合、目標が達成され、超えられることを彼に納得させる方法を見つける必要があります。
だから最初のステップはあなたの上司が感じている痛みを見つけることです。彼の最大の問題は何かを特定します。次に、あなたがしたいことが彼の問題の修正とどのように一致するかを考え出し、それを行うための強力なビジネスケースを提示します。欠陥追跡およびプロジェクト計画システム（時間超過）を使用して、問題がどこにあるかを示す証拠を提供します。感情ではなく事実が必要です。メトリクス（バグ数/モジュール、これらを修正するためのコスト）がない場合、リファクタリングはプログラマーが誰かの負担でプレイするだけです。上司は、それを行うための強力なビジネスケースを提示できる場合にのみ、必要なリソースを提供します。
がらくたコードは、修正するのにあまりにも高額であることが多いです。自動回帰テストがないため、リファクタリングされたコードをテストするコストは非常に高くなります。
ほとんどの場合、実際にリファクタリングを必要とする不良コードを見てきましたが、文書化されていない機能が多数あり、要件には最初から理解できない複雑さがありました。それはマイナーな仕事ではなく、私の経験は、新しい機能を追加するよりもリファクタリングジョブのコストを見積もるのが桁違いに難しいです。
私は先に進み、あなたの上司の後ろでそれをすることを控えます（それが壊れていなかった、そしてあなたがそれを壊した場合、それはどのように見えますか）-とにかく変更が必要なコードを修正しますが、壊れていなければ、 t修正する。