コードをクリーンアップするために定期的な時間をスケジュールすることは良い考えですか？
私は小さな開発者チームを管理しています。たまに、コードのクリーンアップに1日か2日を費やすことにします。
コードベースをクリーンアップするために、定期的な時間、たとえば2か月ごとに1週間をスケジュールするのは良い考えでしょうか？
番号。
作業中に修正します。
- 作業中のビットをリファクタリングするのを待つと、多くのことを忘れてしまい、再びそれに慣れるために時間を費やす必要があります。
- 要件が変更されたために最終的に使用されない「ゴールドメッキ」コードにならない
私の個人的な意見：プロジェクトの90％では絶対に必要ですです。
特に売上に大きく左右されるプロジェクトの場合、通常、すべてのリリースに新機能を組み込むことへの大きなプッシュがあり、必然的に、より良い本能に妥協し、あちこちにいくつかの行き当たりばったりハックを導入する必要があります。
最終的には、これらの小さな妥協を通じて十分な「技術的負債」が発生し、コードベースの欠陥を回避するためにかなりの時間を費やしてしまい、その潜在能力を完全に活用することができなくなります。
通常、この方法で生成される問題には2つのタイプがあります。
- 簡単に修正できるが全身性の可能性がある小さなもの、例えば不適切に名前が付けられたパラメータ、不完全なエラー処理など。通常、それらは、それらが出現するコードブロックの外側にはほとんど影響を与えません。これらに対処する最良の方法は、コードのレビューと、コードの作成/変更時にコードをチェックすることです。他の人が述べたように、これらのエラーを修正するために特別なリファクタリングサイクルを確保する必要はありません。
- 仕様が不完全だったり、設計の決定が不十分だったために生じた大きな問題、または同じ問題に対して2つの異なるソリューションを作成した2人の開発者/チーム。これらは一般に修正がはるかに困難であり、修正するには協調した努力が必要です。その結果、それらは通常の迷惑になるまで、通常は延期されます。これらの種類の問題を修正するには、専用の期間が必要です。
私は通常、3〜4サイクルごとに純粋なリファクタリング/バグ修正サイクルのために時間を確保しようとしています。私は常に、開発者に、コードベースにも不満を感じたときに教えてくれるよう頼んでいます。すべての開発者がクリーンアップ作業に取り組む必要があるわけではありません。通常は（常にではありませんが）チームを少しずらすことができるため、常に1つのチームだけがクリーンアップに取り組んでいます。
私の開発者は、チェックイン（Subversion）またはメインの開発ブランチ（Git）とマージする前に、コードを整頓しています。
私は彼らに以下を行わせます：
- 無関係なコメントを削除する
- メソッド、引数、変数に適切な名前が付けられていることを確認してください
- それらのクラスに構造があることを確認し、必要に応じてアイテムをカプセル化します
- 読みやすさを改善し、すべてを減らすためにリファクタリング コードのにおい
大規模なプロジェクトの場合、開発ブランチからメインブランチにマージする前に、コードが正式にレビューされます。
「献身的な時間」とは、延期されたり、関与する仕事の量によって延期されたりする可能性があることを意味すると思います。開発者にチェックインごとに（JIRAの変更要求/問題に相当）実行させることで、はるかに管理しやすくなります。
私の意見ではありません。テクノロジーの負債に遭遇してからそれを修正するまでの間に時間をかけすぎると、問題の内容のコンテキストが失われます。修正には時間がかかり、修正が悪化する傾向があります。最も重要なことは、「クリーンアップ週間」ではないため、人々は壊れた窓を離れることです。
個人的には、以前にスプリントで作成したことがわかっている場合は、各スプリントの技術的な負債のクリーンアップについて交渉します。それは人々の心の中で借金を新鮮に保ちます。問題のあるコードを使用するコードの量が制限されるため、リファクタリングが容易になります。これは、技術的債務が積み重なるのを防ぎます。また、Push開発者が何かを平手打ちするのを防ぐのに役立ちます。これは、次のスプリントですぐに実行できるようにするためです（そもそも最初から実行する必要があるかもしれません）。
私は間違いなくそうだと言いますが、但し書きは頻繁に、できれば毎週行うべきです。私は、定期的なコードレビューと、コードレビューからのアイテムの実際の操作を組み合わせることで、すぐに成果が得られると思います。 p.s.w.g.の回答を参照してください。
2か月ごとに1週間で十分というわけではありません。これは、あなたの質問に対して「いいえ」で応答した他のほとんどの回答に話しかけます。これらの回答のほとんどの要点は、あまりにも長く待つと、コードに触れなくなり、通常は修正/クリーンアップ/リファクタリングにはるかに長い時間がかかることです。
現在人気のある2つの「いいえ」「はい」の答えは、同じ真実の2つの側面だと思います。 OPは、個人としてだけでなく、彼が管理しているグループについて話していることを思い出してください。グループ内のすべての開発者が、クリーンで読みやすいコードを書くのに十分な規律があるとは限りません。そして、外部からの圧力とアジャイルスタイルの方法論の問題があります。また、人々の最善の努力でも、スタイルの違いは、離れているとクリーンと見なされ、他の人々と一緒に考えられるとクリーンでないコードを書く可能性があることを意味します（きしむインターフェイスは言うまでもありません）。
一方、「作業中に修正する」は、私の考えでは理想的です。あなたはあなたのコードをより「修正された」ものにすることができます
- 注意深いピアCRing
- コード自体と一緒に単体テストを書く
- コーディングガイドラインの採用
- 自動フォーマッターとリンターの使用（ただしYMMV）
- 等.
今、OPのチームが上記を採用し、部下を奨励する場合-たとえばコードレビュー中および定期的なコードクリーンアップセッション中-落とし穴を予測し、事前に醜さを回避するために、時間の経過とともにクリーンアップに必要な時間を短縮できます。 （そして、彼らはその時間をドキュメント化、より深いリファクタリング、そして彼らが書いて統合したものの知識共有に費やすことができました。）
定期的な時間をスケジュールすることは、それが通常のウォーターフォールスタイルのプロジェクトのタスクであれ、アジャイルプロジェクトのストーリーであれ、非常に良いことだと思います。設定された時間を持つことは、それをスケジュールに組み込むだけの場合ほど価値がない場合があります。これにより、プロジェクトの進捗が遅れているため、スケジュールの一部として、またはクリーンアップ日のキャンセルとして、それを実行できます。
莫大な量のコード借金を抱えるプロジェクトを管理してきたため、これらを定期的に実行することが、物事を円滑に機能させるための鍵でした。私たちのもののいくつかは大きいものもあれば、小さいものもありました。
この種の作業を数か月行った後、運用チームのリーダーがすべてが順調に進んでいることを教えてくれました。
各項目は多くのようには見えないかもしれませんが、すべての借金と同じように、広告が表示されます。
理想的な答えは「いいえ」です。これは、これを必要としないようにするために必要な手順を実行するためです（既に述べたいくつかの理由で、進行中にクリーンアップします）。
これは最終的には目標かもしれませんが、これを実際に実行するのとはほど遠いチームがあるかもしれません。
管理者はある程度の責任を負う必要がありますそれは必ずしも開発者の責任ではありません。マネージャーは1つのことを言うことができますが、彼らはプロジェクトを完成させ、悪い習慣を促進する提案をするように働きかけます。彼らは文字通り「後でクリーンアップします」と言うかもしれませんし、それがうまくいけばそれで十分です。
これが重要であることを示すために、特定の時間に専念することから始める必要がある場合があります。チームが（与えられたものではなく）コードをクリーンアップできることがわかったら、より頻繁にコードを組み込むことができます。
最終的には、時間を設定する必要はありません。
個人的に、私は新しい問題を解決し、物事を整理整頓しようとしながらそれを機能させるのに苦労しています。私はそれでよくなっていますが、しばしば意図的な休憩を取り、物事を片付けます。それは私にとっては別の考え方です。最終的には、堅実な習慣が習慣になります。
あなたがたまに追加のコードをクリーンアップすることを意図したのかどうかは、はっきりしていません。そういう意味ではね。私たちがこれまで実践してきたことは、常にいくつかの低下が発生します。
そもそも、これを正しいことをしない言い訳として使うべきではありません[SOLID原則、関連する単体テスト、検査などを適用する]。