logo

การไปร่วมงาน Agile Thailand 2014 ในวันที่ 7-8 มิถุนายน 2557
โดยคิดว่าจะต้องไปแบ่งปันกับเขาบ้าง
เนื่องจากครั้งที่ผ่านๆ มาไปแค่นั่งฟังอย่างเดียว
ในครั้งนี้ตั้งใจไปแบ่งปันอยู่ 2 เรื่อง คือ

  1. Workshop :: Kata Open/Closed Principle
  2. Workshop :: Refactoring Test with Robot Framework

และมี session ที่คนในงานขอมาคือเรื่อง Continuous Integration และ Continuous Delivery
รวมๆ แล้วก็มีอยู่ 3 เรื่อง

มาดูว่าจะแต่เรื่องคืออะไรกันบ้าง

1. Workshop :: Kata Open/Closed Principle

2wBZE7

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

6RaD2Q

โดยเนื้อหาของของ workshop นี้นำมาจากงาน XP2014
ซึ่งคิดว่า ถ้าเอามาจัดที่งาน Agile Thailand 2014 แล้วน่าจะสนุก
เป็นการนำเอาโจทย์ง่ายๆ คือ FizzBuzz มาเขียนกัน
แล้วทำการเพิ่มความสามารถใหม่ๆ เข้ายังปัญหาเดิม เช่น

  • Bang เมื่อหาร 7 ลงตัว
  • FizzBang เมื่อหาร 3 และ 7 ลงตัว
  • FizzBuzzBang เมื่อหาร 3, 5 และ 7 ลงตัว

แล้วนำ code ที่สร้างขึ้นมาของแต่ละคนมาดูกัน
ซึ่งส่วนใหญ่ ก็จะทำการ coding ด้วย if-else ไปเรื่อยๆ
แล้วแก้ไขที่ไฟล์ หรือ class หรือ method เดิมทุกครั้งไป
โดยการแก้ไขแบบนี้มันสะท้อนไปถึงสิ่งที่ทำการพัฒนาระบบงานจริงๆ
ว่ามีการทำงานแบบไหน

ดังนั้นใน workshop นี้จะไม่มีการเขียน if หรือใช้ให้น้อยที่สุด นั่นคือ 1 if เท่านั้น
ซึ่งกลุ่มนี้เขาเรียกตัวเองว่า Anti-If

ต่อมาจึงทำการอธิบายเรื่อง Open/Closed Principle ( OCP ) ว่ามันคือ

  • เปิด สำหรับการเพิ่ม หรือ ขยาย ความสามารถ
  • ปิด สำหรับการแก้ไข

ฟังแล้วน่าจะงงๆ กันแน่นอน จึงอธิบายการทำงานด้วยรูปนี้
Screen Shot 2557-06-09 at 11.08.16 AM

โดยกฎของ Kata OCP นั้นง่ายมากๆ ประกอบไปด้วย 4 ข้อดังนี้

Screen Shot 2557-06-09 at 11.13.40 AM

ดังนั้นลองไป coding ตามกฎ ดูนะครับ …

Slide ผมเอาเขึ้นไว้ที่ SlideShare ตามนี้

และ sourcecode ตัวอย่าง ผมเขียนด้วยภาษา Java อยู่ที่ Github :: Up1 Kata FizzBuzz OCP

จากตัวอย่างนั้น เป็นเพียงวิธีการหนึ่งเท่านั้นครับ ยังมีวิธีการอื่นๆ อีกมากมายในการแก้ไขปัญหานี้

2. Workshop :: Refactoring Robot Framework

10152512_682904085096475_48250654087253657_n

ขอยืมรูปมาจากพี่บอม Karan

ใน session นี้ใช้เวลาเกินไปประมาณเกือบ 1 ชั่วโมง กลายเป็น session 2 ชั่วโมงไปได้ยังไง ?
ตรงนี้ผมไม่ขออภัยนะ  555 … เพราะว่าในห้องไม่มีใครออกไปกินข้างกลางวันเองนะครับ
แต่ต้องขอบคุณทุกๆ คนในห้องครับ ที่ช่วยผมเขียน code กันจนถึงปลายทางไปด้วยกัน
ช่วงที่พูดสนุกมากๆ ครับ ไม่แน่ใจว่าคนในห้องจะสนุกไปกับผมด้วยหรือเปล่า ??

