Menurut Anda apa yang paling membuat orang tidak sabar ketika mereka mengambil alih kode lama? UML yang sangat kompleks? Saya kira tidak demikian. Jawaban saya adalah, jika dengan lebih dari dua kasus, atau beralih dengan lebih dari dua kasus. Namun apakah normal jika menggunakan banyak if else dan mengganti huruf besar/kecil dalam kode Anda? salah! Sebagian besar kasus if else dan switch dengan lebih dari dua cabang tidak akan muncul dalam bentuk hard-coded.
Dari mana asal cabang kompleks?
Pertama-tama, pertanyaan pertama yang ingin kita diskusikan adalah mengapa sering kali terdapat begitu banyak cabang kompleks dalam kode lama. Cabang-cabang kompleks ini sering kali tidak ada dalam kode versi pertama. Dengan asumsi bahwa perancang masih memiliki pengalaman, ia harus memperkirakan area yang mungkin perlu diperluas di masa depan dan mencadangkan antarmuka abstrak .
Namun, setelah kode melewati beberapa iterasi, terutama setelah beberapa penyesuaian pada detail persyaratan, cabang kompleks akan muncul. Penyesuaian rinci terhadap persyaratan sering kali tidak tercermin dalam UML, namun langsung tercermin dalam kode. Misalnya, pesan awalnya dibagi menjadi dua kategori: pesan obrolan dan pesan sistem. Selama desain, ini secara alami dirancang sebagai dua subkategori dari kategori pesan. Namun suatu hari persyaratannya disesuaikan secara rinci. Beberapa pesan sistem penting dan judulnya harus ditampilkan dengan warna merah. Saat ini, pemrogram sering melakukan modifikasi berikut:
Tambahkan atribut penting ke kelas pesan sistem
Tambahkan cabang tentang atribut penting dalam metode render yang sesuai untuk mengontrol warna judul. Mengapa programmer melakukan perubahan seperti itu? Mungkin karena dia tidak menyadari itu seharusnya abstrak. Karena persyaratan mengatakan "beberapa pesan sistem penting", bagi programmer yang telah menerima lebih banyak pelatihan dalam bahasa pemrograman imperatif, hal pertama yang mungkin mereka pikirkan adalah bit flag - bit flag dapat membedakan antara yang penting dan tidak penting. . penting. Ia tidak menyangka persyaratan ini dapat diartikan dengan cara lain, "Pesan sistem dibagi menjadi dua kategori: penting dan tidak penting." Menafsirkannya seperti ini, dia tahu bahwa pesan sistem harus diabstraksi.
Tentu saja mungkin saja pemrogram mengetahui bahwa abstraksi itu mungkin, tetapi karena alasan tertentu memilih untuk tidak melakukannya. Situasi yang sangat umum adalah seseorang memaksa pemrogram untuk mengorbankan kualitas kode sebagai imbalan atas kemajuan proyek. Menambahkan properti dan cabang dengan cepat jauh lebih sederhana daripada pemfaktoran ulang abstrak. Jika Anda ingin melakukan 10 dari bentuk ini Modifikasi, apakah lebih cepat membuat 10 cabang atau 10 abstraksi? Perbedaannya jelas.
Tentu saja, jika ada terlalu banyak if else, beberapa orang pintar akan berdiri dan berkata, "Mengapa kita tidak mengubahnya ke switch case?" Dalam beberapa kasus, hal ini sebenarnya dapat meningkatkan keterbacaan kode, dengan asumsi setiap cabang saling eksklusif. Namun ketika jumlah switch case meningkat, kode juga menjadi tidak terbaca.
Apa kerugian dari cabang yang kompleks?
Apa kerugian dari cabang yang kompleks? Izinkan saya mengambil bagian dari kode lama versi web Baidu Hi sebagai contoh.
beralih (json.hasil) {
kasus "oke":
beralih (json.command) {
kasus "pesan":
kasus "pesan sistem":
if (json.content.from == ""
&& json.content.content == "ditendang") {
/* putuskan sambungan */
} else if (json.command == "pesan sistem"
||.json.content.type == "sistemg") {
/* menampilkan pesan sistem */
} kalau tidak {
/* menampilkan pesan obrolan */
}
merusak;
}
merusak;
Sumber: Pengalaman pengguna pan Baidu