Splync v1.5 — ปรับอัตราการแบ่งได้ตามโครงการและประเภท

เมื่อวันที่ 16 กันยายน 2025 Splync v1.5 ได้เปิดตัว — เพียงสี่วันหลังจากที่การสมรสระหว่างประเทศของเราได้รับการยอมรับในเมือง จนถึงการอัปเดตนี้ Splync ไม่สามารถปรับอัตราการแบ่งได้เลย แต่ละค่าใช้จ่ายถูกแบ่งเท่าๆ กันตามค่าเริ่มต้น ด้วย v1.5 ผู้ใช้สามารถตั้งค่าอัตราการแบ่งที่กำหนดเองทั้งตามโครงการและประเภทได้ การเปลี่ยนแปลงนี้ช่วยให้คู่รักและเพื่อนสามารถแบ่งค่าใช้จ่ายร่วมกันในวิธีที่สะท้อนชีวิตจริงมากขึ้น ไม่ใช่แค่ 50:50 ง่ายๆ คุณสามารถเริ่มโครงการบัญชีใหม่ด้วยการแบ่ง 60:40 สำหรับค่าใช้จ่ายประจำวันในเดือนตุลาคม ขณะที่ค่าเช่าอพาร์ทเมนต์ยังคงแบ่งเท่าๆ กันที่ 50:50 ถ้าเป็นเช่นนั้นเหมาะสมสำหรับคุณทั้งสองคน และถ้าค่าอาหารดูสมดุลที่ 70:30 ขณะที่ค่าบริการสาธารณูปโภคดูเหมาะสมที่ 62:38 คุณสามารถกำหนดอัตราเหล่านั้นแยกกันได้ตามประเภทภายในโครงการเดียวกัน

การเปลี่ยนแปลงที่เห็นได้ชัดที่สุดใน v1.5 คือส่วน Member & Default Shares ใหม่ ซึ่งคุณสามารถเพิ่มสมาชิกโครงการและกำหนดส่วนแบ่งค่าเริ่มต้นให้แต่ละคนได้ ถ้าโครงการมีสองสมาชิก อัตราส่วนอาจเป็น 50:50, 40:60 หรืออะไรก็ได้ที่รู้สึกเหมาะสมกัน ถ้ามีสามสมาชิก อาจเป็น 33.33:33.33:33.34, 50:25:25 หรือการผสมผสานใดก็ได้ที่คุณต้องการ นี่จะกลายเป็นการแบ่งค่าเริ่มต้นของโครงการ ด้านล่างคุณสามารถเลื่อนลงเพื่อปรับส่วนแบ่งของแต่ละประเภทได้หากคุณต้องการให้แตกต่างจากค่าเริ่มต้นของโครงการ เมื่อคุณกำหนดอัตราการแบ่งที่กำหนดเองให้ประเภท เครื่องหมายอัตราสีน้ำเงินจะเปลี่ยนเป็นสีส้ม — เป็นสัญญาณเล็กๆ ว่าประเภทนั้นใช้กฎของตัวเองไม่ใช่ของโครงการทั้งหมด การเปลี่ยนแปลงนี้เพิ่มความยืดหยุ่นให้กับการตั้งค่าโครงการมากขึ้น แต่มันก็ทำให้มุมมองการสร้าง/แก้ไขโครงการซับซ้อนขึ้นเล็กน้อย เพื่อช่วยในเรื่องนี้ ฉันได้เพิ่มปุ่มข้อมูลในแต่ละส่วน คุณสามารถแตะเพื่อดูผู้ช่วยถามตอบเล็กๆ ได้

การดำเนินการเปลี่ยนแปลงนี้ซับซ้อนกว่าที่คาดไว้ Splync เคยคิดว่าโลกมันเป็น 50:50 ที่ชัดเจน — มีเพียงตัวเลขเดียวที่ใช้ทั่วไปและการคำนวณก็เสร็จสิ้น เมื่อฉันตัดสินใจสนับสนุนอัตราการแบ่งที่กำหนดเอง โครงสร้างภายในทั้งหมดต้องคิดใหม่ โครงการไม่สามารถพึ่งพาร้อยละที่แชร์ได้เพียงหนึ่งเดียว แต่ละประเภทจำเป็นต้องมีอัตราของตัวเอง และทุกค่าใช้จ่ายต้องอ้างอิงทั้งค่าเริ่มต้นของโครงการและการยกเว้นที่ระดับประเภท เพื่อให้มันทำงานได้ ฉันต้องเขียนลอจิกการคำนวณใหม่ทั้งหมด ทุกค่าใช้จ่ายขณะนี้มีต้นไม้การตัดสินใจเล็กๆ: “หมวดหมู่นี้มีอัตราของตัวเองหรือไม่? ถ้าใช่ ใช้อัตรานั้น ถ้าไม่ ให้กลับไปใช้อัตราของโครงการ” ฟังดูเรียบง่ายเมื่ออธิบาย แต่การรักษารูปแบบข้อมูลให้สอดคล้องทั่วแอป — iOS views, FastAPI backend และ MariaDB schemas — ต้องการการปรับจูนอย่างระมัดระวังมากกว่าที่คิด

