สรุปสิ่งที่ได้แบ่งปัน และ ได้รับในงาน Code Mania 11

วันนี้มีโอกาสไปแบ่งปันในงาน 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 เรื่อง บุกป่าฝ่าดงอีฟฟฟฟฟ

[slideshare id=58787251&doc=if-if-if-if-160227081304&w=640&h=480] ส่วน 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 แล้วนะ เร็วมาก ๆ https://www.youtube.com/watch?v=PxGDIBwzSFE