แค่เขียนโค้ดอย่าให้มีบั๊กสิเพื่อน

Software Engineer, Project Manager และ QA ทุกคนล้วนเคยเจอสถานการณ์นี้: เดดไลน์จ่อเข้ามาทุกทีแต่ซอฟต์แวร์ยังมีปัญหาอยู่ หน้าเว็บไม่โหลด, API พ่น Error ตลอดเวลา หรือผู้ใช้ดันเห็นข้อความที่ไม่ควรจะเห็น ปัญหาเหล่านี้เราเรียกว่า “บั๊ก” (bugs) ซึ่งมีที่มาจากแมลงตัวเล็กๆ ที่คลานเข้าไปในคอมพิวเตอร์ แล้วไปสัมผัสกับเมนบอร์ดจนตัวมันเองไหม้ไปพร้อมกับเครื่องคอมพิวเตอร์นั่นเอง แน่นอนว่าไม่มีใครตั้งใจเขียนบั๊กขึ้นมาหรอก

แต่ถึงอย่างนั้น... บั๊กก็เกิดขึ้นอยู่ดี

ทุกวัน ทุกที่

แม้แต่ในทีมที่เก่งที่สุด

คำถามคือ:

ทำไมมันถึงเกิดขึ้น? และเราจะทำอย่างไรเพื่อลดพวกมันลงอย่างจริงจัง?

เรามาลองแยกแยะกันดู

ทำไมบั๊กถึงเกิดขึ้น?

1. พัฒนาฟีเจอร์ไม่สมบูรณ์

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

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

บางครั้งสาเหตุหลักก็ง่ายๆ เลยคือ: นิสัยที่ไม่ดี

• เร่งงานให้ทันเดดไลน์โดยไม่คิดให้รอบคอบ

• ละเลยโครงสร้างและแนวทางปฏิบัติที่ดี (Best Practices)

• ก๊อปปี้โค้ดมาวางโดยไม่ทำความเข้าใจ

• การแก้ปัญหาเฉพาะหน้าแบบชั่วคราวที่กลายเป็นโค้ดถาวรแบบลวกๆ

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

2. ขาดการทำ Integration Testing (หรือทำได้ไม่ดีพอ)

แต่ละโมดูลอาจจะผ่านการทดสอบแยกส่วน (Unit Test) มาได้

แต่การเชื่อมต่อโมดูลเข้าด้วยกันโดยไม่มีการทำ Integration Testing คือจุดเริ่มต้นของความวุ่นวาย

การทดสอบอิฐแต่ละก้อนไม่ได้การันตีว่าบ้านจะไม่พังลงมา

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

3. Third-Party Packages ที่สร้างปัญหา

Library และ Framework ภายนอกช่วยให้เราพัฒนาได้เร็วขึ้น จนกระทั่งมันย้อนกลับมาทำร้ายเรา

• การอัปเดตที่ทำให้โค้ดเดิมพัง (Breaking Changes)

• Dependency ที่เลิกใช้งานแล้ว (Deprecated)

• ช่องโหว่ด้านความปลอดภัยที่แฝงเข้ามา

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

นักพัฒนาไม่ใช่คนเดียวที่ต้องรับผิดชอบ

การหลีกเลี่ยงบั๊กคือความร่วมมือของทั้งทีม

และผู้จัดการมีบทบาทสำคัญมากกว่าที่หลายคนคิด

นี่คือสิ่งที่คุณในฐานะ (Project) Manager สามารถทำได้เพื่อช่วยให้ทีมเขียนโค้ดได้ดีขึ้นและสะอาดขึ้น:

1. ให้คำแนะนำที่ชัดเจน

Ticket ที่ไม่ชัดเจนคือสูตรสำเร็จของการเกิดบั๊ก

เป้าหมายที่คลุมเครือนำไปสู่โซลูชันที่คลุมเครือ

ต้องเจาะจง

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

2. ตรวจสอบ Ticket

ก่อนจะย้ายงานข้ามสถานะ (Phase) ให้ตรวจสอบก่อนว่างานนั้นเสร็จสมบูรณ์จริงๆ

มันน่าหงุดหงิดมากสำหรับ QA Engineer ที่ได้รับ Ticket มาทดสอบ แต่กลับพบว่าฟีเจอร์นั้นยังไม่มีให้ทดสอบเลยด้วยซ้ำ หน้าที่ของพวกเขาคือการคิดสถานการณ์การทดสอบที่หลากหลาย มองโซลูชันในมุมมองที่ต่างออกไป และทดสอบผลลัพธ์จากการกระทำต่างๆ ไม่ใช่หน้าที่ของพวกเขาที่จะต้องคอยส่ง Ticket กลับไปกลับมาให้นักพัฒนาแล้วบอกว่า “ไปทำมาใหม่ให้ดีกว่านี้”

อย่าแค่ถามนักพัฒนาว่า “อันนี้ใช้ได้หรือยัง?” ก่อนย้าย Ticket แต่ให้บอกให้นักพัฒนา “ทำให้ดูหน่อยว่ามันใช้ได้” ในทำนองเดียวกัน เมื่อ QA อนุมัติ Ticket ว่าพร้อมขึ้น Production แล้ว ให้ลองขอให้พวกเขารัน Test Flow ให้ดูอีกสักรอบต่อหน้าคุณ

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

3. สร้างวัฒนธรรมการทำงานเป็นทีม

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

