ME_255_OwnershipBrick

ในการสร้างทีมพัฒนา software ขึ้นมานั้น
สิ่งหนึ่งที่ต้องทำการตัดสินใจร่วมกันของทีมก็คือ
การกำหนดความหมายของ Code Ownership หรือ ความเป็นเจ้าของ code กันอย่างไร
ซึ่งมันจะสะท้อนสิ่งต่างๆ ออกมาจากเส้นทางที่เลือก

เนื่องจาก Code Ownership คือข้อตกลงที่จะบอกว่า

  • code ของทีมจะถูกแบ่งเป็นกลุ่มๆ อย่างไร
  • ทีมทำงานกันอย่างไร
  • จะ share code ข้ามทีมอย่างไร
  • ใครมีหน้าที่รับผิดชอบในเครื่องคุณภาพของ code

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

ดังนั้น เรื่อง Code Ownership จึงเป็นสิ่งที่มองข้ามไปไม่ได้เลยนะ

เริ่มต้นมาดูกันก่อนว่า Code Ownership เป็นอย่างไร

คุณ Martin Fowler อธิบายไว้ว่า Code Ownership นั้นสามารถแบ่งได้ 3 กลุ่ม

1. Strong Code Ownership หรือ Individual Code Ownership

ทำการแยกหน้าที่ความรับผิดชอบ codeของแต่ละคน ตาม module, package, class, file ไปเลย
ดังนั้น developer แต่ละคนก็จะสามารถจัดการ code ที่ตอนเป็นเจ้าของได้เท่านั้น
ห้ามไปแก้ไข code ในส่วนของคนอื่นนะ เดี๋ยวจะโดนมิใช่น้อย
แต่ถ้าต้องการแก้ไขจริงๆ ต้องไปคุยคนที่ดูแล เพื่อให้เจ้าของแก้ไขให้ หรือ บอกว่าจะแก้ไขอย่างไร
ดังนั้นในวิธีการนี้ จะทำงานกันในรูปแบบการ patch code
แล้วส่ง patch นั้นไปยังคนที่ดูแลส่วนนั้นๆ

คุ้นๆ กันไหม ?

2. Weak Code Ownership

จะมีลักษณะคล้ายๆ แบบ Strong Code Ownership
แตกต่างกันตรงที่สามารถแก้ไข code ในส่วนที่ตัวเองไม่ได้รับผิดชอบได้เลย

แต่ถ้าการแก้ไขนั้นมันสำคัญมาก และ มีผลกระทบเยอะ
ต้องคุณกับเจ้าของ code ส่วนนั้นซะนะ เพื่อให้เข้าใจตรงกัน

3. Collective Code Ownership หรือ Shared Code

แบบนี้จะไม่มีใครเลยเป็นเจ้าของ code
แต่ ทีม คือ เจ้าของ code ทั้งหมดร่วมกัน
ใครๆ ก็ตามในทีม สามารถทำการแก้ไขส่วนใดๆ ใน code ได้ทั้งหมด
แก้ไขได้แบบทุกที่ทุกเวลา ทำให้เกิด No Code Ownership กันไปเลย
จะไ่ม่มีสิ่งมีชีวิตที่เรียกว่า ฮีโร่ หรือ เทพ ในทีมสำหรับส่วนนั้นๆ อีกต่อไป
มันเป็นสิ่งที่ขัดแย้งต่อชีวิตของ developer มากมาย

โดยคำว่า Collective Code Ownership มันคือแนวปฏิบัติหนึ่งใน Extreme Programming

คำถามก็คือ 
ตอนนี้ทีมของคุณมี Code Ownership แบบไหน ?
คำตอบ
…..

ถ้าตอบว่าเป็นแบบแรก คือ Strong Code Ownership แล้ว
ผมก็ขอยินดีด้วย ว่าคุณจะต้องพบเจอปัญหาแบบนี้แน่เลย

  • ต้องใช้เวลาในการพูดคุย เพื่อโน้มน้าวให้คนที่เป็นเจ้าของ code เข้าใจ และ แก้ไขตามที่เราต้องการ
  • ต้องใช้เวลาในการรอนาน กว่าจะพัฒนาเสร็จ แม้ว่ามันจะเป็นปัญหาง่ายๆ ก็ตาม
  • ถ้าเจ้าของ code ไม่อยู่ ก็เกิดอาการ …. ใช่ไหม
  • มีการส่ง patch หรือ ทำ pull request แบบผิดๆ …

ผมแนะนำว่าควรที่เปลี่ยนมาเป็นแบบที่สอง และ สาม จะดีกว่านะครับ
จะเลือกแบบไหน ก็ขึ้นอยู่กับทีมงานแล้วนะครับ
แต่ถ้าสำหรับผมแนะนำ Collective Code Ownership หรือ Shared Code เลยครับ

มาดูเหตุผลที่ไม่ดีของแต่ละอย่างกันหน่อยสิ ว่าเป็นอย่างไรบ้าง

ทำไม Strong Code Ownership หรือ Individual Code Ownership ถึงไม่ดี ?

จะพบว่าวิธีการนี้มักจะสร้างกำแพงของคนในทีมขึ้นมา
และเกิด dependency ขึ้นมามากมาย ทั้งภายในทีม และ ระหว่างทีม
ส่งผลให้งานที่กำลังทำนั้นต้องหยุดลง เพื่อรอใครคนใดคนหนึ่ง !!

