บทสรุปการใช้ UML

🤔 ทำไมเราต้องใช้ UML ด้วย? ไม่ใช้ได้ป่าว? ข้อดีข้อเสียคือไร?

ในบทความนี้เราจะมาสรุปกันว่า UML มีข้อดีข้อเสียยังไง เพื่อให้แต่ละทีมลองเลือกที่จะนำไปปรับใช้กันเอานะครับ

แนะนำให้อ่าน บทความนี้เป็นส่วนหนึ่งของคอร์ส 👶 UML พื้นฐาน หากเพื่อนๆสนใจอยากดูรายละเอียดของ UML แต่ละตัวว่ามันมีอะไรบ้างก็สามารถกดลิงค์ที่ชื่อคอร์สเข้าไปดูได้เลยนะ หรือจะดูหมวดอื่นๆจาก side menu ก็ได้เน่อ

🤔 ทำไมต้องใช้ UML ?

ในการออกแบบระบบอะไรก็แล้วแต่ ต่อให้เป็นระบบที่ง่ายแค่ไหนก็ตามมันก็มีมุมมองหลายแบบ ดังนั้นเราก็ควรจะทำความเข้าใจตัวระบบที่เรากำลังจะทำงานด้วยเสมอ เพราะไม่อย่างนั้นเราก็จะได้งานที่ลูกค้าไม่อยากได้ออกมานั่นเอง

จากที่ว่ามาถ้าเราจะทำความเข้าใจระบบได้จริงๆ เราจะต้องทำใจแต่ละมุมมองของระบบ เพื่อให้เราสามารถออกแบบได้ถูกต้อง เช่น มุมมองจากฝั่งผู้ใช้ มุมมองจากฝั่ง business มุมมองจากฝั่ง marketing บลาๆ เช่นภาพด้านล่างจะเห็นว่า ของอย่างเดียวกัน แต่ถ้าเรามองจากแต่ละมุมเราจะเห็นภาพกันคนละเรื่องเลย

ปัญหาที่แต่ละคนมองเห็นกันคนละแบบนั้นเกิดขึ้นได้ตลอดเวลา ดังนั้นเราควรจะปรับความเข้าใจให้ทุกคนเห็นเป็นภาพเดียวกันก่อนว่าจริงๆแล้วเรากำลังจะทำอะไร ซึ่งสิ่งที่จะมาช่วยปรับความเข้าใจให้ทุกคนเห็นเป็นภาพเดียวกันก็คือ การเขียน UML ยังไงล่ะ

🤔 UML ใช้ได้กับอะไรบ้าง ?

ภาษา UML นี้แม้ว่ามันจะออกแบบมาให้ใช้กับการออกแบบซอฟต์แวร์ก็จริง แต่มันสามารถเอาไปใช้ได้กับหลายๆเรื่องที่ไม่เกี่ยวกับซอฟต์แวร์เลย เช่น Activity Diagram เราจะเอาไปใช้กับเรื่องอะไรก็ได้ เพื่อให้แต่ละคนเข้าใจขั้นตอนการทำงาน

ตัวอย่างการเอา Activity Diagram ไปใช้กับโรงพยาบาล

มองภาพไม่ชัดกดเพื่อขยายดูได้นะ

🤔 เวลาเขียนต้องถูก format ไหม ?

ถ้าจะถามว่าเราจะต้องเขียนแต่ละ diagram ให้ถูกรูปแบบตามมาตรฐานมันเป๊ะๆหรือเปล่า คำตอบคือ แล้วแต่ละสถานะการณ์ที่ใช้ เช่น ถ้าเราเขียนแบบกากๆเลยแล้วเพื่อนๆในทีมเข้าใจก็เขียนแบบนั้นไปเลยก็ได้ เพราะหัวใจของมันคือทำให้ทุกคนเข้าใจตรงกันนั่นเอง แต่ใยบางจุดที่มันเป็นเรื่องละเอียดอ่อน เช่นการทำงานต้องเป็น asynchronous ต้องเป็น parallel นั่นนู่นนี่ เราก็อาจจำเป็นจะต้องเขียนให้ทีมเข้าใจว่ามันทำงานแบบนี้เพื่อ เพราะเวลาที่ทีมกลับมาดูจะได้เข้าใจว่าจุดนี้มันเป็นเรื่องพิเศษของมันจริงๆนะ ส่วนสถานะการณ์ที่ต้องเขียนให้ถูกเป๊ะๆเลยส่วนตัวผมที่เห็นบ่อยๆคือ เขียนส่งให้กับทีมอื่นที่ไม่ใช่ทีมในบริษัทกันเอง เช่น ทำเป็น document ส่งไรงี้

🤔 ข้อดี vs ข้อเสีย คืออะไร ?

👍 ข้อดี

• ทุกคนเข้าใจกันได้เร็วขึ้น และเห็นเป็นภาพเดียวกัน

• ป้องกันข้อผิดพลาดได้ก่อนที่มันจะกลายเป็นโค้ด

• เพิ่มประสิทธิภาพในการออกแบบ

👎 ข้อเสีย

• แผนภาพมันก็คือเป็นแค่นั้นจริงๆ ไม่ได้หมายความว่าโค้ดจะเป็นแบบนั้น

• ถ้าออกแบบโดยไม่คิดถึง scenarios จะทำให้โค้ดซับซ้อนโดยไม่จำเป็น

• เสียเวลาในการทำให้มันสวย

🎯 บทสรุป

ในการใช้ของทุกอย่างย่อมมีดีมีเสีย ดังนั้นเราควรชั่งน้ำหนักเสียก่อนว่าจะใช้ของแต่ละอย่างเมื่อไหร่ถึงจะเหมาะสมกับหน้างานที่เราเป็นอยู่ UML จะมีประโยชน์มากถ้าทีมคิดภาพตามไม่ออกเราสามารถเอา diagram ไปช่วยทำให้มันชัดเจนได้ สุดท้ายหลักการในการออกแบบอะไรก็แล้วแต่ หัวใจสำคัญที่สุดของมันคือ การวางแผน หรือที่เราเรียกว่า Strategy นั้นสำคัญที่สุดรองลงมจาก Requirement เลยทีเดียว เพราะต่อให้เราทำทุกอย่างมาดีแค่ไหน แต่มันไม่ใช่แผนที่ดี เราก็อาจจะเสียเวลาเพราะไปทำของที่มันอ้อมค้อมเกินไปก็ได้

ลำดับความสำคัญ หัวใจในการเขียนซอฟต์แวร์จากประสบการณ์และมหาเทพหลายๆคนที่ผมร่ำเรียนมาให้ข้อสรุปตรงกันออกมาเป็นแบบนี้ว่า

Requirement → Strategy → Analysis → Design → Implementation

เพราะถ้าเราเข้าใจ Requirement ไม่ถูก งานทั้งหมดที่ทำมาก็ไร้ความหมายแถมจะโดนลูกค้าด่าอีกต่างหาก

เพราะถ้าเราคิด Strategy ไม่ดี เราอาจจะไปทำสิ่งที่มันอ้อมค้อมและเสียเวลามากกว่าที่มันควรจะเป็น และรวมถึงการเรียงลำดับความสำคัญของงานด้วย