สรุปจาก Practical unit testing(GDC 2014): DEEP anti-pattern

สวัสดีครับ บล็อกนี้เรามาต่อกันที่ anti-pattern ตัวที่ 3 ก็คือ DEEP anti-pattern

ปัญหาคือเวลามี test ที่ไม่ผ่านแล้ว ดูที่ result แล้วมันดูไม่ออกว่ามันพังอะไร

ส่วนใหญ่ที่มีปัญหานี้เกิดจากการที่ test นั้นมันมี  assertion หลายๆอัน ซึ่งละเมิดหลักการเขียน unit test ที่ควรจะมี explicit assertion เพียงอันเดียว

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

ทางแก้ก็คือให้แยะ test case ออกมาให้ชัดเจนไปเลยครับ

ทีนี้ เมื่อมาดูผลของการรัน test ก็จะพบว่าอ่านรู้เรื่องมากขึ้น น่าจะนำมาซึ่งการแก้ไขที่ง่ายขึ้นนะ ดังนั้นเราควรจะลดจำนวน assertion ใน test  ให้เหลือน้อยที่สุดเท่าที่เป็นไปได้นะครับ 

สรุปจาก Practical unit testing(GDC 2014): WET anti-pattern

ต่อจากบล็อกที่แล้วนะครับ มาดู anti pattern ลำดับต่อมากัน

WET anti-pattern

มันคืออะไร ลองไปค้นในกู้กิ้ลดูก็เจอ wikipedia อันนี้ครับ

https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

ก็ประมาณว่า WET เนี่ยมันจะย่อมาจาก Write Everything Twice หรือ We Enjoy Typing ก็ได้

แปลลวกๆก็คือ การที่เราชอบพิมอะไรเยอะๆ หลายๆครั้งนั่นเอง (ก็อปวางก็เข้าข่ายนะครับ อิอิ)

ในวีดีโอนั้นยกตัวอย่างว่า เวลาเราแก้ไขโค้ดจริงแล้ว test มันพัง(ซึ่งก็ถูกแล้วนะ) ที่นี้พอไปดูว่า test มันพังตรงไหนก็เจอเพียบเลย อย่างนี้ test มันก็มาขัดขวางการทำงานของเราน่ะสิ!

สาเหตุก็มากจากเจ้า WET นี่เองครับ ลองดูจากตัวอย่างที่เค้ายกมา จะเห็นว่า ใน test มันมีอะไรซ้ำๆกันเยอะเลย

ก็คือใน test  ของเราไม่ได้ยึดหลัก DRY(Don’t Repeat Yourself) เลยนะ!

ดังนั้นจึงควรแก้ไขโดยการ extract  มันออกมาเป็น helper function ซะ

ตรง Assertion ก็เช่นกันควรทำให้มันสื่อสารให้ชัดเจนว่าเราต้องการทดสอบอะไร เพื่อให้ test ของเรามันแก้ไขดูแลรักษาได้ง่าย แนะนำให้สร้าง Custom assert ขึ้นมาเลยครับ

แต่จุดที่ควรจะปล่อยเอาไว้คือ ในส่วนที่เป็น Act ต้องคงไว้ เพราะมันคือสาระสำคัญของ test ของเราครับ

สรุปอีกที่ WET anti-pattern  ก็คือการที่เราปล่อยให้มีโค้ดที่ซ้ำๆกันในเทส แล้วละเลยไม่ได้จัดการอะไรกับโค้ดซ้ำๆเหล่านั้นเลย ซึ่งเราอาจจะทำได้อย่างดีในโค้ดหลัก แต่ไม่ได้ทำในส่วนของ test นำมาซึ่งปัญหาในการแก้ไขในระยะยาว ดังนั้น ถ้าจะเขียน unit test แล้ว ก็ต้องดูแลมันไปพร้อมๆกันทั้งหมดนะครับ ไม่งั้นมันจะกลับมาหลอกหลอนคุณแน่นอน

บล็อกหน้ามาต่อกันที่ DEEP anti pattern ครับ 

สรุปจาก Pratical unit testing(GDC 2014): Opaque anti-pattern.

สวัสดีครับ พอดีเปิดไปเจอวีดีโอน่าสนใจเข้าอันนึงเกี่ยวแนวทางการเขียน unit test จากงาน Game dev conference เมื่อปี 2014 เลยเอามาสรุปเก็บไว้ครับ

