ประสบการณ์ของอีกนักพัฒนา Microsoft คนหนึ่งที่ทำงานกับ BitLocker สำหรับ Windows 8 ได้จุดประกายการอภิปรายเกี่ยวกับข้อจำกัดของเครื่องมือพัฒนาภายในของ Microsoft โดยเรื่องราวนี้เผยให้เห็นว่าแม้แต่งานง่าย ๆ อย่างการอัปเดตข้อความแสดงข้อผิดพลาดก็สามารถกลายเป็นความท้าทายที่ซับซ้อนได้เนื่องจากข้อจำกัดของเครื่องมือ
ปัญหาของข้อความแสดงข้อผิดพลาดแบบคงที่
นักพัฒนาคนนี้ประสบปัญหาด้านการใช้งานที่พบบ่อยขณะทำงานกับระบบการกำหนดค่าของ BitLocker เมื่อผู้ดูแลระบบตั้งค่านโยบายการเข้ารหัสที่เกินขีดจำกัดของระบบ ผู้ใช้จะเห็นข้อความแสดงข้อผิดพลาดที่คลุมเครืออย่าง The BitLocker minimum passphrase length is too high โดยไม่ทราบว่าขีดจำกัดจริงคือเท่าไหร่ เป้าหมายจึงง่าย ๆ คือ เปลี่ยนข้อความเหล่านี้ให้เฉพาะเจาะจงมากขึ้น เช่น The BitLocker minimum passphrase length cannot exceed 20
อย่างไรก็ตาม ข้อกำหนดการแปลภาษาของ Microsoft ได้สร้างอุปสรรคทางเทคนิค ข้อความทั้งหมดที่ผู้ใช้เห็นจะต้องอยู่ในไฟล์ .mc แยกต่างหากเพื่อวัตถุประสงค์ในการแปล ในขณะที่ขีดจำกัดจริงถูกกำหนดเป็นค่าคงที่ในโค้ด C++ การแยกนี้หมายความว่าไม่มีวิธีตรงไปตรงมาในการอ้างอิงค่าคงที่ C++ ภายในข้อความแสดงข้อผิดพลาด
สถาปัตยกรรมระบบข้อความแสดงข้อผิดพลาดของ Microsoft :
- ข้อความที่แสดงให้ผู้ใช้เห็นจะถูกเก็บไว้ในไฟล์
.mcสำหรับการแปลภาษา - ค่าคงที่ C++ ถูกกำหนดแยกต่างหากในไฟล์ header
- API
ShowError()รับเฉพาะ resource ID เท่านั้น ไม่รับ format string - ไม่มีกลไกในตัวที่จะอ้างอิงค่าคงที่ C++ ในไฟล์ข้อความ
โซลูชัน Preprocessor ของ Raymond Chen
เมื่อนักพัฒนาขอความช่วยเหลือในรายชื่อส่งจดหมายภายใน Raymond Chen นักพัฒนา Windows ที่มีชื่อเสียงผู้อยู่เบื้องหลังบล็อก The Old New Thing ได้แนะนำให้ใช้ C preprocessor กับไฟล์ .mc วิธีนี้จะช่วยให้ไฟล์ข้อความแสดงข้อผิดพลาดสามารถอ้างอิงค่าคงที่เดียวกันที่ใช้ในโค้ด C++ ได้ ทำให้ทุกอย่างซิงค์กัน
แม้ว่าจะถูกต้องทางเทคนิค แต่โซลูชันนี้ต้องการการแก้ไขระบบ build ที่ซับซ้อนของ Microsoft นักพัฒนาในที่สุดเลือกที่จะไม่ใช้งานมัน เนื่องจากกลัวความเสี่ยงที่จะทำให้ nightly build ที่เพื่อนร่วมงานหลายร้อยคนพึ่งพาเสียหาย
วิธีแก้ปัญหาด้วย Preprocessor ของ Raymond Chen:
- รัน C preprocessor บนไฟล์
.mcก่อนการคอมไพล์ - อนุญาตให้ไฟล์ข้อความอ้างอิงค่าคงที่ของ C++ ได้โดยตรง
- ต้องปรับเปลี่ยนการกำหนดค่าของระบบ build
- มีความเสี่ยงที่จะทำให้ nightly builds ของทีมพัฒนาทั้งหมดเสียหาย
ปฏิกิริยาจากชุมชนเน้นประเด็นที่กว้างขึ้น
เรื่องราวนี้ได้รับการตอบสนองจากนักพัฒนาที่มองว่าเป็นตัวอย่างของปัญหาใหญ่กว่าในแนวทางปฏิบัติการพัฒนาของ Microsoft สมาชิกชุมชนบางคนสังเกตว่าระบบนิเวศอื่น ๆ อย่าง gettext ได้รองรับการจัดรูปแบบข้อความแบบไดนามิกมานานแล้ว โดยตั้งคำถามว่าทำไม Microsoft ถึงขาดความสามารถที่คล้ายกันสำหรับผลิตภัณฑ์หลักของตน
วิธี Microsoft คือทำสิ่งต่าง ๆ ย้อนหลัง ทำให้สิ่งที่เป็นไปได้กลายเป็นไปไม่ได้ และห่อ API ที่เรียบง่ายและเข้าใจได้ดีไว้หลัง 16 ชั้นของการแยกแยะด้วยชื่อที่แย่มาก
คนอื่น ๆ ชี้ให้เห็นว่า API ShowError() เองก็มีข้อจำกัด รับเพียง resource ID แทนที่จะเป็น format string ที่สามารถรวมค่าไดนามิกได้ ตัวเลือกทางสถาปัตยกรรมนี้บังคับให้นักพัฒนาใช้วิธีแก้ปัญหาชั่วคราวที่ไม่จำเป็น
มุมมองสมัยใหม่เกี่ยวกับเครื่องมือเก่า
สิบหกปีต่อมา นักพัฒนาสะท้อนว่าโซลูชัน preprocessor ของ Raymond Chen ยังคงรู้สึกไม่คาดคิดและไม่ชัดเจน สิ่งนี้บ่งชี้ว่าปัญหาไม่ใช่การขาดความรู้ของนักพัฒนา แต่เป็นช่องว่างในระบบนิเวศเครื่องมือภายในของ Microsoft
การอภิปรายเผยให้เห็นว่าแม้แต่ที่ Microsoft ในการทำงานกับ Windows เอง นักพัฒนาบางครั้งขาดวิธีมาตรฐานในการทำงานพื้นฐาน ความกลัวที่จะทำลายระบบ build ที่ซับซ้อนสามารถทำให้ความก้าวหน้าในการปรับปรุงที่ดูเหมือนง่าย ๆ หยุดชะงัก
เรื่องราวนี้เป็นเครื่องเตือนใจว่าแม้แต่บริษัทเทคโนโลยีขนาดใหญ่ก็สามารถมีเครื่องมือภายในที่สร้างแรงเสียดทานที่ไม่จำเป็นสำหรับนักพัฒนาของตนเอง ซึ่งอาจส่งผลต่อคุณภาพของผลิตภัณฑ์ที่ผู้ใช้หลายล้านคนพึ่งพา
อ้างอิง: I Once Appeared in The Old New Thing