𝗦𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗧𝗿𝗮𝗱𝗲𝗼𝗳𝗳𝘀

ทุกการตัดสินใจในการออกแบบคือการปิดโอกาสในทางเลือกอื่น ซอฟต์แวร์ทำงานอยู่บนพื้นฐานของการแลกเปลี่ยน (trade-offs) คุณต้องตัดสินใจเลือกสิ่งเหล่านี้อย่างมีจุดมุ่งหมาย มิฉะนั้น คุณจะตัดสินใจไปโดยไม่ได้ตั้งใจ

การแลกเปลี่ยนที่คุณมักจะต้องเผชิญ:

• ฟังก์ชันการทำงาน (Functionality) เทียบกับ ประสิทธิภาพ (Performance) โค้ดที่สะอาด (Clean code) มักจะทำงานช้ากว่า ส่วนโค้ดที่ทำงานเร็วก็มักจะอ่านยาก จงใช้โค้ดที่อ่านง่ายสำหรับกระบวนการแบบ batch ที่รันเพียงวันละครั้ง และใช้โค้ดที่ปรับแต่งมาอย่างดี (optimized) สำหรับเส้นทาง (paths) ที่ต้องทำงานหลายพันครั้งต่อหนึ่งคำขอ (request)

• ความยืดหยุ่น (Flexibility) เทียบกับ ความเรียบง่าย (Simplicity) การทำ abstraction ที่ซับซ้อนทำให้โค้ดเข้าใจยาก จงเขียนโค้ดที่เรียบง่ายที่สุดที่สามารถทำงานได้ และออกแบบให้สามารถต่อยอดได้ในภายหลัง

• การขยายตัว (Scalability) เทียบกับ ต้นทุน (Cost) การออกแบบเพื่อรองรับทราฟฟิกมหาศาลต้องใช้เงินทุนมากขึ้นในตอนนี้ การวัดอัตราการเติบโตจะช่วยให้คุณตัดสินใจได้ง่ายขึ้น หากคุณเติบโต 20% ทุกเดือน ให้วางแผนเพื่ออนาคต แต่หากคุณมีเงินทุนจำกัด ให้ระวังเรื่องค่าใช้จ่าย

• ความปลอดภัย (Security) เทียบกับ ความง่ายในการใช้งาน (Usability) ความปลอดภัยที่เข้มงวดเกินไปอาจทำลายประสบการณ์ของผู้ใช้ ครั้งหนึ่งเราเคยบังคับใช้ hardware tokens สำหรับเครื่องมือของผู้ดูแลระบบ (admin tool) ทำให้อัตราการเข้าสู่ระบบสำเร็จลดลงจาก 98% เหลือ 84% และวิศวกรก็ถูกล็อกไม่ให้เข้าใช้งานในช่วงเวลาฉุกเฉิน เราจึงเปลี่ยนไปใช้การแจ้งเตือนผ่านมือถือ (mobile push notifications) แทน ซึ่งทำให้อัตราความสำเร็จกลับขึ้นมาอยู่ที่ 96% จงตั้งเป้าหมายที่ความปลอดภัยที่สมเหตุสมผล ไม่ใช่ความปลอดภัยสูงสุด

วิธีการตัดสินใจให้ดีขึ้น:

  • ระบุเป้าหมายให้ชัดเจน
  • วัดผลด้วยข้อมูลแทนการคาดเดา
  • เริ่มต้นด้วยวิธีแก้ปัญหาที่เรียบง่าย
  • ปรับแต่ง (Optimize) เฉพาะเมื่อมีหลักฐานยืนยันเท่านั้น
  • บันทึกเหตุผลที่คุณเลือกตัดสินใจเช่นนั้น

ครั้งหนึ่งผมเคยพยายามปรับแต่ง (optimize) JSON serializer เพื่อประหยัดเวลาเพียงไม่กี่ไมโครวินาที แต่มันกลับทำให้เกิด memory leak ที่เพิ่มขึ้นถึง 300 MB ผลจากการใช้ profiler แสดงให้เห็นว่าคอขวด (bottleneck) ที่แท้จริงคือ network I/O ดังนั้น ควรใช้ profiler เสมอก่อนที่จะเขียนโค้ดใหม่

หนี้ทางเทคนิค (Technical debt) เป็นเรื่องจริง การเลือกทางลัดในวันนี้ต้องแลกมาด้วยเวลาในวันหน้า เมื่อเราต้องรับช่วงต่อบริการที่จัดการได้ยาก (messy service) เราไม่ได้ทำการเขียนใหม่ทั้งหมด (big rewrite) แต่เราใช้วิธีการเปลี่ยนแปลงทีละน้อยอย่างต่อเนื่อง เราเพิ่ม test coverage จาก 30% เป็น 78% ซึ่งช่วยลดเวลาในการแก้ไขบั๊กจาก 4 วัน เหลือเพียง 1.2 วัน

การแลกเปลี่ยน (Trade-offs) ไม่ใช่เรื่องถาวร จงกลับมาทบทวนการตัดสินใจของคุณอยู่เสมอ ตรวจสอบว่าการปรับแต่งที่คุณทำไปนั้นยังจำเป็นอยู่หรือไม่ การตัดสินใจอย่างมีจุดมุ่งหมายจะช่วยป้องกันไม่ให้ระบบของคุณอยู่ในระดับปานกลางไปเสียทุกอย่าง

Source: https://dev.to/lavkeshdwivedi/software-tradeoffs-44e7

Optional learning community: https://t.me/GyaanSetuAi