Technical Debt เขียน Code แล้วทำไมถึงติดหนี้ แถมมีดอกเบี้ยด้วย !!!

จากหัวข้อของบทความ หลายคนน่าจะสงสัยว่าทำไม "เขียน Code แล้วทำไมถึงติดหนี้ แถมมีดอกเบี้ยด้วย !!!" เดี๋ยวผมจะมาอธิบายครับ ว่าทำไมเราถึงได้สร้างหนี้ และหนี้ในการเขียน Code จริงๆ ก็ไม่เชิงนะ บอกว่าเป็นหนี้ในการพัฒนาระบบ น่าจะดีกว่าครับ โดยหนี้ที่เกิดขึ้นมี ดังนี้ครับ

  • Acceptable - เป็นหนี้ในระยะสั้น และระยะยาวได้ประโยชน์ มองเป็นการลงทุนแนวๆ VI ได้เลยนะเนี่ย
    • Make a trade-off to Hit a market window - ยอมลงทุน ผมไม่มองว่าเป็นหนี้นะ เพื่อให้ตามตลาดให้ทัน ในระยะสั้น อาทิ เช่น การเพิ่มการเชื่อมต่อกับ Social Network อย่าง FB, Twitter เป็นต้น
    • Waiting for Right abstraction - รอแนวทาง การวางโครงสร้างของระบบี่ถูกต้อง เพื่อลดหนี้ในอนาคต
    • Reflection and Learning about your domain or technology - มีการเรียนรู้ และไตร่ตรอง แนวทางของระบบ หรือ เทคโนโลยีใหม่
    • Receive new requirement that render the current solution insufficient - ได้รับ Requirement ใหม่ ที่ทำให้วิธีการแก้ปัญหาในตอนนี้ ไม่ตอบโจทย์ โดยอาจจะเป็นได้รับ Requirement แต่จะไม่เร่งด่วนเท่ากับข้อแรกนะครับ
      • เพื่อให้สามารถแข่งขันได้ เช่น การปรับให้โปรแกรมรองรับการ product ทางการเงินใหม่ๆ
      • เพื่อให้ได้รับประโยชน์จากตลาดมากขึ้น
      • เพื่อให้เกิด Innovation มี Feature ใหม่ครับ ไว้สำหรับ Sale ครับ เช่น ทำหน้า Enquiry ให้มีลูกเล่นทำ pivot กับข้อมูลได้
  • Unavoidable - หนี้ที่เกิดจากสถานการณ์ที่เราไม่สามารถคาดเดาได้
    • Working on the edge of chaos - ทำงานในสภาวะที่สับสนยุ่งเหยิง
    • Inherited debt - หนี้ต่อเนื่องหนุนกันมา จาก code เก่าๆ แต่ถ้าเยอะไปก็ไม่ดีนะครับ สยองงงงงงงงงง
    • Staff turnover - พนักงานลาออก
    • Complying with new regulations - เกิดการเปลี่ยนแปลงจากปัจจัยภายนอก อาทิ เช่น กฏหมายเปลี่ยน กฏเกณฑ์เปลี่ยน ตัวอย่าง เช่น
      • โปรแกรมตรวจสลากกินแบ่ง ต้องปรับให้ระบบรับการตรวจเลขแบบ เลขสามตัวหน้า เพราะ กองสลาก เปลี่ยนกฏ
      • DataSet LQ1 ต้องส่ง Holding ณ วัน Settle จากเดิมที่เป็นวัน Trade เนื่องจาก BOT เปลี่ยนกฏเกณฑ์
    • Changes in demand - การเปลี่ยนแปลงที่เกิดจากความต้องการของผู้ใช้จริงๆ (ไม่นับกรณีที่ขอเปลี่ยน เพราะ ลืมบอก หรือ เข้าใจไม่ตรงกัน หรือ User เองไม่รู้ใจตัวเอง ไม่เชี่ยวชาญในสิ่งที่ต้องการ นะครับ ฮ่าๆ) ตัวอย่างของ Changes in demand
      • Flickr เว็บแชร์รูปภาพชื่อดังแห่งหนึ่ง แต่จริงๆแล้ว Flickr ไม่ได้ทำมาเพื่อแชร์รูปนะครับ แต่เป็นเกมโลกเสมือนชื่อ Neverending แต่เกมไม่ประสบความสำเร็จ แต่ Feature แชร์รูปกลับ โด่งดังแทนครับ และโดน Yahoo ซื้อไปครับ
  • Unnecessary - หนี้ที่เกิดแล้วทำให้ระบบงานเรารอดมีงานส่งได้ แต่ไม่มีประโยชน์ให้แก่ทีมงาน หรือองค์กรเลย
    • Working under stress - ทำงานในสภาวะที่กดดัน
    • Having insufficient knowledge - ขาดความรู้ ขาดทักษะในการเลือกเครื่องมือ เพื่อที่จะมาจัดการกับปัญหา
    • Making premature optimization - การปรับแต่ง Code ให้ทำงานเร็วขึ้น แต่ไม่ได้มีการทดสอบกับ Data จริง ทำให้เวลาใช้งานจริงอาจจะมีปัญหา และการเป็นว่าต้องมาเขียน Code แก้ปัญหาหน้างานให้มันรอดได้ แต่มันก่อเกิดหนี้
    • Adhering  to the not-invented-here syndrome - ไปในทาง Not-Invented-Here Syndrome แบบสุดโต่ง
    • Adhering  to the proudly-found-elsewhere syndrome - ไปในทาง Proudly-Found-Elsewhere Syndrome แบบสุดโต่ง
    • Creating vendor lock-in or framework leakage - เจอข้อจำกัดของ Third Party หรือ Library ต่างๆ
    • Writing one-way code - การเขียน Code หรือการวางโครงสร้างที่ไม่มียืดหยุ่นกับการเปลี่ยนแปลงในอนาคต เช่น Requirement ใหม่ๆ หรือ Feature ใหม่ๆ
    • Writing too-clever code - เขียน Code Logic สุดอลังการทั้งๆที่ปัญหา มันง่ายนิดเดียว
    • Suffering from technical policies - ติดปัญหาจาก Policies ข้างใน อาทิ เช่น การกำหนด Tools ที่ใช้งาน หรือภาษาต่างๆ เพื่อให้ง่ายกับการดูแล แต่บางครั้งการทำตาม Policies อาจจะทำให้เกิดการปัญหาแทน จากการเขียน Code เพื่อให้มันใช้ได้ หรือ หาวิธี Workaround กับมันไปก่อน
  • Bad - หนี้แบบนี้ ถ้าเกิดแล้วระบบงานของเราคงจะรอดยาก หรือขึ้น Production ได้ แต่ปัญหาเพียบบบบ
    • Lack of communication - ขาดการสื่อสารที่ดี
    • Unprofessionalism
    • Habitual(อย่างเป็นประจำ) corner-cutting - ทำอะไรโดยไม่คิดให้ดีก่อน ว่าจะได้ไม่คุ้มเสีย
    • Creating excuses for writing bad code---the broken window syndrome
    • Lack of respect - ขาดความเอาใจใส่
    • Unresolved disagreements - ปัญหาในทีมที่ยังหาข้อตกลงไม่ได้
รูปภาพจาก https://devhumor.com/media/technical-dept-customer-vs-developer
รูปภาพจาก https://devhumor.com/media/technical-dept-customer-vs-developer

ท้ายที่สุดครับ เราสามารถทำให้ Code ดีขึ้นได้นะครับ ขอแค่มีความกล้าที่จะเข้าไปจัดการกับมัน แม้ว่า Legacy Code นั้น เป็นตัวทำเงินให้กับหน่วยงาน หรือองค์กร แต่ถ้าทิ้งไว้นานเข้า หนี้มันเยอะจากดอกเบี้ยนะครับ ระบบยิ่งเก่า ถ้า Code มันแย่ ค่าใช้จ่ายในการจัดการมันจะยิ่งสูงขึ้นเรื่อยๆครับ และก็ระดับของหนี้แปรผันระดับความรู้ Business ของ Develop ครับ ถ้ารู้ไม่ครบ ระบบอาจจะมีหนี้ โดยที่เราไม่รู้ตัวก็ได้นะ


Discover more from naiwaen@DebuggingSoft

Subscribe to get the latest posts sent to your email.