出荷されたばかりのアプリケーションがあります。それを書いたので、amfphpとpropelについて学びました。どちらもアプリケーションで使用するには「いい」ですが、現時点で必要になるとは言えません。
コードをリファクタリングする前に、どのような種類のことを検討しますか？
9 に答える
9
リファクタリング後にコードをチェックするための単体テストを行います。
于 2008-12-18T22:28:54.893 に答える
6
必要な労力と受けた利益、およびそれが他の作業と優先的に適合する場合。
于 2008-12-18T22:29:41.240 に答える
4
するべきか？
コードをリファクタリングできるからといって、コードをリファクタリングする必要があるという意味ではありません。多くの場合、実行する必要のあるはるかに重要なことがあります。欠陥を修正するようなものです。
さて、私がすでにその特定のコードブロックにいて、欠陥解決またはコードメンテナンスの一部として取り組んでいるためにコードのリファクタリングについて話している場合、それはまったく別の話です。しかし、リファクタリングのためだけにリファクタリングするのでしょうか。それは退屈から生まれた忙しい仕事のように聞こえます。確かに、空の欠陥リストはありません。
于 2008-12-18T23:43:40.467 に答える
1
リファクタリングされたコードの保守性。後知恵は20/20ですが、出荷された製品では、エレガントでありながら不可解なデザインを維持するのは悪夢です。また、機能拡張を可能にするためのリファクタリングされた設計の柔軟性は非常に重要です。
于 2008-12-18T22:34:17.190 に答える
1
既存の機能を壊す可能性はどのくらいありますか? 単体テストは、自動化されたリファクタリング ツールと同様に、ここでの優れたセーフティ ネットです。
コードは本当に理解しやすく、後で保守しやすいでしょうか? これは答えるのが難しい質問である可能性があり、うまく答えるには経験が必要です。
于 2008-12-19T00:02:02.147 に答える
0
ソース管理で現在の本番コードベースのフォークを作成し、ソース管理の実験的なブランチですべてのリファクタリングを実行します。
于 2008-12-18T22:35:17.517 に答える
0
単体テストは非常に優れていますが、コードが単体テストでカバーされていない場合は、コードを壊さないようにするための他の手段が必要です。実稼働データベースのコピーを手に入れることができれば、おそらく実際の製品の入力さえあれば、かなりのチャンスがあるはずです。
以前のプロジェクトでは、実際に 14 日間すべての受信データを記録し、その 14 日間の開始時と終了時に prod データベースのスナップショットを保存しました。その後、古いコードと新しいコードを使用してデータベースの状態を比較することができました。 . しかし、単体テストは確かに恐怖の一部を取り除くでしょう:-)
于 2008-12-18T22:47:01.893 に答える
0
コードを嗅ぎます。においが気に入らなければ（つまり、私のようなにおいがしません）、好きになるまでおしっこをします。
ソフトウェア技術にはアジャイルやデザイン パターンなどのクールな名前が必要なので、私はこれを犬のリファクタリングと呼んでいます。
コードを書き直した後、自分でしばらく使用して、自分のドッグフードを食べる.
于 2008-12-18T23:27:30.140 に答える
0
Drejc に +1 を与える必要があります。リファクタリングしない最大の理由は、単体テストがない場合です。しかし、それでもリファクタリングをしてはいけないというわけではありません。私のやり方は、まずコード機能であり、次に常にリファクタリングして設計上の負債に対処することです。嫌悪感を繰り返します。
「十分に良い」パターンは、おそらく地球上で最も使用されているプログラミング方法論であり、それがソフトウェアにバグが多く、厄介である理由の 1 つです。最小エネルギーの「パス」を選択する代わりに、常に最小エネルギーの「ステップ」を選択します。
しかし、注意してください！適切なツールを使用しないリファクタリング (これは言語と IDE によって異なります) は、ネジを叩くようなものです: そこにたどり着くことができますが、効果的ではありません (そしてトラブルに巻き込まれる可能性があります)。
于 2008-12-19T00:48:39.027 に答える