TDD สิ่งดีดีที่ Skip ไม่ได้จริงดิ ?

หลายคนคงได้ยินคำว่า “TDD” กันบ่อยๆ ล่าสุดเราได้มีโอกาสเรียน คอร์ส TDD โดยพี่ปอนด์กับพี่จั๊วะ วันนี้เลยมีพลังอันแรงกล้า อยากส่งต่อ ให้ทุกๆคนได้อ่านกัน

ซึ่งเราค้นพบว่า Test ไม่ได้เป็นแค่ Test แต่เป็นทุกอย่างให้เธอแล้วจริงๆ

Mob Programming (มารุมทำ TDD กัน ทั้งClass)

TDD stand for ?

• TDD มาจากคำว่า Test Driven Development คือเราพัฒนาซอฟต์แวร์โดยใช้ Test เป็นตัวขับเคลื่อนนั่นเอง
• การทำ TDD จะมีอยู่ 3 ขั้นตอนคือ เขียน Test และรันให้ fail จากนั้นเขียน Code แบบง่ายๆ แล้วไปรัน Test ให้ผ่าน สุดท้ายคือกลับมา Refactor code ที่เขียนไปให้ดีขึ้น และทำวนไปเรื่อยๆ

ก่อนที่เราจะลงลึกไปยังสิ่งที่ได้เรียนรู้มา เรามาเล่าแบบ follow timeline กันดีกว่าว่าใน Class มีอะไรบ้าง แล้วเก็บสิ่งเล็กๆจากแต่ละช่วงมาอย่างไร …

บรรยากาศตอนทำ TDD แบบคนเดียวโดยสมมติว่าเรา เป็นพนักงานในช่วงฟองสบู่แตก

Check-in 📌

เริ่มมาด้วยการที่ทุกคนต้องแนะนำตัวกัน โดยที่วิธีแนะนำตัวคือ เราจะต้องตอบคำถามทั้งหมด 4 คำถาม ตามนี้

ชื่ออะไร, ชอบเขียนภาษาอะไร, ทำ TDD มาแล้วกี่เดือน, หวังว่าจะได้อะไรกลับไป

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

• ตรงส่วนนี้เราเป็นคนนึงที่ทำป้ายชื่ออันนี้หล่นบ่อยมาก จนกระทั่งเริ่มเบื่อเลยแปะมันลงบนคอมพิวเตอร์แทน
• ผ่านไปสักพักสิ่งที่เราสังเกตเห็นคือคนส่วนใหญ่ก็มีทำหล่นกันบ้างนะ แต่หลายคนก็เอามันขึ้นมาแปะไว้กับตัวเหมือนเดิมไม่ทางใดก็ทางหนึ่ง
• เห็นแบบนั้นเราก็เลยเอาป้ายชื่อบริษัทมาแขวนไว้และเอาเจ้าป้ายชื่อ Post-it Handmade มาแปะไว้อีกที ซึ่งก็แน่นพอที่จะไม่หล่นอีกแล้ว (เพราะป้ายบริษัทเป็นพลาสติก)
• ถึงตรงนี้เรานึกขึ้นเลยว่า Culture ก็เป็นอีกเรื่องนึงที่จะทำให้บางอย่างเกิดขึ้นและคงอยู่ไปได้นาน
• ถึงจะเป็นเรื่องเล็ก แต่ถ้าทุกๆคนช่วยกันประคับประคองมันก็จะยังคงหาทางไปต่อได้เสมอไม่ทางใดก็ทางหนึ่งเช่นกัน

ชอบเขียนภาษาอะไรกัน (ภาพแรก) , ทำ TDD กันมาแล้วกี่เดือน (ภาพกลาง), หวังว่าจะได้อะไรกลับไป (ภาพสุดท้าย)

Let’s Kata together ✨

ถัดมาเรามาทำ Kata กัน โดย การ Kata เป็นเหมือนการฝึกฝนรูปแบบนึง เราทำเรื่องเดิมๆ ซ้ำๆ ในทุกๆวัน จนกลายเป็น muscle memory กันเลยทีเดียว

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

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

เพิ่มอีกนิดนึง เราไปอ่านเจอมาใน hatoriz.com เขาบอกว่า “Kata คือทำการฝึกฝนทักษะที่สำคัญอย่างสม่ำเสมอ”

เกิดอะไรขึ้นใน Class ??

เริ่มต้นมา ภาพที่แรกที่เราเห็นคือภาพด้านล่างนี้

