บทสรุปการใช้ UML
🤔 ทำไมเราต้องใช้ UML ด้วย? ไม่ใช้ได้ป่าว? ข้อดีข้อเสียคือไร?
Last updated
🤔 ทำไมเราต้องใช้ UML ด้วย? ไม่ใช้ได้ป่าว? ข้อดีข้อเสียคือไร?
Last updated
ในบทความนี้เราจะมาสรุปกันว่า UML มีข้อดีข้อเสียยังไง เพื่อให้แต่ละทีมลองเลือกที่จะนำไปปรับใช้กันเอานะครับ
แนะนำให้อ่าน บทความนี้เป็นส่วนหนึ่งของคอร์ส 👶 UML พื้นฐาน หากเพื่อนๆสนใจอยากดูรายละเอียดของ UML แต่ละตัวว่ามันมีอะไรบ้างก็สามารถกดลิงค์ที่ชื่อคอร์สเข้าไปดูได้เลยนะ หรือจะดูหมวดอื่นๆจาก side menu ก็ได้เน่อ
ในการออกแบบระบบอะไรก็แล้วแต่ ต่อให้เป็นระบบที่ง่ายแค่ไหนก็ตามมันก็มีมุมมองหลายแบบ ดังนั้นเราก็ควรจะทำความเข้าใจตัวระบบที่เรากำลังจะทำงานด้วยเสมอ เพราะไม่อย่างนั้นเราก็จะได้งานที่ลูกค้าไม่อยากได้ออกมานั่นเอง
จากที่ว่ามาถ้าเราจะทำความเข้าใจระบบได้จริงๆ เราจะต้องทำใจแต่ละมุมมองของระบบ เพื่อให้เราสามารถออกแบบได้ถูกต้อง เช่น มุมมองจากฝั่งผู้ใช้ มุมมองจากฝั่ง business มุมมองจากฝั่ง marketing บลาๆ เช่นภาพด้านล่างจะเห็นว่า ของอย่างเดียวกัน แต่ถ้าเรามองจากแต่ละมุมเราจะเห็นภาพกันคนละเรื่องเลย
ปัญหาที่แต่ละคนมองเห็นกันคนละแบบนั้นเกิดขึ้นได้ตลอดเวลา ดังนั้นเราควรจะปรับความเข้าใจให้ทุกคนเห็นเป็นภาพเดียวกันก่อนว่าจริงๆแล้วเรากำลังจะทำอะไร ซึ่งสิ่งที่จะมาช่วยปรับความเข้าใจให้ทุกคนเห็นเป็นภาพเดียวกันก็คือ การเขียน UML ยังไงล่ะ
ภาษา UML นี้แม้ว่ามันจะออกแบบมาให้ใช้กับการออกแบบซอฟต์แวร์ก็จริง แต่มันสามารถเอาไปใช้ได้กับหลายๆเรื่องที่ไม่เกี่ยวกับซอฟต์แวร์เลย เช่น Activity Diagram เราจะเอาไปใช้กับเรื่องอะไรก็ได้ เพื่อให้แต่ละคนเข้าใจขั้นตอนการทำงาน
ตัวอย่างการเอา Activity Diagram ไปใช้กับโรงพยาบาล
ถ้าจะถามว่าเราจะต้องเขียนแต่ละ diagram ให้ถูกรูปแบบตามมาตรฐานมันเป๊ะๆหรือเปล่า คำตอบคือ แล้วแต่ละสถานะการณ์ที่ใช้ เช่น ถ้าเราเขียนแบบกากๆเลยแล้วเพื่อนๆในทีมเข้าใจก็เขียนแบบนั้นไปเลยก็ได้ เพราะหัวใจของมันคือทำให้ทุกคนเข้าใจตรงกันนั่นเอง แต่ใยบางจุดที่มันเป็นเรื่องละเอียดอ่อน เช่นการทำงานต้องเป็น asynchronous ต้องเป็น parallel นั่นนู่นนี่ เราก็อาจจำเป็นจะต้องเขียนให้ทีมเข้าใจว่ามันทำงานแบบนี้เพื่อ เพราะเวลาที่ทีมกลับมาดูจะได้เข้าใจว่าจุดนี้มันเป็นเรื่องพิเศษของมันจริงๆนะ ส่วนสถานะการณ์ที่ต้องเขียนให้ถูกเป๊ะๆเลยส่วนตัวผมที่เห็นบ่อยๆคือ เขียนส่งให้กับทีมอื่นที่ไม่ใช่ทีมในบริษัทกันเอง เช่น ทำเป็น document ส่งไรงี้
ทุกคนเข้าใจกันได้เร็วขึ้น และเห็นเป็นภาพเดียวกัน
ป้องกันข้อผิดพลาดได้ก่อนที่มันจะกลายเป็นโค้ด
เพิ่มประสิทธิภาพในการออกแบบ
แผนภาพมันก็คือเป็นแค่นั้นจริงๆ ไม่ได้หมายความว่าโค้ดจะเป็นแบบนั้น
ถ้าออกแบบโดยไม่คิดถึง scenarios จะทำให้โค้ดซับซ้อนโดยไม่จำเป็น
เสียเวลาในการทำให้มันสวย
ในการใช้ของทุกอย่างย่อมมีดีมีเสีย ดังนั้นเราควรชั่งน้ำหนักเสียก่อนว่าจะใช้ของแต่ละอย่างเมื่อไหร่ถึงจะเหมาะสมกับหน้างานที่เราเป็นอยู่ UML จะมีประโยชน์มากถ้าทีมคิดภาพตามไม่ออกเราสามารถเอา diagram ไปช่วยทำให้มันชัดเจนได้ สุดท้ายหลักการในการออกแบบอะไรก็แล้วแต่ หัวใจสำคัญที่สุดของมันคือ การวางแผน หรือที่เราเรียกว่า Strategy นั้นสำคัญที่สุดรองลงมจาก Requirement เลยทีเดียว เพราะต่อให้เราทำทุกอย่างมาดีแค่ไหน แต่มันไม่ใช่แผนที่ดี เราก็อาจจะเสียเวลาเพราะไปทำของที่มันอ้อมค้อมเกินไปก็ได้
ลำดับความสำคัญ หัวใจในการเขียนซอฟต์แวร์จากประสบการณ์และมหาเทพหลายๆคนที่ผมร่ำเรียนมาให้ข้อสรุปตรงกันออกมาเป็นแบบนี้ว่า
Requirement → Strategy → Analysis → Design → Implementation
เพราะถ้าเราเข้าใจ Requirement ไม่ถูก งานทั้งหมดที่ทำมาก็ไร้ความหมายแถมจะโดนลูกค้าด่าอีกต่างหาก
เพราะถ้าเราคิด Strategy ไม่ดี เราอาจจะไปทำสิ่งที่มันอ้อมค้อมและเสียเวลามากกว่าที่มันควรจะเป็น และรวมถึงการเรียงลำดับความสำคัญของงานด้วย
