การสูญเสียข้อมูลทั้งหมดของสตาร์ทอัพจากการศึกษาทางจิตวิทยาได้จุดประกายการถกเถียงอย่างเข้มข้นเกี่ยวกับวิธีที่การออกแบบภาษาโปรแกรมมิ่งมีอิทธิพลต่อพฤติกรรมของนักพัฒนา เหตุการณ์นี้เกิดขึ้นเมื่อรูปแบบ or die() ที่ได้รับความนิยมใน PHP ทำให้สคริปต์หยุดทำงานก่อนที่จะบันทึกข้อมูลการวิจัย บังคับให้นักวิจัยต้องเริ่มการศึกษาทั้งหมดใหม่
แนวคิดเรื่อง programming affordance ชี้ให้เห็นว่าภาษาโปรแกรมมิ่งนำทางนักพัฒนาไปสู่รูปแบบการเขียนโค้ดบางอย่างอย่างเป็นธรรมชาติ เหมือนกับที่มือจับประตูบอกใบ้ให้ดึง ในขณะที่แผ่นผลักบอกใบ้ให้ผลัก เมื่อรูปแบบเหล่านี้ส่งเสริมการปฏิบัติที่ไม่ดี แม้แต่นักพัฒนาที่มีเจตนาดีก็ทำผิดพลาดอย่างมีราคา
ปรัชญาการจัดการข้อผิดพลาดแบ่งแยกชุมชนนักพัฒนา
การอภิปรายได้เปิดเผยความแตกแยกอย่างชัดเจนในวิธีที่ภาษาโปรแกรมมิ่งต่างๆ เข้าถึงการจัดการข้อผิดพลาด ผู้ที่ชื่นชอบ Go ปกป้องการตรวจสอบข้อผิดพลาดที่ละเอียดยืดยาวของพวกเขา โดยโต้แย้งว่ามันบังคับให้มีการพิจารณากรณีความล้มเหลวอย่างชัดเจน ในขณะเดียวกัน นักวิจารณ์ชี้ไปที่โค้ด boilerplate ที่ซ้ำซากซึ่งสิ่งนี้สร้างขึ้น
Rust เสนอทางกลางด้วยระบบ Result type ซึ่งป้องกันนักพัฒนาจากการเพิกเฉยต่อข้อผิดพลาดโดยไม่เพิ่มความยืดยาวมากเกินไป อย่างไรก็ตาม นักพัฒนายังสามารถหลีกเลี่ยงมาตรการความปลอดภัยได้โดยใช้ฟังก์ชัน unwrap() ซึ่งเป็นการสร้างพฤติกรรม or die() ของ PHP ขึ้นมาใหม่
checked exceptions ของ Java แสดงถึงแนวทางอีกแบบหนึ่ง โดยบังคับให้มีการตัดสินใจจัดการข้อผิดพลาดในเวลาคอมไพล์ แต่นักพัฒนามักจะหาทางเลี่ยงสิ่งนี้โดยการจับ exceptions และโยนใหม่เป็น runtime exceptions ทำลายกลไกความปลอดภัย
แนวทางการจัดการข้อผิดพลาดตามภาษาโปรแกรมมิ่ง:
| ภาษา | วิธีการ | ข้อดี | ข้อเสีย |
|---|---|---|---|
| PHP | รูปแบบ or die() |
ไวยากรณ์ง่าย | ส่งเสริมการออกจากโปรแกรมก่อนเวลา |
| Go | การส่งคืนข้อผิดพลาดแบบชัดเจน | บังคับให้พิจารณา | โค้ดซ้ำซากที่ยาวเยิ่น |
| Rust | ระบบประเภท Result | ความปลอดภัยในเวลาคอมไพล์ | สามารถข้ามได้ด้วย unwrap() |
| Java | Checked exceptions | การบังคับใช้ในเวลาคอมไพล์ | มักถูกหลีกเลี่ยง |
| Python | Unchecked exceptions | การจัดการที่ยืดหยุ่น | ง่ายต่อการเพิกเฉยต่อข้อผิดพลาด |
| JavaScript | ใช้ Exception เป็นหลัก | รูปแบบที่คุ้นเคย | อาจเกิดความล้มเหลวโดยไม่รู้ตัว |
หลักการ Pit of Success
ประเด็นหลักมุ่งเน้นไปที่สิ่งที่นักพัฒนาเรียกว่า pit of success - การทำให้พฤติกรรมที่ถูกต้องเป็นเส้นทางที่ง่ายที่สุดในการก้าวไปข้างหน้า ภาษาที่ทำให้การดำเนินการที่อันตรายรู้สึกเป็นธรรมชาติ เช่น รูปแบบ or die() ของ PHP สร้างกับดักสำหรับนักพัฒนาที่อยู่ภายใต้ความกดดันหรือทำงานกับกำหนดเวลาที่จำกัด
หากคุณไม่ทำให้การทำสิ่งที่ถูกต้องเป็นเรื่องง่ายและการทำสิ่งที่ผิดเป็นเรื่องอึดอัด คนที่มีเจตนาดีจะทำสิ่งที่ผิด
unchecked exceptions ของ Python แสดงให้เห็นรูปแบบที่มีปัญหาอีกแบบหนึ่ง ซึ่งนักพัฒนามีนิสัยเพิ่มการจัดการข้อผิดพลาดแบบขี้เกียจที่ปกปิดปัญหาจริง บริบทสิ่งแวดล้อมก็สำคัญเช่นกัน โค้ดที่เขียนเพื่อผลลัพธ์ที่รวดเร็วมักได้รับการตรวจสอบน้อยกว่าแอปพลิเคชันที่หันหน้าไปหาลูกค้า
เกินกว่าโซลูชันทางเทคนิค
การถกเถียงขยายเกินกว่าคุณสมบัติของภาษาไปสู่วัฒนธรรมองค์กรและการปฏิบัติการตรวจสอบโค้ด นักพัฒนาบางคนรายงานความผิดหวังกับทีมที่ปกป้องการปฏิบัติที่ไม่ดีโดยพูดว่านี่คือวิธีที่เราทำมาตลอด ซึ่งชี้ให้เห็นว่าโซลูชันทางเทคนิคเพียงอย่างเดียวไม่สามารถแก้ไขรูปแบบพฤติกรรมของมนุษย์ได้
การอภิปรายเน้นย้ำถึงความท้าทายพื้นฐานในการพัฒนาซอฟต์แวร์: การสร้างสมดุลระหว่างผลิตภาพของนักพัฒนากับความน่าเชื่อถือของระบบ แม้ว่าจะไม่มีภาษาใดที่แก้ไขการจัดการข้อผิดพลาดได้อย่างสมบูรณ์แบบ ชุมชนยอมรับมากขึ้นว่าการออกแบบภาษามีรูปร่างพฤติกรรมของนักพัฒนาอย่างลึกซึ้ง มักจะในทางที่ละเอียดอ่อนและไม่คาดคิด
ประสบการณ์ของสตาร์ทอัพทำหน้าที่เป็นเรื่องเล่าเตือนใจเกี่ยวกับการทดสอบในสิ่งแวดล้อมการผลิตและต้นทุนที่ซ่อนอยู่ของรูปแบบการเขียนโปรแกรมที่สะดวกแต่อันตราย โซลูชันของพวกเขา - การเปลี่ยนไปใช้ภาษาที่มี affordances การจัดการข้อผิดพลาดที่ดีกว่า - สะท้อนถึงความตระหนักที่เพิ่มขึ้นว่าการเลือกเครื่องมือมีผลกระทบอย่างมีนัยสำคัญต่อคุณภาพซอฟต์แวร์
อ้างอิง: Programming affordance: when a language's patterns make it natural to make mistakes