เนื้อหาที่ผมมำมาใช้ใน workshop จะเริ่มตั้งแต่

  1. โครงสร้างของ test ที่สร้างด้วย Robot Framework ประกอบไปด้วย 4 ส่วนคือ settings, variables, test cases และ keywords
  2. ทำให้เห็นทีละขึ้นตอนว่า Robot Framework มันทำงานอย่างไรบ้าง โดยให้ทำการ run และดู Error ที่เกิดขึ้น
  3. ให้ทำการแก้ไขไปทีละขั้นตอน จนการทดสอบมันผ่าน
  4. ตัวอย่างที่ใช้ใน workshop คือ Login demo จาก Robot Framework Selenium2Library
  5. ผมก็พาออกแบบ test case กันซึ่งมี Valid case และ Invalid case
  6. การเขียนจะเริ่มจากการเขียนแบบง่ายๆ คือ เอา Keyword ที่มีใน library Selenium2Library มาใช้งาน
  7. เมื่อทำงานได้แล้ว ( Make it work ) ก็ทำการ Refactoring เพื่อให้ test นั้นอยู่ในรูปแบบที่อ่านเข้าใจได้ง่าย และไม่ซ้ำซ้อน
  8. จนสุดท้ายได้สิ่งที่เรียกว่า ดีขึ้น ( Make it right )

โดย Slide อยู่ที่นี่ครับ

3. เป็นหัวข้อที่ถูกขอมา เรื่อง Continuous Delivery และ Continuous Integration

ในหัวข้อนี้ ผมเข้าช้าไปประมาณ 15 นาที ต้องขออภัยด้วย เนื่องจากกำลังทำ Kata OCP อยู่ที่ห้อง 301 ครับ

เมื่อเข้ามาในห้อง ผมเริ่มด้วยการสอบถามเรื่อง flow การทำงาน
ตั้งแต่เมื่อ commit sourcecode  ไปยัง repository
ไปจนถึงการ deploy ขึ้น production
เพื่อทำให้เห็นว่า สิ่งที่กำลังทำอยู่เป็นอย่างไร
ขาดอะไรตรงไหนไปบ้าง

ความแตกต่างระหว่าง Continuous Delivery และ Continuous Deployment ว่าเป็นอย่างไร

และใน session นี้ผมจะเน้นย้ำว่า CI และ CD ไม่ใช่ เครื่องมือ เช่น Jenkins
แต่ว่ามันคือ culture ของทีมและองค์กร

สิ่งที่ขาดไปไม่ได้ในระบบ CI และ CD ก็คือ เรื่องของคุณภาพในทุกๆ ขั้นตอน
โดยคุณภาพเช่น

  • มี unit test ไหม
  • มี integration test ไหม
  • มี acceptance test ไหม
  • มี metric ต่างๆ ในการตรวจสอบ code ไหม
  • มีการทำ performance test ไหม
  • มีการทำ security ไหม

ดังนั้นให้กลับไปดูว่า ระบบ CI/CD ที่ทำอยู่ มีเรื่องคุณภาพไหม ?

และเรื่องที่แนะนำไป ก็คือ CI practice ที่สำคัญๆ เช่น

  • Self-test หมายถึง เครื่อง developer ทุกๆ คนสามารถทดสอบหรือ run ระบบงานได้หรือไม่
  • Fast หมายถึงเรื่องความเร็วในการทำงานของระบบ CI ถ้าทำงานช้าแสดงว่าคุณมาผิดทางแล้ว
  • CI server ถ้าคุณมี Self-test และ Fast ก็สามารถนำมาสร้าง CI server ได้ง่าย เพื่อทำให้แน่ใจว่า ระบบยังทำงานถูกต้องอยู่เสมอ

และผมปิดท้ายไว้ว่า CI/CD ไม่ใช่ระบบที่สร้างขึ้นมาเพื่อ หาคนผิด หรือ ตรวจสอบ
แต่สร้างขึ้นมาเพื่อ Continuous Improvement หรือ การพัฒนาและปรับปรุงอย่างต่อเนื่อง

ขอบคุณพื้นที่ในการแบ่งปัน สำหรับงาน Agile Thailand 2014 ครับ