Steven
Steven2 นาทีที่อ่าน

เวอร์ชัน 2 จริง ๆ แล้วต้องแลกด้วยอะไร: 206 คอมมิตแห่งสถานะที่ซื่อสัตย์

GeekBye v2 ไม่ใช่การปล่อยฟีเจอร์ มันคือ 206 คอมมิตที่เล็งไปยังความคิดเดียว: แอปไม่ควรโกหกเกี่ยวกับสถานะของตัวเองเลย นี่คือราคาที่ต้องจ่าย — รวมถึงความผิดพลาดในไฟล์ล็อกเพียงบรรทัดเดียวที่เกือบทำให้เราส่งอะไรออกไปไม่ได้เลย

ความน่าเชื่อถือ
วิศวกรรม
การปล่อยเวอร์ชัน
การปล่อยเวอร์ชัน GeekBye
เวอร์ชัน 2 จริง ๆ แล้วต้องแลกด้วยอะไร: 206 คอมมิตแห่งสถานะที่ซื่อสัตย์

การปล่อย "เวอร์ชัน 2" ส่วนใหญ่คือกองฟีเจอร์ใหม่ที่ติดตัวเลขใหญ่ขึ้น GeekBye v2 กลับตรงกันข้าม มันแทบไม่ได้ส่งความสามารถใหม่ที่ผู้ใช้เห็นเลย 206 คอมมิตของมันเล็งไปที่ความคิดเดียวที่ไม่หวือหวา:

แอปไม่ควรแสดงสถานะที่ไม่เป็นจริงให้คุณเห็น

ฟังดูเป็นเรื่องธรรมดา จนกว่าคุณจะนับดูว่าแอปเดสก์ท็อปมีวิธีโกหกเงียบ ๆ ได้กี่แบบ มันขึ้นเครื่องหมายถูกให้การอัปโหลดที่ยังส่งไม่เสร็จ มันบอกว่า "เชื่อมต่อแล้ว" บนซ็อกเก็ตที่ตายไปเมื่อนาทีที่แล้ว มันเงียบขณะที่บันทึกการถอดเสียงของคุณกำลังหล่นหายไปกับพื้น ทั้งหมดนี้ไม่ใช่การแครช มันแย่กว่าการแครช เพราะแอปดูปกติดีทั้งที่ผิด — และคุณจะรู้ก็ต่อเมื่อสายไปแล้ว ตอนที่การบันทึกที่คุณต้องการไม่อยู่ตรงนั้น

v2 คือการปล่อยเวอร์ชันที่เราออกไปล่าคำโกหกเล็ก ๆ พวกนั้นทีละอัน

คำโกหกที่เราเกลียดที่สุด: การอัปโหลดที่ "สำเร็จ"

GeekBye สามารถสำรองการบันทึกของคุณขึ้น Google Drive ได้ ใน v1 การเชื่อมต่อไปยัง Drive ถูกมองเป็นรายละเอียดเบื้องหลัง — ถ้าได้ก็ดี ถ้าไม่ได้ ความล้มเหลวนั้นก็มองไม่เห็นเสียส่วนใหญ่ แอปจะเดินหน้าต่อโดยดูเหมือนยังเชื่อมต่ออยู่ คุณจะคิดว่าการบันทึกของคุณปลอดภัย บางครั้งมันก็ไม่

v2 สร้างส่วนนี้ขึ้นใหม่รอบ ๆ สถานะการเชื่อมต่อที่ซื่อสัตย์ ตอนนี้ Drive อยู่ในหนึ่งในไม่กี่สถานะที่ชัดเจนและเป็นจริงเสมอ — เชื่อมต่อแล้ว กำลังเชื่อมต่อใหม่ ตัดการเชื่อมต่อ — และแอปจะกระจายทุกการเปลี่ยนสถานะนั้นไปทั่วทั้งหน้าจอในทันทีที่มันเกิดขึ้น เมื่อการเชื่อมต่อล่ม แบนเนอร์การเชื่อมต่อใหม่แบบทั่วทั้งแอป จะบอกคุณทุกที่อย่างตรงไปตรงมา แอปไม่แสร้งว่าการอัปโหลดสำเร็จอีกต่อไปเมื่อมันไม่สำเร็จ ถ้าการสำรองข้อมูลของคุณเกิดขึ้นตอนนี้ไม่ได้ คุณจะรู้เดี๋ยวนี้ — ไม่ใช่สัปดาห์หน้าตอนที่คุณไปหาไฟล์นั้น

