> 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/clean-code/uncle-bob-part-4.md).

# Uncle Bob - Mindset

การทำ Clean Code ตอนที่ 3 จากวีดีโอของ 🧓 **ลุงบ๊อบ** หรือ [**Robert C. Martin**](https://en.wikipedia.org/wiki/Robert_C._Martin) หนึ่งในมหาเทพวงการคอมพิวเตอร์ ซึ่งในรอบนี้เราจะมาดูกันว่า **แนวคิดของโปรแกรมเมอร์ที่ควรจะเป็นมีไรบ้าง** เพราะถ้าหากไม่มีแนวคิดแบบที่ว่ามา การทำ Clean Code ก็จะทำได้ยากขึ้น และ ยิ่งนานเข้าเราก็จะส่งมอบงานได้ช้าลงไปเรื่อยๆนั่นเอง😭

> บอกเลยว่าบทนี้**ลุงบ๊อบแกออกตัวค่อนข้างแรง** และเป็นแนวคิดล้วนๆที่ไม่เกี่ยวกับโค้ดเลย ซึ่งทั้งหมดนั่นบริษัทของ **ดช.แมวน้ำ** นำมาใช้ตั้งแต่วันแรกอยู่แล้วเป็นสิบปี เลยเข้าใจและเห็นประโยชน์ของมันเต็มๆ ดังนั้นจะไม่ขอข้ามซักข้อที่ลุงแกแนะนำมานะขอรับ

{% hint style="success" %}
**แนะนำให้อ่าน**\
บทความนี้เป็นส่วนหนึ่งของบทคอร์ส [👶 **Clean Code**](https://www.saladpuk.com/basic/clean-code) หากเพื่อนๆแมวน้ำสนใจศึกษาเรียนรู้ว่าการทำ Clean Code ว่ามันคืออะไร? มีอะไรบ้าง? บลาๆ ก็สามารถกดที่ชื่อบทความสีฟ้าๆเข้าไปอ่านได้เลยครัช
{% endhint %}

## 🧓 เกริ่น

โปรแกรมคอมพิวเตอร์ทั้งหมดมีจุดเริ่มจากนักคณิตศาสตร์ชื่อ [**Alan Turing**](https://en.wikipedia.org/wiki/Alan_Turing) เพียงคนเดียวในปี 1936 (ทำให้ทุกคนที่เรียนสายคอมต้องเรียนสิ่งที่เรียกว่า [**Turing Machine**](https://en.wikipedia.org/wiki/Turing_machine) นั่นแหละ) และจนสุดท้ายก็ได้คอมพิวเตอร์เครื่องแรกที่ทำงานได้จริงปี 1945 นั่นหมายความว่า **การเขียนโปรแกรมคอมพิวเตอร์พึ่งมีมาไม่นานนี้เอง** โดยเริ่มจากคนเพียงคนเดียว ซึ่งในปี 2019 ถูกบันทึกว่ามีโปรแกรมเมอร์เกิน 26 ล้านคน และมันจะโตขึ้นเป็น 2 เท่าในทุกๆ 5 ปี

> 🧓 ถ้าเราคำนวณดีๆเราจะพบว่า **ครึ่งหนึ่งของโปรแกรมเมอร์มีประสบการณ์ในด้านนี้ไม่ถึง 10 ปีเลย** และ **ถูกสอนโดยอาจารย์ที่ไม่ได้นั่งเขียนโค้ดจริงๆจังๆเพื่อหาเลี้ยงชีพด้วยซ้ำ** ดังนั้นเราเลยจะเห็นโปรแกรมเมอร์ที่ขาดความเป็นมืออาชีพอยู่เต็มไปหมด จึงไม่ใช่เรื่องน่าแปลกใจที่**มหาลัยจะเป็นแค่สถานที่ผลิตโปรแกรมเมอร์ที่ไม่พร้อมออกสู่งานจริง** นั่นเอง

**ความเป็นมืออาชีพจะต้องมาจากการกลั่นความรู้และประสบการณ์จากงานจริงเท่านั้น** ไม่มีทางที่จะนั่งอยู่เฉยๆในวงการนี้แล้วจะเป็นมืออาชีพได้ ดังนั้นเพื่อป้องกันไม่ให้เราสร้างของกากๆออกไป เราจะต้องมีแนวคิด หรือ **Mindset** ในการทำซอฟต์แวร์ตามหัวข้อด้านล่างนี้

{% hint style="info" %}
**เกร็ดความรู้**\
ความรู้ทั้งหมดของสายคอมพิวเตอร์มีต้นกำเหนิดจาก **คณิตศาสตร์** ซึ่งเป็น**หลักในการคิดแบบเป็นเหตุเป็นผลล้วนๆ** หรือเราเรียกว่า **Logical Thinking** นั่นเอง หากใครอยากรู้ว่าหลักการคิดแบบนั้นเป็นยังไงไปอ่านต่อได้ที่[ **คิดแบบตรรกะจำแบบโปรแกรมเมอร์**](https://www.saladpuk.com/v/tips/logic-thinker) (รูปข้างในประกันว่าฮาแน่นอน) และหากสนใจอยากดูว่าคอมเครื่องแรกถูกสร้างมาได้ยังไง (คนสร้างเกือบถูกเอาไปยิงตาย) ก็ไปสามารถไปหาดูหนังได้จากเรื่อง [**The Imitation Game**](https://www.youtube.com/watch?v=nuPZUUED5uk) ครัช
{% endhint %}

## ☝ High Quality Product

ไม่ว่าโปรเจ็คที่ทำจะเล็กน้อยแค่ไหนก็ตาม เมื่อเราจะส่งมอบงานนั้น โค้ดเหล่านั้นจะต้องเป็น **Production Code** ด้วย นั่นหมายความว่าโค้ดที่เราเขียนมันจะต้องเป็น 

* [**Testable Code**](https://www.saladpuk.com/software-testing/tdd101) - สามารถทดสอบโค้ดได้ว่าไม่มีข้อผิดพลาด
* [**Clean Architecture**](https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html) - ออกแบบความรับผิดชอบแต่ละส่วนได้เหมาะสม
* [**Clean Code**](https://www.saladpuk.com/basic/clean-code) - โค้ดแก้ไขเพิ่มเติมได้ง่าย รวมถึงโค้ดเข้าใจได้ง่าย
* [**SOLID** ](https://www.saladpuk.com/basic/solid)- ใช้หลักในการออกแบบที่เหมาะสมกับปัญหาที่เจอ
* [**Manageable** ](https://www.saladpuk.com/basic/devops)- ต้องถูกปรับเปลี่ยนตามสถานะการณ์ได้

> 🧓 ทุกคนบนโลกย่อมคาดหวังงานที่มีคุณภาพเสมอ เช่น เราไปซื้อรถซักคัน เราก็ต้องคาดหวังว่ารถที่เราซื้อมา ถูกทดสอบในทุกๆด้านแล้ว เมื่อนำมาวิ่งจริงต้องไม่เกิดปัญหา และถ้ามีปัญหาร้านที่เราซื้อมาต้องแก้ปัญหาได้ทันทีทันใด นั่นแหละงานที่มีคุณภาพ ดังนั้นซอฟต์แวร์ก็ไม่ต่างจากรถ เพราะเราในฐานะคนสร้างซอฟต์แวร์ก็ไม่อยากส่งของกากๆให้ลูกค้าเช่นกัน (We will not ship shit!! 💩)

## ⏱️ Iteration Length

รูปแบบการทำซอฟต์แวร์ที่เหมาะสมที่สุดในตอนนี้คือ [**Agile** ](https://www.saladpuk.com/basic/agile-methodology)ซึ่งเราจะมีการกำหนดรอบการส่งงาน หรือที่เราเรียกกันว่า **Iteration** หรือ **Sprint** นั่นเอง โดยลุงบ๊อบแนะนำว่า **1 รอบการทำงานควรจะมีระยะเวลาแค่ 1-2 สัปดาห์เท่านั้น ยิ่งสั้นยิ่งดีแต่ไม่ควรสั้นกว่า 1 สัปดาห์** ซึ่งงานที่ส่งมอบจะต้องเป็น High Quality Product ด้วย เพราะยิ่งเราทำ Iteration ได้เร็วนั่นหมายความว่า Business สามารถปรับแผนรับมือกับตลาดได้เร็วขึ้นนั่นเอง

{% hint style="info" %}
**เกร็ดความรู้**\
ในสมัยสงครามโลกครั้งที่ 2 (แมวน้ำจำประเทศไม่ได้แต่เข้าใจว่าเป็นเมกากับเยอรมนี) ซึ่งสมัยนั้นความสามารถเครื่องบินเมกายังไม่สามารถสู้กับเครื่องบินของเยอรมนีได้เลย ทั้งความเร็ว ความแม่นยำ ขีปนาวุธ บลาๆ ดังนั้นในทางทฤษฎีถ้าเครื่องบิน 2 ประเทศนี้เจอกัน ของเมกาย่อมถูกยิงตกก่อนแน่นอน แต่ว่าผลสถิติการสู้กันของเครื่องบินทั้ง 2 ประเทศนี้กลับพบว่า ส่วนใหญ่เครื่องบินเมกาจะชนะ ซึ่งเหตุผลเดียวที่เมกาชนะนั่นคือ **เครื่องบินเมกาสามารถบินกลับลำได้ก่อน** เพราะการที่เครื่องบินจะยิงกันได้ มันจะต้องบินมาอยู่ด้านหลังอีกลำเสียก่อน ดังนั้นแม้ความสามารถเครื่องบินเมกาจะด้อยกว่า แต่เนื่องจาก**การกลับมาอยู่จุดได้เรียบได้เร็วกว่า อัตราชนะเลยสูงกว่า**นั่นเอง . . . กลับมาที่เรื่องของเรา การที่เราสามารถส่งมอบซอฟต์แวร์ได้บ่อยๆ ในระยะเวลาสั้นๆ ย่อมทำให้ด้านธุรกิจสามารถปรับเปลี่ยนกลยุทธ์ตามกระแสตลาดได้เร็วขึ้น ดังนั้นไม่แปลกที่ป๋าแกแนะนำแบบนั้น
{% endhint %}

{% hint style="success" %}
**แนะนำให้อ่าน**\
หากใครที่ยังไม่ได้นำ Agile ไปใช้ หรืออยากศึกษาเพิ่มเติม ว่าเราจะส่งมอบซอฟต์แวร์ให้เร็วและยังคงประสิทธิภาพได้ยังไง แมวน้ำแนะนำให้ศึกษาจากบทความนี้เบยครัช [👦 **Agile Methodology**](https://www.saladpuk.com/basic/agile-methodology)
{% endhint %}

## 🚀 Stable Productivity

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

> 🧓 สาเหตุหลักที่เรายิ่งทำโปรเจคเดิมไปนานๆแล้วมันจะช้าลง ช้าลง กลายเป็นเต่า นั่นก็เพราะว่าเราทำมันรกทิ้งไว้ และ ยิ่งทำก็จะยิ่งรกขึ้นเรื่อยๆ นั่นแหละคือสิ่งที่ทำให้โปรเจคเราช้าลง ดังนั้น Mindset ของโปรแกรมเมอร์มืออาชีพจะต้อง **Clean ทุกอย่างที่เห็นว่ามันรก ที่เห็นว่ามันไม่สมควร** เพื่อเราจะได้ลุยไปข้างหน้าได้เรื่อยๆโดยไม่สะดุดนั่นเอง

{% hint style="success" %}
[**Technical debt**](https://en.wikipedia.org/wiki/Technical_debt)\
ยิ่งทำยิ่งรก ยิ่งทำยิ่งช้า หรือคำที่เราได้ยินกันบ่อยๆว่า **Technical debt** ยังไงล่ะ ซึ่งสังเกตง่ายๆว่า **เมื่อไหร่ก็ตามที่มีปัญหาเกิดขึ้น แล้วเราเลือกแก้ปัญหาแบบง่ายๆไปก่อน** **เพียงแค่นั้นแหละงานของเราก็มี Technical debt แล้ว** เพราะวิธีที่ถูกต้องมันใช้เวลาคิดนานกว่า ไหนจะต้องไปนั่งวิเคราะห์หาต้นเหตุของปัญหา และวิเคราะวิธีการแก้ไขที่เหมาะสม ดังนั้นหลายคนเลย **ติดหนี้** ที่จะคอยกัดกร่อนความเร็วของการทำงานโดยไม่รู้ตัว
{% endhint %}

## 💸 Inexpensive Adaptability

การแก้ไขเปลี่ยนแปลงที่เกิดขึ้นควรมีค่าแลกเปลี่ยนที่เท่าเทียมเสมอ เช่น เมื่อมีการแก้ไขเพิ่มเติมเกิดขึ้น 

* ถ้าการเปลี่ยนนั้น **กระทบหลายส่วน** ก็ควรใช้ เวลา เงิน กำลังคนมาก ในปริมาณมาก
* ถ้าการเปลี่ยนนั้น **กระทบแค่นิดหน่อย** ก็ควรใช้ เวลา เงิน กำลังคน แค่นิดหน่อยเท่านั้นเอง

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

> 🧓 คำว่า **Hardware คือสิ่งที่แก้ไขเปลี่ยนแปลงได้ยาก** (Hard) เพราะมันออกแบบแล้วเปลี่ยนแทบไม่ได้ ซึ่งตรงข้ามกับ **Software ที่มันเป็นของที่เปลี่ยนแปลงง่าย** (Soft) ดังนั้น 💖 **หัวใจหลักของการสร้างซอฟต์แวร์คือการทำให้มันเปลี่ยนแปลงได้ง่าย** ... หากเราทำซอฟต์แวร์ออกมาแล้วต้องมาร้องโอดครวญเพราะมันแก้ไขยาก มันหมายความว่า **คุณ(เอ็ง)ออกแบบ Architecture ได้กากเอง** เพราะมันผิดหลักธรรมชาติของมัน ซึ่งการที่เราจะทำให้ซอฟต์แวร์แก้ไขได้เราจะต้องมีของ 2 อย่างคือ **Clean** และ **Suite of Tests**

{% hint style="info" %}
**เกร็ดความรู้**\
การทำ **Suite of Tests** คือหนึ่งในหัวใจหลักของการทำ **Clean Code** เพราะการที่เราจะไปแก้ไขโค้ดซักตัว เ**ราจะรู้ได้ยังไงว่าที่เราแก้ไปมันจะไม่ทำให้อย่างอื่นพัง?** ดังนั้นการที่เรามี Suite of Tests มันจะเป็นเหมือน **ตาวิเศษ** ที่จะช่วยบอกเราว่า โค้ดที่แก้ไปตะกี้ มันไปทำอะไรพังหรือเปล่านั่นเอง ซึ่งหากเพื่อนๆคนไหนสนใจอยากได้ตาวิเศษอันนี้ไปใช้ในโปรเจค ก็สามารถไปศึกษาเพิ่มเติมได้จากบทความนี้ครัช [👦 **Test-Driven Development**](https://www.saladpuk.com/software-testing/tdd101)
{% endhint %}

## 🦸🏽‍♂️ Continuous Improvement

ทุกๆวันโค้ดกับตัวระบบจะต้องดีขึ้นเรื่อยๆ เพราะโปรแกรมเมอร์จะต้องไม่ทำงานช้าลง ดังนั้น Architecture ในแต่ละวันมันจะต้องสอดคล้องกับความต้องการของลูกค้า และ ดูแลรักษา แก้ไขเพิ่มเติม บลาๆ ต้องทำได้ง่ายยิ่งขึ้นตลอดเวลา ไม่อย่างนั้นทุกข้อที่กล่าวมาก็จะทำได้ยากขึ้น

## 💪 Fearless Competence

**อย่ากลัวที่จะแก้โค้ด** ซึ่งโดยปรกติโปรแกรมเมอร์จะไม่อยากที่จะแก้โค้ดทุกๆอย่าง และยิ่งเป็นของคนอื่นก็จะยิ่งไม่อยากยุ่งเลย เพราะเราไม่รู้ว่าแก้ไปแล้วมันจะมีผลอะไรตามมาหรือเปล่า ซึ่งถ้ามี **คนแก้ต้องรับผิดชอบ** 

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

วิธีการ **แก้โค้ดเน่าคือการทำ Refactor โดยมี Tests คอยสนับสนุน** เพราะไม่อย่างนั้นเราไม่มีทางรู้เลยว่าโค้ดที่แก้มันแก้ 1 พัง 10 หรือเปล่า

{% hint style="success" %}
**แนะนำให้อ่าน**\
**โค้ดเน่า** คือการออกแบบหรือการเขียนโค้ดที่ทำออกมาได้กากๆ ทำให้เกิดปัญหา bug ผุดเป็นดอกเห็น จับนิดแตะหน่อยพัง บลาๆ ซึ่งอาการทั้งหมดของโค้ดเน่ามีอะไรบ้าง สามารถศึกษาได้จากบทความ [👶 **Code Smells**](https://www.saladpuk.com/basic/code-smells)
{% endhint %}

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

วิธีการแก้ปัญหา Fragile Test คือการทำ **Test-Driven Design โดยทำในมุม Abstraction** ไม่อย่างนั้น Coupling จะไม่หายไป

{% hint style="success" %}
**แนะนำให้อ่าน**\
Coupling กับ Cohesion เป็นคำศัพท์พื้นฐานสำคัญในการออกแบบ ถ้าใครอยากทบทวนก็ไปอ่านได้จากบทความนี้เบยครัช [**มารู้จักกับ SOLID กันดีกว่า**](https://www.saladpuk.com/basic/solid/intro)
{% endhint %}

## 🤖 Automation

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

> 🧓 ถ้าคุณโยนงานให้ฝ่าย QA ไปตรวจว่าโค้ดทำงานถูกหรือเปล่า มันจะผิดพลาดได้ง่ายมาก เพราะถ้าเวลามันกระชั้นชิดแล้วมีงานที่ต้องทดสอบล้นมือ ฝ่าย QA ก็ต้องเลือกแค่บางส่วนที่เขาคิดว่าสำคัญมาทดสอบเท่านั้น ซึ่งเอาเข้าจริงๆฝ่าย QA ไม่มีทางเลือกเทสได้ถูก เพราะเขาไม่มีทางรู้เลยว่าโปรแกรมเมอร์ไปแก้โค้ดที่โมดูลไหนบ้าง และมันกระทบกับโมดูลไหนบ้าง ดังนั้น bugs มันก็จะถูกส่งต่อไปให้ผู้ใช้นั่นเอง

คนที่จะตรวจโค้ดได้ดีที่สุดก็คือตัวโปรแกรมเมอร์เอง ซึ่งเราจะต้องสร้างระบบในการตรวจความถูกต้องขึ้นมาเอง และมันจะต้องตรวจเรื่องซ้ำๆเมื่อไหร่ก็ได้ และ ระบบ Automation มันควรที่จะทำเรื่องอื่นๆต่อได้ด้วยตัวมันเองถึงจะได้ประโยชน์สูงสุด

{% hint style="success" %}
**แนะนำให้อ่าน**\
การทำ Automation เป็นการทำให้ระบบทำงานได้ด้วยตัวเอง เช่น ตรวจว่ามี bug หรือเปล่า เอางานไปขึ้นเซิฟเวอร์ให้เรา ตรวจสอบสถานะเซิฟเวอร์ auto backup บลาๆ ซึ่งของเหล่านี้เราเรียกมันว่า Continuous Integration และ Continuous Delivery นั่นเอง ซึ่งเพื่อนๆสามารถศึกษาอ่านต่อได้จาก [👶 **DevOps พื้นฐาน**](https://www.saladpuk.com/basic/devops#build-pipeline) หรือจะไปดูการใช้งานจริงได้จาก ลองทำ [**Continuous Integration (CI)**](https://www.saladpuk.com/cloud/azure-devops/ci) กับ ลองทำ [**Continuous Delivery (CD)**](https://www.saladpuk.com/cloud/azure-devops/cd)
{% endhint %}

## 🤝 We Cover For Each Other

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

> 🧓 การให้ใครก็ตามมาสานงานต่อมันไม่ใช่เรื่องง่าย แต่การที่เราทำ **Pair Programming** จะช่วยทำให้เรื่องเหล่านั้นง่ายขึ้น และการทำ Pair Programming ไม่จำเป็นต้องไปนั่งทำคู่กันตลอดเวลา อาจจะทำสัปดาห์ละ 30-60 นาทีก็ยังได้

{% hint style="info" %}
**เกร็ดความรู้**\
การทำ [**Pair Programming**](https://en.wikipedia.org/wiki/Pair_programming) **คือการให้เดฟ 2 คนนั่งทำงานด้วยกันโดยใช้คอมเดียวกัน ซึ่งถ้าทำถูกจริงๆมันจะเร็วมาก** เพราะมันเป็นวิธีลัดในการสอน เช่นเอา Senior มาจับคู่กับ Junior เขาก็จะได้เรียนรู้ และเป็นการทำ Code Review ย่อยๆเลย อีกทั้งทำให้มีมีคนเข้าใจตัวงานนั้นๆเพิ่มขึ้นด้วย เมื่อจะแก้ไขปรับเปลี่ยนอะไรก็ไม่จำเป็นต้องรอแค่ Senior เท่านั้น หรือมองในอีกมุมคือ มีคนช่วยตรวจสอบความถูกต้องมากขึ้น เพราะบางที Junior ก็อาจะไม่เข้าใจตัวงานจริงๆ ถ้าทำคนเดียวก็จะได้ของแปลกๆมา แล้ว Senior ก็ช่วยปรับความเข้าใจได้นั่นเอง และสุดท้ายเราควรจะเปลี่ยนคนจับคู่ไปเรื่อยๆ เพราะมันจะทำให้ทุกคนในทีมหมุนเวียนแลกเปลี่ยนความรู้ เทคนิค บลาๆ จนทำให้ทุกคนทำงานร่วมกันได้ดีขึ้น และ เข้าใจในงานแต่ละส่วนมากยิ่งขึ้นนั่นเอง (บริษัทส่วนใหญ่จะทำ Pair Programming ไม่ถูกทำให้เห็นว่ามันเสียเวลา แต่ถ้าเข้าใจและทำถูกจริงๆ ในระยะยาวทีมที่ทำ Pair จะมีประสิทธิภาพสูงมากเมื่อเทียบกับทีมที่ไม่ทำ)
{% endhint %}

## 📅 Honest Estimates

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

> 🧓 เราสามารถประมาณเวลาโดยใช้ความจริงช่วยได้ เช่น 
>
> * Best case - ทุกอย่างราบลื่นหมด ทุกคนฟังแล้วเข้าใจ ไม่มีคนลาใดๆตลอดเวลา ไม่มีคนหัวเสีย บลาๆ น่าจะใช้เวลาราวๆ 7 วันนะ
> * Normal case - ไม่ได้ราบลื่นทุกอย่าง มีปัญหาบ้างแต่ก็ค่อยๆแก้ได้ น่าจะใช้เวลาราวๆ 20 วันนะ
> * Worst case - มีปัญหาตลอดเวลา ทั้งเรื่องเทคนิค ทั้งเรื่องคนในทีม บลาๆ น่าจะใช้เวลาราวๆ 45 วันนะ
>
> ซึ่งการที่เราพูดตามความเป็นจริงมันจะช่วยให้ **Manager** สามารถนำไปวิเคราะห์วางแผนต่อได้ เช่น ถ้าเขาต้องการตัวนี้จริงๆภายใน 2 อาทิทตย์ เราจะสามารถตัดตัวที่ไม่จำเป็นตัวไหนออกได้บ้าง? หรือตัวไหนเข้ามาแทนที่ได้บ้าง? เพราะเขาต้องวางแผนในแง่ของธุรกิจต่อนั่นเอง ดังนั้น**ห้ามสัญญาถ้าเราไม่สามารถรักษาสัญญานั้นได้**

## 🙌 ส่งท้ายบท

**การสร้างซอฟต์แวร์มันไม่ได้ยากแต่มันต้องคิดเยอะ** ดังนั้นทุกอย่างที่จะทำให้ทีมทำงานได้ช้าลงเราต้องกำจัดมันทิ้ง จะได้มีเวลาไปคิดออกแบบวิธีการที่เหมาะสม ดังนั้นการทำ **Clean Code, Teamwork, Automation** เป็นสิ่งที่ขาดไม่ได้เลย 

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

{% embed url="<https://www.youtube.com/watch?v=fEbY9KTwrKM>" %}

## 🎥 วีดีโอลุงบ๊อบ

{% embed url="<https://www.youtube.com/watch?v=Qjywrq2gM8o>" %}