Refactoring for Y

วันนี้เป็นวันที่เดินทางมาไกลมากกก จากสายใต้ใหม่สู่ Geeky Base (ออกตั้งแต่ 07:00 โมง มาถึงประมาณ 08:40 ครับ) มารู้จักกับคำว่า "Refactor" มาขึ้นครับ โดยคุณ J Prayoch Rujira ก่อนที่เริ่มให้แต่ละคนทำการ

• การแนะนำตัว
• งานที่ทำ และTechnology ที่ใช้
• Burning Question(อะไรที่มันค้างใจทำไมถึงต้องมาครับ) สำหรับผม คือ Refractor จากเดิมที่ใช้ใจ มาหาหลักการครับ

มาที่สรุปมีหัวข้อ ดังนี้

เมื่อพูดถึงการสร้าง Software เราคงเคยเจออะไรแบบนี้

• มี Code เดิม อยู่ มาวันนี้มีการเพิ่ม Feature แล้ว
  • ปรับยังไง
  • ทำแบบไหน
  • ของเดิมจะบึ้มไหม
• ถ้าไม่มี Good Design ทำให้ Maintain (ดูแล) ได้ยาก พอเกิดปัญหาจริงขึ้นมา ไม่ว่าจะช่วง Dev, UAT, PROD หรือ UAT on PROD (อันนี้ผมเติมเองนะ เจอบาง Site ทำจริง) เมื่อถึงจุดนั้น หน้าที่ของ Developer คือ ทำให้ Business มันเดินต่อได้เร็วที่สุด (อุดรูรั่ว หรือ ดับไฟ แล้วแต่คนนะ) ไม่ว่าจะเป็น
  • Hotfix
  • Workaround
  • Patch
  • Hack
• สำหรับผม Codebase มันเป็นเรือลำดับที่กำลังล่องในทะเลแห่ง Requirement ผ่านไปเรือรัว (มี Change / Bug) เราตัดสินใจยังไง
  1. เราก็แค่อุดรููรั่ว
  2. เอาเรือลำนี้กลับเข้าอู่ เพื่อซ่อมแซม หรือป่าว
  3. หรือ ปล่อยไปเรื่อยๆ จนเรือจม ?

• หรือ มองในมุมของการเงิน ยิ่งนานวัน Code ยิ่งแก้ยาก  มีหนี้เยอะขึ้น ทบๆไปเรื่อยจน ดอกเบี้ยขึ้นสูง หรือ เรียกว่า Technical Dedt
• พอ Code มันเน่า
  • ทำงานลำบาก
  • Developer ลาออก
• การทำ Software เป็นเรื่องของการเปลี่ยนแปลง (คหสต. ของผม การเปลี่ยนแปลงที่มีการควบคุมระดับนึง)

Refactoring คือ อะไร ?

• การปรับ Code ให้ง่ายขึ้น แต่ความถูกต้อง เหมือนเดิม
• External vs Internal
  • Extenal ความถูกต้อง
  • Internal - กระบวนการช่วยเสริม External เช่น การ Test, Refactor เป็นต้น

ทำให้ Code ดีขึ้นได้อย่างไร

• Source Code คือ การสื่อสาร เขียนให้ Work ง่าย แต่เขียนให้สื่อสารยาก มัน คือ ศาสตร์ ที่พระเจ้า และเราในโลกอดีตที่เข้าใจ ใช่ครับ

ใน Agile มี Technical Excellent เข้ามาช่วง ดังนี้

• Engineering Practices
  • Communication
  • Collaboration ทำให้คนร่วมมือกัน
  • Source Control
  • CI CD - Easy build , Deploy
  • แนวคิด Test First / ATDD / TDD
• Testing
  • Manual
  • Automate Test
  • UI Test
  • Intergration
  • Unit Test
• Testing ในอุดมคติ ควร Manual Test น้อย แต่มี Unit Test เยอะ (นึกถึงรูปสามเหลียม)'

Let's Refactoring

เริ่มต้นด้วย RECAP Basic Principle - OOP ในช่วงนี้เล่นเกม 5s number game ในไทย 5ส  เกมหาตัวเลข 1-49 แบบเรียงกัน สรุปได้ ดังนี้

• #01 สะสาง -  เอาที่ไม่เกี่ยวข้องออกไป อาจจะเป็น code ขยะ
• #02 สะดวก - ตีช่องจำกัดวง แบ่งเป็นกลุ่มหรือหมวดหมู่
• #03 สะอาด - จัดเรียงอะไรที่มันดูรกให้เรียบร้อย ทำให้ Code Clean ถ้าจากโจทย์น่าจะเอาเรียงลำดับ
• #04 สร้างมาตรฐาน - ทำมาตรฐาน เช่น Code Review / ทำ Design Pattern
• #05 สร้างนิสัย - ทำ 4 ส ที่กล่าวซึมซับ

Code Smell - Code ที่อ่านไม่รู้เรื่อง นึกถึง ห้องน้ำ เหม็น อยู่ไปจะชิน เหมือนกัน Code เนี่ยแหละ อยู่กับ Code เน่าๆจนชิน) living with code smell มารู้กันว่า Code Smell แบบไหนบ้างที่พอเจอบ่อยๆ