เบื้องล่างนี่คือสถาปัตยกรรมเล็ก ๆ ไม่ใช่สโลแกน: แหล่งความจริงเดียวสำหรับการเชื่อมต่อ เหตุการณ์ที่กระจายออกไปยังทุกส่วนของ UI เมื่อมันเปลี่ยน และแบนเนอร์ที่อ่านจากสถานะนั้นโดยตรง ไม่มีเส้นทางไหนที่การเชื่อมต่อล่มแล้ว UI ดูเหมือนยังต่ออยู่ เพราะทั้งสองอ่านจากข้อเท็จจริงเดียวกัน

คำโกหกของการบันทึกที่หายไป

การแก้เรื่องความซื่อสัตย์ใหญ่ ๆ อันที่สองคือ การกู้คืนการบันทึก การถอดเสียงแบบเรียลไทม์ต้องการการเชื่อมต่อที่มีชีวิต ใน v1 ถ้าการเชื่อมต่อนั้นสะดุดกลางคัน — Wi-Fi กระพริบ ผ่านอุโมงค์ VPN เชื่อมต่อใหม่ — เสียงในช่วงที่ขาดหายไปนั้นอาจหายไปดื้อ ๆ บันทึกการถอดเสียงจะมีรูโหว่ และไม่มีอะไรบอกคุณ

v2 เปลี่ยนสัญญา: เสียงถูก เก็บไว้ในเครื่องระหว่างช่วงที่การเชื่อมต่อขาดหาย และนำมากระทบยอดในภายหลัง เมื่อลิงก์หลุด GeekBye จะเก็บเสียงไว้อย่างปลอดภัยบนเครื่องของคุณ เมื่อมันกลับมา เสียงที่บัฟเฟอร์ไว้นั้นจะถูกส่งและเย็บกลับเข้าไปในบันทึกการถอดเสียงในตำแหน่งที่ถูกต้อง เน็ตแย่สามสิบวินาทีจะไม่ทำให้คุณเสียการประชุมสามสิบวินาทีอีกต่อไป นี่คือฐานรากที่การปล่อยเวอร์ชันด้านความน่าเชื่อถือรุ่นหลัง ๆ สร้างต่อยอดโดยตรง — กลไกเชื่อมต่อใหม่และบัฟเฟอร์ในทำไมแอปจดบันทึก AI ของคุณถึงหยุดเมื่อ Wi-Fi แย่ ก็คือความคิดเดียวกัน ที่ถูกทำให้แกร่งขึ้น

คำโกหกของพายุป็อปอัป

มีความไม่ซื่อสัตย์ที่แนบเนียนกว่าในวิธีที่แอปรายงานปัญหา: มันรายงานมากเกินไป ช่วงเน็ตไม่เสถียรครั้งเดียวสามารถจุดชนวนข้อผิดพลาดเดียวกันได้ห้าครั้ง แล้วจู่ ๆ คุณก็มีกองการแจ้งเตือนสีแดงเหมือนกันเป๊ะ ทับข้อความหนึ่งเดียวที่สำคัญไว้ นั่นก็ไม่ซื่อสัตย์เช่นกัน — มันคือสัญญาณรบกวนที่แสร้งเป็นข้อมูล

ดังนั้น v2 จึงเพิ่ม การจำกัดอัตราการแจ้งเตือนแบบผูกกับหมวดหมู่ และการส่งต่อข้อผิดพลาด ข้อผิดพลาดถูกจัดกลุ่มตามสิ่งที่มันเป็นจริง ๆ และแต่ละหมวดถูกจำกัดอัตรา เพื่อให้ปัญหาต้นเหตุเดียวสร้างข้อความชัดเจนหนึ่งข้อความ ไม่ใช่ระดมยิงเป็นชุด ปัญหาการจำกัดอัตราถูกส่งไปยังข้อความการจำกัดอัตรา ปัญหาการเชื่อมต่อถูกส่งไปยังข้อความการเชื่อมต่อ แอปบอกคุณว่า อะไรจริง เพียงครั้งเดียว — วินัยเดียวกันที่ต่อมาป้องกันไม่ให้ 429 ปลอมตัวเป็นการล็อกเอาต์ในวันที่แอปของเรา DDoS ตัวเอง

ตัวเลข 206 นั่นแหละคือประเด็น

สถานะที่ซื่อสัตย์ แบนเนอร์เชื่อมต่อใหม่ การกู้คืนการบันทึก การส่งต่อการแจ้งเตือน — นั่นคือสี่ความคิด แต่การปล่อยเวอร์ชันนี้มี 206 คอมมิต ที่เหลือหายไปไหน?

