𝗪𝗵𝘆 𝗠𝗼𝘀𝘁 𝗦𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗜𝘀 𝗕𝘂𝗶𝗹𝘁 𝗕𝗮𝗰𝗸𝘄𝗮𝗿𝗱𝘀

ทำไมซอฟต์แวร์ส่วนใหญ่ถึงถูกสร้างแบบย้อนกลับ

เรื่องนี้เกิดขึ้นเพราะผู้คนให้รางวัลกับสิ่งที่ไม่ใช่สิ่งที่ควรให้

ฟีเจอร์ได้รับความสนใจ แต่สถาปัตยกรรมไม่ได้รับ การประกาศเปิดตัวได้รับความสนใจ แต่เอกสารประกอบไม่ได้รับ ความสามารถใหม่ๆ ได้รับความสนใจ แต่การบำรุงรักษาไม่ได้รับ

ทีมงานมักเริ่มจากส่วนที่มองเห็นได้ และละเลยรากฐาน

คำถามทั่วไปเกี่ยวกับซอฟต์แวร์มักมุ่งเน้นไปที่ขั้นตอนที่ผิด:

  • เราควรสร้างฟีเจอร์อะไรบ้าง?
  • แดชบอร์ดควรมีหน้าตาเป็นอย่างไร?
  • เราควรสนับสนุนการเชื่อมต่อ (Integrations) อะไรบ้าง?
  • เราจะประกาศอะไรเป็นอย่างต่อไปดี?

คำถามเหล่านี้มาเร็วเกินไป คุณต้องเข้าใจระบบก่อนที่จะเริ่มสร้างฟีเจอร์

ลองนึกถึงการสร้างบ้าน คุณไม่ได้เริ่มจากการเลือกสีทาบ้าน แต่คุณเริ่มจาก:

  • รากฐาน
  • โครงสร้าง
  • ระบบประปา
  • ระบบไฟฟ้า

รายละเอียดที่มองเห็นได้นั้นขึ้นอยู่กับระบบที่มองไม่เห็น ซอฟต์แวร์ก็ทำงานในลักษณะเดียวกัน

User Interface คือสิ่งที่มองเห็นได้ แต่สถาปัตยกรรมไม่ใช่ ฟีเจอร์คือสิ่งที่มองเห็นได้ แต่ระบบที่สนับสนุนฟีเจอร์เหล่านั้นไม่ใช่

ระบบคือตัวกำหนดว่าซอฟต์แวร์จะประสบความสำเร็จหรือไม่

ฟีเจอร์แก้ปัญหาเฉพาะจุด แต่ระบบแก้ปัญหาเป็นหมวดหมู่ ฟีเจอร์สร้างฟังก์ชันการทำงาน แต่ระบบสร้างความสม่ำเสมอ

หากมุ่งเน้นแต่ฟีเจอร์ ความซับซ้อนจะเพิ่มขึ้น แต่หากมุ่งเน้นที่ระบบ ความซับซ้อนจะถูกจัดระเบียบ

เอกสารประกอบคือสิ่งที่เปิดเผยความจริง ระบบที่ออกแบบมาดีจะมีเอกสารประกอบที่ชัดเจน ส่วนระบบที่ออกแบบมาไม่ดีจะต้องใช้คำอธิบายที่ยาวและซับซ้อน หากเวิร์กโฟลว์ (Workflow) ใดต้องใช้คู่มือหลายหน้า แสดงว่าตัวเวิร์กโฟลว์นั่นแหละคือปัญหา

ผู้ใช้ไม่ได้สัมผัสแค่ฟีเจอร์ใดฟีเจอร์หนึ่ง แต่พวกเขาสัมผัสถึง "ระบบ"

ผู้ใช้ไม่เห็น:

  • ระบบยืนยันตัวตน (Authentication)
  • APIs
  • การคิวรีฐานข้อมูล (Database queries)
  • ขั้นตอนการติดตั้งระบบ (Deployment pipelines)

แต่ผู้ใช้สัมผัสถึง:

  • ความน่าเชื่อถือ
  • ความเร็ว
  • ความเรียบง่าย
  • ความมั่นใจ

ความรู้สึกเหล่านี้มาจากระบบโดยรวม

การสร้างแบบย้อนกลับนั้นเข้าใจง่าย ฟีเจอร์สามารถแสดงให้เห็นได้ในภาพสกรีนช็อต คุณสามารถประกาศเปิดตัวฟีเจอร์ได้ แต่คุณไม่สามารถประกาศเปิดตัว "ระบบ" ได้โดยง่าย

งานที่มองไม่เห็นคือสิ่งที่สร้างมูลค่าได้มากที่สุด

ผมเปลี่ยนวิธีการทำงาน ผมเลิกถามว่าโปรเจกต์นี้ต้องการฟีเจอร์อะไร แต่เริ่มถามว่าผมกำลังสร้างระบบแบบไหนอยู่

ระบบสร้างข้อจำกัด ระบบสร้างลำดับความสำคัญ และระบบสร้างทิศทาง

การสร้างฟีเจอร์จะง่ายขึ้นเมื่อมีรากฐานที่มั่นคง

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

เลิกเริ่มต้นด้วยส่วนที่มองเห็นได้ก่อน จงสร้างระบบขึ้นมาก่อน แล้วปล่อยให้ฟีเจอร์ต่างๆ ค่อยๆ ปรากฏออกมาจากระบบนั้นเอง

ที่มา: https://dev.to/stinklewinks/why-most-software-is-built-backwards-46i