ในวีดีโอนั้นจะพูดถึง Anti pattern ในการเขียน unit test 4 แบบด้วยกัน วันนี้เราจะมาเริ่มที่แบบแรกกันก่อน

Opaque anti-pattern

ลองไปเปิดดิกดู Opaque นั้นก็แปลว่า ทึบ, อับแสง, ไม่โปร่งใส่ แล้วมันเกี่ยวอะไรกับการเขียนเทส ลองมาดูกัน

1.Hard to see HOW.

คือโค้ดที่ดูยากว่ามันทำงานอย่างไร มันทำให้ยากต่อการทำความเข้าใจ ดูแลยาก แก้ไขยาก

2.Magic literals

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

3.Informative consistent test name.

ก็คือชื่อ test ที่ไม่ได้สื่อว่า test นั้นจะทดสอบอะไร คาดหวังอะไร ซึ่งในวีดีโอนั้นได้แนะนำรูปแบบการตั้งชื่อ test ตามรูป

4.Arrange-Act-Assert.

test ที่ไม่ได้แบ่งให้เห็นชัดเจนระหว่างสามขั้นตอนนี้ ดังนั้นก็ควรจะแบ่งให้ชัดเจนนะครับ

จบแล้วครับ เดี๋ยวมาต่อตอนหน้า กับ WET anti pattern 

ลองกดดูวีดีโอด้วยนะครับ

Estimation จุดเริ่มต้นเส้นทาง Agile ของผม

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

นั่นคือเรื่อง Estimation หรือแปลเป็นไทยก็คือการ ประเมิน

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

มีผู้ใหญ่ท่านหนึ่งบอกผมว่าให้ทำบ่อยๆ เดี๋ยวจะประเมินแม่นขึ้นเรื่อยๆเอง

แต่ผมว่า งานแต่ละงาน มันมีรายละเอียดไม่เหมือนกันนะ ผมนึกไม่ออกเลยว่าเราจะประเมินแบบนี้แม่นขึ้นได้ยังไง

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

ทีนี้ก็จะมีคำถามต่อมาอีกว่า เฮ้ยตัวเลขนี้มาได้ยังไง เยอะไปมั้ย ฯลฯ ต้องมานั่งต่อรองกันอีก เป็นเรื่องที่ผมเหนื่อยหน่ายมาก

ผมจึงเริ่มออกตามหาว่าโลกภายนอกเขาทำกันยังไงนะ หลักการที่ถูกต้องมันคืออะไร ก็เลยได้เจอคลิปวีดีโอในเว็บ Youtube เข้าอันหนึ่ง (ผมหาเท่าไหร่ก็หาไม่เจอ เนื่องจากมันนานมากๆแล้ว เลยไม่สามารถหามาแปะตรงนี้ได้ ขอโทษด้วยครับ -/\-) เป็นการแนะนำ Session ของงานสัมมนางานไหนสักงานหนึ่งนี่แหละ เมื่อประมาณปี 2011-2012
ในคลิปนั้นเป็นลุงหัวเกรียนๆคนหนึ่งออกมาขายของ แกเล่าให้ฟังว่า เวลาเราประเมินว่างานงานหนึ่งมันใหญ่ขนาดไหนนี่เราทำยังไง เราก็กะๆเอาใช้มั้ยครับ แต่เราไม่มีทางรู้ได้หรอกว่ามันใหญ่หรือเล็กจริงๆ

ลองเอาขวดน้ำขวดหนึ่งมาวาง แล้วลองกะดูสิว่าขวดนี้มันใหญ่หรือเล็ก ทำไม่ได้ใช้มั้ยล่ะ

ทีนี้ มันจะดีกว่ามั้ยถ้าเรามีขวดน้ำที่ใหญ่กว่ามาวางคู่กันให้เทียบได้ง่ายๆ อันนี้เป็นการประเมินแบบ Relative เป็นเทคนิคการEstimateอันหนึ่งที่ใช้ใน Agile ครับ

ผมนี่อึ้งไปเลยครับ โคตรจะ make sense มันมีวิธีแบบนี้ในโลกด้วยเหรอวะเนี่ย