หายเข้าไปในหางยาว ๆ ที่ไม่หวือหวา ซึ่ง "อย่าแสดงสถานะเท็จเลย" ต้องการจริง ๆ ทุกจุดที่ UI เก่าอาจหลุดออกจากความเป็นจริงได้ ต้องถูกค้นหาและเดินสายใหม่ให้อ่านจากความจริงแทนสำเนาที่เก่าค้าง ทุกเส้นทางการเชื่อมต่อใหม่ต้องถูกทำให้อัปเดตสถานะที่ใช้ร่วมกัน แทนที่จะเดาเอาเองในเครื่อง การแก้ความน่าเชื่อถือเล็ก ๆ หลายสิบจุดทั่วทั้งการบันทึก การถอดเสียง และการอัปโหลด — แต่ละจุดปิดช่องว่างเฉพาะที่แอปเคยดูถูกทั้งที่ผิด

นี่คือราคาของ "เวอร์ชัน 2" ที่แท้จริง เมื่อเป้าหมายคือความไว้วางใจแทนฟีเจอร์ ไม่มีคอมมิตพาดหัวเดียว มีแต่ 206 คอมมิตเล็ก ๆ และการปล่อยเวอร์ชันนี้ รู้สึก เหมือนเป็นสิ่งเดียว — ความสงบ — ก็เพราะทั้ง 206 คอมมิตดึงไปในทิศทางเดียวกัน

การปล่อยเวอร์ชันนี้เกือบไม่ได้ออก

นี่คือเรื่องเล่าสมรภูมิ และเป็นเรื่องที่ดีด้วย เพราะมันเกี่ยวกับแอปของ เราเอง ที่โกหก เรา

เมื่อคุณตัดปล่อยเวอร์ชัน สคริปต์อัปเวอร์ชันจะประทับเลขใหม่ไปทั่วทั้งโปรเจกต์ ใน v2.0.0 มันอัปเดตเวอร์ชันของแอป — แต่ package-lock.json ซึ่งเป็นบัญชีแยกประเภทของ dependency ที่แม่นยำของ npm กลับถูกทิ้งไว้ให้ชี้ไปยังเวอร์ชัน เก่า คือ 1.9.0 ในเครื่องทุกอย่างปกติดี ไม่มีใครลง dependency ใหม่แค่เพื่อจะบิลด์ แต่ CI รัน npm ci และงานทั้งหมดของ npm ci คือ ปฏิเสธที่จะไปต่อถ้าไฟล์ล็อกไม่ตรงกับ manifest มันเป็นฟีเจอร์ความเข้มงวด — และมันทำสิ่งที่มันควรทำเป๊ะ ด้วยการทำให้การบิลด์ของการปล่อยเวอร์ชันครั้งใหญ่ที่สุดที่เราเคยตัดล้มเหลว

จากนั้นปัญหาที่สองที่เจ้าเล่ห์กว่าก็โผล่ขึ้นมาข้างใต้ npm เวอร์ชันใหม่กว่าได้ ตัด dependency แบบ transitive ที่เป็นตัวเลือกทิ้ง — แพ็กเกจ encoding ที่ node-fetch ดึงเข้ามา — ออกจากไฟล์ล็อกโดยถือว่าไม่จำเป็น เว้นแต่การติดตั้งแบบสะอาดของ CI เรา ต้องการ มัน การติดตั้งจึงพังในแบบที่ไม่เกี่ยวอะไรกับโค้ดของเราเลย และเกี่ยวทั้งหมดกับบัญชีที่ผิดไปอย่างแนบเนียน

ทั้งสองเป็นการแก้เพียงบรรทัดเดียว: ซิงก์ไฟล์ล็อกกลับให้ตรงกับเวอร์ชันจริง กู้คืนรายการที่ถูกตัดทิ้ง ทั้งสองยังเป็นตัวอย่างที่สมบูรณ์แบบและทำให้ถ่อมตัวของสิ่งที่ v2 พูดถึงพอดี — สถานะที่อ้างว่าเป็นจริงแต่ไม่จริง ไฟล์ล็อกควรเป็นบันทึกที่ซื่อสัตย์ว่าแอปพึ่งพาอะไร เมื่อมันเลื่อนออกจากความเป็นจริง การบิลด์ก็ทำสิ่งที่แอปของเราทำเพื่อผู้ใช้ตอนนี้เป๊ะ ๆ: มันปฏิเสธที่จะแสร้งว่าทุกอย่างเรียบร้อยดี กลายเป็นว่าการส่งมอบการปล่อยเวอร์ชันด้านความน่าเชื่อถือ ก็คือปัญหาความน่าเชื่อถือลงไปจนถึงก้นบึ้ง

