เจาะประเด็น
Tech Debt
"เขียนใหม่จากศูนย์" คือกับดักที่โค้ดเหม็นชอบใช้หลอกเรา
วงการ dev ชอบฝันว่า rewrite ทีเดียวจบ แต่ความจริงคือคุณอาจได้ระบบพังสองชุดที่ต้องดูแลแทนที่จะเป็นชุดเดียว
ทีมข่าว เอไอไทย.com
⏱ อ่าน 4 นาที
ถ้าคุณคิดว่า "โค้ดเก่าแม่งโคตรเลว เอาใหม่หมดเลยดีกว่า" — ขอเตือนไว้ก่อนว่าคุณอาจกำลังเดินเข้าป่าที่มีแต่คนหลงทางมาก่อนคุณเยอะแล้ว
เรื่องนี้มันคลาสสิกมาก Simon Willison เจ้าของบล็อกสาย dev ที่คนทั้งวงการอ่าน ไปเจอคอมเมนต์ใน Lobste.rs ถกกันเรื่อง "โค้ดพังจนทนไม่ไหว จะจุดไฟเผาแล้วเขียนใหม่ทั้งระบบดีไหม" แล้วเขาก็สวนกลับด้วยประสบการณ์ตรงที่ทำเอาคนที่คิดจะ rewrite ต้องหยุดคิด — เพราะในโลกความจริง การเขียนใหม่จากศูนย์มันแทบจะไม่เคยสำเร็จอย่างที่ฝัน
ฟังดูเข้าท่าใช่ไหม? โค้ดเก่าเต็มไปด้วยหนี้เทคนิค (technical debt) ยิ่งแกะยิ่งมึน ฟีเจอร์ใหม่ใส่ทีไรพังทุกที ก็เลยประกาศกร้าวว่า "เลิกกับของเก่า เขียนใหม่หมด!" ทีมใหม่ตั้งขึ้นมา คนเก่งๆ ไปนั่งเขียน greenfield project สดใสไร้มลพิษ สัปดาห์แรกโค้ดสะอาดปิ๊ง สปีดการพัฒนาวิ่งฉิว — แต่เดี๋ยวก่อน ความจริงมันไม่ได้จบแค่นั้น
ระหว่างที่ทีมใหม่กำลังสนุกกับของเล่นชิ้นใหม่ ระบบเก่าที่ "กำลังจะถูกแทนที่" มันยังทำงานอยู่ และยังต้องแบกธุรกิจหลักของบริษัทต่อไป คนที่ดูแลมันรู้ดีว่าอีกไม่นานตัวเองก็จะถูกยุบทีม หรือถูกย้ายไปทำโปรเจกต์ใหม่อันสดใสกว่า — ฉะนั้นแรงจูงใจในการพัฒนาระบบเก่ามันเหลือศูนย์ จะทำก็แค่ให้ผ่านๆ ไป ไม่ออกแบบให้ดี ไม่เขียนเทสต์ ไม่ทำเอกสาร เพราะเดี๋ยวก็โดนทิ้งอยู่ดี หนี้เทคนิคของระบบเก่าก็เลยยิ่งพอกพูนหนักขึ้นไปอีก
แล้วอีกฟากหนึ่ง ทีมใหม่ที่เริ่มต้นด้วยความมั่นใจเต็มร้อยก็เริ่มเจอความจริงอันโหดร้าย — พวกเขาไม่รู้จริงๆ ว่าระบบเก่ามันทำอะไรบ้าง คิดดูสิ ถ้ามันมีเอกสารครบหรือมีเทสต์ครอบคลุม มันก็คงไม่ต้องโดนเขียนใหม่ให้วุ่นวายขนาดนี้ใช่ไหม? ยิ่งเวลาผ่านไป ยิ่งเห็นชัดว่า "ของที่กำลังจะแทนที่" มันซับซ้อนกว่าที่คิดไว้ตอนประชุมคิกออฟเยอะมาก
ผ่านไปหลายเดือนจนถึงหลายปี ระบบใหม่ยังไม่สามารถแทนที่ระบบเก่าได้เต็มร้อย แรงกดดันจากผู้บริหารก็เริ่มมา "จะเอาไงต่อ? ลงทุนไปตั้งเยอะ ยังไม่เห็นของออกมาสักที" สุดท้ายก็ต้อง compromise — ระบบใหม่ถูกลงโปรดักชัน แต่รับผิดชอบแค่ subset เล็กๆ ของระบบเก่า หรือไม่ก็กลายเป็นที่ลงฟีเจอร์ใหม่ๆ ที่ระบบเก่าไม่มีแรงจะแบกรับไหว
และนี่คือตอนจบที่พีคที่สุด — คุณไม่ได้มีระบบที่ดีกว่าหนึ่งระบบ แต่คุณมีระบบที่แย่สองระบบในโปรดักชันพร้อมๆ กัน ระบบเก่าที่ไม่มีใครอยากแตะ แต่ยังต้องรันต่อไปเพราะธุรกิจยังใช้มันอยู่ และระบบใหม่ที่ประมวลผลฟีเจอร์จริงๆ แค่ไม่กี่อย่าง ที่เหลืออีก 80% เป็นโค้ดที่ตั้งใจจะแทนที่ระบบเก่าแต่ยังทำไม่เสร็จ — กลายเป็นซากเดดโค้ดที่ต้องดูแลเพิ่มอีกชุด
ถ้าคุณโชคดีสุดๆ บริษัทอาจจะยังไม่หมดความอดทนกับระบบใหม่ และปล่อยให้ทีมค่อยๆ เคลียร์งานต่อไปเรื่อยๆ แต่ยิ่งเวลาลากยาว ระบบเก่ายังรันได้ (ถึงจะห่วยแต่ก็ไม่ตาย) ความเสี่ยงที่ "ทิศทางบริษัทเปลี่ยน" หรือ "priority เปลี่ยน" ก็ยิ่งสูง จนสุดท้ายโปรเจกต์แทนที่ทั้งหมดก็อาจถูกทิ้งกลางทาง — คุณเหลือระบบสองระบบที่เคยมีแค่ระบบเดียว และหนี้เทคนิครวมก็เพิ่มเป็นสองเท่าโดยไม่ได้อะไรกลับมา
Simon ไม่ได้แค่เล่าเรื่องน่ากลัว แต่เขาชี้ทางออกที่น่าสนใจกว่าเยอะ — อ้างอิงบทความของ Will Larson เรื่อง "Migrations: the sole scalable fix to tech debt" ที่บอกว่าการย้ายระบบแบบค่อยเป็นค่อยไป (migration) คือทางรอดที่ยั่งยืน ไม่ใช่การทิ้งของเก่าแล้วเริ่มนับหนึ่งใหม่ และถ้าเขาเจอเหตุการณ์แบบนี้อีกในอนาคต เขาจะเลือกอุดระบบเก่าด้วย automated testing ให้หนาที่สุดก่อน แล้วค่อยๆ ทำ targeted refactor ทีละจุด — ซึ่งตรงกับความเชื่อส่วนตัวเรามาก เพราะโค้ดที่ "เขียนมานาน" มันไม่ได้เลวร้ายไปทั้งหมด มันแค่มีจุดที่เน่าจริงๆ ไม่กี่จุด แก้ให้ตรงจุดดีกว่าทิ้งทั้งระบบแล้วเริ่มจากศูนย์ที่ไม่มีใครรู้จักอะไรเลย
ระบบเก่า
ยังรันธุรกิจหลักอยู่ จะหยุดพัฒนาไม่ได้ แต่คนดูแลหมดแรงจูงใจ เพราะรู้ว่าอีกไม่นานโดนแทนที่ — สุดท้ายหนี้เทคนิคยิ่งทวีคูณ
ระบบใหม่
เริ่มต้นเร็วเพราะไม่มีของเก่ามาถ่วง แต่พอนานไปก็พบว่าไม่มีใครเข้าใจระบบเดิมจริงๆ สุดท้ายลงโปรดักชันแบบครึ่งๆ กลางๆ แทนที่ได้แค่บางส่วน
ทางออก
อย่าเพิ่งฝันถึง greenfield เขียนเทสต์ให้ระบบเก่าหนาขึ้นก่อน แล้วค่อยๆ refactor ทีละจุด — โอกาสสำเร็จสูงกว่า "เขียนใหม่" เยอะ
ฟังนะ การเขียนโค้ดใหม่จากศูนย์มัน sexy และน่าตื่นเต้นเสมอ แต่มันคือกับดักที่ทำให้บริษัทเจ๊งมาแล้วนับไม่ถ้วน — ถ้าอยากแก้หนี้เทคนิคจริงๆ จงใช้วิธีที่น่าเบื่อแต่ได้ผล: เขียนเทสต์ให้หนา แล้วค่อยๆ แก้ทีละจุด ไม่งั้นคุณอาจได้ระบบพังสองอันที่ต้องดูแลแทนที่จะเป็นหนึ่งเดียวที่แข็งแรง
ที่มา: Simon Willison's Weblog — อ่านต้นฉบับ
ความคิดเห็น 3
กำลังโหลดความคิดเห็น...