ปีใหม่นี้ มาหยุดการเขียนโค๊ดห่วยๆกันเถอะ — ภาคหนึ่ง

Inspiring and Practical Story of How To Stop Writing Crappy Code from Henrik Kniberg — Part 1

ได้อ่านบทความของเฮนริค คนิเบิร์ก ปรมาจารย์ด้าน Lean และ Agile Software Development ที่เขียนเกี่ยวกับการแก้ไขปัญหาเรื่อง Technical Debt แล้วรู้สึกประทับใจมาก ขอแบ่งปันความรู้ที่ได้มาเป็นชุดบทความทั้งหมดสามตอนครับ เริ่มตอนแรกวันปีใหม่นี้เลย

คุณเฮนริคเริ่มบทความด้วยการถามคนอ่านว่า “เฮ้ พวกคุณอยู่ใน Software Development Team ที่พยายามจะเป็น Agile ใช่อ๊ะป่าว?” ถ้าใช่ … ครั้งหน้าที่ทุกคนอยู่พร้อมหน้าพร้อมตากัน ลองถามคำถามนี้

รู้สึกอย่างไรต่อคุณภาพของโค๊ดที่คุณเขียน?

ให้ทุกคนลงคะแนนระหว่าง 1–5 ดู … 5 คือ “มันยอดมาก โคตรภูมิใจในผลงาน” 1 คือ “นรกชัดๆ” ถ้าเสียงส่วนใหญ่บอกว่า 4 กับ 5 ไม่มีใครให้ต่ำกว่า 3 เลย … คุณก็ไม่ต้องอ่านบทความนี้ต่อแล้วหละ ทุกอย่างไปได้สวย

ถ้าคุณเห็นความแตกต่างของคะแนนมันเยอะมาก แบบว่าบางคนให้ 5 บางคนให้ 1 คุณต้องทำความเข้าใจในการให้คะแนนครั้งนี้กันใหม่แล้วว่ามีอะไรผิดปกติมั้ย เช่น คุณให้คะแนนในโค๊ดชุดเดียวกันป่าว? หรือความหมายของคำว่าคุณภาพของแต่ละคนไม่เหมือนกันอย่างไร?

แต่ถ้าเราจะเห็นเสียงส่วนใหญ่เป็น 2 หรือต่ำกว่า จะมี 4 หรือ 5 บ้างเป็นส่วนน้อยจริงๆ … นั่นแปลว่าตอนนี้เรามีปัญหาเรื่อง Technical Debt แล้วหละ ในบทความชุดนี้คุณเฮนริคขอเรียกมันว่า Crappy Code (โค๊ดห่วยๆ)

ณ จุดนี้ ขอแสดงความยินดีด้วย พวกคุณเพิ่งเปิดเผยปัญหาที่ซีเรียสออกมาแล้ว คุณรู้แล้วด้วยซ้ำว่าซีเรียสแค่ไหน (ก็ผลคะแนนเฉลี่ยเมื่อกี๊) ใช้เวลาแค่หนึ่งนาทีเอง ใครๆก็ทำได้ไม่ต้องเป็น Agile Coach หรือ Scrum Master หรอก เมื่อได้ตัวเลขมาแล้วก็ไม่ต้องอาย เอาขึ้นกระดานให้เห็นชัดๆกันไปเลยว่าทีมคุณกำลังเจอปัญหาอะไรอยู่ การทำให้ปัญหามองเห็นได้เป็นก้าวสำคัญในการแก้มัน ไม่ต้องกังวล คุณไม่ได้เจอปัญหานี้คนเดียวแน่นอน รับประกันได้

ตอนนี้ถึงเวลาที่คุณต้องถามคำถามสำคัญแล้ว

เราต้องการให้มันเป็นแบบนี้หรือ?

ถ้าไม่ แล้วคุณอยากให้คุณภาพของโค๊ดเราเป็นแบบไหน? Developer ส่วนใหญ่ย่อมอยากให้มันเป็น 4 หรือ 5 แต่เพื่อความแน่ใจลองถามเสียงส่วนใหญ่ของทีมว่าเป้าหมายของเราคืออะไร อยู่ที่จุดไหนกันแน่

ถ้าเกิดเหตุการณ์ที่เสียงแตกกระจายเรื่องคุณภาพของโค๊ด คุณต้องถกกันเพิ่มเติมอีกนิดนึงถึงความหมายของคำว่าโค๊ดที่ดีคืออะไร อาจจะหยิบหลักการของ Ken Beck (เจ้าพ่อ Agile Software Development อีกคนหนึ่ง) ที่ชื่อ 4 Rules of Simple Code มาเป็นจุดเริ่มต้นก็ได้