หลังจากดูจบ ผมก็ไม่รอช้ารีบหาข้อมูลทันทีว่าตาลุงหัวเกรียนนี่คือใครกัน แล้วก็ได้เข้าร่วมชั้นเรียน Spartan ได้รู้จักกับเหล่าเกรียนส์ SPRINT3R และนั่นก็คือจุดเริ่มต้นเส้นทาง Agile  ของผมครับ

ป.ล.ผมยังตามหาวีดีโอนี้อยู่นะ ใครเจอรบกวนแจ้งเบาะแสด้วย -/\-

อย่าเพิ่งรีบเก็บโต๊ะตอนกำลังกิน

สวัสดีครับ วันนี้มาฟังพี่ปุ๋ย เจ้าของ somkiat.cc แบ่งปันเรื่องการเขียนบล็อก

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

พี่ปุ๋ยแนะนำว่า เขียนให้เสร็จไปก่อนแล้วค่อยกลับมาดูเพื่อแก้ไขมันทีหลัง

สาเหตุสำคัญเลยที่เวลาเรากำลังพยายามเขียนบล็อกแล้วล้มเหลวคือ "เขียนไปแล้วแก้ไป"

พิมพ์ไปสองสามตัว แล้วก็ย้อนกลับมาดู เอ๊ะ มันดูดีมั้ยนะ แก้ตรงนี้หน่อยดีกว่า ประโยคนี้จะโดนคนด่ามั้ย เฮ้ยอันนี้พิมพ์ผิด อ้าวอ่านไม่รู้เรื่อง ฯลฯ  ส่วนใหญ่แล้วจะกลัวไปเองด้วยนะ แล้วก็พิมพ์ๆแก้ๆมันอยู่อย่างนั้น ถ้าโชคดีก็เข็นจนเสร็จได้

แต่ส่วนใหญ่แล้ว ผมจะเลิกเขียน แล้วก็ปล่อยให้มันอยู่สถานะ draft ไปทั้งอย่างนั้น

แน่นอนว่าไอ้ draft พวกเนี้ย เราไม่เคยเอามาเขียนต่อจนมันเสร็จเลย!

ขโมยรูปมาจาก facebook ของพี่ปุ๋ย https://www.facebook.com/photo.php?fbid=10153321436038588&set=a.424501298587.197700.590338587&type=1&permPage=1

เรื่อง draft นี่พี่ปุ๋ยแกแนะนำให้ลบทิ้งไปให้หมดครับ เพราะถ้าคุณทิ้งไว้นาน ก็คงลืมไปหมดแล้วล่ะ ว่าจะเขียนต่อยังไง

ที่ไอ้คำแนะนำที่ว่าให้เขียนๆไปก่อนเนี่ย ก็มีอยู่ใน Online course ของ Coursera เหมือนกันครับ ในชั้่นเรียน Learning how to learn ซึ่งก็มีนักเขียนมือโปรมาแชร์เกี่ยวกับวีธีการเขียนหนังสือเหมือนกัน คำแนะนำก็ประมาณนี้เลย คือ

"Don't clean table while you are dining."

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

คำแนะนำนี้สามารถนำไปปรับใช้กับการเขียนโค้ดได้เหมือนกันนะครับ

ขอยกขั้นตอนของ TDD มาแปะ มีอยู่ว่า

• Make it work.
• Make it right.
• Make it fast.

การเขียนให้เสร็จไปก่อนค่อยกลับมาแก้เนี่ย ก็คือ Make it work หรือสรุปอีกทีก็คือการทีเราเลือกแก้ทีละปัญหานั่นเองครับ

ตรงนี้มีคำอธิบายเพิ่ม +Chokchai Phatharamalai เคยเล่าให้ฟัง ก็คือตอนที่เราเขียนกับตอนที่เราแก้เนี่ย มันใช้สมองคนละซีกกันครับ ตอนเขียนทีแรก เราใช้สมองด้านเหตุผล แต่ตอนที่แก้ไขหรือตกแต่ง ใส่รูป ฯลฯ เราใช้ด้านอารมณ์ ซึ่งตรงนี้สมองของเราจะมีจังหวะของมันครับ เรื่องพวกนี้มีอยู๋ในชั้นเรียน Learning how to learn เช่นกัน

ผมว่าแนวคิดนี้นำไปปรับใช้ได้กับหลายๆอย่างเลยนะครับไม่ใช่แค่การเขียน ลองดูครับผม

เขียนเทสนี่มันยากจริงๆ