• Bad naming – เพราะเราใช้เวลาทำความเข้าใจเยอะมากกว่าเขียน Code ตั้งชื่อได้ดีต้องรู้อะไรบ้าง
  • เข้าใจ Business ด้วย
  • ไม่จำเป็นต้องย่อ
  • ชื่อยากๆ มักมาจาก ไม่เก่ง Eng ไม่เข้าใจ Domain
• Duplicate Code – Code ซ้ำ เรื่องนี้ เป็นที่มาของ OOP แต่มันก็ยังรอดมาจนถึงปัจจุบัน โดย Duplicate มีดังนี้
  • Blatant – เห็นชัด จากการ Copy & Paste
  • Subtle – ต้องตีความ เพราะ เขียนคนละแบบ แต่ผลลัพธ์เหมือนกัน ถ้าจะแก้ต้องเลือก
  • ผลจาก Duplicate
    • Hard to fix bugs
    • Bloated codebase
    • hard to read
    • Complexity ++++++
  • Principle Don't repeat yourself
  • *** Duplicate ไม่ใช่แค่ Code ลองดูใน Value จำเป็นต้องแยกออกมาเป็น Constant กลางไหม ?
• Comment
  • เอาที่ไม่จำเป็นออก หรือไม่ปรับ Code ส่วนนั้นที่เกี่ยวกับ Comment ไปเป็น Method ใหม่เลย
  • ไม่จำเป็น ต้องใส่หมด
• Hard Code
• Eliminate tmp – กำจัดตัวแปรพวก tmp ทั้งหลาย
• Long Method
  • Method ที่ยาวมาก ทำให้อ่านยาก และเทสยากด้วย ๖ทุกคนจะบอกว่าทำ ทำไม / ไม่มีเวลา / ไม่รู้แก้ยังไง
  • แก้ไขโดย Extract Method ออกมาเป็นอันย่อยๆ
• Large Class
  • Class ที่มีงานเยอะ Reposonse Method หลายอย่าง
  • ทำให้น้อยที่สุด
  • ดู SRP (Single Responsibility Principle) หนึ่งใน SOLID แยกงานลองนึกถึง MVC
    • Tools ที่แนะนำ – CRC CARD
    • Not God Class -> แบ่ง Class ย่อยๆ ทำงานเป็น Team
• Switch Statement (ดง If)
  • พวก Condition
  • Ex ต้องการ Value if to map
  • Behavior มีการทำงานทีแตกต่าง -> Design Pattern แยก Method แตก Class
  • ถ้ามัน Complex ลอง Split
• Side Effect
  • Method ทำงานได้หลายอย่าง
  • แก้ไขโดย Method ทำงานหนึ่งเดียว
• Long Parameter
  • arg – ส่งไป
  • parameter – รับมา
  • ยุบไปเป็น Class Data Object สิ ของลุง Martin
    • Class ไม่ควรเกิน 3
    • หรือยกไปเป็น Member
• ดูเพิ่มเติมได้จาก Code Smell C2 รวม Paper เรื่อง Code Smell

Refactoring

• ปรับจากภายใน ลด Code Smell แต่ต้องทำให้มันต้องถูกนะ
• ต้องมี Unit Test ก่อนทำเสมอ
• ทำ Code ให้มัน Ready to maintain
• ทำตาม Step ดังนี้ จากมาก >> น้อย
  • Pass test
  • Reveals intension
  • No Dulplicate
  • Fewest Element
• การ Refactoring ไม่จำเป็นต้องทำทุกจุดใน Code แต่ให้ดีที่สุดในจุดที่ทำเงิน และ Criticalที่สุด ส่วนที่เหลือให้รองลงมา นึกถึง 80/20 เลย

ปิดท้าย Code smell กับ Refactoring มีการทำ Workshop ด้วยภาษา Java ด้วย

• ฝึกแก้ Code Smell
• TDD – Fizzbuzz
• Test เพื่อเข้าใจ Legacy Code
  • ถ้าไม่รู้อะไรก็ New มาเลย มองเป็น Top-Down ได้ไหม
  • จากนั้นลงไปที่ Method ย่อยๆ
  • Exploratory Test ไล่ Test ตาม Flow เดิมของระบบ อาจจะต้องสอบถามฝั่ง Business หรือผู้ที่คลุกคลีกับ Code นั้มานาน
  • แก้ Legacy Code บางส่วน เพื่อให้เข้าใจการทำงานของ Code ได้ แต่อย่าเผลอ Check-in !!!
• Unit test คือ Test ที่สนใจการทำงานของหน่วยนั้่นๆอย่างเดียว
• Code ตาม Team Style naming ด้วย
• ทำ Test แบบ baby step - ก้าวที่ละนิด
• Refactoring test ด้วยนะ
• Triangulation test - เพิ่ม Data เข้าไป เพื่อให้เห็น Pattern
• การตั้งชื่อ Test สำคัญ มองเป็น Report ได้ง่าย
• แนะนำเครื่องมือ อย่าง SonarCube -> Code Analyser
• ตัว Intellij มี Test Coverage - ตรวจได้ว่า Code ถูก Test ไป หรือยัง ใน MS Visual Studio ก็มีนะ

และก็ Signature ของ Blog อาหารครับ