สิ่งที่เผลอ ๆ กลายมาเป็นตัวรับน้ำหนัก
(jefftk.com)- โครงสร้างหรือโค้ดที่เดิมดูเป็นเพียงสิ่งเล็กน้อยหรือชั่วคราว เมื่อเวลาผ่านไปอาจกลายเป็นสิ่งที่ ค้ำจุนระบบ อยู่ จึงควรตรวจสอบความสัมพันธ์การพึ่งพาในปัจจุบันก่อนแก้ไข
- Chesterton's Fence เป็นหลักการที่มีประโยชน์ซึ่งบอกว่าควรเข้าใจเหตุผลของการสร้างก่อนลบออก แต่ถ้ามองแค่เจตนาแรกเริ่ม ก็อาจพลาดบทบาทที่เกิดขึ้นภายหลังได้
- ระหว่างการปรับปรุงห้องน้ำในบ้าน เสาไม้แนวตั้งที่ดูเหมือนเป็น สิ่งกีดขวาง แท้จริงแล้วหลังจากหน้าที่เป็นฉากกั้นตู้เสื้อผ้าหมดไป ก็ได้กลายเป็นส่วนที่ช่วยรับน้ำหนักของชั้นสองอยู่บางส่วนจากการเปลี่ยนแปลงโครงสร้างที่ผิดพลาด
- ในระบบคอมพิวเตอร์ที่ซับซ้อน ประวัติการเปลี่ยนแปลงและเอกสารการออกแบบเป็นเพียงจุดเริ่มต้นเท่านั้น และต้องดูควบคู่กันไปด้วยว่าคอมโพเนนต์นั้น ผสานรวม อยู่ในระบบปัจจุบันอย่างไร
- เมื่อต้องลบหรือแก้ไขคอมโพเนนต์เก่า หากไม่ตรวจสอบทั้งเหตุผลในการออกแบบในอดีตและบทบาทแฝงในปัจจุบันพร้อมกัน ก็อาจทำให้เกิดปัญหาที่ไม่คาดคิดได้
สิ่งที่ Chesterton's Fence อาจมองข้าม
- Chesterton's Fence คือแนวคิดที่ว่าก่อนจะเปลี่ยนแปลงหรือนำบางอย่างออก ต้องรู้ก่อนว่าสิ่งนั้น ถูกสร้างขึ้นมาทำไม
- สิ่งที่มนุษย์สร้างขึ้นอย่างรั้วหรือประตู โดยมากมักมีเหตุผลบางอย่างที่ใครบางคนเคยเห็นว่ามีประโยชน์
- แม้แต่การออกแบบที่ดูไร้ความหมายโดยสิ้นเชิง ก็อาจเป็นเพราะผู้ที่ต้องการเปลี่ยนแปลงกำลังมองข้ามปัญหาไปบางด้าน
- อย่างไรก็ตาม มุมมองนี้อาจทำให้เราโฟกัสเฉพาะบทบาทที่ผู้สร้างเดิมตั้งใจไว้ และมองข้าม การพึ่งพาใหม่ ที่เกิดขึ้นในภายหลัง
การค้นพบโครงสร้างรับน้ำหนักโดยบังเอิญระหว่างซ่อมบ้าน
- หลายปีก่อน ระหว่างการปรับปรุงห้องน้ำในบ้าน มี เสาไม้แนวตั้ง ต้นหนึ่งที่ขวางงานอยู่
- เดิมเสาต้นนั้นเป็นส่วนหนึ่งของฉากกั้นตู้เสื้อผ้า และดูเหมือนว่าหน้าที่เป็นฉากกั้นตู้เสื้อผ้าจะไม่จำเป็นอีกต่อไปแล้ว
- หากมองตามแนวคิด Chesterton's Fence อย่างเดียว ก็ดูเหมือนว่าจะถอดออกได้ แต่ในความเป็นจริง เมื่อเวลาผ่านไปมันกลับกลายเป็น โครงสร้างรับน้ำหนัก ไปแล้ว
- จากการเปลี่ยนแปลงโครงสร้างอื่นที่ผิดพลาด เสาต้นนี้จึงมีส่วนช่วยค้ำจุนชั้นสองของบ้านอยู่
- เราจึงต้องตรวจสอบไม่เพียงแค่ว่าสิ่งนั้นถูกสร้างขึ้นมาทำไมในตอนแรก แต่ยังต้องดูด้วยว่าภายหลังมันได้รับ บทบาทเพิ่มเติม อะไรบ้าง
บทเรียนที่ใช้ได้กับระบบคอมพิวเตอร์ที่ซับซ้อน
- ปัญหาแบบเดียวกันนี้เกิดซ้ำได้เมื่อมีการเปลี่ยนแปลงระบบคอมพิวเตอร์ที่ซับซ้อน
- การตรวจดูประวัติการเปลี่ยนแปลง อ่านเอกสารการออกแบบเดิม และทำความเข้าใจว่าทำไมคอมโพเนนต์หนึ่งจึงถูกสร้างมาในลักษณะนั้น ยังเป็นสิ่งที่มีประโยชน์อยู่
- แต่เพื่อความปลอดภัย เราต้องดูด้วยว่าปัจจุบันคอมโพเนนต์นั้น เชื่อมโยงและถูกใช้งาน อยู่ในระบบอย่างไร
- เมื่อเวลาผ่านไป คอมโพเนนต์มักได้รับ บทบาทเสริม ที่ต่างไปจากจุดประสงค์เดิมได้ง่าย
- การเปลี่ยนแปลงอย่างปลอดภัยเริ่มต้นจากการตรวจสอบทั้งเจตนาในการออกแบบในอดีตและบทบาทจริงในปัจจุบันควบคู่กัน
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
รู้สึกเหมือนในที่สุดก็มีชื่อเรียกสิ่งนี้เสียที
ผมทำงานสนับสนุนด้าน ระบบควบคุม ค่อนข้างมาก และก็ไม่ใช่เรื่องแปลกที่โค้ด PLC ซึ่งจัดการอุปกรณ์กายภาพแบบแปลก ๆ จะสร้างปัญหาที่ไม่ได้ตั้งใจขึ้นมา
เลยชอบพูดซ้ำ ๆ ว่า “ทุกครั้งที่คุณแก้ปัญหาไฟฟ้า/เครื่องกลด้วยซอฟต์แวร์ เกรมลินหนึ่งตัวจะถือกำเนิดขึ้น”
ต่อให้เจอสาเหตุรากของบั๊ก หรือข้อจำกัดที่ถูกโปรแกรมไว้ซึ่งอยากเอาออก ผมก็จะปฏิเสธเสมอจนกว่าจะรู้ก่อนว่าโค้ดนั้นมีไว้ทำไม ไม่มีโค้ดไหนถูกใส่มาโดยไม่มีเหตุผล จึงต้องรู้ก่อนว่าทำไมถึงต้องมีตัวจับเวลา หรือการ override นั้น
บางครั้งมันก็เป็นเรื่องดี เพราะโค้ดนั้นอาจมีไว้แก้ปัญหาที่หายไปแล้ว แต่บ่อยครั้งมันก็เป็นโค้ดที่ใส่ไว้เพื่อป้องกันอุบัติเหตุบางอย่าง แล้วพอมีการเปลี่ยนคนทำงาน วัตถุประสงค์เดิมก็หายไป ถ้าไม่มีเอกสาร ผมจะระวังมากกับการย้อนงานที่คนอื่นทำไว้ทันที
มันยังเกี่ยวกับความเชื่อใจกันระหว่างเพื่อนร่วมงานด้วย โดยปกติแล้วคนเราจะไม่ทำอะไรโดยไม่มีเหตุผล ถ้ามีโค้ดอยู่ ก็ต้องถือว่ามันมีจุดประสงค์ และเชื่อว่าในตอนแรกน่าจะมีการพิจารณามาอย่างเพียงพอแล้ว ถ้าความเชื่อนั้นพังลง การตัดสินใจทุกอย่างก็จะยากขึ้น
ถ้าเป็นเหตุผลที่ต้องไปโต้ตอบกับสิ่งนอก codebase อย่างระบบปฏิบัติการ, ระบบไฟล์, ฐานข้อมูล, HTTP endpoint, ฮาร์ดแวร์ แบบนี้ ถ้าไม่ใช่แค่การเรียก API หรือไลบรารีธรรมดา ผมจะคอมเมนต์ไว้ 100%
ถ้าต้องใส่
sleepเพราะข้อจำกัดด้านอัตราการเรียกของอีกบริการหนึ่ง ผมจะเขียนไว้ว่าใครเป็นคนกำหนด, ค่าจำกัดที่รู้ ณ ตอนนั้นคือเท่าไร, ถ้าไม่แน่ชัดก็จะบอกว่า “คาดเดาเอา แต่ดูเหมือนจะใช้ได้”, และถ้าเกินแล้วระบบจะมีอาการยังไงถ้าใช้ฐานข้อมูลกับงานจุกจิกที่ดูเหมือนใช้ระบบไฟล์ก็พอได้ แต่จริง ๆ แล้วถ้าเข้าถึงระบบไฟล์ในสภาพแวดล้อมนั้นด้วยวิธีที่จำเป็น จะทำให้ system call พุ่งหนักภายใต้โหลดจนทรัพยากรถูกใช้หมด ผมก็จะคอมเมนต์ไว้
แม้แต่ทางอ้อมแก้บั๊กของไลบรารียอดนิยมที่ Ubuntu ไม่ยอมแก้ใน LTS release ก็เป็นสิ่งที่ควรคอมเมนต์เหมือนกัน ผมเขียนคอมเมนต์แนว “รู้แหละว่านี่ไม่ค่อยดี แต่เหตุผลคือแบบนี้” มาเยอะมาก
แม้ตอนนี้จะขี้เกียจทำให้รองรับการขยายระบบ และก็คาดว่าไม่น่าจำเป็นในตอนนี้ แต่ถ้าต้องเขียนโค้ดที่ในสเกลใหญ่จะทำงานได้ไม่ดี ผมก็จะคอมเมนต์ไว้ด้วย อาจจะเป็นการปกป้องศักดิ์ศรีตัวเองนิดหน่อย แต่ก็ประมาณว่า “รู้ว่าอ่านทั้งไฟล์เข้าหน่วยความจำ แต่นี่เป็นงาน batch ที่เกิดไม่บ่อยและคาดการณ์ได้ และไฟล์ก็น่าจะเล็ก จึงโอเค ถ้าหน่วยความจำไม่พอ ให้เริ่มดูจากตรงนี้ ถ้าจะเปลี่ยนเป็นการเรียกแบบ on-demand ก็เขียนใหม่ซะ”
ประเด็นที่บทความนี้พยายามชี้คือ แค่นั้นอย่างเดียวไม่พอ เพราะต้องรู้ด้วยว่ามีอะไรอย่างอื่นถูกสร้างทับอยู่บนสมมติฐานที่ว่าโค้ดนั้นมีอยู่ด้วย
“ไม่รู้ว่าทำไม rung นี้ถึงจำเป็น แต่ลองลบแล้วพิสูจน์ด้วยตัวเองดู”
ผมเลยไม่ไปยุ่งกับมันโดยไม่จำเป็น และก็ไม่ได้ลองพิสูจน์ด้วย
ในทางประวัติศาสตร์ วิศวกรไฟฟ้าและวิศวกรเครื่องกลมักมองซอฟต์แวร์จริงจังน้อยกว่าระบบไฟฟ้าหรือเครื่องกล และผลก็คือในวัฒนธรรมวิศวกรรมที่ EE/ME ครอบงำ มักมีโค้ดเละเทะออกมาได้ง่าย
แม้แต่ในหมู่คนที่ภายนอกถือว่าเป็น Professional Engineer ก็ยังพบงานวิศวกรรมซอฟต์แวร์ที่อ่อนประสบการณ์จนยอมรับได้ยากอยู่บ่อย ๆ
ไม่ต้องพูดถึงโค้ดที่ไม่มีเอกสาร ส่วนใหญ่ฮาร์ดแวร์ยังเป็นของสั่งทำเมื่อ 30 ปีก่อน จนไม่มีแม้แต่ วงจรไดอะแกรม ของอุปกรณ์ที่กำลังทำงานอยู่
ผมก็เคยเจออะไรคล้าย ๆ กัน
หลายปีก่อนผมซื้อบ้านเก่าหลังหนึ่ง และเจ้าของก่อนหน้าก็ทำงานเกือบทุกอย่างด้วยตัวเองมาตั้งแต่ทศวรรษ 1960
รางน้ำสังกะสีน่าจะรั่วมาหลายสิบปีจนทำให้โครงสร้างหลังคาบางส่วนเสียหาย และหลังคาก็ถูกพยุงไว้ด้วย แผ่นไม้กรุ ที่ติดเพิ่มไว้ด้านในตอนยุค 70 เพื่อปิดทับไว้ กล่าวคือแผ่นไม้นั้นกลายเป็นตัวรับน้ำหนักจริง ๆ
ในบ้านหลังนี้ผมเจออะไรแบบนี้อีกเยอะ เช่นตรงปลายหลังคาที่กระเบื้องกว้างไม่พอ แทนที่จะซื้อเพิ่ม เขากลับอุดด้วยปูนซีเมนต์กับเศษกระถางเซรามิกแตก ๆ
ทุกวันนี้เราไปพึ่ง drywall กับไม้อัดให้ทำหน้าที่นั้นเวลาเกิดแผ่นดินไหวหรือพายุ
ถ้าคุณเห็นการสร้างบ้านใหม่โดยรื้อจนเหลือแต่โครง คุณจะเห็นมีการเสริมค้ำบางชิ้นเพิ่มเข้าไป มันไม่ได้มีไว้กันไม่ให้ผนังพัง แต่มีไว้เพื่อรักษา มุมฉากและความเรียบระนาบ จนกว่าจะยกผนังกลับขึ้นมาอีกครั้ง
มองเผิน ๆ จะเหมือนมีคนขับรถชนประตูโรงรถจนยุบหนัก แต่พอดูดี ๆ จะเห็นว่าหลังคากำลังแขวนอยู่กับรางที่ติดประตูแบบหวุดหวิด และเกือบพังเต็มที
ตอนแรกผมคิดจะต่อปลายจันทันแล้วเปลี่ยนแค่ประตูโรงรถ เพราะก่อนหน้านี้อีกฝั่งก็มีคนทำแบบนั้นแล้ว ดูเหมือนใช้ได้ แต่ตอนนี้ชักคิดว่าอาจต้องทำหลังคาใหม่ทั้งชุด
ที่น่ากังวลจริง ๆ คือสายไฟชวนพิรุธที่พาดอยู่ทั่วชั้นใต้ดิน มีทั้งสายไฟค่อนข้างใหม่, สายเก่าหุ้มผ้า, และเทปไฟฟ้าที่ใช้พันต่อมันเข้าด้วยกัน โชคดีที่ดูเหมือนไม่มีเส้นไหนรับน้ำหนักอยู่
ดูเหมือนว่าบทความนี้และคอมเมนต์เกือบทั้งหมดกำลังพลาดประเด็นจริงไป ประเด็นสำคัญคือ การทดสอบมีไม่พอ
ซอฟต์แวร์ต่างจากเครื่องมือการผลิตอื่นทั้งหมดตรงที่ เราสามารถทดสอบการเปลี่ยนแปลงได้จริงก่อนจะนำไปใช้กับโลกจริง
ถ้ามีการทดสอบที่ดี ก็ไม่สำคัญว่าเจตนาเดิมคืออะไร หรือฟีเจอร์นั้นจะมีการใช้งานใหม่หรือผู้ใช้กลุ่มใหม่เกิดขึ้นหรือไม่ แก้แล้วรันเทสต์ก็จะบอกได้ว่าการแก้นั้นดีหรือไม่
ถ้ามีการทดสอบที่ดี ก็ไม่จำเป็นต้องมีโบราณคดีซอฟต์แวร์, รุ่นเก๋าที่รู้ทุกซอกทุกมุมของระบบ, อัจฉริยะที่สร้างโมเดลระบบซับซ้อนในหัวได้, เอกสารความต้องการที่ครอบคลุม, หรือระบบปล่อยใช้งานอย่างระมัดระวังที่ทำให้ผู้ใช้บางกลุ่มเป็นหนูทดลอง
ถ้ามีการทดสอบที่ดี คุณอาจสุ่มเปลี่ยนระบบไปเรื่อย ๆ แล้วหยุดเมื่อได้การปรับปรุงด้วยซ้ำ ซึ่งเหมือนกับวิธีที่ Google รายงานว่า AI “พัฒนา” การปรับปรุงการจัดเรียงได้อย่างแม่นยำ
แต่ถึงอย่างนั้น นักพัฒนาฝั่งทดสอบก็ยังได้ค่าตอบแทนน้อยกว่าครึ่งหนึ่ง แผนกทดสอบก็เล็กกว่าตามสัดส่วน QA ก็ถูกบีบด้วยกำหนดการที่ตายตัวและจำกัด และแทบไม่มีวีรบุรุษทางเทคโนโลยีที่มาจากสาย QA เลย น่าจะเพราะมันถูกมองว่าเป็นงานต่อยอดและเชิงรับ
คุณอาจลบโค้ดที่ไม่ได้ใช้กับเทสต์ของมันออกไป แต่ความจริงมันอาจยังถูกใช้อยู่ก็ได้
หลังเปลี่ยนแล้วเทสต์ล้มเหลว แต่เพราะเทสต์เปราะบางเลยแก้เทสต์ให้เข้ากับสถานการณ์ใหม่ แล้วค่อยพบว่ามีบางอย่างกำลังพึ่งพาพฤติกรรมเดิมอยู่ก็ได้
การทดสอบนั้นยอดเยี่ยม และในระบบที่ปิดจบในตัวเองมากพอก็อาจเพียงพอได้ด้วยตัวมันเอง แต่ในระบบที่ใหญ่กว่านั้น บางครั้งก็ยังต้องมี telemetry หรือการทยอยปล่อยใช้งานด้วย
เดิมทีโค้ดอาจมีไว้คำนวณ VAT ของรายการซื้อสินค้า แต่ค่อย ๆ กลายเป็นวิธีบังคับรีเฟรชแคช VAT ตามหมวดหมู่สินค้า และถูกเรียกใช้ในบริบทที่ไม่เคยคาดคิดมาก่อน
คอมเมนต์ก็เหมือนกัน มันอธิบายเจตนาเดิมและผลข้างเคียงได้ แต่ไม่สามารถอธิบายได้ว่าในเวลาต่อมาเมธอดหรือคลาสนั้นถูกใช้ที่ไหน หรือจริง ๆ แล้วมันกลายเป็นอะไรไปแล้ว
ในโลกอุดมคติ คอมเมนต์ก็ควรถูกอัปเดตเมื่อโลกภายนอกเปลี่ยนไป แต่ในความเป็นจริง แทบไม่ค่อยเกิดขึ้นถ้าโค้ดภายในไม่ได้เปลี่ยนตามไปด้วย
โดยปกติเทสต์จะเสื่อมสภาพ ดูเหมือนว่าการทดสอบเองก็มีวันหมดอายุ และสุดท้ายบางเทสต์ก็เริ่มตายไป
ปัญหาเรื่อง dependency, ความคาดหวังของ API ที่เปลี่ยนไป, อัปเดตด้านความปลอดภัย, บัญชีและข้อมูลรับรองที่หมดอายุ, endpoint ของเครื่องและสถานะที่เปลี่ยนไป ปะปนกันจนผลการทดสอบไม่สามารถบอกความถูกต้องของโปรแกรมได้อีกต่อไป
มูลค่าทางธุรกิจของการซ่อมเทสต์ที่พังทีละตัวมักต่ำมาก จึงมักถูกปิดทิ้งไปเลย หรือถูกบังคับให้ “ผ่าน” ทั้งที่ควรเป็นข้อผิดพลาด
ทำแบบนี้ซ้ำไป 10 หรือ 20 ปี ไม่นานก็จะเกิดการแบ่งระหว่าง “เทสต์ที่เราเชื่อถือจริง” กับ “เทสต์ที่ยุ่งเกินกว่าจะซ่อมหรือเก็บกวาด”
ความรู้ว่าเทสต์ไหนดีหรือไม่ดีกลายเป็นความรู้เฉพาะกลุ่มที่สูญหายไปพร้อมกับการย้ายตำแหน่งและเปลี่ยนบทบาทงาน แล้วสักจุดหนึ่ง ก้อนรวมของ “เทสต์ที่โกหกว่าใช้งานได้” กับ “เทสต์ที่ไม่มีใครตามดูอีกแล้วว่าความล้มเหลวนั้นจริงไหม” ก็กลายเป็นสิ่งที่บังเอิญต้องมารับน้ำหนักเสียเอง
จะดีกว่าถ้าพูดไปเลยว่าโปรแกรมเมอร์ควรเป็นคนเขียนเทสต์ เก็บไว้คู่กับโค้ด และให้รันอัตโนมัติในกระบวนการ build
แต่ผมก็ยังคิดว่าแม้แต่ test-driven development ที่ทำอย่างถูกต้อง ก็ไม่สามารถแทนที่การออกแบบที่ดีและแนวปฏิบัติที่ดีได้ แม้แต่สเปกที่ง่ายมากก็แทนด้วยเทสต์ทั้งหมดไม่ได้
ถ้ามีเพียงสเปกว่า
f(S)ต้องคืนค่าสตริงที่นำมาต่อกับตัวเอง การจะยืนยันว่าfถูกต้องด้วยเทสต์ที่ชัดเจนซึ่งปฏิบัติต่อfเป็น black box อย่างเดียวทำได้ยาก ข้อกำหนดเชิงรูปแบบ ก็สำคัญคุณอาจลองจิ้มตรวจดูได้ไม่กี่จุด แต่ถ้ามีค่าที่ผิดเพียงค่าเดียวแล้วทำให้สถานการณ์วิกฤต การทดสอบก็อาจไม่สามารถแสดงให้เห็นได้
โบราณคดีซอฟต์แวร์, รุ่นเก๋า, อัจฉริยะที่สร้างโมเดลระบบในหัว, เอกสารความต้องการที่ครอบคลุม, และระบบปล่อยใช้งานที่ใช้ผู้ใช้บางส่วนเป็นหนูทดลอง จะถูกล้อเลียนก็ได้ แต่ทั้งหมดล้วนเป็นการตอบสนองต่อความจริงที่ว่าซอฟต์แวร์นั้นยาก และซอฟต์แวร์ก็ยากจริง ๆ
โดยทั่วไปทีมซอฟต์แวร์ต้องรับผิดชอบต่อคุณภาพของงานตัวเองโดยตรง และไม่สามารถโยนปัญหาข้ามเส้นแบ่งขององค์กรได้
ฉันเข้าใจได้ว่าตะปูสตัดที่เดิมไม่สำคัญอาจมารับน้ำหนักในภายหลังได้ แต่จากประสบการณ์ของฉัน มันดูเป็นสัญญาณของ การออกแบบแบบขี้เกียจ
อย่างน้อยเวลาสร้างซอฟต์แวร์ เราพอมองออกได้ว่ากำลังจะเอาสตัดตกแต่งมารับบางส่วนของบ้าน และถ้ารู้แบบนั้นแล้วยังเลือกปล่อยให้เป็นอย่างนั้นแทนที่จะสร้างโครงสร้างใหม่ที่ดีกว่า สุดท้ายทีมพัฒนาก็มักจะหดหู่กันพอสมควร
ฉันเห็นด้วยกับบทความนี้ แต่การทำงานในที่ที่เราคาดหวังได้ว่าจะไม่ต้องเจอการค้นพบแบบนี้บ่อย ๆ ย่อมดีกว่ามาก
ประเด็นของบทความนี้ไม่ใช่ว่าอย่าใช้สตัดตกแต่งเป็นองค์ประกอบรับน้ำหนัก แต่ใกล้เคียงกับการบอกว่า จงตระหนักว่าอาจมีใครบางคนก่อนหน้าคุณที่ทำแบบนั้นไปแล้ว
นี่เป็นจุดยืนที่อนุรักษ์นิยมยิ่งกว่าการตีความแบบพื้นฐานของรั้วของเชสเตอร์ตันเสียอีก และแม้แต่การตีความพื้นฐานนั้น คนจำนวนมากก็ยังผลักไสมันว่าเป็นข้อจำกัดที่มากเกินไป
สำหรับฉัน บทความนี้โดนใจมาก ถ้าพูดในเชิงโปรแกรม ฉันเคยลบชิ้นส่วนกรอบตกแต่งที่ “เอาไว้ประดับ” แล้วเพดานก็พังลงมาจริง ๆ เหนือหัว
ว่าระบบนั้นแข็งแรงหรืออันตรายจนขยายต่อไม่ได้ ขึ้นอยู่กับบริบท
คุณสามารถทำ thought experiment อย่าง “ถ้าทีมขายโตเป็นสองเท่าและกินตลาดได้ 100% เราจะยังขายและ onboard ลูกค้าให้เร็วที่สุดได้ไหม?” ได้เสมอ และภายใต้เงื่อนไขแบบนั้น การใช้ฐานข้อมูลเป็น message queue ก็อาจโอเคได้
ถ้าผลคือทีมพัฒนาต้องลำบาก อย่างนั้นก็ถือว่าเป็นความผิดพลาด ระบบนั้นดูแลรักษายากหรือกลายเป็นนรกด้านปฏิบัติการ
แต่การใช้สตัดตกแต่งของซอฟต์แวร์เป็นองค์ประกอบรับน้ำหนักไม่ได้แปลว่าจะจบแบบนั้นเสมอไป ยังมีระบบมากมายที่ช่วยประหยัดเวลาไปได้หลายเดือนในการทำวิธีแก้ที่สมบูรณ์แบบกว่า และสุดท้ายก็ทำหน้าที่ของมันอย่างเงียบ ๆ ได้ดี
ส่วนอื่นของโค้ดเบสไม่เคยส่งอินพุตผิดพลาดมาเลย ดังนั้นแขนงนั้นจึงเป็น dead code และไม่ได้รับภาระใด ๆ
แล้ววันหนึ่งก็มีบั๊กโผล่มาส่งอินพุตผิดพลาดเข้ามา และแขนงนั้นก็จัดการกับมันและกู้คืนได้อย่างขยันขันแข็ง ในจังหวะนั้นแขนงนั้นก็กลายเป็น แขนงรับน้ำหนัก
ตัวอย่าง “สิ่งที่บังเอิญมารับน้ำหนัก” ที่ฉันชอบที่สุดคือการตั้งค่า
sudoผิดมีการอนุญาตให้ใช้
sudoโดยไม่ต้องใส่รหัสผ่านกับคำสั่งfindทำให้สามารถใช้-execรันโค้ดใด ๆ ด้วยสิทธิ์ root ได้ง่าย ๆ และสคริปต์สนับสนุนสำคัญหลายตัวของผลิตภัณฑ์ก็ถูกเขียนให้ใช้อันนี้เรียกได้ว่าเป็น การยกระดับสิทธิ์ที่กลายเป็นตัวรับน้ำหนัก
เมื่อหลายปีก่อนฉันรีโมเดลครัว
ตรงปลายด้านหนึ่งของครัวเก่ามีคานขนาดใหญ่พาดอยู่ ซึ่งถูกเพิ่มเข้ามาในงานรีโมเดลครั้งหนึ่งก่อนที่เราจะซื้อบ้าน เพื่อทำชั้นสองขึ้นมา การจะขยายครัวต้องเอาสิ่งนี้ออก
พอรื้อเพดานออกก็พบว่าคานนั้นอยู่ค่อนไปทางขวาประมาณ 2 ฟุตจากตำแหน่งที่มันควรจะรองรับผนังชั้นบน
สุดท้ายเราก็แก้ไขและย้ายคานเข้าไปอยู่ในผนังชั้นบนได้เรียบร้อย แต่เมื่อถามถึงตำแหน่งเดิม ผู้รับเหมาก็ตอบประมาณว่า
“มันมีทั้งคนที่อยากทำให้ถูกต้อง กับคนที่ไม่ใส่ใจ สุดท้ายคุณภาพก็จะถูกตั้งตาม ค่าต่ำสุด”
ข้อดีอย่างหนึ่งของซอฟต์แวร์เมื่อเทียบกับระบบกายภาพคือ เราสามารถทำเอกสารให้เจตนาชัดเจนขึ้นได้ง่ายกว่าผ่าน คอมเมนต์และ type ในโค้ด
โดยเฉพาะในภาษาที่เป็น dynamic อย่าง Python มันไม่สมบูรณ์แบบ แต่ก็ช่วยได้มาก
อุปมาแบบเดียวกับสตัดที่กลายเป็นตัวรับน้ำหนักอาจเป็นโปรเจ็กต์แฮกกาธอนที่ไม่เคยคิดว่าจะได้ขึ้น production
ในความเป็นจริง งานจำนวนมากที่เราทำก็คือแฮ็กอะไรบางอย่างให้พอใช้งานได้ แล้วก็ไปทำอย่างอื่นต่อ
แผนการบำรุงรักษาจำเป็นต้องรู้ว่าชิ้นส่วนหรือชุดประกอบที่เปลี่ยนได้แต่ละตัวกำลังรับ “ภาระ” แบบไหนอยู่
น่าเสียดายที่วิศวกรรมระบบในปัจจุบันได้เบี่ยงออกไปไกลจากเป้าหมายดั้งเดิมมาก แต่นั่นคือแนวคิดตั้งต้น
เหตุผลหนึ่งที่ทุกวันนี้แผนกวิศวกรรมระบบมีอำนาจน้อยลงเมื่อเทียบกับเดิม คือเรื่องการเงินได้เข้ามาอยู่ในแผนการบำรุงรักษา ค่าเสื่อมราคาสินค้าคงคลังนั้นโหดร้าย และอย่างน้อยจากประสบการณ์ของฉัน การตัดสินว่า “อะไรควรเก็บเป็นอะไหล่สำรอง” เดี๋ยวนี้แทบไม่ใช่เรื่องที่วิศวกรรมระบบเป็นคนชี้ขาดแล้ว
ผลลัพธ์ก็คาดเดาได้ แต่ก็ถูกชดเชยบางส่วนด้วยมาตรฐานที่สูงมากของบุคลากรซ่อมบำรุงด้านการบินและอวกาศ พวกเขาเก่งกว่าช่างซ่อมเครื่องซักผ้าอย่างเห็นได้ชัด เป็นต้น
แน่นอนว่าฝ่ายการเงินก็อยากลดมาตรฐานนั้นลงไปอีกหลายขั้น
แต่ฉันก็ยังประหลาดใจเสมอว่าพบบ่อยแค่ไหนที่องค์ประกอบต้นน้ำซึ่งดูเหมือน “มีไว้ประดับ” แท้จริงแล้วกำลังทำหน้าที่เป็น ตัวจำกัดความเร็ว อยู่ และพอเอามันออก ส่วนที่เหลือของระบบก็วิ่งจนควบคุมไม่อยู่
มันทำให้นึกถึงกรณีที่ผู้ใช้เอาบั๊กของซอฟต์แวร์ไปใช้โดยไม่รู้ตัว แล้วผนวกมันเข้าเป็นส่วนหนึ่งของ workflow ปกติ
ผลคือพอแก้บั๊กนั้น workflow ก็สะดุดและเกิดความไม่พอใจ
เขาบอกว่า “ทำไมมันถึงอยู่ตรงนั้นดูออกได้ไม่ยาก มันเป็นส่วนหนึ่งของผนังกั้นตู้เสื้อผ้า” แต่เมื่อเวลาผ่านไปมันกลับบังเอิญมารับน้ำหนัก และจากการเปลี่ยนแปลงโครงสร้างอื่นที่ผิดพลาด สตัดตัวนั้นจึงมาช่วยรองรับชั้นสองของบ้าน
แต่จริง ๆ แล้วมันไม่ชัดเลยว่าทำไมมันถึงอยู่ตรงนั้น แถมฉันก็ไม่ค่อยเชื่อคำอธิบายว่ามันบังเอิญมารับน้ำหนัก
แม้มันจะดูเป็นเหตุผลที่ผิดสำหรับคุณ แต่ก็ดูมีความเป็นไปได้ไม่น้อยว่า สำหรับคนในเวลานั้น มันถูกทำให้ รับน้ำหนักโดยตั้งใจ ด้วยเหตุผลที่พวกเขาเห็นว่าถูกต้อง
เพียงแต่การรู้ว่าทำไมมันถึงอยู่ตรงนั้นตั้งแต่แรก ไม่ได้บอกว่าตอนนี้มันกำลังทำหน้าที่อะไรอยู่
สมัยก่อนนักวิจัยหลังปริญญาเอกด้านฟิสิกส์ที่ฉันเคยร่วมงานด้วย มักจะแปะป้ายแบบนี้ไว้บนการจัดวางอุปกรณ์เป็นครั้งคราว
“ห้ามแตะต้อง มีอันตรายแฝงอยู่”
ในห้องแล็บมีแต่คนฉลาด ๆ และพวกเขาคุ้นเคยกับการมองอะไรบางอย่างแล้วสรุปด้วยเหตุผลของตัวเองได้ว่าควรเปลี่ยนมันได้หรือไม่
ป้ายนี้เป็น คำเตือน ว่าอย่าเพิ่งรีบตัดสินแบบนั้นเร็วเกินไป