เคยใช้ app ที่ยิ่งใช้ไปนานๆ ยิ่งรู้สึกอยากเลิกใช้ ไม๊ครับ แบบอยากให้เรท 1 ดาว เพราะใช้แล้วติดๆขัดๆ บั๊กเยอะ ใช้ยาก ไม่เหมือนตอนใช้ตอนแรกๆ หรือเคยได้ยินเรื่องราวของซอฟต์แวร์ที่ประสบปัญหาการใช้งานบ้างไม๊ครับ เหตุที่เป็นเช่นนั้น ส่วนหนึ่งมาจากโค้ดเน่าๆที่แฝงตัวอยู่ในโปรเจคเป็นไวรัสพร้อมที่จะติดต่อไปหาโปรแกรมเมอร์คนอื่นได้ทุกเมื่อ ลองมาทำความเข้าใจถึงสาเหตุของการส่งกลิ่น และทำไมถึงติดต่อกันได้ครับ
ธรรมชาติของการพัฒนาซอฟต์แวร์ มักจะมี deadline ในการส่งมอบ working software ให้กับลูกค้า หรือ users เป็นรอบๆ และบางครั้งก็เร่งรีบจากสาเหตุหลายประการ ทำให้ทีมพยายาม focus ไปที่ features ที่จะส่งมอบ และเทส feature นั้นๆ รวมถึงสิ่งที่พอจะทำได้เช่น performance ในขณะที่มักจะลืมสิ่งที่ถูกมองข้ามได้ง่ายอย่างเช่น maintainability และ reusability
ถ้าโปรเจคส่งมอบได้ จะเข้าสู่โหมด maintenance ในช่วงนี้จะมีการแก้โค้ดและ enhancement ในลักษณะเพิ่มโค้ดเข้าไปเรื่อยๆ ตาม feedback ที่ได้มา หากยิ่งไม่มีการ refactor หรือ improve code quality แล้วนั้น มันก็จะค่อยๆกัดกร่อน quality กล่าวคือ ถ้าในโค้ดมี “code smells” หรือโค้ดเน่าอยู่ และหากเราไม่ refactor มัน มันจะไปสู่จุดที่ไม่มีโปรแกรมเมอร์คนไหนกล้าแตะโค้ดเลย เพราะกลัวจะยิ่งทำให้สถานการณ์ (quality) แย่ลงกว่าเดิม
โค้ดที่เน่ามักจะแก้ยากกว่าโดยธรรมชาติ เพราะมันทำความเข้าใจได้ยาก โค้ดมักจะพันกันเป็นเส้นสปาเกตตี การไม่ใช้หลักการของ DRY (Don’t repeat yourself), YAGNI (You ain’t gonna need it) หรือ KISS (keep it simple and short) และ best practices อื่นใด ล้วนแล้วแต่ทำให้โค้ดเน่า การแก้เพียงแค่นิดเดียวอาจทำให้พังทั้งโปรเจคได้เลย กล่าวคือมันอาจเปราะบางถึงขั้นที่ไม่สามารถควบคุมได้ และสุดท้าย users ต้องย้ายไปใช้ซอฟต์แวร์ของเจ้าอื่น หรือสั่งให้เขียนขึ้นใหม่ อย่างไรก็ตาม สำหรับซอฟต์แวร์ขนาดใหญ่อย่าง enterprise software การทำเช่นนั้น จะมีค่าใช้จ่ายที่สูงมาก
แล้วทำไม quality ของซอฟต์แวร์ถึงถูกกัดกร่อนได้เร็วขนาดนั้น ทำไม programmer ไม่ทำตามหลักการหรือ best practies เพื่อไม่ให้เกิด “code smells” ลองไปดูคำอธิบายด้วยทฤษฎี “Broken Window” กัน
ทฤษฎี Broken Window เขียนโดย Wilson and Kelling ในปีค.ศ. 1982 มีใจความว่า “ตึกที่มีหน้าต่างแตกเพียงบานเดียว หากไม่รีบซ่อม นานวันเข้า มันมีแนวโน้มที่จะแตกเพิ่มโดยผู้ไม่หวังดี นำไปสู่การบุกรุกเข้าไป และหากตึกไม่มีคนอยู่ พวกเค้าก็จะอยู่อาศัย ซ่องสุม และเป็นบ่อเกิดแห่งอาชญากรรม”
หรือถ้าจะอธิบายง่ายๆด้วยปัญหาสายโทรศัพท์โทรศัพท์ หากมีช่างคนนึงที่ไม่เดินสายให้เรียบร้อย ช่างที่เดินสายคนต่อๆไปก็จะทำตาม และเกิดเป็นปัญหาสายสัญญาณที่ยุ่งเหยิงและแก้ได้ยากในที่สุด
ในโลกของซอฟต์แวร์นั้น programmer ทราบดีว่า code smells เป็นอย่างไร แต่ก็นั่นแหละ หาก product manager ต้องการ launch product ให้เร็วที่สุด เค้าจะเลือกที่จะละเลยหลักการบางอย่างพื่อให้เสร็จทัน deadline ยิ่งถ้ามีคนก่อนหน้าเคยทำไว้เป็นตัวอย่างแล้ว เค้าจะไม่ลังเลที่จะทำตามกัน ยิ่งถ้าคนอื่นๆไม่ใส่ใจ เช่น peer review ที่หละหลวม ยิ่งส่งเสริมให้เกิด code smells และท้ายที่สุดก็จะนำไปสู่ความยุ่งเหยิงจนยากที่จะแก้ ถึงขั้นต้องเลิกล้มโปรเจคกันไป
วิธีแก้ปัญหาที่ดีที่สุดในสถานการณ์เช่นนี้คือ ต้องรีบแก้ใข code smells ในขณะที่มันยังไม่หมักหมมจนเป็นดินพอกหางหมู ในการพัฒนาซอฟต์แวร์หากไม่รีบทำการ refactor แต่เนิ่นๆ มันจะไปเร็วมากและยากที่จะกลับมาแก้ไข การ refactor เล็กๆน้อยๆในทุกๆ bug fix และ improvement กลับทำได้ง่ายกว่าและมีประสิทธิภาพกว่าการที่ต้อง refactor ใหญ่ๆ ที่ต้องมีการ approve ให้ทำ เนื่องจากต้องใช้เวลาและมีค่าใช้จ่าย การนำ refactor activities เช่นพวก tech debt tickets มาอยู่ในทุกๆ sprint ควรต้องทำให้เป็นนิสัย การเพิ่มความเข้มข้นในการทำ peer review process ก็เป็นสิ่งที่ต้องทำเป็นอย่างย่ิง
สรุป
บ่อยครั้ง การทำ refactor ใหญ่ๆ มักเกิดได้ยาก แต่ไม่ได้แปลว่าการ refactor เล็กๆ ไม่สามารถเกิดได้ ดังนั้นสิ่งแรกที่ต้องทำ คือควร refactor ทุกครั้งที่มีการ change code ใช้เวลาเพิ่มขึ้นสักนิดเพื่อ make sure ว่า code มีคุณภาพ ประการที่สองคือโปรแกรมเมอร์ต้องตระหนักให้มากว่าการละเลยหลักการหรือ best pratices สามารถสร้างปัญหาในอนาคตได้ สองอย่างนี้จะช่วยรักษาให้โปรเจคมีคุณภาพ และนำไปสู่ maintainability และ reusability ในท้ายที่สุด