ไม่มีสุนัขตัวไหนได้รับอันตรายระหว่างการสร้างแอปนี้
(shmck.substack.com)- ในปี 2016 ใช้เวลาตามหาปัญหาอยู่หนึ่งสัปดาห์ เมื่อ ฟังก์ชันอัปโหลดรูปภาพพร้อมข้อมูลตำแหน่ง ของแอปมือถือ React Native ล้มเหลวเฉพาะใน Android เบตา และไม่สามารถทำให้เกิดซ้ำได้บน Android ในเครื่องหรือ iOS
- Android เบตาไม่แสดงข้อผิดพลาดใด ๆ แม้อัปโหลดรูปภาพล้มเหลว และทุกครั้งที่อัปโหลดบิลด์ใหม่ขึ้น Play Store ต้องใช้เวลา ประมาณ 1 ชั่วโมง ทำให้การทดสอบสมมติฐานเป็นไปอย่างช้า
- เมื่อนำไปเทียบกับกรณีของงานระบบฝังตัว ฮาร์ดแวร์ เคมี และสัตวแพทย์ จะเห็นได้ว่าการดีบักซอฟต์แวร์นั้นทั้งเร็วกว่าและสังเกตการณ์ได้มากกว่ามาก
- สาเหตุที่แท้จริงคือความต่าง เพียงตัวอักษรเดียว โดยเขียน MIME type ของรูปภาพเป็น
"jpg"ทั้งที่แม้นามสกุลไฟล์จะเป็น.jpgแต่ MIME type ต้องเป็น"jpeg" - สภาพแวดล้อมการพัฒนาที่ใช้ log การสังเกตแบบเรียลไทม์ ดีบักเกอร์ และการทดลองซ้ำได้ในต้นทุนต่ำ ถือเป็นสิทธิพิเศษอย่างมากเมื่อเทียบกับวงจรป้อนกลับของอาชีพอื่น
การอัปโหลดรูปภาพที่ล้มเหลวเฉพาะบน Android เบตา
- ฟีเจอร์ geolocated photos ของแอปมือถือ React Native ดูเหมือนพร้อมสำหรับการปล่อยในวันจันทร์แล้ว แต่หลังปล่อย Android เบตา รูปภาพกลับอัปโหลดไม่สำเร็จ
- การทดสอบ Android ในเครื่องและ iOS เบตาทำงานได้ปกติ จึงไม่เห็นสาเหตุของความล้มเหลวในทันที
- แม้อัปโหลดเวอร์ชันที่ปรับปรุงการจัดการข้อผิดพลาดขึ้นไปใหม่ การอัปโหลดก็ยังล้มเหลวโดย ไม่มี feedback ใด ๆ
- การอัปโหลดเวอร์ชันรอบใหม่ขึ้น Play Store ใช้เวลา ประมาณ 1 ชั่วโมง และต้องรอให้บิลด์ถูกปล่อยขณะเตรียมสมมติฐานถัดไป
วงจรป้อนกลับที่ยาวนานกว่าของอาชีพอื่น
- วิศวกรระบบฝังตัวเจอสถานการณ์ที่หลังปล่อย เฟิร์มแวร์อัปเดต ไปยังอุปกรณ์ระยะไกลแล้ว โหนดไม่ตอบสนอง
- หากต้องการหาสาเหตุ ต้องนำอุปกรณ์กลับมาตรวจวิเคราะห์
- บางกรณีต้องใช้เวลา หลายเดือน กว่าจะรู้ว่าอะไรผิดพลาด
- วิศวกรฮาร์ดแวร์มองว่าฮาร์ดแวร์รุ่นใหม่ที่ส่งไปใช้งานระยะไกล อาจต้องผ่านไปหลายฤดูกาลกว่าจะเผยข้อบกพร่องของการออกแบบ
- รับอุปกรณ์เก่าคืนทางไปรษณีย์ แล้วนำสิ่งที่แก้ไขไปสะท้อนในผลิตภัณฑ์รุ่นถัดไป
- มีกรณีที่เพิ่มช่องระบายอากาศเพื่อลดความร้อน แต่รูใหญ่พอให้ต่อหัวเสือเข้าไปทำรัง กลายเป็นบั๊กที่แย่กว่าเดิม
- แม้จะทดสอบในห้องแล็บได้ แต่การยืนยันขั้นสุดท้ายก็ยังต้องเกิดขึ้น ภาคสนาม
วิธีรับมือกับความล้มเหลว
- CEO เล่าย้อนถึงสมัยเป็นนักเคมีที่กำลังเตรียมวิทยานิพนธ์ปริญญาเอก ว่าเคยทำการทดลองด้วยทุนวิจัยก้อนใหญ่สำหรับสารเคมีราคาแพง แต่หลายสัปดาห์ต่อมาผลลัพธ์กลับดูเหมือนล้มเหลวเพราะ ข้อผิดพลาดในการทดลอง
- เขาไม่สามารถหาคำตอบได้ว่าอะไรผิดไป และตอบไม่ได้ด้วยซ้ำว่าหากไม่อยากทำผิดแบบเดิมอีก จะทำอะไรให้ต่างออกไป
- ถึงอย่างนั้นก็ยังได้รับทุนวิจัยรอบที่สอง และประสบการณ์นี้กลายเป็นตัวอย่างของ ภาวะผู้นำที่มีความเห็นอกเห็นใจ ที่ช่วยพยุงคนที่ล้มเหลวให้ลุกขึ้นมาใหม่
กรณีจากสัตวแพทย์ที่ชี้ให้เห็นความเสี่ยงที่สูงกว่า
- เพื่อนสัตวแพทย์รักษาสุนัขแก่ที่ป่วย และแนะนำเจ้าของให้ทำ X-ray แต่เจ้าของปฏิเสธเพราะค่าใช้จ่าย
- สิ่งที่ทำได้ดีที่สุดโดยไม่มี X-ray คือคลำท้องสุนัขจากภายนอก และพบว่ามีวัตถุขนาดใหญ่
- สิ่งที่ผ่าออกมาคือ ซังข้าวโพด แต่เพราะไม่มี X-ray จึงไม่อาจมั่นใจได้ว่านั่นคือปัญหาทั้งหมดหรือไม่
- วันถัดมาสุนัขตัวนั้นก็ตาย และต่างจากปัญหาการปล่อยแอปมือถือ ความล้มเหลวในบางอาชีพอาจเกี่ยวพันกับชีวิตและความตายจริง ๆ
บั๊กตัวอักษรเดียวและสิทธิพิเศษของเครื่องมือดีบัก
- เช้าวันศุกร์พบความไม่สอดคล้องกันระหว่างเอกสาร Android กับโค้ดเบส และต้นเหตุที่สร้างปัญหามาทั้งสัปดาห์คือ อักขระเพียงตัวเดียว
- MIME type ของรูปภาพถูกตั้งไว้เป็น
"jpg"แต่ที่จริงต้องเป็น"jpeg"ขณะที่ไฟล์ถูกบันทึกเป็น.jpg - นักพัฒนาซอฟต์แวร์สามารถมองลึกเข้าไปในกระบวนการที่ซับซ้อน เฝ้าดูการทำงานแบบเรียลไทม์ บันทึก log และหยุดการทำงานด้วยดีบักเกอร์เพื่อตรวจดูได้
- ความสามารถเหล่านี้ทั้งถูกและรวดเร็ว และสามารถทดลองซ้ำได้หลายครั้งต่อวันด้วยการคลิกเพียงไม่กี่ครั้ง
- แม้ซอฟต์แวร์จะสำคัญและทรงอิทธิพลได้ไม่แพ้อาชีพอื่น แต่ผู้พัฒนาก็ทำงานอยู่ในสภาพแวดล้อมที่ควรรู้สึกขอบคุณสำหรับ เครื่องมือดีบัก ที่มีอยู่ตอนนี้
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เรื่องนี้แทบจะเป็นนิทานเปรียบเปรยที่แสดงให้เห็นว่าทำไมวิศวกรรมซอฟต์แวร์ถึงต่างจากอาชีพอื่น ๆ หรือพูดติดตลกว่าอาชีพที่ ‘จริงจัง’
ผมยังชอบเวอร์ชันที่สั้นและคมกว่านี้ด้วย: วิศวกรซอฟต์แวร์ วิศวกรฮาร์ดแวร์ และหัวหน้าแผนกกำลังไปประชุมที่สวิตเซอร์แลนด์ ระหว่างทางรถเบรกแตกบนถนนภูเขาชัน รถไถลชนราวกั้นแล้วลงเขาไปก่อนจะหยุดได้อย่างปาฏิหาริย์
หัวหน้าแผนกบอกว่าให้เปิดประชุม กำหนดวิสัยทัศน์ พันธกิจ และเป้าหมาย แล้วแก้ปัญหาหลักด้วยการปรับปรุงอย่างต่อเนื่อง ส่วนวิศวกรฮาร์ดแวร์บอกว่าให้ใช้มีดพก Swiss Army ถอดเบรกออกมาซ่อม
แต่วิศวกรซอฟต์แวร์พูดว่า “ก่อนจะทำอะไร เราลองช่วยกันเข็นรถกลับขึ้นไปข้างบนแล้วดูว่า มันเกิดซ้ำได้ไหม”
แต่ในเวลาเดียวกัน ข้อเสียใหญ่มากของวิศวกรรมซอฟต์แวร์ก็คือมันทำงานกับการนามธรรมเช่นกัน ฐานทั้งหมดจึงขยับได้หมด
http://thecodelesscode.com/case/154
การมีความสามารถแบบนั้นไม่ได้แปลว่าวิศวกรซอฟต์แวร์ดูตลกหรือไม่สมจริง
วิศวกรรมในพื้นที่ดิจิทัล มอบความสามารถในการดีบักที่ในโลกกายภาพแทบจะเป็นปาฏิหาริย์ ถ้าอยากสร้างของชิ้นเดิม 10 ชิ้นแล้วทดสอบ 10 แบบ ก็แค่ CTRL+C, CTRL+V ตามตัวอักษรเลย อยากเห็นช่างซ่อมทำแบบนั้นบ้าง
ผมเบื่อมากกับคำบ่นทำนองที่ว่าวิศวกรซอฟต์แวร์ไม่ใช่ ‘วิศวกรจริง’ และถ้าจะให้แก้ปัญหาได้ก็ต้องมีการประชุมออกแบบขนาดใหญ่ล่วงหน้าและวางแผนกันมหาศาล
สาขาวิศวกรรมอื่นไม่ได้ทำงานแบบนั้นเพราะเป็นมืออาชีพกว่าเรามาก หรือเพราะวิธีนั้นดีกว่า แต่เพราะ พวกเขาไม่มีทางเลือกอื่น ต่างหาก คุณไม่ใช่จะเพิ่งสร้างโรงแรมเสร็จแล้วมารู้ว่าต้องยกเพดานขึ้นอีก 6 นิ้ว แล้วรื้อทั้งหมดสร้างใหม่กันหรอก
ถ้าคุณสั่ง
ceilingHeight += 6แล้วกด “Rebuild” จากนั้นโรงแรมก็สร้างตัวเองขึ้นใหม่ โดยมี automated unit test ตรวจแม้กระทั่งการเข้าถึง และต้นทุนรวมอยู่ที่ 2.82 ดอลลาร์ พวกเขาก็คงทำแบบนั้นเหมือนกันนั่นแหละเราควรเลิกมีปมด้อยได้แล้ว เรากำลังทำวิศวกรรมด้วยเครื่องมือที่วิศวกรโยธาหรือเครื่องกลในโลกจริงทำได้แค่ฝัน และเป็นเรื่องธรรมดามากที่กระบวนการจะแตกต่างกันมาก
แน่นอนว่าบางครั้งเราอาจใช้กระบวนการกับปัญหาได้ไม่มากพอ แต่ถ้าคิดว่านั่นเป็นปัญหาเฉพาะของการเขียนโปรแกรม ผมก็อยากสั่งให้คุณไปดู https://www.imdb.com/title/tt4788946/ สักสองสามชั่วโมง
ไม่ใช่เรื่องของความเหนือกว่า แต่ถ้าขาดเกณฑ์ข้อใดข้อหนึ่งไป คุณก็ไม่ได้ทำวิศวกรรม จากประสบการณ์ของผม งานพัฒนาซอฟต์แวร์ส่วนใหญ่ขาดครบทั้งสี่ข้อ นั่นไม่ได้แปลว่ามันแย่เสมอไป แต่หมายความว่างานพัฒนาซอฟต์แวร์ส่วนใหญ่ไม่ใช่วิศวกรรม
และไม่ได้หมายความเลยว่าวิศวกรรมนั้นเหนือกว่าการพัฒนา
มันเหมือนความต่างระหว่างการปั้นดินเหนียวกับการแกะสลักหินอ่อน ถ้าพลาดกับดินเหนียวก็แค่แตะปรับใหม่ได้ทันที แต่ถ้าคุณสกัดหินอ่อนในส่วนที่ไม่ควรออกไป ก็ต้องสั่งก้อนหินอ่อนใหม่
ถ้าคุณเอา แนวทางแบบแกะหินอ่อน มาใช้ในโลกของดินเหนียว คุณก็จะเป็นช่างปั้นดินที่แย่มาก หรืออย่างน้อยก็ไร้ประสิทธิภาพมาก
และการจะเถียงกันว่างานปั้นแบบไหนมีค่ากว่ากันก็ไม่ค่อยมีประโยชน์ ทั้งสองอย่างต่างก็มีที่ทางของตัวเองในสังคม
ceilingHeight += 6มากที่สุดในโลกจริงวันนี้ผมก็เพิ่งโมเดลของชิ้นหนึ่งแล้วสั่งพิมพ์ออกมา ก่อนจะรู้ว่ามีจุดหนึ่งที่น่าจะหนาขึ้นอีกสัก 1 มม. ผ่านไป 30 วินาที เวอร์ชัน 2 ก็ถูกส่งเข้าเครื่องพิมพ์แล้ว
มันวิเศษจริง ๆ แทบอดใจรอไม่ไหวให้สิ่งนี้แพร่หลายเหมือนเครื่องพิมพ์กระดาษทั่วไป
https://www.youtube.com/watch?v=NPVT2lvMvOk
หลายครั้งตลอดอาชีพของผม มีกรณีที่บางอย่างพังแต่เงียบสนิทจนทุกคนตันไปหมด ไม่มี error output ไม่มีอะไรเลย
ในหลายกรณี สาเหตุก็คือไลบรารี third-party ระดับล่างไปทำ
catch (e) {}ไว้ ประสบการณ์ครั้งแรก ๆ ที่เจอเรื่องแบบนี้เป็นบทเรียนที่ดี และตอนนี้ผมไม่ปล่อยให้ข้อผิดพลาดไหนผ่านไปแบบมองข้ามอีกแล้ว อย่างน้อยก็ต้องล็อกไว้ซอฟต์แวร์ที่คุณเขียนวันนี้อาจถูกใช้งานในอีก 5 ปีข้างหน้า ในสภาพแวดล้อมที่คุณไม่เคยนึกถึงเลยก็ได้
30 ปีต่อมา:
/* X systems I modul body I 14.09.1990 */void xxvcda(int *addr, int sizeof)เขายังไม่รู้ด้วยซ้ำว่ามีฟีเจอร์ของภาษาที่ให้ยก exception ใหม่จากตัวก่อนหน้าเพื่อ รักษาบริบทของ stack trace ไว้ เป็นอะไรที่น่าสนุกดี อย่างน้อยนี่ไม่ใช่งานหลักของผม แต่งานหลักก็มีความสนุกในแบบของมันเหมือนกัน
DRF กลืน validation error แล้วคืนแค่ error ทั่วไปกลับมา จนไม่มีเบาะแสอะไรเลย สุดท้ายผมต้องไล่ลงไปเองพร้อมเพิ่ม logging เพื่อหาว่าเกิดอะไรขึ้น
เพื่อนนักฟิสิกส์คนหนึ่งชอบอ้างคำพูดของ Rutherford ที่ว่า “วิทยาศาสตร์ทั้งหมดล้วนเป็นฟิสิกส์ หรือไม่ก็เป็นการสะสมแสตมป์”
สิ่งที่เขาหมายถึงคือ ฟิสิกส์นั้นต่างจากคณิตศาสตร์หรือวิทยาการคอมพิวเตอร์ตรงที่มีวิธีถูกตรวจสอบได้ด้วย ความเป็นจริงทางกายภาพ
สาขาของเขาคือสนามแม่เหล็กสุดขั้ว เป็นการทดลองแบบทำขดลวดทองแดงขนาดมหึมา ปล่อยกระแสไฟจนมันแทบหลอมละลาย แล้วจุดระเบิดรอบขดลวดเพื่อทำให้สนามแม่เหล็กตรงกลางพุ่งขึ้นแรงที่สุดเท่าที่มนุษย์เคยสร้างได้ในช่วงเสี้ยววินาที ก่อนที่ทองแดงเหลวอุณหภูมิหลายพันองศาจะกระเด็นออกมาและอุปกรณ์ทั้งชุดถูกทำลาย
ในสภาพแวดล้อมการทำงานแบบนั้น ความผิดพลาดหรือการคำนวณพลาดหมายถึงคนอาจตายได้อย่างรวดเร็วและน่าสยดสยองมาก ดังนั้นเขาจึงไม่เห็นด้วยเวลานักศึกษาปริญญาเอกคณิตศาสตร์ที่ความเสียหายสูงสุดคือมีฝุ่นชอล์กติดเสื้อสเวตเตอร์ เรียกตัวเองว่าเป็นนักวิทยาศาสตร์
พูดอีกอย่างคือ เป็นความพยายามทำความเข้าใจพลวัตของสิ่งที่ศึกษา หรือไม่ก็แค่รวบรวมข้อเท็จจริงน่าสนใจและตั้งชื่อให้สิ่งที่สนใจเท่านั้น
สำหรับใครที่สนใจเส้นทางอาชีพซูเปอร์วายร้ายแต่ไม่รู้จะเริ่มตรงไหน EMP ของจริงก็ทำกันแบบนั้นแหละ
[1] https://en.m.wikipedia.org/wiki/Explosively_pumped_flux_comp...
พอเกิดเรื่องแบบนี้ขึ้น ก็มักอยากให้มี มาตรการแก้ไขที่ต้นน้ำ เสมอ ถ้ามี logging และการรายงานข้อผิดพลาดที่เหมาะสม ก็คงไม่ต้องใช้เวลาตั้งอาทิตย์กว่าจะแก้ได้
ไลบรารีที่ได้รับ MIME type
image/jpgผิด ๆ ควรจะโยน exception, crash ไปเลย หรืออย่างน้อยก็ทิ้ง log แบบชัดเจนมาก ๆ อยากรู้เหมือนกันว่าผู้เขียนต้นฉบับไปแจ้งบั๊กกับไลบรารีนั้นหรือยังเขามีสิทธิ์เข้าถึงเพื่อตรวจสอบหรือปฏิเสธได้ไหมว่ามีการอัปโหลดรูปเข้ามาที่เซิร์ฟเวอร์จริง ๆ? ทำไมในสภาพแวดล้อมทดสอบอัปโหลดได้ แต่ในแอปเวอร์ชันรีลีสกลับไม่ได้? แล้วสภาพแวดล้อมทดสอบต่างกันอย่างไร?
ในทางทฤษฎี Shawn ควรมีสิทธิ์เข้าถึงมากพอที่จะหาคำตอบได้ค่อนข้างเร็วว่า “อัปโหลดสำเร็จแล้วแต่ทำไมถึงไม่แสดงผล” ไม่ว่าจะเป็นการรันเซิร์ฟเวอร์เอง หรือขอความช่วยเหลือจากคนที่ช่วยวินิจฉัยได้ว่าทำไมการอัปโหลดถึงล้มเหลวแบบเงียบ ๆ
สำหรับผม บทเรียนที่สำคัญกว่าการที่ “MIME type ของรูปเป็น
jpgทั้งที่ควรเป็นjpeg” คือ เหตุใดมันถึงใช้ได้ใน test แต่ใช้ไม่ได้ใน production มากกว่า ตัวบั๊กเองยังไม่สำคัญเท่ากับเหตุผลที่สภาพแวดล้อมทำให้หาบั๊กได้ยากเคยมีกรณีหนึ่งที่แอปเดสก์ท็อปของผมทำงานผิดพลาดหนัก แต่ไม่มีข้อผิดพลาดถูกบันทึกลง log เลย หลายวันต่อมาถึงพบว่า file handle หมด และ log4net เองก็เขียน log ไม่ได้ถ้าขอ file handle ไม่สำเร็จ วิธีแก้เฉพาะหน้าคือย้อนการแก้บั๊กเล็ก ๆ ตัวหนึ่งกลับไป แต่การแก้จริงคือปรับแต่ง log4net ให้เปิดไฟล์ log ค้างไว้ตลอด แบบนั้นถึงแอปจะใช้ file handle หมด ก็ยังบันทึกข้อผิดพลาดได้
เป้าหมายไม่ใช่ความเงียบ นักพัฒนาหลายคนชอบคิดแบบนั้น แต่เป้าหมายที่แท้จริงคือ ความถูกต้องแม่นยำ ถ้าไม่มีข้อผิดพลาดก็ควรเงียบ แต่ถ้ามีข้อผิดพลาดที่กระทบผู้ใช้ ก็ควรมีกรอบเตือนสีแดงใหญ่ ๆ ขึ้นมา
ผมคิดว่านักพัฒนาควรเริ่มชอบข้อความ error ได้แล้ว ข้อความ error ที่เขียนดีจะช่วยชี้สาเหตุได้เร็ว และประหยัดเวลาของทุกคนไปมาก
ถ้านักพัฒนาคนนี้ได้เรียนรู้ว่าควรแสดงข้อความ error ให้บ่อยขึ้นในอนาคต ก็ถือเป็นผลลัพธ์ที่ดีมาก
ทำให้นึกถึงเพื่อนร่วมงานเก่าคนหนึ่งที่ชอบพูดว่า “เราไม่ได้กำลังสร้างระบบควบคุมการจราจรทางอากาศสักหน่อย” ซึ่งหมายถึง ต่อให้พลาดก็ไม่ถึงกับมีคนตาย
ตอนนั้นเรากำลังทำเกมกันอยู่ แต่จริง ๆ แล้วมันก็ใช้ได้กับแทบทุกแอป CRUD ที่ผมเคยเขียน
อีกเรื่องหนึ่งคือ ผมชอบถามหัวหน้าด้านเทคนิคระดับอาวุโสคนอื่น ๆ โดยเฉพาะระดับ Director, VP, CTO ว่า “ความผิดพลาดที่แพงที่สุดที่คุณเคยทำคืออะไร” ถ้าเป็นวิศวกรจูเนียร์ ผมแนะนำว่าอย่างน้อยควรถามคำถามนี้สักครั้งในชีวิตการทำงาน
ผู้นำสายเทคนิคระดับสูงหลายคนมีเรื่องเล่าระดับ หลักแสนถึงหลักล้านดอลลาร์ ได้หมด ผมเคยเห็นคนทำโปรเจกต์เสียหายไปหลายล้านดอลลาร์แล้วกลับได้เลื่อนตำแหน่งทันทีด้วยซ้ำ สิ่งสำคัญคือการเข้าใจว่าทำไมเรื่องแบบนั้นถึงเกิดขึ้นได้ และแม้แต่ทำไมมันถึงอาจเป็นเรื่องที่ดีก็ได้
ความหงุดหงิดจากเกมที่มีบั๊กอาจลุกลามไปเป็นการขับรถไล่บี้หรือการทะเลาะตะโกนด่ากันในชีวิตจริงได้ เคยมีคนฆ่าตัวตายเพราะคอมพิวเตอร์ส่งบิลผิดมาแล้ว ซอฟต์แวร์ก็เคยทำบริษัทล่มเพราะทำข้อมูลสำคัญหาย
ผู้คนเคยถูกฆาตกรรมเพราะแอปโซเชียลมีเดียที่ดูเหมือนไม่สำคัญ และ Twitter ก็เคยถูกใช้จัดตั้งการปลุกระดมเพื่อการสังหารหมู่ เคยมีคนถูกสะกดรอยและทำร้ายจากข้อมูลที่ Pokemon Go รั่วออกไปด้วย
ซอฟต์แวร์มีพลังในโลกจริง ถ้าไม่จริงก็คงไม่มีเหตุผลให้ต้องเขียนซอฟต์แวร์ด้วยซ้ำ
ผมเคยสร้างซอฟต์แวร์ที่อาจทำข้อมูลสำคัญสูญหายได้ และตอนนี้ก็กำลังสร้างซอฟต์แวร์ที่ถ้าทำงานผิดพลาดอาจทำให้น้ำท่วมได้
เราควรภูมิใจกับงานของตัวเองให้มากกว่านี้หน่อย
ในฐานะวิศวกรซอฟต์แวร์ ฉันค่อนข้างชอบการดีบัก เพราะมันทำให้ได้ใช้ทักษะและวิธีคิดที่ต่างจากการออกแบบและลงมือพัฒนา
แน่นอนว่านี่ไม่ได้หมายความว่าการดีบักไม่สร้างความเครียด ตอนพัฒนาซอฟต์แวร์สำหรับตู้สลับสายโทรศัพท์ 5ESS ของ AT&T มีเดโมอยู่ครั้งหนึ่ง และในห้องแล็บทดสอบมีสายโทรศัพท์ที่ตั้งไว้สำหรับฟีเจอร์ของเราเพียงเส้นเดียว
ไม่ว่าจะลองกี่ครั้งซอฟต์แวร์ก็ไม่ทำงาน ทั้งที่ฉันมั่นใจว่าซอฟต์แวร์ไม่มีปัญหา จึงเครียดกับการไล่เช็กทุกอย่างที่เป็นไปได้ สุดท้ายพอให้ช่างแล็บช่วยตรวจวงจร ก็พบว่าสายเส้นเดียวที่ถูกตั้งค่าไว้ดัน ถูกถอดออก. เป็นปัญหาฮาร์ดแวร์โง่ ๆ เอง
การดีบักระบบกระจายบนคลาวด์นั้นเลวร้ายกว่ามากแบบทวีคูณ เมื่อเทียบกับตอนที่สามารถรันทุกบริการบนเครื่องโลคัลได้ และแม้แต่ระบบกระจายบนเครื่องโลคัลนั้นก็ยังแย่กว่าการดีบักปัญหาได้ภายในโปรแกรมเดียวมาก
ดีบักเกอร์จริง ๆ ก็ช่วยให้การดีบักดีขึ้นมากเช่นกัน ฉันไม่เคยเข้าใจคนที่ยึดติดว่าจะใช้แค่
printfdebugging หรือดีบักเกอร์จริงอย่างใดอย่างหนึ่ง ทั้งที่ใช้ทั้งคู่แล้วได้ประโยชน์มหาศาล และถ้ามีระบบ trace ที่ดีก็ยังดีกว่าprintfdebugging มากด้วย จึงควรพูดถึงไว้ตรงนี้ช่วงแรก ๆ ของการเขียนโปรแกรม ฉันมักใส่อารมณ์ที่ไม่จำเป็นลงไปกับสภาวะที่ยังไม่รู้ว่าเกิดอะไรขึ้น แต่ต่อมาก็ค่อย ๆ ยอมรับวงจรแบบ “เดี๋ยวนะ ทำไมเป็นแบบนี้? ไม่รู้สิ... อ้อ เดี๋ยว... ว้าว ที่มันไม่ทำงานนี่มีเหตุผลสมเหตุสมผลจริง ๆ!” และก็ซึมซับได้ว่าถ้าไปจนสุดทางแล้วจะรู้สึกดี
ตอนนี้ สภาวะไม่รู้นั้นจะพังได้ก็เพราะความคาดหวังและพฤติกรรมของคนอื่นเท่านั้น เมื่อเวลาผ่านไป ฉันได้เรียนรู้ว่าต้องจัดการเรื่องการเลือกภาษา การเลือกสถาปัตยกรรม ฯลฯ อย่างเด็ดขาด เพื่อให้กระบวนการนี้ง่ายและเร็ว
ในช่วงนี้ของอาชีพ การโน้มน้าวล่วงหน้าว่า AWS Lambda เป็นตัวเลือกที่ไม่ดีในแง่ประสิทธิภาพ ต้นทุนรวม ความสามารถในการดีบัก และความเร็วในการพัฒนา นั้นง่ายกว่ามาก เมื่อเทียบกับการต้องมาอธิบายทีหลังว่าทำไมการแก้ปัญหาแค่เรื่องเดียวถึงใช้เวลานานขนาดนั้น
ฉันขำตอนท้ายมาก เมื่อวานนี้เอง ฉันเพิ่งแก้ปัญหาที่หลอกหลอนบริษัทมา 3 ปีได้ และต้นเหตุของเราคือตัวอักษร A
ตลอด 3 ปีที่ผ่านมา มีคนคนหนึ่งคอยแก้ข้อมูลเข้าออกแบบแมนนวล และมันก็กลายเป็นส่วนหนึ่งของงานเขาไปแล้ว ถึงขั้นตั้งนัดซ้ำในปฏิทินไว้สำหรับการเก็บกวาดเป็นประจำ
ลูกค้านับล้านต้องพึ่งคนคนนี้เพื่อให้แพ็กเกจข้อมูลมือถือของตัวเองถูกใช้กับสายโทรศัพท์อย่างถูกต้อง
คุณคงจินตนาการได้ว่าถ้าเขาลืมหรือไปพักร้อนจะวุ่นวายแค่ไหน
ท้ายที่สุด สาเหตุมาจาก
if $line->status == STATUS_ACTIVEโดยฝั่งหนึ่งเป็นActiveแต่อีกฝั่งเป็นactiveสุนัขไม่ได้รับบาดเจ็บ แต่เงินจำนวนประเมินไม่ได้หายไปหลายปีคนที่น่าสงสารคนนั้นไม่ใช่คนที่ขาดไม่ได้อีกต่อไปแล้ว ก็พูดเล่นครึ่งหนึ่งนั่นแหละ ซอฟต์แวร์มีไว้เพื่อทำให้งานมีประสิทธิภาพขึ้น แต่ก็ควรมองแรงจูงใจของมนุษย์ด้วย
ฉันเคยเจ็บปวดมากเป็นพิเศษตอนกรอกฟิลด์ HL7 บน Mac ดูเหมือนว่าอักขระ
’ที่พิมพ์จากคีย์บอร์ด Mac จะไม่เข้ากันกับ HL7 ทุกเวอร์ชัน หรือไม่ก็ไม่ตรงกับปลายทางที่ HL7 ถูกส่งต่อไปแม้จะเป็นความทรงจำเก่าแล้ว แต่ความต่างของคำอย่าง
o’clockกับo′clockก็เคยทำให้การกระจายรายงานรังสีวิทยาพัง และเป็นอยู่นานหลายปีกว่าจะจับได้HN แสดง
’ต่างจากที่ฉันพิมพ์ แต่ก็ยังเป็นอักขระตัวเดิมอยู่ดี ปัญหาครึ่งหนึ่งตอนดีบักคือมองไม่เห็นความต่างนี่แหละ เลยยิ่งตลกเข้าไปใหญ่STATUS_ACTIVEถูกนิยามผิดอย่างนั้นหรือ?มีความเสี่ยงเสมอที่ใครสักคนจะ “หวังดี” แก้คำสะกดผิด
refererในHttpHeader::REFERRERให้เป็นreferrerแต่คำสะกดผิดนั้นถูกตรึงไว้ในมาตรฐาน HTTP แล้ว ดังนั้นถ้าทำแบบนั้นซอฟต์แวร์จะพังหมด ความรับผิดชอบตกเป็นของ Phillip Hallam-Baker สมัยอยู่ CERNเรื่องรังแตนฟังดูไม่ใช่เรื่องไกลตัวเลย
ผู้ให้เช่าอาคารสำนักงานของเราได้ติดตั้งอินเทอร์เฟซหน้าจอสัมผัสไว้นอกอาคาร เพื่อให้โทรเข้าแต่ละแผนกต้อนรับและให้คนข้างในเปิดประตูได้ เหตุผลคือไม่มีพนักงานต้อนรับที่มองเห็นประตูได้โดยตรง
อุปกรณ์นั้นอยู่ได้ 6 เดือนก่อนจะเริ่มทำงานผิดปกติอย่างหนัก สาเหตุคือพวกเขาติดตั้งอินเทอร์เฟซซึ่งโดยพื้นฐานแล้วเป็นแท็บเล็ต Android สีดำขนาดใหญ่ไว้ที่ด้านตะวันออกของอาคาร
พอเข้าช่วงกลางฤดูใบไม้ผลิ มันก็รับแดดเต็ม ๆ ทุกวันจนร้อนเกินไป ทำให้อุปกรณ์สัมผัสและฮาร์ดแวร์หน้าจอบางส่วนเสียหาย
ในซอฟต์แวร์แบบที่ฉันทำ ปกติไม่ต้องกังวลเรื่อง ภาระความร้อน
บริษัทรถไฟโพสต์บน Twitter ว่า “มีความแออัดรุนแรงบนเส้นทางที่ผ่าน Lewisham เพราะปัญหาในการออกรถอันเกิดจากแสงแดดจ้า”
พวกเขายังบอกด้วยว่าแสงอาทิตย์ฤดูหนาวที่อยู่ต่ำส่องใส่จอมอนิเตอร์สำหรับการออกรถจนคนขับมองไม่เห็น
ข้อความที่ว่า “ในที่สุดก็แก้ได้แล้ว เพราะตัวอักษร ‘E’” นี่ขำดี
บั๊กที่เรียบง่ายและเล็กที่สุดมักจะกลายเป็นสิ่งที่หายากที่สุดในการตามเจอ เช้าวันนี้ฉันก็เพิ่งเสียเวลาไปชั่วโมงสองชั่วโมงกับการหา off-by-one error
ต้นเหตุมาจาก
index + 1ตัวเดียวที่ลืมแก้ตอนรีแฟกเตอร์