レガシーコードを引き継ぐときに人々が最もイライラするのは何だと思いますか?非常に複雑な UML ですか?私はそうは思わない。私の答えは、else が 2 つ以上ある場合、または case が 3 つ以上ある場合は switch です。しかし、コード内でif elseやswitch ケースを多用するのは普通のことでしょうか?間違っている！ 3 つ以上の分岐を持つ if else および switch ケースのほとんどは、ハードコーディングされた形式で表示されるべきではありません。
複雑な分岐はどこから来たのでしょうか?
まず最初に、議論したい最初の疑問は、なぜ従来のコードには非常に多くの複雑な分岐が存在するのかということです。これらの複雑な分岐は、コードの最初のバージョンには存在しないことがよくあります。設計者がまだある程度の経験を持っていると仮定すると、将来拡張する必要がある領域を予測し、抽象インターフェイスを予約する必要があります。
ただし、コードが数回反復された後、特に要件の詳細を数回調整した後、複雑な分岐が表示されます。要件に対する詳細な調整は、多くの場合、UML には反映されませんが、コードに直接反映されます。たとえば、メッセージは当初、チャット メッセージとシステム メッセージの 2 つのカテゴリに分類されていましたが、これらは自然にメッセージ カテゴリの 2 つのサブカテゴリとして設計されました。しかし、ある日、要件が詳細に調整されるため、一部のシステム メッセージは重要であり、そのタイトルが赤色で表示されるようになります。このとき、プログラマーは次のような変更を行うことがよくあります。
システムメッセージクラスに重要な属性を追加します。
タイトルの色を制御するために、対応する render メソッドに重要な属性に関するブランチを追加するのはなぜでしょうか。おそらくそれは抽象的であるべきだと彼が気づいていなかったからかもしれない。要件には「一部のシステム メッセージは重要である」と記載されているため、命令型プログラミング言語でより多くのトレーニングを受けたプログラマにとって、最初に思いつくのはフラグ ビットです。フラグ ビットは重要なものとそうでないものを区別できます。 。 重要。同氏は、この要件が「システム メッセージは 2 つのカテゴリ、重要なものと重要でないものに分類される」という別の方法で解釈される可能性があるとは予想していませんでした。このように解釈すると、システム メッセージは抽象化する必要があることがわかりました。
もちろん、プログラマは抽象化が可能であることを知っていても、何らかの理由で抽象化を行わないことを選択する可能性があります。非常に一般的な状況は、プロジェクトの進行速度と引き換えにコードの品質を犠牲にすることをプログラマーに強いるというものです。プロパティとブランチを追加する方が、抽象的なリファクタリングよりもはるかに簡単です。この形式の変更を 10 個実行したい場合、10 個作成した方が早いでしょうか。分岐か 10 個の抽象化か?違いは明らかです。
もちろん、if else が多すぎると、「スイッチのケースに変えたらどうですか？」と立ち上がる賢い人もいるでしょう。場合によっては、各ブランチが相互に排他的であると仮定すると、これによりコードの可読性が実際に向上します。しかし、スイッチケースの数が増えると、コードも読めなくなります。
複雑な分岐のデメリットは何ですか?
複雑な分岐のデメリットは何ですか?例として、Baidu Hi Web バージョンの古いコードのセクションを取り上げます。
スイッチ (json.result) {
「OK」の場合:
スイッチ (json.command) {
ケース「メッセージ」:
ケース「システムメッセージ」:
if (json.content.from == ""
&& json.content.content == "キックされました") {
/* 切断します */
else if (json.command == "システムメッセージ"
|| json.content.type == "sysmsg") {
/* システムメッセージをレンダリングします */
} それ以外 {
/* チャット メッセージをレンダリングします */
}
壊す;
}
壊す;