images
ก่อนหน้านี้เคยอธิบายไว้ว่า เราควร tracking พวก technical debt
และทำการเขียนออกมาเป็น backlog เลยนะ
เพื่อทำให้ทีม และ ผู้ว่าจ้าง เห็นว่าต้องมีค่าใช้จ่าย และ ความเสี่ยง มากน้อยเพียงใด
เพื่อทำให้ผู้ว่าจ้าง และ ทีม มาช่วยกันจัดเรียงความสำคัญของ backlog
โดยมีเป้าหมายเพื่อ ทำให้แน่ใจว่าค่าใช้จ่ายและความเสี่ยงจะลด หรือ หมดไปในที่สุด
ซึ่งมันเป็นแนวปฏิบัติที่ดีมากๆ แต่ …

Track ไป ก็แก้ได้ไม่หมดหรอกนะ !!

ตัวอย่างเช่น

  • ปัญหาการ copy-and-paste ก่อให้เกิด code ที่ซ้ำซ้อนกันเยอะมากๆ
  • ปัญหา Coding style ที่หลากหลายมากๆ
  • ชื่อแย่ๆ ของตัวแปร และ method ต่างๆ
  • Method มีขนาดใหญ่มากๆ
  • การ Hard code
  • พวก Magic number ต่างๆ
  • Bug เล็กๆ น้อยๆ

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

แล้วยังไงล่ะ ?
แทนที่จะทำการ track เรื่องพวกนี้ ก็ให้ทำเป็นนิสัยเลยไหม
คือให้ทำการ refactoring code แบบวันต่อวันไปเลย
หรือ ถ้าคุณเปิด code ขึ้นมา แล้วพบว่ามันแย่นะ ให้ทำการแก้ไขทันที
ลองคิดดูสิ ถ้าคุณและทีมไม่ทำการแก้ไข code ที่มันแย่ๆ ที่สร้างกันขึ้นมา
แล้วใครละ ? ที่จะมาแก้ไข
ตอบได้เลยว่า ไม่มีหรอกนะ

ดังนั้นให้ทำการแก้ไขซะนะ
มันไม่มีค่าใช้จ่ายอะไรเลยนะ

การไม่รู้ว่า สิ่งที่ตัวเองทำมันคือ Technical debt

มันเป็นหนี้ที่น่ากลัวมากๆ เพราะว่า แม้แต่คุณยังไม่รู้เลยนะ
แน่นอนว่าคุณก็ไม่รู้แน่ๆ ว่าต้องทำอย่างไรให้ดีขึ้น ใช่ไหม ?

ความไม่รู้นี่เองส่งผลให้คุณตัดสินใจเลือก และ ทำอะไรออกมาที่แย่ๆ
เช่น

  • มีการใช้ framework แต่ไม่ได้รู้จักมันดีเลย ใช้ได้อย่างเดียว
  • เรื่อง Top security ที่ OWASP ยังไม่รู้จักเลย ดังนั้นไม่ต้องคิดว่า จะป้องกันด้านความปลอดภัยได้อย่างไร

แน่นอนว่าหนี้เหล่านี้ มันไม่เคยไปอยู่ใน backlog หรอกนะ
แต่เมื่อมีอะไรเปลี่ยนแปลง เช่นมีคนที่มีประสบการณ์สูงๆ เข้ามาในทีม
แล้วมาดู code ของคุณ แล้ว จะพบว่า คุณทำการ hack framework ที่ใช้นะ
และแล้วความจริงก็ถูกเปิดเผยขึ้น
และทันใดนั้นเองหนี้ก็ได้เกิดขึ้นมาแล้ว

ลองคิดดูเล่นๆ ถ้าไม่มีอะไรเปลี่ยนแปลง
หนี้มันก็ถูกซ่อน ปิดบังไว้อย่างนั้นต่อไป
ซึ่งมันน่ากลัวสุดๆ เลยว่าไหมครับ ?

Technical debt มันใหญ่ และ เยอะมากๆ

