コードをクリーンアップするために定期的な時間をスケジュールすることは良い考えですか？[閉まっている]

私は小さな開発者チームを管理しています。コードをクリーンアップするために、1〜2日を費やすことにします。

コードベースをクリーンアップするために、2か月ごとに1週間などの定期的な時間をスケジュールすることをお勧めしますか？

番号。

作業中に修正します。

• 作業中のビットをリファクタリングするのを待つと、それについて多くのことを忘れてしまい、もう一度慣れるために時間を費やす必要があります。
• 要件が変更されたために、決して使用されない「ゴールドメッキ」コードになることはありません。

私個人の意見：プロジェクトの90％には絶対に必要です。

特に販売に大きく左右されるプロジェクトの場合、通常、すべてのリリースに新機能を含めることは大きな推進力になり、必然的に自分のより良い本能を妥協し、あちこちでいくつかのクラッジ/ハックを導入しなければなりません。

最終的には、これらの小さな妥協によって十分な「技術的負債」が生じ、コードベースの欠陥を回避するためにかなりの時間を費やし、その潜在能力を最大限に活用することができなくなります。

通常、この方法で生成される問題には2つのタイプがあります。

• 簡単に修正できますが、システムに影響を与える可能性のある小さなパラメーター、たとえば、不適切な名前のパラメーター、不完全なエラー処理など。コードブロックの外では、通常は影響がほとんどありません。これらに対処する最善の方法は、コードのレビューと、コードの作成/変更中のチェックです。他の人が述べたように、これらのエラーを修正するために特別なリファクタリングサイクルを用意する必要はありません。
• 仕様が不完全であったり、設計の決定が不十分であったり、2人の開発者/チームが同じ問題に対して2つの異なるソリューションを作成したりして生じた大きなもの。これらは一般に修正がはるかに困難であり、修正するために協調した努力が必要です。結果として、それらは通常、永続的な迷惑になるまで延期されます。これらの種類の問題を修正するには、専用の時間が必要です。

私は通常、3〜4サイクルごとに純粋なリファクタリング/バグ修正サイクルの時間を確保しようとしています。私は常に、開発者がコードベースにも不満を感じているときはいつでも教えてくれるように頼みます。すべての開発者がクリーンアップ作業に取り組む必要があるわけではありません-通常（常にではありませんが）チームを少しずらすことができるため、常に1つのチームのみがクリーンアップに取り組んでいます。

チェックイン（Subversion）またはメイン開発ブランチ（Git）とマージする前に、開発者にコードを整頓してもらいます。

私は彼らに次のことをさせます：

• 無関係なコメントを削除する
• メソッド、引数、変数に適切な名前が付けられていることを確認してください
• クラスに構造があり、アイテムが必要に応じてカプセル化されていることを確認します
• リファクタリングして読みやすくし、コードのにおいを減らします

大規模なプロジェクトの場合、開発ブランチからメインブランチにマージする前に、コードが正式にレビューされます。

「献身的な時間」とは、それが延期されたり、関与する作業量のために延期されたりすることを意味すると思います。開発者にチェックインごと（JIRAでの変更要求/問題に相当）にそれを実行させることにより、はるかに管理しやすくなります。

私の意見ではありません。技術的な負債に遭遇してからそれを修正するまでの間に時間をかけすぎると、問題が何であるかのコンテキストを失います。修正に時間がかかり、さらに悪化する傾向があります。最も重要なのは、「1週間のクリーンアップ」ではないため、人々は壊れたウィンドウを離れます。

個人的には、以前にスプリントでいくつかを作成したことがわかっている場合は、各スプリントの技術的な負債のクリーンアップについて交渉します。それは人々の心に負債を新鮮に保ちます。リファクタリングが容易になるように、問題のコードを使用するコードの量を制限します。技術的な負債が積み重なるのを防ぎます。そして、開発者が何かを一緒に平手打ちするのをやめるのに役立ちます。なぜなら、私は彼らに次のスプリントをすぐにやらせるつもりだからです。

ただし、但し書きを付けて、間違いなく「はい」と言います。頻繁に、できれば毎週行うべきです。定期的な定期的なコードレビューと、コードレビューから出てくる項目に実際に対処することは、非常に迅速に報われると思います。pswgの答えをご覧ください

