จากบทความเรื่อง Longevity of Source Code
ทำการวิเคราะห์ code ได้อย่างน่าสนใจ
จึงนำมาสรุปบางส่วน ดังนี้
Developer ทุกคนลองกลับไปดู code ที่ทำงานอยู่ด้วยทุกวันดูสิว่า
- Code เหล่านั้นมันอายุเท่าไร ?
- Code เหล่านั้นมันเก่าแก่ไหม ?
- ถ้ามีอายุ 6 เดือนมันเก่าแก่ไหมนะ ?
- หรือต้องมีอายุ 5 หรือ 10 หรือ 15 หรือ 20 ปีขึ้นไป ถึงจะเก่าแก่ ?
- มี code ชุดไหนที่มีอายุมากที่สุด ?
- code ที่มีอายุเยอะ ๆ มีจำนวนกี่เปอร์เซ็นจากทั้งหมด ? 10% หรือ 50% หรือ 90%
จะหาคำตอบไปเพื่ออะไรกัน
ดังนั้นลองมาหาคำตอบกันดีไหม
เริ่มต้นจากธรรมชาติของ Software
เมื่ออายุของบริษัทเพิ่มมากขึ้น
เราพบว่าจำนวน code ที่มีอายุมากก็เยอะขึ้นตาม
ซึ่ง code เหล่านั้นมันเหมือนกับของโบราณ
บางคนอาจจะเรียกว่า Legacy code
บางคนอาจจะเรียกว่า มรดกเลือด
บางคนอาจจะบอกว่า เป็นของโบราณ
บางคนอาจจะบอกว่า สิ่งที่น่าขยะแขยง อย่าไปยุ่งกับมัน
และเมื่อคุณเข้าไปรายละเอียดการทำงานของ code เหล่านั้น
คุณจะยิ่งรู้สึกว่า เหมือนการเข้ายังบ้านเมืองเก่า ๆ
ที่มีแต่ซากปรักหักพัก
แต่ละส่วนพร้อมที่จะถล่มลงมา !!
แนวความคิดแรก ๆ ที่ developer ส่วนใหญ่คิดคือ ?
If it ain’t broke, don’t fix it
แต่มีประโยคหนึ่งที่น่าสนใจคือ
ถ้าคุณกลับไปดู code ที่เขียนในหนึ่งปีที่ผ่านมา
แล้วพบว่าในปัจจุบันก็ไม่มีอะไรเปลี่ยนแปลงเลย
นั่นหมายความว่า ในหนึ่งปีที่ผ่านมา
คุณในฐานนะ Developer ไม่ได้เรียนรู้อะไรจากระบบนี้เลย !!
Developer ควรที่จะเรียนรู้อยู่อย่างเสมอสิ
- เข้าใจ business domain ดีขึ้น
- เข้าใจวิธีการออกแบบ และ สร้างดีขึ้น
- ปรับเปลี่ยนสถาปัตยกรรมให้ดีขึ้น
- ใช้เครื่องมือที่ดีขึ้น
- มีแนวทางการทำงานที่ดีขึ้น
- มีมาจรฐานการทำงานที่ดีขึ้น
- มีแนวคิดใหม่ ๆ ออกมา
- ที่สำคัญคือ code ที่คุณเขียนออกมานั้น ควรจะดีขึ้นเช่นกัน
แต่คำถามที่น่าสนใจ คือ
คุณกลับไปปรับปรุงและแก้ไข code ให้ดีขึ้นบ้างไหม ?
ทั้ง ๆ ที่เราก็รู้กันว่า code ที่มันแย่ ๆ
มันยิ่งส่งผลให้การแก้ไขยากลำบากขึ้นทุกวัน
แต่ก็ไม่ยอมปรับปรุง และ แก้ไขกัน !!
นั่นคือ เราไม่เคยใช้หนี้ที่สร้างไว้เลยนะ …
แต่สิ่งที่เลวร้ายกว่า คือ
เราไม่ทำการปรับปรุง และ แก้ไข
ทั้ง ๆ ที่รู้ว่า code เหล่านั้นมันไม่ดี
กลับมาดูกันว่า code ของเรามันมีอายุเท่าไร ?
จากการวิเคราะห์ code จำนวนหนึ่ง จาก project จำนวนหนึ่ง
พบว่า
code กว่า 70% ที่เราเขียนในวันนี้
จะทำงานอยู่บน production
โดยไม่ถูกเปลี่ยนแปลงไปประมาณ 12 เดือน
และหลังจาก 12 เดือน จะพบว่า code เหล่านั้นเข้าสู่สถานะการ maintenence
เพราะว่า จะเริ่มถูกแก้ไขกันบ้างแล้ว !!
แสดงผลการวิเคราะห์ดังรูป
ลองคิดดูสิว่า
กว่า 70% ของ code ที่เราเขียนไม่ถูกเปลี่ยนแปลงเลย
มันหมายความว่าอย่างไร ?
- code มันดีอยู่แล้ว ?
- code มันทำงานได้ดีอยู่แล้ว ?
- เราไม่กลับไปแก้ไข code ให้ดีขึ้นเลย ?
- เราไม่เคยเปลี่ยน library ที่ดีกว่าเลย ?
- เราไม่เคยจะปรับปรุงสถาปัตยกรรมของระบบให้ดีขึ้นเลย ?
- เราไม่เคยเรียนรู้อะไรจากมันเลย ?
- เราไม่มีเวลา ?
โดยสรุปแล้ว
Code ต่าง ๆ ถูกสร้างมาด้วยเหตุผลที่แตกต่างกันไป
แต่ส่งมอบสิ่งที่มีคุณค่าทาง business อย่างแน่นอน
แต่ code เหล่านั้นมันก็กลายมาเป็น หนี้สิน
หรือเป็นตัวถ่วงของทีมพัฒนา ของ bussiness ของบริษัทอย่างรวดเร็วเช่นกัน
ถ้าไม่ดูแลให้ดี หรือ ไม่ปรับปรุงให้ดีอยู่อย่างเสมอ
เมื่อเวลาผ่านไปนานขึ้น
code ก็ยากต่อการดูแลรักษามากขึ้นเรื่อย ๆ
จากการวิเคราะห์ข้อมูลของ code ทำให้เราเห็นว่า
code มันอยู่กับเราไปนานมาก ๆ
ดังนั้น จึงเป็นเหตุผลที่สมเหตุสมผล ว่า
ทำไมเราควรดูแลรักษา code ให้ดียิ่งขึ้นอย่างสม่ำเสมอ
ดังนั้น ถ้าคุณไม่ทำการแก้ไข และ ปรับปรุง code ให้ดีขึ้นเลย
คุณก็ต้องทนอยู่ หรือ อยู่ทนกับ code เหล่านั้นไปตลอด
ซึ่งมันไม่สนุกเลย !!
คำถาม แล้วจะเริ่มอย่างไรดีล่ะ ?
คำตอบคือ
ต้องยอมรับก่อนว่า code ที่เราดูแลอยู่นั้น
มันยากต่อการแก้ไขนะ
มันยากต่อการแก้ไขขึ้นเรื่อย ๆ
จากนั้นจึงเริ่มหาวิธีการแก้ไขให้มันดีขึ้น
ทั้งในระยะสั้น และ ระยะยาว
สุดท้ายแล้วลองกลับไปดูสิว่า
Code ที่คุณทำงานอยู่ด้วยนั้นมีอายุเท่าไร ?
และมันยากต่อการแก้ไขไหม ?
