Code ที่ developer ทำงานอยู่ด้วยนั้น มีอายุเท่าไร ?

จากบทความเรื่อง 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 ที่คุณทำงานอยู่ด้วยนั้นมีอายุเท่าไร ? และมันยากต่อการแก้ไขไหม ?