เราไม่ชอบเขียนเทสเพราะอะไรกันนะ

ย้อนกลับไปสมัยผมเริ่มทำงานใหม่ๆ ก็ถูกบอกให้เขียนเทสเหมือนกัน

แต่ไม่มีใครบอกว่าต้องทำยังไง

เลยทำไปแบบงงๆ เขียนโปรแกรมให้มันทำงานได้ก่อนก็แล้วกัน

พองานเสร็จ เราจะมาเขียนเทส ก็พบว่า ทำไมมันยากจังวะ

• เขียนเทสนี่มันเขียนยังไง ไม่เห็นมีใครมาบอก ในมหาลัยก็ไม่ได้สอน
• Test case เค้าออกแบบกันยังไง
• อยากจะเทสแค่หน่อยเดี่ยว ทำไมต้อง setup นู่นนี่นั่นเต็มไปหมด
• แล้ว UI ล่ะ จะเทสยังไง
• Database ต้องมา Roll back ทุกครั้งที่รัน unit test เนี่ยนะ !?

เท่าที่นึกได้ก็ประมาณนี้ สุดท้ายแล้ว ก็ไม่มีใครทำ ทำยาก เสียเวลา เวลา Requirement เปลี่ยนทีนึง เทสที่เขียนไว้ก็พัง ต้องมาแก้อีก ยิ่งเสียเวลาเข้าไปใหญ่ กว่าจะดีบั๊กจนแก้ได้ ไม่ได้มีเวลาขนาดนั้นนะว้อย

แล้วก็เลิกเขียนเทสกันไปในที่สุด มีใครมีอาการคล้ายๆผมอย่างนี้บ้างไหมครับ :)

การต่อ Micro Block กับการเขียนโค้ด

สวัสดีครับ วันนี้ผมได้นำเอาตัวต่อ Micro block (ของก็อป แหะๆ) ที่ซื้อมาดองไว้นานมาแล้ว เอามาต่อเล่นเสียที
โดยในการต่อจะมีเทคนิคอย่างหนึ่งที่ผมค้นพบเอง ซึ่งก็มั่นใจว่าไม่ใช่ผมคนเดียวหรอกที่มีเทคนิคแบบนี้ เอาเป้นว่าผมยังไม่เคยเจอบทความหรืออะไรก็ตามที่แนะนำเทคนิดการต่อลักษณะนี้อย่างจริงจังก็แล้วกันนะ

โอเค กลับมาที่การต่อ Micro block ของผมนี่ ขอเล่าย้อนไปสักเล็กน้อยตอนที่ผมเริ่มซื้อมาต่อกล่องแรก ก็ไม่มีอะไรมาก ก็กางคู่มือความหาชิ้นส่วนจากในกองมาต่อๆ จนเสร็จ
แต่ผมค้นพบว่า การคุ้ยหาชิ้นส่วนมาจากกองนั้นมันเหนื่อยเอามากๆ
ยิ่งถ้าเป็นตัวที่รายละเอียดสูงๆล่ะก็ ยิ่งเหนื่อยมากขึ้นไปอีก -_-'
แถมความแสบของเจ้าตัวต่อจีนแดงนี้อีกอย่างหนึ่งคือ มันให้ชิ้นส่วนมาไม่ครบ!!
ลองคิดดูนะฮะ ว่ามันปวดร้าวแค่ไหน ที่ชิ้นส่วนที่คุณหามาเนิ่นนานน่ะ มันไม่มีอยู่อ่ะ ;_;
นี่อาจจะเป้นสาเหตุของการดองเรื่องต่างๆเอาไว้ของมนุษยชาติก็ได้นะครับ แหะๆๆ

โอเค กลับมาเข้าเรื่อง ที่นี้ตัวต่อๆมาผมก็พยายามแก้ไขปัญหานี้ครับ ด้วยการแบ่งแยกมันออกเป็นกองๆ ตามประเภท และ สี ของมันซะ แบบในรูป

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

ที่ว่ามานั้นมันทำให้ผมนึกถึงข้อความนี้ในบทที่ 10 ของหนังสือ  Clean code ของ  Robert C. Martin ครับ

"Do you want your tools organized into toolboxes with many small drawers each containing well-defined and well-labeled components? Or do you want a few drawers that you just toss everything into?"

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

อันนี้เป็นลิงค์ของหนังสือ Clean code ครับ http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

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