https://checkio.org/ แหล่งรวมโจทย์ที่หลากหลายให้ฝ่าฟัน

แว็บแรกที่เห็นนี่คือ อื้อหืออ~ นี่เกมใช่ไหม ปรากฎว่าอ้าวเกมจริงๆนี่หว่า แต่เป็น Coding Game แบบนึงที่มีโจทย์ให้เราได้ฝึกฝนกันนับไม่ถ้วนกันเลยทีเดียวลองเข้าไปเล่นกันได้ที่ https://checkio.org/

ซึ่งเราก็เริ่ม “กาตะ” กันด้วยโจทย์ Fizzbuzz ในตำนาน

โจทย์คือ มี function ที่รับเลขจำนวนเต็มบวกมา โดย return ค่าตามเงื่อนไขดังนี้

• “Fizz Buzz” เมื่อตัวเลขที่รับเข้ามาหาร 3 และ 5 ลงตัว
• “Fizz” เมื่อตัวเลขที่รับเข้ามาหาร 3 ลงตัว
• “Buzz” เมื่อตัวเลขที่รับเข้ามาหาร 5 ลงตัว
• และ return ตัวเลขที่รับเข้ามาหากไม่ตรงเงื่อนไขใด

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

“โชคดีได้งานใหม่พอดี แต่เราต้องเริ่มงานต่อจากพนักงานคนเก่าที่ออกไป” … และนั่นก็คือเราต้องไปนั่งเขียน Code ต่อที่เครื่องของคนอื่นนั่นเอง ผ่ามผ๊ามมม ~

ลองนึกภาพดูเล่นๆ ว่า ทุกคนที่ไปเรียนด้วยกันวันนั้น ไม่ได้เขียนภาษาเดียวกันหมด และแน่นอนว่าวิธีคิดของแต่ละคนก็ไม่เหมือนกันเลย

ทำให้นึกภาพออกเลยว่า เวลาเราไปทำงานต่อจากใครสิ่งที่จะเกิดขึ้นคืออะไร หลังจากนั้นเราก็ศึกษาวิธีคิดของคนอื่นๆ และเขียน Code กันต่อ

ตัวอย่าง การแก้โจทย์ FizzBuzz ด้วย Python

และการนั่งเขียน Code เครื่องคนอื่นนั้นก็เป็นเหมือนชนวลไปสู่ช่วงถัดไป …

Working with legacy code 📝

Photo by Niklas Hamann on Unsplash

Photo by NeONBRAND on Unsplash

ในโลกแห่งความเป็นจริงบางครั้งเราก็ไม่ได้เริ่มจากทุ่งโล่ง

มันอาจไม่ได้สวยงามแบบทุ่งลาเวนเดอร์ มันอาจเป็นป่าดิบชื้นรกร้างหรือกองขยะก็เป็นได้

Software ก็เช่นกัน เราอาจพบว่าหลายครั้งที่เริ่มงานใหม่ ก็เริ่มจากที่ที่มีอารยธรรมบางอย่างอยู่แล้ว

มีเรื่องเกี่ยวกับ boy scout rule ที่ได้ถูกกล่าวถึง จะมีกฏนึงนั่นคือ

“Always leave the campground cleaner than you found it”.

เมื่อออกจาก Camp แล้วมันจะต้องสะอาดกว่าตอนที่เข้ามาเสมอ

และสิ่งที่สวยงามอยู่แล้วมันจะยิ่งสวยงามยิ่งขึ้นไปอีก

https://medium.com/@biratkirat/step-8-the-boy-scout-rule-robert-c-martin-uncle-bob-9ac839778385

TDD.

กล่าวได้ว่า Test เป็นเหมือน Executable Requirement Document

กงล้อแห่งการทำ TDD ที่ควรจำให้ขึ้นใจ

นึกภาพดูเล่นๆว่า เรามี List ของ Requirement อยู่ในมือ และเพื่อให้แน่ใจว่า ระบบเป็นไปตามความต้องการหรือไม่นั้น เราต้องไล่อ่านไปทีละข้อ ว่า Software ที่เราพัฒนาขึ้นมาทำงานถูกต้องตามความต้องการแค่ไหน และเมื่อได้พัฒนา Feature ใหม่ขึ้น เราก็ต้องกลับมาตรวจสอบ Requirement Document ดูอีกครั้ง

Test เป็นเหมือน Requirement Document ที่ Execute ได้

