要件を待機している間の、影響の少ないリファクタリングと粗雑なコードのコードクリーニング

ずさんな方法で製品の既存のコードベースを継承しました。基本的な設計は非常に不十分であり、残念ながら完全なリファクタリングなしではほとんど何もできません（高結合、低凝集、コードのof延する複製、技術設計文書なし、単体テストではなく統合テスト）。この製品には、歴史、リスクに対する許容度が最小限の重要な「現金牛」クライアントへの高い露出、ギリシャ人を赤面させる技術的負債、非常に大きなコードベースと複雑さ、そしてチームによるバグへの戦い疲れた敗北主義アプローチがあります私。

古いチームは別の部門に船をジャンプして、別のプロジェクトを台無しにする機会を得た。プロジェクト管理の失敗とは対照的に、技術的な無能なプロジェクトの失敗を経験することは非常にまれですが、これは確かにそれらのケースの1つです。

今のところ、私は一人でいますが、私には多くの時間、意思決定の自由、将来の方向性、そして私を助けるためにゼロからチームを構築する能力があります。

私の質問は、機能要件の収集段階で自由時間があるときに、このようなプロジェクトでの影響の少ないリファクタリングについて意見を集めることです。何千ものコンパイラ警告があり、それらのほとんどは未使用のインポート、未読のローカル変数、型チェックの不在、および安全でないキャストです。コードの書式設定は非常に読みにくく、ずさんなため、コーダーはパーキンソン病にかかっており、特定の行でスペースバーを押した回数を制御できませんでした。通常、さらにデータベースとファイルリソースが開かれ、安全に閉じられることはありません。無意味なメソッド引数、同じことを行う重複メソッドなど。

次の機能の要件を待っている間、私は、影響が少ない低リスクのものを掃除しながら、時間を無駄にしているのか、正しいことをしているのかと考えました。新しい機能が以前に時間を費やしたコードを削除することを意味する場合はどうなりますか？私はアジャイルのアプローチを開始するつもりであり、これがアジャイル開発中に絶えずリファクタリングするのは許容可能であり、普通であることを理解しています。

これを行うことによるプラスまたはマイナスの影響を考えてください。

まず、ユニットテストは統合テストの代替ではないことを指摘したいと思います。この2つは共存している必要があります。統合テストがあることを感謝します。さもないと、小さなリファクタリングの1つが、許容度の低いキャッシュカウの1つをあなたに弾道的にさせる可能性があります。

コンパイラの警告と未使用の変数およびインポートの作業を開始します。最初にクリーンビルドを取得します。次に、現在の動作を文書化する単体テストの記述を開始し、実際のリファクタリングを開始します。

マイナスの影響はほとんどありません。コードベースを深く理解することで、より大きなリファクタリングに役立ちます。リファクタリング中はまだ動作する製品があるのに対して、リファクタリング中はリファクタリングよりもリファクタリングの方がほぼ常に望ましいのですが、リライト中はそうではありません。そして最終的に、製品の販売はあなたの給料を支払わなければなりません。

要件が入り始めたら、スポットライトアプローチと呼ばれる方法を使用します。通常のアジャイルなことを行い（優先順位を付けてから、反復のために小さなスラブを切り離し、それを処理します）、コードの改善のためにかなりの時間を残します。とにかく作業している場所をリファクタリングします。時間が経つにつれて、コードのその部分で作業している理由を管理に正当化するのが困難な領域に進出することなく、コードベースの広い領域をカバーします。

ユニットテストを書くことはあなたの時間のより貴重な使用かもしれません：それはあなたにコードベースの現在の働きへのいくつかの洞察を与えるでしょう、そしてあなたがあなたが最初からすべてを書き直すよりもむしろあなたが持っているものから始めることに決めたなら、あなたはしっかりした基盤を持ちますあまりリスクをとることなく変更を加えることができます。可能性としては、単体テストを作成する際に、コードベースを変更してテスト可能な形にするだけです。ユニットテスト可能は通常、モジュール化され、カプセル化され、外部状態からほとんど独立していることも意味するため、これらは優れています。そして、何よりも、よく書かれた単体テストは非常に貴重な技術文書です。ユニットテストを実施すると、念のためにワイルドな推測や書き直しを行うのではなく、現在のコードベースでできることとできないことを判断できます。

答えをブレンドする-私の考えはテストとクリーンアップをブレンドすることでしょう-多分50/50？TDDのようなアプローチを行う領域で作業している場合-テストを設定し、ユニットおよび統合テストが希望どおりであることを確認してから修正を開始する必要があります。時間の許す限り先に進んでください。

これはおそらくそれほど進歩しないことを意味しますが、少なくともいくつかの分野では安定したコードベースがあり、優れた開始ベースがあることを意味します。

私の腸の反応は、最初は「壊れたコードをクリーンアップするのは本当に痛いですか？」でした。（別名、コンパイラーエラー）、しかし、問題を修正すると、実際にはいくつかの非常に奇妙なケースで機能を壊したことがありました。スレッドが死ぬ代わりに、悪い場所にメモリが残っていたためです-本質的に、悪いブレークはさらに悪いエラーを隠していたからです。それは文字通り不快な驚きのパンドラの箱である場合があります。

より多くの要件を待っている間にこれを実行していることを考えると、混を診断するためにできることはすべて長期的な健全性に大いに役立つと思います。