วันนี้มีโอกาสไปแบ่งปันในงาน Code Mania 11 :: Raise the bar จัดโดยสมาคมโปรแกรมเมอร์ไทย
โดยพูดเรื่อง บุกป่าฝ่าดงอีฟฟฟ
เพื่ออธิบายวิธีการปรับปรุง code ที่มันยุ่งเหยิงให้ดีขึ้น
รวมทั้งความรู้ต่าง ๆ ที่ได้รับกลับมา
จึงทำการสรุปไว้นิดหน่อย
เริ่มจากสิ่งที่ได้แบ่งปัน คือ บุกป่าฝ่าดงอีฟฟฟ
เป้าหมายของการพูดครั้งนี้ คือ
- มิใช่บอกว่าห้ามใช้ if/else หรือ switch/case แต่เราจะจัดการอย่างไรดี ให้แก้ไขง่าย
- เริ่มต้นที่ mindset ที่มีต่อ Legacy code และ code ที่มันยุ่งเหยิงใหม่ซะ นั่นคือ ถ้าเห็นว่าไม่ดี ให้ลงมือแก้ไขให้ดีขึ้น
เริ่มต้นด้วยการนำ code รูปแบบต่าง ๆ
ซึ่งข้อมูลมาจาก blog เรื่อง ว่าด้วยเรื่อง ป่าดงอีฟ
จากนั้นทำการอธิบายขั้นตอนการจัดการกับ Legacy code
โดยเริ่มจากทำความเข้าใจ code เหล่านั้นเสียก่อน
แต่โชคไม่ดีที่ code เหล่านั้น มันยุ่งเหยิง และ ซับซ้อนเหลือเกิน
แล้วเราจะทำอย่างไรดีล่ะ ?
ปล. code เหล่านี้มันทำงานถูกต้องตาม requirement นะ !!
สิ่งที่แนะนำ คือ ถ้าอยากเข้าใจ Legacy code ให้ทำดังนี้
เริ่มด้วยต้องรู้ว่า code ในปัจจุบันเป็นอย่างไรบ้าง ในเชิงตัวเลขที่จับต้องได้
ซึ่งผมแนะนำให้ใช้ SonarQube เพื่อวิเคราะห์ code
จะทำให้รู้ว่า code เป็นอย่างไรบ้าง เช่น
- มี Line of Code เท่าไร
- มีความซับซ้อนของ class, method เท่าไร
- มี code smell ตรงไหนบ้าง เช่นพวก Magic Number, Magic String, Issue ต่าง ๆ และ Duplication code เป็นต้น
มาถึงตรงนี้เราจะได้ค่าตัวเลขเริ่มต้น
เพื่อเอาไว้ใช้วัดผลหลังจากการแก้ไข
ว่าการแก้ไขมันช่วยอะไรเราหรือไม่ อย่างไร
จากนั้น เริ่มทำความเข้าใจการทำงานของ code
ด้วยการเขียนชุดการทดสอบ (Test cases)
ซึ่งแต่ละ test case ประกอบไปด้วย
Input และ Expected result หรือ ผลลัพธ์ที่คาดหวัง
หรือค่า Example สำหรับการทดสอบนั่นเอง
ยังไม่พอนะ เพื่อเพิ่มความมั่นใจ และ น่าเชื่อถือของ test case
ต้องทำการวัดค่าของ Test coverage หรือ ตัวเลขที่บอกว่า
test case ทั้งหมดมันครอบคลุม production code มากน้อยเพียงใด
โดยจาก demo ของผมนั้น
เขียน test case ไปจนกว่า Test coverage = 100%
เครื่องมือที่ใช้ตรวจสอบคือ Cobertura
ซึ่งชุดการทดสอบมันมีข้อดีคือ
- ขจัดความกลัว
- ทำให้รู้ว่าอาจจะมีบาง feature ที่ไม่เสร็จ !!
ขั้นตอนต่อมา ก็เข้าสู่การแก้ไข code หรือ Refactor code กัน
เนื่องจากเราได้สร้างความมั่นใจ และ ขจัดความกลัวจากการแก้ไขไปแล้วนั่นเอง
โดยแนะนำให้ทำแบบ step-by-step
หรือตามกลุ่มการทำงานจาก test case นั่นเอง
ให้เริ่ม refactor code ไปทีละกลุ่ม
ซึ่งแนวคิดที่ใช้คือ
แยกออกมาเป็น method เล็ก ๆ (Extract to new method)
หลังจากการแก้ไขแล้ว อย่าลืม run test case ทั้งหมดนะครับ !!
ผลที่ได้คือ
สามารถลดค่าความซับซ้อนของแต่ละ method จาก 19 ไปเป็น 4
รวมทั้งทำให้เราเห็น code ที่อาจจะ duplicate ได้ง่ายอีกด้วย
นี่เป็นหนึ่งในแนวคิด ของการแบ่งการทำงานเป็นส่วนเล็ก ๆ
แน่นอนว่า มันดีกว่า method ขนาดใหญ่แน่นอน !!
ตามจริงมันยังไม่จบนะครับ
เนื่องจาก เราต้องแก้ไข duplication code อีก !!
Slide เรื่อง บุกป่าฝ่าดงอีฟฟฟฟฟ
ส่วน Source code ทั้งหมดอยู่ที่ Github::Kata GildedRose
โดยแบ่งออกเป็น 3 branch ตามขั้นตอน ดังนี้
- 01_legacy_code เป็น code เริ่มต้น ซึ่งไม่มีชุดของการทดสอบ
- 02_add_testcases เป็น code ที่เพิ่มชุดการทดสอบเข้ามา ซึ่งมีค่า test coverage 100%
- 03_refactor_to_small_method เป็น code ที่ทำการ refactoring ด้วยการสร้าง method ใหม่
สิ่งที่ได้รับจากงาน Code Mania 11 มีดังนี้
ช่วงเช้าไม่ค่อยได้ฟังเท่าไร เนื่องจากเผา slide อยู่ !!
แต่ก็แอบฟังเป็นบางช่วง ที่ได้ยินประโยคแจ่ม ๆ เช่น
- ถ้าเราหลีกเลี่ยงปัญหาใดปัญหาหนึ่งไม่ได้แล้ว ก็ต้องควบคุมมันให้ได้
- ใช้ของที่ทีมมีความรู้ความเข้าใจจะดีกว่า
- ถ้าวิธีการใหม่ ๆ มันดี แต่ไม่ได้ทำให้ business ดีขึ้น หรือ ไม่มีความจำเป็นต้องทำ ก็ไม่ต้องทำ
ส่วนในช่วงบ่ายหลังจากพูดเสร็จ ก็พยายามหาห้องที่พูดเรื่อง Spark
แต่กว่าจะหาเจอก็ถึง slide หน้าสุดท้าย
สรุปได้ว่า Big Data + Spark = คู่จิ้นฟินเวอร์
จากนั้นเข้าไปฟังเรื่อง Building and Maintaining Open-source Project
ซึ่งทำให้เห็นแนวคิด มุมมองของคนพัฒนา Opensource project
ว่ามันไม่ธรรมดาจริง ๆ
ทั้งเรื่องของโครงสร้างของ community
ทั้งเรื่องการแก้ไขข้อขัดแย้งต่าง ๆ
ทั้งเรื่องของการขยาย community
ทั้งเรื่องจรรยาบรรณ
ทั้งเรื่องขั้นตอนการทำงาน และ พัฒนา
เป็นเรื่องที่มีคุณค่าต่อผมอย่างมาก
มันเปิดโลก เปิดกะโหลกของผมอย่างมากมาย
มีประโยคที่สำคัญมาก ๆ คือ
Technology doesn’t make the better world.
People do !!
ปิดท้ายด้วยการเข้าฟังเรื่อง Functional Reactive Programming
โดยใน session นี้มันใหม่สำหรับผมอย่างมาก
ซึ่งทำให้เห็นมุมมองต่าง ๆ ของ Functional programming
และต่อจากนั้นตามมาด้วย Reactive
ได้รับฟังถึง keyword ต่าง ๆ มากมาย อาจจะทำให้ใครหลาย ๆ คนธาตุไฟเข้าแทรกได้ !!
ตัวอย่างเช่น Iterator vs Observer pattern
รวมทั้งมี resource ต่าง ๆ ให้ไปดูเพิ่มเติมมากมาย เช่น
- Optimizing the Netflix API
- Netflix JavaScript Talks – Async JavaScript with Reactive Extensions
- End to End Reactive Programming at Netflix
- Interactive diagram สำหรับการอธิบายการทำงานของ Reactive
- Reactive Programming for a demanding world
มีประโยคที่น่าคิด คือ Everything is a Stream
สุดท้ายขอขอบคุณทีมจัดงาน Code Mania 11
ที่จัดงานดี ๆ สนุก ๆ ครับ
แถมให้โอกาสได้ไปแบ่งปัน และ เก็บความรู้อีก
ครั้งหน้าเจอกันใหม่ครับ
ปล. ทีมงานเขาเอา VDO ทั้งหมดขึ้น youtube แล้วนะ เร็วมาก ๆ