การอัปเดตใดๆ ที่เกี่ยวข้องกับเซิร์ฟเวอร์ต้องจัดการอย่างระมัดระวังที่สุด หากคุณแก้ไขโค้ดเซิร์ฟเวอร์ที่มีอยู่ผิดพลาด ผู้ใช้ที่ยังอยู่บน v1.4 จะพบกับบั๊กหรือข้อผิดพลาดของระบบทันที ตัวอย่างเช่น โปรแกรมเซิร์ฟเวอร์สำหรับ v1.5 คาดหวังการตั้งค่าโครงการที่จะรวมถึงข้อมูลอัตราส่วน แต่แอปลิเคชัน v1.4 ส่งการตั้งค่าโครงการโดยไม่มีอัตราส่วนเลย พอเวอร์ชันสองเวอร์ชันนั้นพยายามสื่อสารกัน การร้องขอล้มเหลว — เพียงเพราะพวกเขาพูด “ภาษา” ที่แตกต่างกันเล็กน้อย ผู้พัฒนาสามารถทำการเปลี่ยนแปลงอย่างปลอดภัยในสภาพแวดล้อมทดสอบได้ ส่วนที่ยากเริ่มขึ้นหลังจากส่งเวอร์ชันใหม่ให้ Apple ตรวจสอบ ขณะที่ผู้ใช้ยังอยู่บน v1.4 ในช่วงเวลาทั้งหมดจากการส่งจนถึงการเปิดตัว เซิร์ฟเวอร์ต้องรองรับทั้งสองเวอร์ชันพร้อมกัน เพื่อให้ผู้ตรวจสอบของ Apple สามารถทดสอบ v1.5 และผู้ใช้เดิมสามารถใช้ v1.4 ต่อไปได้โดยไม่มีการขัดจังหวะ

ในการพัฒนาแอป “endpoint” คือที่ที่แอปส่งคำขอไปยังเซิร์ฟเวอร์ — คล้ายกับเคาน์เตอร์เฉพาะในศาลาว่าการเมือง หนึ่งเคาน์เตอร์จัดการการสมรส อีกเคาน์เตอร์จัดการบันทึกผู้อยู่อาศัย และอีกเคาน์เตอร์จัดการหนังสือเดินทาง แอปทำงานเหมือนกัน: แต่ละ endpoint เป็นหน้าต่างเฉพาะที่เซิร์ฟเวอร์รับคำขอแบบเฉพาะ เช่น ล็อกอิน สร้างโครงการ แก้ไขค่าใช้จ่าย คำขอเป็นเพื่อน ฯลฯ เมื่อ Splync v1.4 ส่งคำขอ มันไปยัง “หน้าต่าง” เก่าที่เข้าใจรูปแบบเก่า Splync v1.5 ส่งคำขอไปยัง “หน้าต่าง” ใหม่ที่เข้าใจข้อมูลอัตราส่วน ถ้าเซิร์ฟเวอร์ปิดหน้าต่างเก่าเร็วเกินไป ผู้ใช้ v1.4 จะไม่สามารถ “ส่ง” ข้อมูลของพวกเขาได้ นั่นเป็นเหตุผลที่ในระหว่างการอัปเดต เซิร์ฟเวอร์ต้องเปิดทั้งสองหน้าต่าง — ทั้งสอง endpoints — จนกว่าผู้ใช้ทุกคนจะย้ายไปยังเวอร์ชันใหม่ได้อย่างปลอดภัย จริงๆ แล้วการจัดการหน้าต่างทั้งสองพร้อมกันนั้นให้ความรู้สึกเหมือนการคิดในมิติพิเศษ

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