แบบถ้าเป็น file word ปกติคือเราต้องมาอ่านใช่ไหมว่า software ที่สร้างขึ้นมานี่ ทำงานถูกต้องตรงตามความต้องการแค่ไหน

แต่พอมาเป็น test ที่รันได้มันก็จะมองเห็นชัดๆเลยว่า โอเคข้อนี้เขียวตรงตาม Requirement ข้อนี้แดง ไม่ตรงตาม Requirement

Pair Programming.

การ Pair Programming ก็คือการที่เราใช้ 2 สมอง และอีก 1 เครื่องคอมพิวเตอร์ เพื่อแก้โจทย์ปัญหาด้วยกัน ซึ่งพูดง่ายๆก็คือ Developer 2 คนมาสุมหัวร่วมด้วยช่วยกันเขียน Code และจริงๆ มันก็มีโครงสร้างของการทำ Pair Programing ด้วยตัวอย่างเช่น Driver-Navigator, Ping pong เป็นต้น

• Driver-Navigator ให้เรานึกภาพว่าเรากำลังออกเดินทางไป Road trip ที่ไหนสักแห่ง ไปกันสองคน มีคนนึงเป็นคนขับ และอีกคนคอยบอกทาง นั่นก็คือ Driver จะเป็นคนกุมคีย์บอร์ด ในขณะที่ Navigator จะคอยช่วยมองดูความผิดพลาดต่างๆ และมองเรื่อง Architecture ซึ่งการ Pair Programing แบบนี้จะไปได้สวยเมื่อ Navigator มีความเชี่ยวชาญในระดับนึงนั่นเอง
• Ping pong ก็คือการ Pair Programing และทำ TDD ไปด้วยนั่นเองนั่นคือ หนึ่งคน ทำหนึ่งอย่างและวนไปเรื่อยๆ เช่น

Developer A: เขียน 1 Test
Developer B: เขียน Code
Developer A: Refactor
และ Developer B ก็วนกลับมาเขียน Test ไปเรื่อยๆ นั่นเอง

Mob Programming.

ทำไมบางครั้งหลายหัวจึงดีกว่าหัวเดียว, ใช่แล้ว Mob Programing ก็คือการรุมกันเขียน Code แบบมากกว่า 3 คนขึ้นไปนั่นเอง

ซึ่งการทำ Mob programing นั้นก็มีกฎอยู่ว่า จะต้องมี หนึ่งคนเป็น Driver (คนพิมพ์) ซึ่ง Driver จะเป็นผู้เดียวเท่านั้นที่แก้ Code ได้ และมีอีกหนึ่งคนเป็น Navigator ซึ่งจะเป็นคนคอยคิด คอยตัดสินใจ review และนำให้เกิดการ Discuss กัน Navigator ห้ามจับคีย์บอร์ดเด็ดขาด และคนอื่นๆที่เหลือก็จะรอเปลี่ยน Role ไปเรื่อยๆ

Code Smell.

ของที่ Test ง่ายคือของที่ถอดประกอบ แกะ ง่าย มี loose coupling สูง เป็นทักษะที่ต้อง อาศัยการฝึกฝน ถึงจะดีขึ้น สิ่งสำคัญ คือเราสามารถมองเห็นหรือสัมผัสได้ ถึงสิ่งที่จะนำไปสู่การเกิดปัญหาในอนาคต หรืออาจเป็น error ที่แอบแฝงอยู่

Refactoring .

การ Refactoring คือการที่เราทำให้ Codeที่ ทำงานได้อยู่แล้วนั้นมีประสิทธิภาพ มากขึ้น อาจจะทำให้ Run เร็วขึ้น อ่านง่ายขึ้น หรือป้องกันความผิดพลาดในอนาคตได้ดียิ่งขึ้น ซึ่งเราควรเดินตามลำดับขั้น ทีละน้อยๆ แล้ว Run Test บ่อยๆ
ใช่แล้ว เราสามารถ Refactor Code ได้อย่างสบายใจเมื่อรู้ว่าเราได้เขียน Test เพื่อให้มั่นใจว่า Software ของเรายังเป็นไปตาม Requirement อยู่

อย่า Refactor ถ้าไม่มั่นใจว่าสิ่งที่พยายาม จะ Improve นั้นไปกระทบส่วนอื่นหรือเปล่า
เพราะฉะนั้นเรามาเขียน Test กัน เย้~

Closing.

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

ทิ้งท้ายไว้ด้วยสิ่งเหล่านี้

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

You can’t perform better until you practice