ลดปัญหา System Dependency ด้วย Versioning

A Lesson Learned from Hubspot.com

The Way It Is

ผมเชื่อนะว่าพวกเราหลายๆคนเคยอยู่ในสถานการณ์ที่ต้องรับเคราะห์กรรมที่เรา หรือทีมเราไม่ได้เป็นคนก่อ เคราะห์กรรมที่เห็นได้ชัดเจนมากอย่างหนึ่งคือ System Dependency … แบบนี้

Development Phase:

พี่จากทีม B: “น้องๆ เดี๋ยวพี่จะแก้ระบบของพี่หน่อยนะ รบกวนน้องช่วยดู System Design ให้ด้วยว่ากระทบกับระบบของน้องรึเปล่า”

เรา: งานตัวเองก็จะทำไม่ทันอยู่แล้ว ยังให้ไปช่วยทีม B อีก ไรวะ

Testing Phase:

พี่จากทีม B: “น้องๆ พี่เขียนโค๊ดเสร็จละ รบกวนเทสดูด้วยนะว่าระบบน้องโอเคอยู่มั้ย”

เรา: แม่ม งานเพิ่มเฉยเลย Requirement อะไรก็ไม่รู้ ไม่ได้เกี่ยวกับทีมเราเลย ทำไมต้องทำด้วยเนี่ยะ

Deployment Phase:

พี่จากทีม B: “น้องขาาาา คืนนี้พี่จะ Deploy ระบบขึ้น Production แล้วนะคะ รบกวนน้อง Stand By รอดูผลด้วยค่ะ ประมาณตีสอง”

เรา: สลัดแล้วค่าาาาา ตีสอง เรื่องของกรูมั้ยเนี่ยะต้องแหกขี้ตาตื่นมา Stand By

Support Phase:

พี่จากทีม B: “น้องขาาาา ซวยแล้วค่ะ ที่พี่ Deploy ระบบไปเมื่อคืนมันทำให้ระบบน้องล่มอะค่ะ”

เรา: เออ เจริญนะ โดนทั้งขึ้นทั้งล่อง เบื่อ

ทั้งหมดนี้มันเป็นความผิดของพี่จากทีม B รึเปล่า? ผมคิดว่าไม่ใช่ซะทีเดียว มันผิดที่ความยุ่งเหยิงของระบบต่างหาก เมื่อ System Dependency เยอะผลลัพธ์ที่เห็นได้ชัดก็คือสิ่งที่ผมเล่าให้ฟังข้างบน

สำหรับ “เรา” มันเหมือนเนื้อไม่ได้กินหนังไม่ได้รองนั่งเอากระดูกมาแขวนคอเพราะงานที่เราต้องทำมันไม่ได้เกี่ยวข้องอะไรกับระบบของเราเลย ทุกอย่างที่ทำไปก็ไม่เกิดประโยชน์อะไรกับทีมเรา แถมถ้าทำผิดก็ซวยหนักอีก

แบบนี้ไม่เวิร์ค

The Way It Should Be

HubSpot บริษัทผู้ผลิต Inbound Marketing Platform ระดับโลกมีการแก้ปัญหา System Dependency ที่ง่ายและน่าสนใจ (จริงๆบางคนก็รู้แล้วหละ เล่าให้ฟังเป็นการย้ำเตือน) หลักการของ HubSpot คือ

“… a part of the app can only change when it itself is deployed; other projects getting changed or deployed won’t have any effect. With this we can ensure that a project can only break when a member of the team that maintains it is at their keyboard.”

“… ส่วนใดๆของแอฟจะเปลี่ยนแปลงได้ก็ต่อเมื่อตัวเองถูก Deploy เท่านั้น; การเปลี่ยนแปลงหรือ Deploy ของโปรเจกต์อื่นจะไม่เกิดผลกระทบต่อแอฟนั้นไม่ว่ากรณีใดๆ ด้วยวิธีนี้เราถึงสามารถมั่นใจได้ว่าถ้าแอฟเราจะพังก็เป็นเพราะสมาชิกในทีมเรากำลังแก้ไขหรือ Deploy มันด้วยตัวเอง”

เป็นแนวคิดที่ดีจัง (แนะนำให้อ่านเพิ่มเติมที่ How We Deploy 300 Times a Day) แล้วเค้าทำได้อย่างไร? … มันเป็นเรื่องง่ายๆที่หลายคนคงลืมไป

Versioning

เค้าทำได้ด้วยการกำหนดเลข Version นั่นเอง

มันเป็นเรื่องยากที่เราจะลด System Dependency ลงได้ บางครั้งอาจจะไม่ใช่เรื่องที่ควรทำด้วยซ้ำเพราะการตัด Dependency ออกจาก External System อาจจะหมายถึงการเขียนโค๊ดส่วนนั้นเองทั้งหมด เช่น แทนที่จะใช้ระบบ Login หรือ Authentication ที่เป็นของกลาง เราก็เลือกที่จะทำระบบสองอย่างนี้ในแอฟเราเองซึ่งมันจะกลายเป็นการทำงานซ้ำซ้อนและเป็นการเพิ่มปริมาณโค๊ดอย่างไม่จำเป็น

ถึงแม้เราจะลด System Dependency ลงไม่ได้ แต่เราสามารถลดปัญหาที่เกิดจาก System Dependency ได้ด้วยการที่เรากำหนดให้ชัดเจนเลยว่า “แอฟของเราสามารถทำงานได้ดีกับระบบ B, C, D ที่ Version อะไรบ้าง” — ตัวอย่างใน Dependency Declaration File ซึ่งมักจะถูกรวมไว้เป็นส่วนหนึ่งของ Build Process

เมื่อเป็นแบบนี้แล้วต่อให้เรา Build และ Deploy แอฟของเราวันนี้ พรุ่งนี้ เดือนหน้า หรือปีหน้า มันก็จะถูกชี้ไปที่ Version ที่ถูกต้องของระบบ B, C, D เสมอ และแอฟของเราก็จะทำงานได้ตามปกติอย่างที่มันควรจะเป็น

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

จะ Design, Develop, Test, Deploy หรือ Support ยังไงก็ลุยเลยนะครับ ระบบผมยังทำงานได้ตามปกติ และผมก็แฮปปี้กับมัน ณ จุดนี้ ☺

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

The Future Has Arrived — It’s Just Not Evenly Distributed Yet, William Gibson

อนาคตอยู่ตรงนี้แล้ว เรามีหน้าที่ต้องถ่ายทอดมันออกไปให้คนอื่นได้สัมผัสสิ่งดีๆร่วมกันครับ