การมีทีมที่คอยช่วยเหลือกันเมื่อเจอเรื่องยาก ไม่เพียงแต่จะช่วยประหยัดเวลา แต่ยังช่วยยกระดับคุณภาพของงานด้วย โค้ดถูกเขียนขึ้นเพื่อให้คนอื่นดูแลต่อ ดังนั้นการตรวจสอบว่าโค้ดนั้นอ่านง่ายและดูแลต่อได้ (Maintainable) ก่อนจะปล่อยขึ้น Production จึงเป็นเรื่องสำคัญมาก

การทำ Peer Review ช่วยบังคับให้ทุกคนทำตาม Best Practices และมาตรฐานของทีม นอกจากนี้ยังช่วยกระตุ้นการเรียนรู้ภายในทีมด้วย จงสร้างวัฒนธรรมที่นักพัฒนารู้สึกสบายใจที่จะพูดคุยเกี่ยวกับโค้ดและโซลูชันของพวกเขา

Teamwork makes the dream work.

4. ปล่อยให้นักพัฒนาได้โฟกัส (ชั่วคราว)

การสลับบริบทไปมา (Context Switching) คือศัตรูตัวฉกาจของการทำงานที่ต้องใช้สมาธิสูง (Deep Work)

เมื่อนักพัฒนาได้โฟกัสกับฟีเจอร์เดิมตั้งแต่ต้นจนจบ:

• พวกเขาจะเข้าใจเคสที่อาจเกิดขึ้นได้ยาก (Edge Cases) ได้ดีขึ้น

• พวกเขาสังเกตเห็นความไม่สอดคล้องกันได้เร็วขึ้น

• พวกเขาจะเขียนโค้ดที่มีความเสถียรมากขึ้น

การให้นักพัฒนาสลับไปมาระหว่างงานหรือโปรเจกต์ต่างๆ จะทำลายประสิทธิภาพการทำงานและเพิ่มโอกาสที่จะเกิดข้อผิดพลาด

ปล่อยให้พวกเขาได้โฟกัสเถอะ

5. สร้างแรงจูงใจให้ทีม

บั๊กจะเพิ่มขึ้นเมื่อคนรู้สึกเครียด ถูกจู้จี้จุกจิก (Micromanaged) หรือถูกขัดจังหวะอยู่ตลอดเวลา

ให้พื้นที่นักพัฒนาได้ใช้สมาธิอย่างเต็มที่

ไว้วางใจให้พวกเขาจัดการลำดับการทำงานของตัวเอง

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

นักพัฒนาที่มีความสุขและมีสมาธิจะสร้างผลิตภัณฑ์ที่ดีกว่า มันง่ายๆ แค่นั้นเอง

6. ปรัชญาการทำ Postmortem แบบไม่โทษกัน

ความผิดพลาด เกิดขึ้นได้เสมอ ตราบใดที่คุณยังลงมือทำอะไรสักอย่าง

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

เมื่อบั๊กปรากฏขึ้น ให้โฟกัสที่ตัวปัญหาแทนที่จะเป็นตัวบุคคล คุณไม่สามารถ “ซ่อม” คนได้ แต่คุณสามารถซ่อมแซมระบบและกระบวนการเพื่อสนับสนุนให้คนตัดสินใจได้ถูกต้องมากขึ้นเมื่อต้องออกแบบและดูแลระบบที่ซับซ้อน

ลองถามคำถามเหล่านี้:

• มีอะไรผิดพลาดในกระบวนการบ้าง?

• เราจะแก้ไขมันได้อย่างไร?

• เราเรียนรู้อะไรจากเรื่องนี้ได้บ้าง?

เมื่อปัญหาได้รับการแก้ไขแล้ว ให้บันทึกทุกอย่างลงใน Postmortem แต่อย่าชี้นิ้วด่ากัน! ให้ปฏิบัติกับเหตุการณ์นั้นเหมือนกับว่าใครในทีมก็สามารถทำพลาดแบบนี้ได้ ทำให้ Postmortem เป็นไปในเชิงสร้างสรรค์โดยเน้นที่การกระทำ เมื่อเรียนรู้แล้ว ให้แชร์สิ่งที่ได้เรียนรู้กับทีม Engineering หรือผ่าน Mailing List ภายในองค์กร และควรมีการรีวิว Postmortem เหมือนที่คุณรีวิวโค้ดนั่นแหละ

บั๊กจะเกิดขึ้นแน่นอน

แต่คุณเลือกได้ว่าจะรับมือกับมันอย่างไร

คุณไม่สามารถกำจัดบั๊กได้ทั้งหมด

แต่คุณสามารถสร้างกระบวนการที่ตรวจจับพวกมันได้ตั้งแต่เนิ่นๆ และสร้างวัฒนธรรมที่ช่วยลดความถี่ในการเกิดบั๊กได้

ที่ We Do Dev Work เราเชื่อว่าการเขียนโค้ดที่สะอาดและเชื่อถือได้ไม่ใช่แค่เรื่องของทักษะทางเทคนิคเท่านั้น

แต่มันคือเรื่องของการสื่อสาร ความชัดเจน สมาธิ และความรับผิดชอบร่วมกัน

เพราะการพัฒนาที่ดีไม่ใช่เวทมนตร์

แต่มันคือนิสัยที่สร้างขึ้นทีละเล็กทีละน้อย