สามสิ่งที่ v2 สอนเรา

  1. ความล้มเหลวที่อันตรายคือความล้มเหลวที่เงียบงัน การแครชประกาศตัวเอง แต่ "เชื่อมต่อแล้ว" ปลอม ๆ การอัปโหลดสำเร็จลวงตา บันทึกการถอดเสียงที่มีรูโหว่มองไม่เห็น — สิ่งเหล่านี้ทำให้คุณเสียความไว้วางใจ ก็เพราะไม่มีอะไรดูผิดปกติเลย จงล่าคำโกหกเงียบ ๆ
  2. ความซื่อสัตย์คือสถาปัตยกรรม ไม่ใช่ข้อความ คุณไม่สามารถแปะ "พูดความจริง" ลงบน UI เป็นแบนเนอร์ได้ แบนเนอร์ต้องอ่านจากแหล่งความจริงเดียวกันกับทุกสิ่งที่เหลือ ไม่เช่นนั้นมันจะกลายเป็นอีกสิ่งหนึ่งที่ผิดได้ ข้อเท็จจริงเดียว กระจายออกไป — อย่ามีสำเนาสองชุดที่ขัดแย้งกันได้เด็ดขาด
  3. เวอร์ชัน 2 ที่คู่ควรกับเลขนั้น ส่วนใหญ่มองไม่เห็น ถ้า v2 ของคุณคือรายการฟีเจอร์ มันก็คือ v1.5 ที่มีการตลาด v2 ที่แท้จริงคือ 206 คอมมิตที่ไม่มีใครชี้ทีละอันได้ รวมกันเป็นผลิตภัณฑ์ที่แค่หยุดโกหกคุณ

GeekBye v2.0.0 คือฐานรากที่การปล่อยเวอร์ชันทุกครั้งตั้งแต่นั้นสร้างต่อยอด สำหรับสิ่งที่ฐานรากนั้นแบกรับ ดูทำไมแอปจดบันทึก AI ของคุณถึงหยุดเมื่อ Wi-Fi แย่, วันที่แอปของเรา DDoS ตัวเอง(v2.0.1) และการถอดเสียงสดเมื่อไฟร์วอลล์บล็อก WebSocket(v2.0.8) สำหรับความสงบที่ทั้งหมดนี้รับใช้อยู่ ดูมีอะไรใหม่ใน GeekBye v2

บทความที่เกี่ยวข้อง

วันที่แอปของเรายิง DDoS ใส่ตัวเอง
Steven
Steven2 นาทีที่อ่าน

วันที่แอปของเรายิง DDoS ใส่ตัวเอง

กองงานอัปโหลดที่ค้างอยู่ ถูกปล่อยออกมาทีเดียวทั้งหมดตอนเปิดแอป กลายเป็นการเปลี่ยนทุก client ของ GeekBye ให้เป็นการโจมตีแบบ denial-of-service เล็กๆ ใส่เซิร์ฟเวอร์ของเราเอง วิธีแก้ — และบันได connection-liveness ที่มันบังคับให้เราต้องสร้าง — เป็นหนึ่งในสิ่งที่มีประโยชน์ที่สุดที่ v2 สอนเรา

ความน่าเชื่อถือ
เครือข่าย
วิศวกรรม
เมื่อไฟร์วอลล์บล็อก WebSocket แล้วการถอดเสียงเรียลไทม์จะเป็นยังไง
Steven
Steven3 นาทีที่อ่าน

เมื่อไฟร์วอลล์บล็อก WebSocket แล้วการถอดเสียงเรียลไทม์จะเป็นยังไง

เครือข่ายองค์กรชอบปล่อย HTTPS ให้ผ่าน แต่แอบฆ่า WebSocket upgrade ทิ้งเงียบๆ ซึ่งทำให้การถอดเสียงเรียลไทม์พังแบบไร้เสียง GeekBye v2.0.8 จะ fall back ไปยัง transport แบบ HTTPS ล้วนโดยอัตโนมัติ — และระหว่างที่ทำมันออกมา เราก็เจอบั๊กที่จะทำให้ทั้งฟีเจอร์นี้ไร้ประโยชน์ไปเลย

ถอดเสียง
เครือข่าย
วิศวกรรม
ทำไมการบันทึกหน้าจอถึงจับมอนิเตอร์ผิดตัว (และวิธีที่เราแก้)
Steven
Steven2 นาทีที่อ่าน

ทำไมการบันทึกหน้าจอถึงจับมอนิเตอร์ผิดตัว (และวิธีที่เราแก้)

บนเครื่องที่ต่อสองจอ GeekBye บันทึกและแคปหน้าจอหลักเสมอ ไม่ว่าคุณจะทำงานอยู่บนจอไหน การแก้คือฟังก์ชันเล็กๆ ตัวเดียว — แต่เวอร์ชันแรกของมันผิด และ code review จับได้ว่าทำไม

บันทึกหน้าจอ
หลายจอ
วิศวกรรม