คุณคิดว่าอะไรทำให้ผู้คนใจร้อนที่สุดเมื่อพวกเขารับช่วงต่อรหัสเดิม UML ที่ซับซ้อนอย่างยิ่ง? ฉันไม่คิดอย่างนั้น คำตอบของฉันคือ ถ้ามีมากกว่าสองกรณี หรือสลับกับมากกว่าสองกรณี แต่เป็นเรื่องปกติหรือไม่ที่จะใช้ if else จำนวนมากและ สลับเคส ในโค้ดของคุณ? ผิด! กรณี if else และ switch ส่วนใหญ่ที่มีสาขามากกว่าสองสาขาไม่ควรปรากฏในรูปแบบฮาร์ดโค้ด
สาขาที่ซับซ้อนมาจากไหน?
ก่อนอื่น คำถามแรกที่เราต้องการจะพูดคุยคือเหตุใดจึงมีสาขาที่ซับซ้อนมากมายใน Legacy Code สาขาที่ซับซ้อนเหล่านี้มักจะไม่มีอยู่ในโค้ดเวอร์ชันแรก สมมติว่าผู้ออกแบบยังคงมีประสบการณ์อยู่บ้าง เขาควรคาดการณ์พื้นที่ที่อาจจำเป็นต้องขยายในอนาคตและสำรองอินเทอร์เฟซ แบบนามธรรม
อย่างไรก็ตาม หลังจากที่โค้ดผ่านการวนซ้ำหลายครั้ง โดยเฉพาะอย่างยิ่งหลังจากการปรับเปลี่ยนรายละเอียดข้อกำหนดหลายครั้ง สาขาที่ซับซ้อนจะปรากฏขึ้น การปรับเปลี่ยนข้อกำหนดโดยละเอียดมักไม่สะท้อนให้เห็นใน UML แต่จะสะท้อนให้เห็นโดยตรงในโค้ด ตัวอย่างเช่น ข้อความเดิมถูกแบ่งออกเป็นสองประเภท: ข้อความแชทและข้อความระบบ ในระหว่างการออกแบบ ข้อความเหล่านี้ได้รับการออกแบบโดยธรรมชาติให้เป็นหมวดหมู่ย่อยสองหมวดหมู่ แต่แล้ววันหนึ่งข้อกำหนดต่างๆ ก็มีการปรับเปลี่ยนอย่างละเอียด ข้อความของระบบบางส่วนก็มีความสำคัญ และควรแสดงหัวเรื่องเป็นสีแดง ในเวลานี้ โปรแกรมเมอร์มักจะทำการแก้ไขดังต่อไปนี้:
เพิ่มคุณลักษณะที่สำคัญให้กับคลาสข้อความของระบบ
เพิ่มสาขาเกี่ยวกับคุณลักษณะที่สำคัญในวิธีการเรนเดอร์ที่สอดคล้องกันเพื่อควบคุมสีของหัวเรื่อง เหตุใดโปรแกรมเมอร์จึงทำการเปลี่ยนแปลงดังกล่าว อาจเป็นเพราะเขาไม่รู้ว่ามันควรจะเป็นนามธรรม เนื่องจากข้อกำหนดระบุว่า "ข้อความของระบบบางส่วนมีความสำคัญ" สำหรับโปรแกรมเมอร์ที่ได้รับการฝึกอบรมเพิ่มเติมเกี่ยวกับภาษาการเขียนโปรแกรมที่จำเป็น สิ่งแรกที่พวกเขาอาจนึกถึงคือบิตแฟล็ก - บิตแฟล็กสามารถแยกแยะระหว่างบิตที่สำคัญและไม่สำคัญได้ . สำคัญ. เขาไม่ได้คาดหวังว่าข้อกำหนดนี้สามารถตีความได้ในลักษณะอื่น "ข้อความของระบบแบ่งออกเป็นสองประเภท: สำคัญและไม่สำคัญ" เมื่อตีความเช่นนี้ เขารู้ว่าข้อความของระบบควรจะเป็นนามธรรม
แน่นอนว่าเป็นไปได้ที่โปรแกรมเมอร์รู้ว่าสิ่งที่เป็นนามธรรมนั้นเป็นไปได้ แต่ด้วยเหตุผลบางอย่างเลือกที่จะไม่ทำเช่นนั้น สถานการณ์ที่พบบ่อยมากคือมีคนบังคับให้โปรแกรมเมอร์เสียสละคุณภาพของโค้ดเพื่อแลกกับความคืบหน้าของโปรเจ็กต์โดยการเพิ่มคุณสมบัติและสาขานั้นง่ายกว่าการปรับโครงสร้างใหม่แบบนามธรรมมาก หากคุณต้องการทำ 10 ของการปรับเปลี่ยนแบบฟอร์มนี้ จะเร็วกว่าหรือไม่ถ้าจะสร้าง 10 สาขาหรือ 10 นามธรรม? ความแตกต่างที่ชัดเจน
แน่นอน ถ้ามี if else มากเกินไป คนฉลาดบางคนก็จะยืนขึ้นแล้วพูดว่า "ทำไมเราไม่เปลี่ยนเป็น switch case ล่ะ?" ในบางกรณี สิ่งนี้สามารถปรับปรุงความสามารถในการอ่านโค้ดได้จริง โดยสมมติว่าแต่ละสาขาแยกจากกัน แต่เมื่อจำนวนเคสสวิตช์เพิ่มขึ้น โค้ดก็จะอ่านไม่ได้เช่นกัน
สาขาที่ซับซ้อนมีข้อเสียอย่างไร?
สาขาที่ซับซ้อนมีข้อเสียอย่างไร? ฉันขอยกตัวอย่างส่วนหนึ่งจากโค้ดเก่าของเวอร์ชันเว็บ Baidu Hi
สวิตช์ (json.result) {
กรณี "ตกลง":
สวิตช์ (json.command) {
กรณี "ข้อความ":
กรณี "ข้อความระบบ":
ถ้า (json.content.from == ""
&& json.content.content == "ถูกเตะ") {
/* ตัดการเชื่อมต่อ */
} อื่นถ้า (json.command == "systemmessage"
||.json.content.type == "sysmsg") {
/* แสดงข้อความระบบ */
} อื่น {
/* แสดงข้อความแชท */
-
หยุดพัก;
-
หยุดพัก;
ที่มา: ประสบการณ์ผู้ใช้ Baidu pan