อะไรคือสาเหตุของปัญหานี้?

ออกแนวสำนวนโวหารเล็กน้อยแต่

“Things are the way they are because they got that way!” -Jerry Weinberg

“ที่เรื่องมันเป็นอย่างที่เป็นอยู่เพราะมันถูกทำให้เป็นแบบนั้น” (แปลแล้วก็งงๆ ฮ่าๆ) แต่โดยสรุปที่คุณเฮนริคบอกไว้คือ ความห่วยถูกใส่ลงไปในโค๊ดก็เพราะ Developer ใส่มันลงไป โค๊ดห่วยๆถูกสร้างขึ้นด้วยน้ำมือของ Developer ไม่ว่าจะสถานการณ์ใดๆก็ตาม การกระทำของ Developer จะเป็นตัวตัดสินคุณภาพของโค๊ดเสมอ

ขั้นแรกในการแก้ปัญหา Technical Debt คือการยอมรับความจริงข้อนี้ก่อน

แต่เดี๋ยว … คุณอาจจะมีข้อแก้ตัวว่า “เห้ย ผมไม่ได้เป็นคนเขียนโค๊ดห่วยๆนี้ขึ้นมานะ คนเก่ามันทำไว้ มันเป็น Legacy Code มากล่าวหากันแบบนี้ก็ไม่แฟร์ซิ”

ก็ได้ๆ … คุณเฮนริคแนะนำให้เปลี่ยนคำถามเป็น “แล้วโค๊ดเก่าชุดนี้มันมีคุณภาพที่ดีขึ้นหรือแย่ลงล่ะ?” ให้คะแนน 1–5 เหมือนเดิม 5 คือ “ดีขึ้นอย่างรวดเร็ว” และ 1 คือ “บัดซบลงอย่างรวดเร็ว” … คะแนนเฉลี่ยที่ได้ออกมาก็ใช้เป็นตัววัดความรุนแรงของปัญหานี้ได้ไม่ต่างกัน

ทำไมเราถึงเขียนโค๊ดห่วยๆ?

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

มันอาจจะไม่ใช่เพราะคุณตั้งใจเขียนโค๊ดห่วยๆ คุณเฮนริคบอกว่าเค้าไม่เคยเจอ Developer คนไหนที่ชอบและสนุกกับการเขียนโค๊ดห่วยๆ

มันอาจจะไม่ใช่เพราะคุณไม่รู้วิธีการที่จะเขียนโค๊ดให้ดีมีคุณภาพ ทักษะอาจจะต่างกันไปแต่ขอแค่ให้มีคนไม่กี่คนในทีมของคุณที่รู้วิธีการเขียนโค๊ดดีๆที่สะอาดสะอ้านและความเต็มใจของสมาชิกที่เหลือที่จะเรียนรู้ รวมกับเทคนิคและนิสัยในการทำ Code Review หรือ Pair Programming ทีมส่วนใหญ่จะมีทักษะและความสามารถเพียงพอที่จะเขียนโค๊ดที่ดีมีคุณภาพได้ … ถ้าเค้าได้เวลาเหมาะสมตามที่เค้าต้องการ

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

อย่างไรก็ตาม คุณเฮนริคเน้นว่าเหตุผลหลักที่ทำให้เราเขียนโค๊ดห่วยๆคือ “ความกดดัน”

คุณเฮนริคเล่าว่า เค้าเคยได้ยินคำบ่นประมาณนี้อยู่บ่อยๆ “เราไม่มีเวลาที่จะเขียนโค๊ดดีๆสะอาดๆหรอก” (ประโยคนี้อย่างแย่มันคือการโกหกคำโต และอย่างดีมันคือข้อแก้ตัวที่ฟังไม่ขึ้น) ความจริงก็คือคุณมีเวลา 24 ชั่วโมงเหมือนคนอื่น (เหมือนกับ Developer ที่ Google, Facebook, Amazon, Spotify และอื่นๆ) มันขึ้นอยู่กับคุณว่าจะเลือกทำอะไรกับมัน ยอมรับซะว่าคุณมีเวลาเหลือเฟือที่จะเขียนโค๊ดดีมีคุณภาพแต่คุณเลือกจะไม่ทำ

แต่เอาเถอะ ไหนๆก็ไหนๆแล้ว เราลองมาวิเคราะห์เรื่องความกดดันกันต่ออีกนิดว่า ความกดดันพวกนี้มันมาจากไหนกัน … ในบทความวันพรุ่งนี้ครับ

สวัสดีปีใหม่ครับทุกคน … ปีนี้จะเป็นปีที่ดีของคนที่ตั้งใจ Stop Writing Crappy Code โย่ว

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

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

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