# บทสรุปการใช้ 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 %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://www.saladpuk.com/basic/uml/summary.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.