> For the complete documentation index, see [llms.txt](https://www.saladpuk.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.saladpuk.com/basic/uml/summary.md).

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

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

{% hint style="info" %}
**แนะนำให้อ่าน**\
บทความนี้เป็นส่วนหนึ่งของคอร์ส [👶 UML พื้นฐาน](https://saladpuk.gitbook.io/learn/basic/uml) หากเพื่อนๆสนใจอยากดูรายละเอียดของ UML แต่ละตัวว่ามันมีอะไรบ้างก็สามารถกดลิงค์ที่ชื่อคอร์สเข้าไปดูได้เลยนะ หรือจะดูหมวดอื่นๆจาก side menu ก็ได้เน่อ
{% endhint %}

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

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

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

![](/files/-LofQDi1ZO1O8YpdklJ1)

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

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

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

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

![มองภาพไม่ชัดกดเพื่อขยายดูได้นะ](/files/-M-VM1GSqXfaou8fKkD-)

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

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

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

### 👍 ข้อดี

* ทุกคนเข้าใจกันได้เร็วขึ้น และเห็นเป็นภาพเดียวกัน
* ป้องกันข้อผิดพลาดได้ก่อนที่มันจะกลายเป็นโค้ด
* เพิ่มประสิทธิภาพในการออกแบบ

### 👎 ข้อเสีย

* แผนภาพมันก็คือเป็นแค่นั้นจริงๆ ไม่ได้หมายความว่าโค้ดจะเป็นแบบนั้น
* ถ้าออกแบบโดยไม่คิดถึง scenarios จะทำให้โค้ดซับซ้อนโดยไม่จำเป็น
* เสียเวลาในการทำให้มันสวย

## 🎯 บทสรุป

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

{% hint style="success" %}
**ลำดับความสำคัญ**\
หัวใจในการเขียนซอฟต์แวร์จากประสบการณ์และมหาเทพหลายๆคนที่ผมร่ำเรียนมาให้ข้อสรุปตรงกันออกมาเป็นแบบนี้ว่า

Requirement → Strategy → Analysis → Design → Implementation

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

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