2か月ごとに1週間では十分ではないことは間違いありません。これは、あなたの質問に「いいえ」で答えた他のほとんどの答えに語ります。これらの答えのほとんどの要点は、あまりにも長く待つとコードに触れることができなくなり、通常は修正/クリーンアップ/リファクタリングにはるかに時間がかかることです。

時々コードを追加することを意図しているかどうかはそれほど明確ではありません。そういう意味で、はい。私たちが従うことは何であれ、常にいくらかの劣化が起こります。

そもそも正しいことを行わない言い訳として使用しないでください[SOLID原則、関連する単体テスト、検査などを適用する]。

現在の2つの人気の「いいえ」「はい」の答えは、同じ真実の2つの側面だと思います。OPは、個人としてだけでなく、彼が管理しているグループについて話していることを思い出してください。グループ内のすべての開発者が、簡潔で読みやすいコードを書くのに十分な規律があるとは考えられません。そして、外部からのプレッシャーとアジャイルスタイルの方法論の問題があります。また、人々の最善の努力があっても、スタイルの違いは、離れているときにはきれいであると考えられるが、他の人と一緒に考えると汚れているコードを書くことを意味します（奇妙なインターフェースは言うまでもありません）。

一方、「作業中に修正する」というのは、私の意見では理想的なものです。次の方法でコードをさらに「修正」することができます

• 慎重なピアCRing
• コード自体と一緒に単体テストを書く
• コーディングガイドラインの採用
• 自動フォーマッターとリンターを使用（ただしYMMV）
• 等

今、OPのチームが上記を採用し、コードレビュー中や定期的なコードクリーンアップセッション中に部下を励ます場合、落とし穴を予測し、事前にさを回避しようとすると、時間の経過とともに、クリーンアップ時間。（そして、彼らはその時間を文書化、より深いリファクタリング、そして彼らが書いて統合したものの知識共有に費やすことができました。）

通常のウォーターフォールスタイルのプロジェクトのタスクであっても、アジャイルプロジェクトのストーリーであっても、定期的な時間をスケジュールすることは非常に良いと思います。時間を設定することは、スケジュールに組み込むだけの価値はありません。これにより、プロジェクトに遅れているため、スケジュールの一部として終わらせることができます。

莫大な量のコードの借金を抱えるプロジェクトを管理していたので、これらを定期的に実施することが、物事を円滑に進めるための鍵となりました。私たちのもののいくつかは大きく、いくつかは小さかった。

この種の作業を数か月行った後、運用チームのリーダーは、すべてがスムーズに実行されていることを教えてくれました。

各アイテムはそれほど多くないように見えるかもしれませんが、すべての借金と同じように、それは宣伝されます。

理想的な答えは「いいえ」です。これが必要になるのを避けるために必要なステップを踏むからです（すでに述べたいくつかの理由で、クリーンアップしてください）。

これは最終的には目標かもしれませんが、これを実際に実行するにはほど遠いチームがあるかもしれません。

マネージャーは何らかの責任を負わなければなりません。常に開発者のせいではありません。マネージャーは一つのことを言うことができますが、彼らはプロジェクトを終わらせ、悪い慣行を促進する提案をするようにプッシュし始めます。彼らは文字通り「後で掃除する」と言うかもしれませんし、うまくいけばそれで十分です。

これが重要であることを示すために、特定の時間を捧げることから始める必要があるかもしれません。チームが（指定されていない）コードをクリーンアップできることがわかったら、それをより頻繁に組み込むことができます。

最終的には、時間を設定する必要はありません。

個人的に、私は新しい問題を解決し、物事を整頓しようとしながらそれを機能させることに苦労しています。私はそれで良くなっていますが、しばしば意図的な休憩を取り、物事をきれいにします。それは私にとって異なる考え方です。最終的には、堅実な習慣が習慣になります。

いいえ、コーディング中にこれを行う必要があります。TDDを使用している場合、これはリファクタリングと呼ばれます。コードを修正してクリーンアップするのに1〜2か月待つときの問題は、コードのすべての部分を覚えているわけではないため、コードの動作を変更できることです。

何かを動作させるために必要なコードを最初にコーディングすることに基づいたリファクタリングをお勧めします。そして、動作するとすぐに、再設計、最適化、およびきれいにします。