บางครั้ง หรือ บ่อยครั้งก็ไม่แน่ใจนะ ที่คุณจะเผชิญกับหนี้ชิ้นใหญ่มากๆ
คุณอาจจะพบว่า เลือก architecture ผิด
คุณอาจจะพบว่า เลือกภาษาโปรแกรมผิด
คุณอาจจะพบว่า เลือก framework ผิด
คุณอาจจะพบว่า เลือก technology ผิด
ส่งผลทำให้ระบบไม่สามารถรองรับการขยายตัวได้
ส่งผลทำให้ระบบมีจุดอ่อนด้วยความปลอดภัยเยอะมากๆ
ส่งผลทำให้ระบบเปลี่ยนแปลงได้ยากสุดๆ ไปเลย

ทำให้คุณไม่สามารถ refactoring ได้เลย
แต่คุณมีสองทางเลือก คือ

  1. ทำมันให้ดีขึ้นด้วยความพยายามสูงสุด
  2. เขียนใหม่

ผมเชื่อว่าร้อยละ 99.99 ของนักพัฒนาเลือก เขียนใหม่ !!
แต่ให้เชื่อเถอะว่า ถึงว่าระบบมันจะแย่สุดๆ ยังไงก็ตาม
มันย่อมมีข้อดีบ้างล่ะนะ ดังนั้น refactoring เถอะครับ

ในข้อนี้จะเขียนหนี้ลง backlog ไปเท่าไร ก็ไม่น่าจะช่วยอะไรนะครับ !!!

Fix it now แต่ไม่ใช่ทั้งหมดนะ !!

หนี้ต่างๆ นั้นคุณสามารถทำบางสิ่งบางอย่างเพื่อลดจำนวนลงได้
ซึ่งอาจจะเป็นหน้าที่โดยตรงของคุณ หรือ ไม่ก็ได้
เรื่องนี้มันบ่งบอกว่าคุณมีความตั้งใจ และ มีวินัย มากเพีบงใดมากๆ

บางครั้งคุณคิดว่า เราต้องได้รับ feedback กลับมาให้รวดเร็ว
ดังนั้น เรามีความคิดที่ว่า ทำให้มันเสร็จๆ ไปก่อน
เดี๋ยวยังไงก็ต้องกลับมาเขียนใหม่อยู่แล้ว !!
แนวคิดนี้มันเป็นต้นเหตุหลักของ technical debt เลย

หรือบางครั้งอยู่ภายใต้ความกดดัน
ดังนั้นทำให้มันเสร็จให้เร็วที่สุดเท่าที่จะทำได้กันไปเลย
แนวคิดนี้ก็เป็นต้นเหตุหลักของ technical debt ด้วยนะ

หรือบางครั้ง นักพัฒนาชอบทำให้เพียง code ทำงานได้ (Make it work)

  • ใช้ทั้งวิธีการ hack
  • ใช้ทั้งวิธีการ copy-and-paste
  • ไร้มาตรฐานการเขียน
  • ไม่มีการ review code ใดๆ ทั้งสิ้น
  • ไม่เขียน test หรือเขียนแต่ไม่เพียงพอ

แต่สิ่งที่ทำคือ debug code ไงล่ะ
สุดท้ายก็เจ็บปวดในการ maintain code
แล้วบอกว่า สิ่งที่ทำมานั่นคือ มาตรฐานของเรานะ … มันใช่หรือไม่ !!!

ยิ่งถ้าปล่อยหนี้ไว้นานมากเท่าไร
การแก้ไขก็ยิ่งยากเป็นพันทวีขึ้นไป
และสุดท้ายคุณนั่นแหละ ที่ต้องเราภาระในการชำระหนี้
หรือจะหนีก็ว่ากันไป !!!

ดังนั้น อย่าทำการ tracking technical debt เลย แต่ให้จัดการมันซะ !!

แน่นอนว่ายังไงคุณก็ต้อง tracking สิ ไม่งั้นจะรู้ได้อย่างไร
จะเข้าใจได้อย่างไรว่ามีหนี้อะไรบ้าง
แต่ถ้าคุณเห็นหนี้แล้ว จะทำการเขียนไว้ใน backlog ไปทำอะไร ?

ดังนั้น เปลี่ยนแนวคิดใหม่ว่า
ถ้าคุณเจอ technical debt แล้ว
ให้ทำการแก้ไข หรือ จัดการมันเลยในทีนทีดีกว่านะ
แทนที่จะเสียเวลามานั่งเขียน backlog
มันคือ หน้าที่ ความรับผิดชอบ ที่คุณจะต้องฝึกกันได้แล้วนะครับ
เริ่มตั้งแต่ตอนนี้เป็นต้นไป