まず、コードのない質問で申し訳ありませんが、1 つ明確にしたいことがあります。
私のチームには、コードの品質を積極的に推進している上級開発者がいます - マージリクエストのレビュー、くだらないコードなどはありません。しかし、チームの他のメンバーのほとんどは、「やり遂げる」というメンタリティを持っています。私はビジネスマンとして、コードをまったくチェックしませんが、品質を気にする人がいなければ、ある時点で重いリファクタリングサイクルにぶつかると思います.
しかし、もちろん、品質を気にしすぎることにはマイナス面もあります。それには時間がかかるだけです。ビジネス ニーズの変化に応じて方向転換する必要がある場合は、多くの美しいコードを投入する必要があるかもしれません。
2 つの質問: a) 製品の品質をどのように維持していますか? どのようなプラクティスを使用していますか? b) コードの品質を気にするのに十分な行はどこにありますか (少なすぎず、多すぎず)?
アジャイルを開発するかどうかに関係なく、コードの品質は重要です。品質の向上にはさらに時間がかかるというあなたの意見はまったく正しいです。ほとんどの人は、品質問題の数をできるだけ減らすことを目的として、任意の場所のコードを多かれ少なかれクリーンアップするために、より大きなブロック (「プロジェクトのリファクタリング」) に時間を費やしたため、失敗します。
私が使用することをお勧めするプロセスは、変更されたコードを常に以前よりも少しきれいに (より良く) 残すというボーイスカウトの規則に従うことです。つまり、関数、手順、メソッド、またはその他のコード単位を変更するたびに、その品質の問題を修正します。利点は、コードを既に理解しており (とにかくコードを変更する必要があったため)、テストされることです (元の変更をテストする必要があるため)。つまり、品質向上のための追加の労力 (コメントの追加、識別子の改善、冗長性の削除など) は非常に少ないということです。さらに、作業中のコードのみを改善しているので、手を加えていないコードを改善するために時間を無駄にすることはありません。
ボーイスカウトのルールに従うことで、品質は低下せず、時間の経過とともに着実に向上します。それはまた、妥当なレベルの「気遣い」でもあります。これについては、こちらに詳しく書いています。さらに、レガシーの問題、新しい問題、最近変更したコードの問題を確実に区別できる、 Teamscaleのような高品質の分析ツールが必要です。
静的コード分析に使用しているツールであるSonar Qubeで良い経験をしました。そのため、コードベースでコードの匂いなどを追跡できます。もう 1 つのポイントは、問題の修正はスプリントで計画できることです。IDE統合も利用可能です!