คุณเจอปัญหาแบบนี้บ้างไหม ?
เช่น รอการ approve การแก้ไขจากใครคนใดคนหนึ่ง
ดังนั้น จึงเกิดปัญหาคอขวดขึ้นมา แต่ก็ยังทำมันอยู่ ….

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

คำพูดที่มักจะได้ยินในทีม ที่มี Code Ownership แบบนี้คือ
อย่ามายุ่งกับ code ของฉันนะ  code ของฉันไม่ผิดหรอกนะ !!


Screen Shot 2557-11-22 at 1.43.26 AM

มันส่งผลให้เกิด

  • ขาดการทำงานเป็นทีม
  • ขาดการ review code
  • ขาดการ refactor ในแนวทางที่ทีมเข้าใจ
  • หรืออาจจะ refactor มากจนเกินไปอีกด้วย
  • feedback ในเรื่องต่างๆ จะช้ามาก
  • ชอบโยนความผิด และ รับผิดชอบให้คนอื่นๆ
  • ไม่ค่อยสนใจภาพของระบบใหญ่ หรือ ทั้งหมด จะสนใจแต่ในส่วนที่ตอนเองรับผิดชอบ

ดังนั้นเปลี่ยน Code Ownership เถอะนะครับ เพื่อไม่เป็นภาระของลูกหลาน

ทำไม Collective Code Ownership หรือ Shared Code ถึงไม่ดี ?

ปัญหาที่สามารถเกิดกับรูปแบบนี้ คือ การ share code มากจนเกินไปนั่นเอง
ทำให้เกิดปัญหาดังนี้

  • Code ไร้ซึ่งความแน่นอน เช่นโครงสร้างของ code ไม่ดี อาจจะเกิด duplicate เยอะ
  • เกิด bug จำนวนมาก เช่น การ refactoring code แบบไม่เข้าใจ อาจจะไปทำให้ code ส่วนอื่นทำงานไม่ได้
  • เกิดสังคมนิยม blame คือ โยนความผิดกันไปมา ซึ่งมันไม่สนุกเลย
  • การส่งมอบที่ล่าช้า เพราะว่าไม่มีใครเลยที่เชี่ยวชาญในส่วนนั้นๆ โดยที่ทุกคนต้องพยายามทำความเข้าใจ ทำให้ไม่มีเวลาเขียน code กัน

ดังนั้น ถ้าคุณเชื่อใน Collective Code Ownership หรือ Shared Code แล้ว
มันจะทำงานได้ดีก็ต่อเมื่อ คุณนำไปใช้อย่างถูกที่ ถูกเวลา และถูกทีม คือ

  • ความสามารถภายในทีมใกล้เคียงกัน
  • developer แต่ละคนให้ความสนใจในงานตนเอง เคารพ และ เชื่อมั่นคนในทีม
  • สถานะของ code ต้องดีอยู่ตลอดเวลา
  • Unit test ขาดไม่ได้เลย ถ้าไม่มีแล้วคุณจะรู้ได้อย่างไรว่า code ของทีมยังดี และ ทำงานถูกต้องตามที่คาดหวัง

อย่าลืมว่า Collective Code Ownership หรือ Shared Code นั้นมาจาก Extreme Programming
ดังนั้นทีมจะประสบความสำเร็จได้ ถ้าทุกๆ คนในทีมแบ่งปันความเข้าใจ
ทั้งในเรื่องของ domain problem และ การออกแบบของระบบ
ตลอดจนเรื่องของ technical skill ต่างๆ
ที่จะต้องมี หรือ ปรับปรุงให้ดีขึ้นอยู่อย่างสม่ำเสมอ เช่น

โดยสรุปแล้ว

ผมมักจะเลือกทั้ง Collective Code Ownership + Weak Code Ownership
เนื่องจากสมาชิกในทีมมีความสามารถ ประสบการณ์ ต่างๆ ไม่เท่ากัน
ถ้า code ส่วนที่เป็นส่วนทำงานหลัก หรือ ส่วนที่ถูกใช้งานเยอะๆ จากส่วนอื่น
ซึ่งแน่นอนว่ามันจะกระทบต่อเรื่องความถูกต้อง คุณภาพ และ ขวัญกำลังใจของทีม
ดังนั้น ถ้าต้องการแก้ไข code ส่วนนั้น อาจจะต้องมีการพูดคุยกันเสียก่อน
ผลที่ได้ตามมาก็คือ จะเกิดการอธิบายการทำงานในส่วนนั้น
นั่นคือ การเริ่มแบ่งปันความรู้ความเข้าใจให้คนอื่นๆ ในทีม

จะเห็นได้ว่า Code Ownership ในแต่ละแบบมีทั้งข้อดีและข้อเสีย ( แต่ Strong Code Ownership อย่าเอามาใช้นะ )
ซึ่งคุณต้องเลือกระหว่าง

  • ความยึดหยุ่น vs คุณภาพของงาน
  • Team ownership vs Individual ownership

แต่สุดท้ายแล้ว สิ่งที่คุณต้องมองกลับไปดูทีมคือ

  • ทีมสามารถส่งมอบได้ไหม ?
  • ทีมติดปัญหาอะไรไหม ?
  • ทีมทำงานได้รวดเร็วไหม ?
  • ทีมทำงานได้ดีขึ้นไหม ?
  • ถ้าทีมมีจำนานสมาชิกลดลงจากเดิม ยังคงสามารถส่งมอบงานได้ไหม ?
  • ทีมคุณมีความสุขไหม ?

ถ้าไม่ในข้อใดข้อหนึ่ง ก็ต้องเริ่มแก้ไข และ ปรับปรุงแล้วนะครับ