มาทำ YAGNI กันเถอะ !!
เคยมั้ย เวลาเจอโค้ดของเพื่อน แต่ไม่รู้ว่าต้องใช้ทำไม ?
จำเป็นต้องทำ Feature นี้ให้ Perfect ขนาดนี้มั้ย ?
เราต้องทำให้โค้ดของเรา รองรับทุก ๆ Case ด้วยมั้ยนะ ?
วันนี้ผมมาแนะนำหนึ่งแนวทาง สำหรับคนที่กำลังเผชิญสิ่งที่เราไม่แน่ใจว่าเราต้องใช้มันหรือเปล่า นั่นคือ YAGNI
YAGNI
ไม่ใช่คำที่มีความหมาย แต่มันย่อมากจาก “You Aren’t Gonna Need It.” หรือ “You Ain’t Gonna Need It.” ซึ่งเป็นหนึ่งในแนวคิดจาก Extream Programming ในการตัดสินใจว่าสิ่งที่เรากำลังทำอยู่ หรือ Feature ที่เรากำลังจะทำนั้น จำเป็นต้องใช้เลยหรือไม่
หลายคนอาจจะทำไปเพราะเป็น Task ที่ได้รับมอบหมาย หรือโดยที่เจ้าตัวเองทำไปโดยไม่ได้ตั้งใจ หรืออาจจะทำไปเพราะคิดว่า
ทำไปก่อนเหอะ เดี๋ยวถ้าย้อนกลับมาทำมันจะเสียเวลาเอานะ
ก็ไม่ใช่เรื่องที่ผิดที่จะทำ แต่อย่าลืมว่าการทำงานของเราย่อมต้องใช้ Resource ซึ่ง Resource ที่สำคัญที่สุดนั่นคือ เวลา และเมื่อเวลาผ่านไปกลับมาคิดได้ว่า
“เราไม่เห็นต้องเสียเวลากับการทำแปลภาษา (i18n) มา 6 เดือนเลย ในเมื่อใน Phase แรกในเมื่อลูกค้าหลักเป็นคนในประเทศ”
บทเรียนที่ได้จากการทำไปนอกจากความรู้ก็คือ
รู้อะไร ไม่เท่า รู้งี้
Code != กำไร
การมีโค้ดที่เยอะ Feature ก็ต้องเยอะตาม ก็ต้องมีกำไรที่เพิ่มขึ้น แต่อย่าลืมว่าเจ้าหนี้ที่จะตามมาทวงต้นจากเรา นั้นมีชื่อว่า Technical Debt มีคำว่า “หนี้” ในชื่อ ซึ่งเจ้าหนี้คนนี้ไม่ได้ทวง “เงิน” แต่จะมาทวง “เวลา” ที่เราต้องมาดูแลโค้ดที่เราสร้างขึ้น ต้องมาตามดูแลและแก้บัคเวลาที่บาปมันก่อตัว
หนี้ทั้ง 4 ที่ทุกคนจะต้องแบกรับกับโค้ดที่ออกมา นั้นประกอบด้วย
- Cost of building — ค่าของการสร้าง
- Cost of delay —ค่าเสียโอกาส ในการสร้าง Feature อื่น
ด้วยความที่ Feature ของงานนั้นอาจจะมีมากมาย การที่เราเลือกที่จะทำ Feature A นั่นหมายความว่า คุณจะเสียโอกาสในทำ Feature B ในเวลานั้นไป และอีกทางเลือกคือการไม่ทำ ก็เป็นหนึ่งในทางเลือกในการรักษา Resource - Cost of carry — ค่าความบาปของโค้ด นั่นหมายความว่ายิ่งโค้ดเรามากขึ้น ผูกมัดกันมากขึ้น ความยุ่งยากในการจัดการ และพัฒนาก็ต้องสูงขึ้นตาม
- Cost of repair — ค่าในการซ่อมแซม มีโค้ด ก็ต้องมีบัค
อีก Cost หนึ่งที่อยากจะเสริม นั่นคือเวลาของ Tester ที่ต้องคอยมาตรวจสอบอีกรอบ หมายความว่าหากมี Feature ที่มากขึ้น Use Case ที่มากขึ้น ก็จะไปเพิ่มต้นทุนให้ Tester ด้วย
วิธีการทำ YAGNI
ซึ่งวิธีที่จะเล่าเป็นในส่วนของ Coding ที่ Developer ได้พัฒนา ต้องบอกว่าโดยส่วนตัวก็ไม่ได้มี Best Practice ในการทำก็คือจัด Session มาคุยกันสำหรับ Developer
โดยจะจัด Session ชื่อว่า “YAGNI” ที่จะจัดขึ้นก่อนเริ่ม Sprint ใหม่ หากไม่ได้ทำเป็น Sprint ก็อาจจะนัดกันทุก ๆ 2 อาทิตย์หรือตามที่แล้วแต่ทีมจะสะดวก
ภายใน Session จะให้ทุก ๆ คนเตรียม Topic เกี่ยวกับโค้ดว่า “ส่วนนี้ต้องใช้หรือเปล่านะใน Phase นี้” “ส่วนนี้เขียนแบบนี้ได้หรือเปล่านะ” ซึ่งมันอาจจะคล้ายกับการ Review Code แต่เป้าหมายของ Session นี้คือ
โค้ดตรงนี้คิดว่าไม่น่าจะได้ใช้ เอาออกเลยได้มั้ยนะ ?
แล้วปกติ Dev ไม่ได้คุยกันเรื่องโค้ดหรอ ?
จากประสบการณ์ที่เคยทำงานกับทีมที่อยู่ด้วยกันที่ Office นั่งข้างกันห่างกันไม่เกิน 1 ก้าว แทบจะไม่ได้พูดคุยกันเรื่องความทุกข์ยากของโค้ด ซึ่งหน้าที่ของทุกคนก็คือการทำงานของตัวเองให้เสร็จ
ในช่วงเวลาที่ Coding ทุกคนก็มักจะ Focus กันกับหน้าจอ Editor ของตน เมื่อเงยหน้ามา สิ่งแรกที่จะพูดคือ “วันนี้กินอะไรดี ?”
หากเป็นช่วงเย็นก็จะเป็น “เข้าเกมยัง ?”
สิ่งที่ผมเชื่อว่าวิธีการที่ดีที่สุดในการแก้ปัญหา ก็คือ “การหันหน้าคุยกัน” เพราะในการทำงานจริง มีปัญหาเรื่องอื่นนอกจาก YAGNI ให้เราได้เผชิญอีกมาก
สุดท้ายนี้ ผมขอฝากคำพูดหนึ่งที่จะสามารถให้เพื่อนฝ่าฟันปัญหาและอุปสรรคต่าง ๆ ได้นั่นคือ
ปัญหาส่วนใหญ่แก้ไขได้ ด้วยการคุยกัน
Refs:
