0

これは実際のコードに関する質問ではありませんが、ここで質問します。ちょっとした変更が複数の機能やクラスを壊すほど悪いコードベースで、皆さんはどのように作業しているのだろうか? 小さな変更を加えたり、リファクタリングを試みたりするたびに、すべてが吹き飛ばされます。

考えてみてください: 循環依存、二重インクルード (C++)、スイッチの列挙型ではなく単純な整数、最初にそのライブラリにビルドされたアプリに依存する社内ライブラリ、ライブラリで開始するゴースト スレッド、メインではなく開始するループバックグラウンドで黒魔術を実行しているライブラリクラス、アプリケーション内のすべての場所で呼び出されたライブラリ内のシングルトン、長くて理解できないswitchステートメント、一貫性のない変数名、変数名の非常に悪いスペル、およびリストが延々と続きます。

機能を追加しようとするたびに、その機能の基盤が不完全で、不安定で、保守できず、拡張に適していないことがわかります。コードを見るたびに、ほぼ瞬時に行き詰まり、すべてをリファクタリングせずに機能を追加することは不可能に思えます。

機能をコードにハッキングすることはできますが、それは戻ってきて、お尻を噛むだけなので、他のチーム メンバーが気にしていないように見えても、私は単純にそれを拒否します。その態度がコードベースをひどいものにしていると思います。

私は学生で、これは学校のプロジェクトのためのものなので、お気づきかもしれませんが、私は絶対にクラス A のプログラマーではありません。そして再利用可能。

完全なリファクタリングはオプションではないようです。人々は 100% 消極的で、他の 29 人に対しては私です。コードを見始めるたびに、自分の顔を壁にぶつけて、自分の顔を食べて、プロジェクトを削除して、他の人からの発言に対する憎しみ、欲求不満、反発から、プロジェクトを削除して二度と見たくないという衝動を感じます。今は問題なく動作しています。」このようなものをどのように処理しますか?私は本当に私の正気のためにいくつかのヒントを使うことができました.

4

1 に答える 1

1

リファクタリングは良いことですが、それを行うには根本的な前提があります。優れたテストがたくさんあるということです。

コードベースには、各メソッドの役割を明確に説明する十分な単体テストがありますか? そうでない場合は、それらを書き始めるべきです。ビッグバンから始めないでください。

パイロット機能部分を特定し、それらの完全な単体テストを記述します。記述されたテストが十分であるかどうかを判断するためのガイドラインは、コード カバレッジです (ただし、これは単なるガイドラインです)。ここで、 SOLIDの原則を念頭に置いて、機能部分にリファクタリングを適用します。

于 2013-05-25T14:31:41.687 に答える