การพัฒนา
- เริ่มจากเล็กแล้วค่อยขยาย: เมื่อสร้างระบบใหม่หรือเพิ่มฟีเจอร์ให้ระบบเดิม ให้เริ่มจากเวอร์ชันที่เรียบง่ายมากและแทบไม่มีฟังก์ชันที่จำเป็น จากนั้นค่อย ๆ ขยายเพิ่มทีละน้อย
- เปลี่ยนทีละอย่าง: ระหว่างการพัฒนา หากการทดสอบล้มเหลวหรือฟังก์ชันทำงานไม่ได้ การเปลี่ยนแปลงทีละอย่างจะช่วยให้หาต้นตอปัญหาได้ง่ายกว่ามาก
- เพิ่ม logging และการจัดการข้อผิดพลาดตั้งแต่เนิ่น ๆ: เมื่อพัฒนาระบบใหม่ การเพิ่ม logging และการจัดการข้อผิดพลาดตั้งแต่ช่วงแรกมีประโยชน์มาก
- โค้ดบรรทัดใหม่ทุกบรรทัดควรถูกเรียกใช้งานอย่างน้อยหนึ่งครั้ง: ควรทดสอบก่อนที่ฟีเจอร์จะเสร็จสมบูรณ์
- ทดสอบเป็นส่วน ๆ ก่อนทดสอบทั้งระบบ: ส่วนที่ผ่านการทดสอบมาอย่างดีจะช่วยประหยัดเวลา
- ทุกอย่างใช้เวลานานกว่าที่คิด: โดยเฉพาะในการเขียนโปรแกรม มักใช้เวลานานกว่าที่คาดไว้
- ทำความเข้าใจโค้ดเดิมก่อน: ก่อนเพิ่มฟีเจอร์ใหม่ ต้องเข้าใจวิธีแก้ปัญหาปัจจุบันก่อน การอ่านโค้ดเป็นทักษะที่จำเป็นพอ ๆ กับการเขียนโค้ด
- อ่านและรัน: มีสองวิธีที่เสริมกันในการทำความเข้าใจโค้ด คือการอ่านโค้ดและการรันโค้ด
การแก้ปัญหา
- บั๊กมีอยู่เสมอ: แนวทางแบบ "ทำให้ถูกต้องตั้งแต่แรก" ไม่ใช่วิธีที่ดี
- จัดการรายงานปัญหา: นักพัฒนาควรใช้เวลาในการจัดการรายงานปัญหาจากลูกค้าและแก้บั๊ก สิ่งนี้ช่วยให้เข้าใจได้ดีขึ้นมากว่าลูกค้าพยายามทำอะไร ระบบถูกใช้งานอย่างไร การแก้ปัญหาง่ายหรือยากแค่ไหน และระบบถูกออกแบบมาได้ดีเพียงใด
- ทำให้ปัญหาเกิดซ้ำได้: ขั้นตอนแรกของการแก้บั๊กคือทำให้ปัญหาเกิดซ้ำได้ จากนั้นเมื่อเพิ่มการแก้ไขแล้ว ค่อยตรวจสอบว่าปัญหาหายไปหรือไม่
- หลังแก้ข้อผิดพลาดที่รู้แล้ว ให้ดูว่าเหลืออะไรอยู่: เมื่อมีหลายปัญหา ให้แก้ปัญหาที่ทราบทั้งหมดก่อน แล้วค่อยดูอาการที่ยังเหลืออยู่
- อย่าคิดว่าเป็นเรื่องบังเอิญ: ระหว่างการทดสอบและแก้ปัญหา อย่าเชื่อว่าเป็นเรื่องบังเอิญ แต่ควรสืบสวนต่อไป เช่น "เปลี่ยนค่า timer แล้วระบบรีสตาร์ตบ่อยขึ้น นี่ไม่ใช่เรื่องบังเอิญ เพิ่มฟีเจอร์ใหม่แล้วฟีเจอร์ที่ไม่เกี่ยวกันกลับช้าลง? นี่ก็ไม่ใช่เรื่องบังเอิญ ควรตรวจสอบต่อ"
- เชื่อมโยงกับ timestamp: ใช้ timestamp ของเหตุการณ์ในการแก้ปัญหา
การทำงานร่วมกัน
- คุยกันต่อหน้ามีแบนด์วิดท์สูงที่สุด: เมื่อต้องคุยกันเรื่องวิธีแก้ปัญหา การพูดคุยต่อหน้าดีกว่าวิธีอื่นทั้งหมด (วิดีโอ โทรศัพท์ แชต อีเมล)
- Rubber duck debugging: เมื่อคุณตันกับปัญหา การอธิบายปัญหาให้เพื่อนร่วมงานฟังมักทำให้คุณฉุกคิดถึงวิธีแก้ แม้อีกฝ่ายจะไม่พูดอะไรเลย ระหว่างที่คุยกันก็มักจะตระหนักได้ว่าปัญหาคืออะไร ฟังดูเหมือนเวทมนตร์ แต่ใช้ได้ผลบ่อยอย่างน่าประหลาด
- ถาม: เวลาทำความเข้าใจโค้ด การอ่านและรันมักเป็นวิธีที่ดี แต่ถ้าสามารถถามคนที่รู้เรื่องนี้ดีอยู่แล้วได้ (น่าจะเป็นผู้เขียนเดิม) ก็ควรถามควบคู่กันไปด้วย
- แบ่งปันเครดิต: ให้เครดิตกับคนที่สมควรได้รับ แทนที่จะพูดว่า "เราลอง..." ให้พูดว่า "Marcus เป็นคนเสนอไอเดียให้ลอง" (ถ้าเป็นเช่นนั้นจริง) ควรเอ่ยถึงคนที่ช่วยเหลือหรือมีส่วนร่วมอย่างตั้งใจ
อื่น ๆ
- ลองทำดู: ถ้าไม่แน่ใจว่าฟีเจอร์ของภาษาทำงานอย่างไร ให้เขียนโปรแกรมเล็ก ๆ ขึ้นมาทดสอบ
- นอนพัก: เมื่อเจอปัญหาที่ยาก ควรนอนคิดข้ามคืนก่อนตัดสินใจ
- การเปลี่ยนแปลง: อย่ากลัวที่จะเปลี่ยนบทบาทหรืองานเป็นครั้งคราว การได้ทำงานกับผู้คนอื่น ๆ ผลิตภัณฑ์อื่น ๆ หรือบริษัทอื่น ๆ เป็นสิ่งที่กระตุ้นและสร้างแรงบันดาลใจ
- เรียนรู้อย่างต่อเนื่อง: หนึ่งในข้อดีที่ยิ่งใหญ่ที่สุดของการพัฒนาซอฟต์แวร์คือยังมีพื้นที่ให้เรียนรู้และค้นพบได้อีกเสมอ ลองใช้ภาษาโปรแกรมและเครื่องมือต่าง ๆ อ่านหนังสือเกี่ยวกับการพัฒนาซอฟต์แวร์ และลงเรียนคอร์ส MOOC การพัฒนาทีละเล็กทีละน้อยจะสะสมจนสร้างความเปลี่ยนแปลงที่จับต้องได้ต่อความรู้และความสามารถของคุณ
7 ความคิดเห็น
การพบปะกันต่อหน้ามีแบนด์วิดท์สูงที่สุด - เป็นการสื่อความที่ยอดเยี่ยม
+1.
การดีบักแบบยางเป็ด พออธิบายให้คนที่ไม่รู้เรื่องการเขียนโปรแกรมจริง ๆ ฟัง ก็จะนึกออกเองว่าปัญหาอยู่ตรงไหน
+1.
เป็นหลักการอันล้ำค่ายิ่งครับ
+1
ว้าว ทุกอย่างเป็นคำพูดที่ดีเลยนะ น่าเสียดายที่การพบกันต่อหน้ามีแบนด์วิดท์สูงที่สุด หวังว่าเทคโนโลยีจะพัฒนาไปได้มากกว่านี้นะ