| description |
|---|
🤔 Clean Code - แนวคิดของโปรแกรมเมอร์มืออาชีพมีไรบ้าง ? |
การทำ Clean Code ตอนที่ 3 จากวีดีโอของ 🧓 ลุงบ๊อบ หรือ Robert C. Martin หนึ่งในมหาเทพวงการคอมพิวเตอร์ ซึ่งในรอบนี้เราจะมาดูกันว่า แนวคิดของโปรแกรมเมอร์ที่ควรจะเป็นมีไรบ้าง เพราะถ้าหากไม่มีแนวคิดแบบที่ว่ามา การทำ Clean Code ก็จะทำได้ยากขึ้น และ ยิ่งนานเข้าเราก็จะส่งมอบงานได้ช้าลงไปเรื่อยๆนั่นเอง😭
บอกเลยว่าบทนี้ลุงบ๊อบแกออกตัวค่อนข้างแรง และเป็นแนวคิดล้วนๆที่ไม่เกี่ยวกับโค้ดเลย ซึ่งทั้งหมดนั่นบริษัทของ ดช.แมวน้ำ นำมาใช้ตั้งแต่วันแรกอยู่แล้วเป็นสิบปี เลยเข้าใจและเห็นประโยชน์ของมันเต็มๆ ดังนั้นจะไม่ขอข้ามซักข้อที่ลุงแกแนะนำมานะขอรับ
{% hint style="success" %}
แนะนำให้อ่าน
บทความนี้เป็นส่วนหนึ่งของบทคอร์ส 👶 Clean Code หากเพื่อนๆแมวน้ำสนใจศึกษาเรียนรู้ว่าการทำ Clean Code ว่ามันคืออะไร? มีอะไรบ้าง? บลาๆ ก็สามารถกดที่ชื่อบทความสีฟ้าๆเข้าไปอ่านได้เลยครัช
{% endhint %}
โปรแกรมคอมพิวเตอร์ทั้งหมดมีจุดเริ่มจากนักคณิตศาสตร์ชื่อ Alan Turing เพียงคนเดียวในปี 1936 (ทำให้ทุกคนที่เรียนสายคอมต้องเรียนสิ่งที่เรียกว่า Turing Machine นั่นแหละ) และจนสุดท้ายก็ได้คอมพิวเตอร์เครื่องแรกที่ทำงานได้จริงปี 1945 นั่นหมายความว่า การเขียนโปรแกรมคอมพิวเตอร์พึ่งมีมาไม่นานนี้เอง โดยเริ่มจากคนเพียงคนเดียว ซึ่งในปี 2019 ถูกบันทึกว่ามีโปรแกรมเมอร์เกิน 26 ล้านคน และมันจะโตขึ้นเป็น 2 เท่าในทุกๆ 5 ปี
🧓 ถ้าเราคำนวณดีๆเราจะพบว่า ครึ่งหนึ่งของโปรแกรมเมอร์มีประสบการณ์ในด้านนี้ไม่ถึง 10 ปีเลย และ ถูกสอนโดยอาจารย์ที่ไม่ได้นั่งเขียนโค้ดจริงๆจังๆเพื่อหาเลี้ยงชีพด้วยซ้ำ ดังนั้นเราเลยจะเห็นโปรแกรมเมอร์ที่ขาดความเป็นมืออาชีพอยู่เต็มไปหมด จึงไม่ใช่เรื่องน่าแปลกใจที่มหาลัยจะเป็นแค่สถานที่ผลิตโปรแกรมเมอร์ที่ไม่พร้อมออกสู่งานจริง นั่นเอง
ความเป็นมืออาชีพจะต้องมาจากการกลั่นความรู้และประสบการณ์จากงานจริงเท่านั้น ไม่มีทางที่จะนั่งอยู่เฉยๆในวงการนี้แล้วจะเป็นมืออาชีพได้ ดังนั้นเพื่อป้องกันไม่ให้เราสร้างของกากๆออกไป เราจะต้องมีแนวคิด หรือ Mindset ในการทำซอฟต์แวร์ตามหัวข้อด้านล่างนี้
{% hint style="info" %}
เกร็ดความรู้
ความรู้ทั้งหมดของสายคอมพิวเตอร์มีต้นกำเหนิดจาก คณิตศาสตร์ ซึ่งเป็นหลักในการคิดแบบเป็นเหตุเป็นผลล้วนๆ หรือเราเรียกว่า Logical Thinking นั่นเอง หากใครอยากรู้ว่าหลักการคิดแบบนั้นเป็นยังไงไปอ่านต่อได้ที่ คิดแบบตรรกะจำแบบโปรแกรมเมอร์ (รูปข้างในประกันว่าฮาแน่นอน) และหากสนใจอยากดูว่าคอมเครื่องแรกถูกสร้างมาได้ยังไง (คนสร้างเกือบถูกเอาไปยิงตาย) ก็ไปสามารถไปหาดูหนังได้จากเรื่อง The Imitation Game ครัช
{% endhint %}
ไม่ว่าโปรเจ็คที่ทำจะเล็กน้อยแค่ไหนก็ตาม เมื่อเราจะส่งมอบงานนั้น โค้ดเหล่านั้นจะต้องเป็น Production Code ด้วย นั่นหมายความว่าโค้ดที่เราเขียนมันจะต้องเป็น
- ****Testable Code - สามารถทดสอบโค้ดได้ว่าไม่มีข้อผิดพลาด
- ****Clean Architecture - ออกแบบความรับผิดชอบแต่ละส่วนได้เหมาะสม
- ****Clean Code - โค้ดแก้ไขเพิ่มเติมได้ง่าย รวมถึงโค้ดเข้าใจได้ง่าย
- ****SOLID - ใช้หลักในการออกแบบที่เหมาะสมกับปัญหาที่เจอ
- ****Manageable - ต้องถูกปรับเปลี่ยนตามสถานะการณ์ได้
🧓 ทุกคนบนโลกย่อมคาดหวังงานที่มีคุณภาพเสมอ เช่น เราไปซื้อรถซักคัน เราก็ต้องคาดหวังว่ารถที่เราซื้อมา ถูกทดสอบในทุกๆด้านแล้ว เมื่อนำมาวิ่งจริงต้องไม่เกิดปัญหา และถ้ามีปัญหาร้านที่เราซื้อมาต้องแก้ปัญหาได้ทันทีทันใด นั่นแหละงานที่มีคุณภาพ ดังนั้นซอฟต์แวร์ก็ไม่ต่างจากรถ เพราะเราในฐานะคนสร้างซอฟต์แวร์ก็ไม่อยากส่งของกากๆให้ลูกค้าเช่นกัน (We will not ship shit!! 💩)
รูปแบบการทำซอฟต์แวร์ที่เหมาะสมที่สุดในตอนนี้คือ Agile ซึ่งเราจะมีการกำหนดรอบการส่งงาน หรือที่เราเรียกกันว่า Iteration หรือ Sprint นั่นเอง โดยลุงบ๊อบแนะนำว่า 1 รอบการทำงานควรจะมีระยะเวลาแค่ 1-2 สัปดาห์เท่านั้น ยิ่งสั้นยิ่งดีแต่ไม่ควรสั้นกว่า 1 สัปดาห์ ซึ่งงานที่ส่งมอบจะต้องเป็น High Quality Product ด้วย เพราะยิ่งเราทำ Iteration ได้เร็วนั่นหมายความว่า Business สามารถปรับแผนรับมือกับตลาดได้เร็วขึ้นนั่นเอง
{% hint style="info" %}
เกร็ดความรู้
ในสมัยสงครามโลกครั้งที่ 2 (แมวน้ำจำประเทศไม่ได้แต่เข้าใจว่าเป็นเมกากับเยอรมนี) ซึ่งสมัยนั้นความสามารถเครื่องบินเมกายังไม่สามารถสู้กับเครื่องบินของเยอรมนีได้เลย ทั้งความเร็ว ความแม่นยำ ขีปนาวุธ บลาๆ ดังนั้นในทางทฤษฎีถ้าเครื่องบิน 2 ประเทศนี้เจอกัน ของเมกาย่อมถูกยิงตกก่อนแน่นอน แต่ว่าผลสถิติการสู้กันของเครื่องบินทั้ง 2 ประเทศนี้กลับพบว่า ส่วนใหญ่เครื่องบินเมกาจะชนะ ซึ่งเหตุผลเดียวที่เมกาชนะนั่นคือ เครื่องบินเมกาสามารถบินกลับลำได้ก่อน เพราะการที่เครื่องบินจะยิงกันได้ มันจะต้องบินมาอยู่ด้านหลังอีกลำเสียก่อน ดังนั้นแม้ความสามารถเครื่องบินเมกาจะด้อยกว่า แต่เนื่องจากการกลับมาอยู่จุดได้เรียบได้เร็วกว่า อัตราชนะเลยสูงกว่านั่นเอง . . . กลับมาที่เรื่องของเรา การที่เราสามารถส่งมอบซอฟต์แวร์ได้บ่อยๆ ในระยะเวลาสั้นๆ ย่อมทำให้ด้านธุรกิจสามารถปรับเปลี่ยนกลยุทธ์ตามกระแสตลาดได้เร็วขึ้น ดังนั้นไม่แปลกที่ป๋าแกแนะนำแบบนั้น
{% endhint %}
{% hint style="success" %}
แนะนำให้อ่าน
หากใครที่ยังไม่ได้นำ Agile ไปใช้ หรืออยากศึกษาเพิ่มเติม ว่าเราจะส่งมอบซอฟต์แวร์ให้เร็วและยังคงประสิทธิภาพได้ยังไง แมวน้ำแนะนำให้ศึกษาจากบทความนี้เบยครัช 👦 Agile Methodology****
{% endhint %}
ไม่ว่าจะผ่านไปนานแค่ไหนก็ตาม เราต้องสามารถส่งมอบงานได้เร็วเท่าวันแรกที่เริ่มทำโปรเจคเสมอ หรือพูดสั้นๆว่า เราต้องไม่ทำงานช้าลง นั่นเอง ซึ่งข้อดีของเรื่องนี้คือ ทุกครั้งที่มีการเพิ่ม Feature หรือความสามารถใหม่ๆเข้ามา ทีมก็จะส่งมอบงานได้เร็วเช่นเคย
🧓 สาเหตุหลักที่เรายิ่งทำโปรเจคเดิมไปนานๆแล้วมันจะช้าลง ช้าลง กลายเป็นเต่า นั่นก็เพราะว่าเราทำมันรกทิ้งไว้ และ ยิ่งทำก็จะยิ่งรกขึ้นเรื่อยๆ นั่นแหละคือสิ่งที่ทำให้โปรเจคเราช้าลง ดังนั้น Mindset ของโปรแกรมเมอร์มืออาชีพจะต้อง Clean ทุกอย่างที่เห็นว่ามันรก ที่เห็นว่ามันไม่สมควร เพื่อเราจะได้ลุยไปข้างหน้าได้เรื่อยๆโดยไม่สะดุดนั่นเอง
{% hint style="success" %}
****Technical debt
ยิ่งทำยิ่งรก ยิ่งทำยิ่งช้า หรือคำที่เราได้ยินกันบ่อยๆว่า Technical debt ยังไงล่ะ ซึ่งสังเกตง่ายๆว่า เมื่อไหร่ก็ตามที่มีปัญหาเกิดขึ้น แล้วเราเลือกแก้ปัญหาแบบง่ายๆไปก่อน เพียงแค่นั้นแหละงานของเราก็มี Technical debt แล้ว เพราะวิธีที่ถูกต้องมันใช้เวลาคิดนานกว่า ไหนจะต้องไปนั่งวิเคราะห์หาต้นเหตุของปัญหา และวิเคราะวิธีการแก้ไขที่เหมาะสม ดังนั้นหลายคนเลย ติดหนี้ ที่จะคอยกัดกร่อนความเร็วของการทำงานโดยไม่รู้ตัว
{% endhint %}
การแก้ไขเปลี่ยนแปลงที่เกิดขึ้นควรมีค่าแลกเปลี่ยนที่เท่าเทียมเสมอ เช่น เมื่อมีการแก้ไขเพิ่มเติมเกิดขึ้น
- ถ้าการเปลี่ยนนั้น กระทบหลายส่วน ก็ควรใช้ เวลา เงิน กำลังคนมาก ในปริมาณมาก
- ถ้าการเปลี่ยนนั้น กระทบแค่นิดหน่อย ก็ควรใช้ เวลา เงิน กำลังคน แค่นิดหน่อยเท่านั้นเอง
แต่บ่อยครั้งที่เรามองกลับมาที่โปรเจคของเรา เมื่อมีการแก้ไขเพิ่มเติมเกิดขึ้น เหล่าโปรแกรมเมอร์ก็จะกรีดร้อง แล้วกร่นด่า ให้เหตุผลสารพัดออกมาว่าทำไมถึงทำได้ยาก ขัดกับ 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****
{% endhint %}
ทุกๆวันโค้ดกับตัวระบบจะต้องดีขึ้นเรื่อยๆ เพราะโปรแกรมเมอร์จะต้องไม่ทำงานช้าลง ดังนั้น Architecture ในแต่ละวันมันจะต้องสอดคล้องกับความต้องการของลูกค้า และ ดูแลรักษา แก้ไขเพิ่มเติม บลาๆ ต้องทำได้ง่ายยิ่งขึ้นตลอดเวลา ไม่อย่างนั้นทุกข้อที่กล่าวมาก็จะทำได้ยากขึ้น
อย่ากลัวที่จะแก้โค้ด ซึ่งโดยปรกติโปรแกรมเมอร์จะไม่อยากที่จะแก้โค้ดทุกๆอย่าง และยิ่งเป็นของคนอื่นก็จะยิ่งไม่อยากยุ่งเลย เพราะเราไม่รู้ว่าแก้ไปแล้วมันจะมีผลอะไรตามมาหรือเปล่า ซึ่งถ้ามี คนแก้ต้องรับผิดชอบ
🧓 ถ้าเรามี Mindset แบบนี้มันจะทำให้เราแก้โค้ดเฉพาะจุดที่ไม่กระทบกับตัวเองเท่านั้น ซึ่งนั่นไม่ใช่การตัดสินใจออกแบบที่ดี เพราะต้นเหตุของปัญหามันไม่ได้ถูกแก้ ดังนั้นยิ่งปล่อยทิ้งไว้โค้ดก็จะเน่าลงไปเรื่อยๆ ทำให้เราทำงานได้ช้าลงไปทุกครั้งที่มีคนมาแก้ไขโค้ด
วิธีการ แก้โค้ดเน่าคือการทำ Refactor โดยมี Tests คอยสนับสนุน เพราะไม่อย่างนั้นเราไม่มีทางรู้เลยว่าโค้ดที่แก้มันแก้ 1 พัง 10 หรือเปล่า
{% hint style="success" %}
แนะนำให้อ่าน
โค้ดเน่า คือการออกแบบหรือการเขียนโค้ดที่ทำออกมาได้กากๆ ทำให้เกิดปัญหา bug ผุดเป็นดอกเห็น จับนิดแตะหน่อยพัง บลาๆ ซึ่งอาการทั้งหมดของโค้ดเน่ามีอะไรบ้าง สามารถศึกษาได้จากบทความ 👶 Code Smells****
{% endhint %}
🧓 ลุงเจอการเขียน Test ที่ไปพันกับระบบบ่อยครั้ง แล้วเมื่อระบบเปลี่ยนมันก็จะทำให้ Test พัง ต้องกลับไปแก้ทุกครั้ง ซึ่งนั่นก็เป็น Fragile Test หรือเทสเน่าในอีกรูปแบบ และโดยส่วนมากจะเกิดกับคนที่เขียนเทสไม่ชำนาญ เพราะดันไปออกแบบให้มันเกิด Coupling กัน
วิธีการแก้ปัญหา Fragile Test คือการทำ Test-Driven Design โดยทำในมุม Abstraction ไม่อย่างนั้น Coupling จะไม่หายไป
{% hint style="success" %}
แนะนำให้อ่าน
Coupling กับ Cohesion เป็นคำศัพท์พื้นฐานสำคัญในการออกแบบ ถ้าใครอยากทบทวนก็ไปอ่านได้จากบทความนี้เบยครัช มารู้จักกับ SOLID กันดีกว่า****
{% endhint %}
เราจะไม่สามารถทำงานเร็วขึ้นได้เลยถ้ามันทำ Automation ไม่ได้ เพราะการทำ Automation คือการโยนภาระทั้งหมดของคนไปให้คอมพิวเตอร์ทำแทน เนื่องจากคอมมันทำงานได้เร็วกว่า ประหยัดค่าใช้จ่ายกว่า และโอกาสผิดพลาดน้อย เมื่อเทียบกับการให้คนมานั่งทำของเหล่านั้นเอง
🧓 ถ้าคุณโยนงานให้ฝ่าย QA ไปตรวจว่าโค้ดทำงานถูกหรือเปล่า มันจะผิดพลาดได้ง่ายมาก เพราะถ้าเวลามันกระชั้นชิดแล้วมีงานที่ต้องทดสอบล้นมือ ฝ่าย QA ก็ต้องเลือกแค่บางส่วนที่เขาคิดว่าสำคัญมาทดสอบเท่านั้น ซึ่งเอาเข้าจริงๆฝ่าย QA ไม่มีทางเลือกเทสได้ถูก เพราะเขาไม่มีทางรู้เลยว่าโปรแกรมเมอร์ไปแก้โค้ดที่โมดูลไหนบ้าง และมันกระทบกับโมดูลไหนบ้าง ดังนั้น bugs มันก็จะถูกส่งต่อไปให้ผู้ใช้นั่นเอง
คนที่จะตรวจโค้ดได้ดีที่สุดก็คือตัวโปรแกรมเมอร์เอง ซึ่งเราจะต้องสร้างระบบในการตรวจความถูกต้องขึ้นมาเอง และมันจะต้องตรวจเรื่องซ้ำๆเมื่อไหร่ก็ได้ และ ระบบ Automation มันควรที่จะทำเรื่องอื่นๆต่อได้ด้วยตัวมันเองถึงจะได้ประโยชน์สูงสุด
{% hint style="success" %}
แนะนำให้อ่าน
การทำ Automation เป็นการทำให้ระบบทำงานได้ด้วยตัวเอง เช่น ตรวจว่ามี bug หรือเปล่า เอางานไปขึ้นเซิฟเวอร์ให้เรา ตรวจสอบสถานะเซิฟเวอร์ auto backup บลาๆ ซึ่งของเหล่านี้เราเรียกมันว่า Continuous Integration และ Continuous Delivery นั่นเอง ซึ่งเพื่อนๆสามารถศึกษาอ่านต่อได้จาก 👶 DevOps พื้นฐาน หรือจะไปดูการใช้งานจริงได้จาก ลองทำ Continuous Integration (CI) กับ ลองทำ Continuous Delivery (CD)****
{% endhint %}
ทุกคนในทีมต้องช่วยเหลือซึ่งกันไม่เกี่ยงงานกัน เพราะงานของทุกคนมันก็คืองานของทีม หากมีใครทำไม่เสร็จก็หมายถึงทั้งทีมทำไม่เสร็จ ดังนั้นเมื่อมีหนึ่งคนล้มไป คนที่เหลือในทีมจะต้องเข้ามาสานงานต่อได้ทันที
🧓 การให้ใครก็ตามมาสานงานต่อมันไม่ใช่เรื่องง่าย แต่การที่เราทำ Pair Programming จะช่วยทำให้เรื่องเหล่านั้นง่ายขึ้น และการทำ Pair Programming ไม่จำเป็นต้องไปนั่งทำคู่กันตลอดเวลา อาจจะทำสัปดาห์ละ 30-60 นาทีก็ยังได้
{% hint style="info" %}
เกร็ดความรู้
การทำ Pair Programming คือการให้เดฟ 2 คนนั่งทำงานด้วยกันโดยใช้คอมเดียวกัน ซึ่งถ้าทำถูกจริงๆมันจะเร็วมาก เพราะมันเป็นวิธีลัดในการสอน เช่นเอา Senior มาจับคู่กับ Junior เขาก็จะได้เรียนรู้ และเป็นการทำ Code Review ย่อยๆเลย อีกทั้งทำให้มีมีคนเข้าใจตัวงานนั้นๆเพิ่มขึ้นด้วย เมื่อจะแก้ไขปรับเปลี่ยนอะไรก็ไม่จำเป็นต้องรอแค่ Senior เท่านั้น หรือมองในอีกมุมคือ มีคนช่วยตรวจสอบความถูกต้องมากขึ้น เพราะบางที Junior ก็อาจะไม่เข้าใจตัวงานจริงๆ ถ้าทำคนเดียวก็จะได้ของแปลกๆมา แล้ว Senior ก็ช่วยปรับความเข้าใจได้นั่นเอง และสุดท้ายเราควรจะเปลี่ยนคนจับคู่ไปเรื่อยๆ เพราะมันจะทำให้ทุกคนในทีมหมุนเวียนแลกเปลี่ยนความรู้ เทคนิค บลาๆ จนทำให้ทุกคนทำงานร่วมกันได้ดีขึ้น และ เข้าใจในงานแต่ละส่วนมากยิ่งขึ้นนั่นเอง (บริษัทส่วนใหญ่จะทำ Pair Programming ไม่ถูกทำให้เห็นว่ามันเสียเวลา แต่ถ้าเข้าใจและทำถูกจริงๆ ในระยะยาวทีมที่ทำ Pair จะมีประสิทธิภาพสูงมากเมื่อเทียบกับทีมที่ไม่ทำ)
{% endhint %}
ทีมต้องกล้าที่จะพูดความจริง ในหลายๆครั้งที่ทีมถูกถามว่าจะใช้เวลาทำนานแค่ไหน เราต้องบอกความจริงที่เป็นไปได้เท่านั้น ซึ่งถ้าทำตามสัญญาไม่ได้ ทีมก็จะไม่ได้รับความเชื่อใจ และ เสียกำลังใจในการทำงาน เพราะในโลกของธุรกิจสัญญาถือเป็นเรื่องใหญ่มาก แค่ผิดสัญญาที่ให้ไว้บริษัทอาจจะทำธุรกิจต่อไม่ได้เลย ดังนั้นบริษัทอาจจะมีปัญหาเพราะทีมเดฟไปสัญญาที่รักษาไม่ได้นั่นเอง
🧓 เราสามารถประมาณเวลาโดยใช้ความจริงช่วยได้ เช่น
- 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" %}