ในการดูแลรักษา code ของระบบต่าง ๆ มันไม่ได้ง่ายเลย
ยิ่งเป็น Legacy code แล้วยิ่งยากเข้าไปใหญ่
แต่ก่อนอื่นต้องทำความเข้าใจกับ code ก่อน
ทั้งเรื่องของ
- ข้อมูลทั่วไปของ code เช่น จำนวนบรรทัด จำนวนไฟล์ จำนวน method
- ข้อมูลเรื่องความซับซ้อนของ code
- ข้อมูลเรื่อง code ที่ซ้ำซ้อน (Duplication)
- ความสัมพันธ์ของ code (Dependency)
โดยเรื่องที่มีความสำคัญอย่างมากก็คือ เรื่อง ความสัมพันธ์ของ code (Dependency)
ว่าผูกติดกันอย่างไรบ้าง ?
เรามักจะเรียกว่า Tight-coupling และ Loose-coupling นั่นเอง
ดังนั้นเราลองมาดูใน Android project กันหน่อยสิ
คำถาม ทำไมเราต้องรู้ว่า code มันมีความสัมพันธ์กันอย่างไร ?
คำตอบ
เราจะรู้ และ มั่นใจได้อย่างไรว่า
code ที่เรากำลังทำการแก้ไขนั้น มันกระทบส่วนไหนบ้าง ?
เช่น
- มี code ส่วนไหนที่เรียกใช้บ้าง ?
- มี code ส่วนไหนถูกเรียกใช้บ้าง ?
ยิ่งถ้าเป็น Developer ที่เพิ่งเข้ามาดู code ชุดนี้ด้วยแล้ว คุณจะทำอย่างไร ?
ยิ่งถ้าเป็น Developer ที่มีประสบการณ์น้อย จะทำอย่างไร ?
ดังนั้น สิ่งที่ต้องทำให้เห็นภาพชัดก่อนก็คือ
รู้และเข้าใจก่อนว่า code แต่ละส่วนมันมีความสัมพันธ์กันอย่างไรนั่นเอง
ระบบตัวอย่าง คือ Android project
ซึ่งทำการ build ด้วย Gradle
ส่วน library สำหรับการดูความสัมพันธ์ของ code คือ JDepend
โดย JDepend นั้น ทำการสรุปให้ว่า
Source code ของภาษา Java ที่เราเขียนขึ้นมาในแต่ละ package นั้น
มันไปเรียกใช้งาน class/method จาก package อะไรบ้าง ?
มันถูกเรียกใช้งานจาก packagge ไหนบ้าง ?
ซึ่งทำให้เราเห็นว่า
คุณภาพในการออกแบบ code ของระบบเราเป็นอย่างไร
ทั้งในมุมมองของ extensibility
ทั้งในมุมมองของ reusability
ทั้งในมุมมองของ maintainability
ในระดับของ package
เพื่อทำให้เราสามารถแก้ไขได้อย่างถูกต้อง
การใช้งาน JDepend กับ Gradle
เนื่องจาก Android project นั้นทำการ build ด้วย Gradle
ดังนั้นเราจึงต้องเพิ่ม JDepend เข้าไปที่ Gradle ด้วย ดังนี้
คำอธิบาย
- เพิ่ม plugin jdepend
- ในทำงานหลังจาก task compileDebugSources
- เพิ่ม task ชื่อว่า jdepend เข้าไปใน project โดยผลการวิเคราะห์จะอยู่ในไฟล์ build/reports/jdepend.xml
ดังนั้นสามารถใช้งานด้วยคำสั่ง
$./gradlew depend
หรือสามารถดูว่ามี task jdepend หรือไม่ ด้วยคำสั่ง
$./gradlew tasks
แต่ผลการทำงานจาก JDepend นั้นจะเป็นไฟล์ XML ซึ่งอ่านลำบาก
จึงต้องใช้เครื่องมืออื่นมาช่วยเหลือนิดหน่อย ดังนี้
1. นำไปทำงานกับ Jenkins หรือระบบ Continuous Integration (CI)
เนื่องจากมี plugin สำหรับการสร้างรายงานของ JDepend อยู่แล้ว
ซึ่งมีผลการทำงานดังรูป
ซึ่งจากรายงานมันมี column ต่าง ๆ ที่ต้องเข้าใจคือ
- TC (Total Class) จำนวน class ทั้งหมดในแต่ละ package = CC + AC
- CC (Concrete Class) จำนวน concrete class ทั้งหมดในแต่ละ package
- AC (Abstract Class) จำนวน abstract class หรือ interface ทั้งหมดในแต่ละ package
- Ca (Afferent Coupling) จำนวน package อื่นที่เรียกใช้งาน class จาก package นี้
- Ce (Efferent Coupling) จำนวน package อื่นที่ถูกเรียกใช้งาน class จาก package นี้
- A (Abstractness) อัตราส่วนระหว่า abstract class/interface กับ class ทั้งหมดใน package
- I (Instability) เป็นค่าที่บอกว่าใน package นี้จะเปลี่ยนแปลงบ่อยหรือไม่ ถ้าค่ามาแสดงว่าเปลี่ยนบ่อย หรือ ไม่เสถียรนั่นเอง คำนวณจากสูตร Ce / ( Ce + Ca )
- D (Distance from the main sequence) เป็นค่าความสมดุลระหว่าง A กับ I โดยที่ A+I=1 ดังนั้น D = 1 – (A+I)
- V (Volatility) โดยปกติมีค่าเป็น true หรือ 1 นั่นคือ เอา package เหล่านั้นมาคิดคำนวณนั่นเอง ถ้าไม่ต้องการมาคำนวณก็กำหนดเป็น false หรือ 0 ได้
2. สามารถนำไฟล์ XML มาแสดงผลในรูปภาพสวย ๆ ด้วย Gephi
สามารถเขียน code เพื่อแปลงข้อมูล XML จาก JDepend เพื่อเปิดใช้งาน gephi ได้ด้วย
ลองดู code จากที่นี่ Graph Source code analysis
แสดงผลการทำงานดังรูป
จากนี้ไปน่าจะทำให้เห็นแล้วว่า code ที่เราต้องดูแลนั้น
มีความสัมพันธ์กันอย่างไรบ้าง
น่าจะทำให้ชีวิตดีขึ้นมาไม่มากก็น้อยนะครับ
