# 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="" %} ## 🎥 วีดีโอลุงบ๊อบ {% embed url="" %} --- # 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/clean-code/uncle-bob-part-4.md?ask= ``` 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.