ข้ามไปยังเนื้อหาหลัก

เกี่ยวกับสถาปัตยกรรม

ปัญหา​

โดยปกติ การคุยเรื่องสถาปัตยกรรมจะเกิดขึ้นเมื่อการพัฒนาเริ่มหยุดชะงักเพราะปัญหาบางอย่างในโปรเจกต์

Bus-factor & การ Onboarding​

มีคนจำนวนจำกัดที่เข้าใจโปรเจกต์และสถาปัตยกรรมของมัน

ตัวอย่าง:

  • "ยากมากที่จะเพิ่มคนเข้ามาช่วยพัฒนา"
  • "สำหรับทุกปัญหา ทุกคนมีความเห็นคนละทางว่าจะเลี่ยงยังไง" (แอบอิจฉา Angular นิดๆ นะ)
  • "ไม่เข้าใจเลยว่าเกิดอะไรขึ้นในก้อน Monolith ใหญ่นี้"

ผลกระทบที่แฝงอยู่และควบคุมไม่ได้​

มี Side effects แฝงเยอะมากระหว่างการพัฒนา/Refactoring ("ทุกอย่างขึ้นอยู่กับทุกอย่าง")

ตัวอย่าง:

  • "Feature นี้ Import Feature นั้น"
  • "อัปเดต Store ของหน้านึง อีกหน้านึงพังเฉย"
  • "Logic กระจายไปทั่วแอป ตามหาไม่เจอเลยว่าเริ่มตรงไหน จบตรงไหน"

การ Reuse Logic ที่ควบคุมไม่ได้​

ยากที่จะนำกลับมาใช้ใหม่/แก้ไข Logic ที่มีอยู่

ในขณะเดียวกัน มักจะมี สองขั้วที่สุดโต่ง:

  • เขียน Logic ใหม่หมดสำหรับแต่ละ Module (ทำให้มีโค้ดซ้ำซ้อนใน Codebase)
  • หรือมีแนวโน้มที่จะยัดทุก Module ลงในโฟลเดอร์ shared จนกลายเป็นถังขยะใหญ่ๆ (ซึ่งส่วนใหญ่ถูกใช้แค่ที่เดียว)

ตัวอย่าง:

  • "ฉันมี Business Logic เดียวกัน N แบบในโปรเจกต์ ซึ่งฉันก็ต้องจ่ายค่าดูแลมันทั้งหมด"
  • "มี Component ปุ่ม/Pop-up/... 6 แบบในโปรเจกต์"
  • "กองขยะของ Helpers"

ความต้องการ (Requirements)​

ดังนั้น ดูเหมือนจะเป็นเหตุเป็นผลที่จะนำเสนอ ความต้องการที่พึงประสงค์สำหรับสถาปัตยกรรมในอุดมคติ:

note

ที่ไหนที่บอกว่า "ง่าย" หมายถึง "ค่อนข้างง่ายสำหรับนักพัฒนากลุ่มกว้าง" เพราะชัดเจนว่า เป็นไปไม่ได้ที่จะทำ Solution ที่สมบูรณ์แบบสำหรับทุกคนครับ

ความชัดเจน (Explicitness)​

  • ควรจะ ง่ายต่อการเชี่ยวชาญและอธิบาย โปรเจกต์และสถาปัตยกรรมให้ทีมเข้าใจ
  • โครงสร้างควรสะท้อน คุณค่าทางธุรกิจของโปรเจกต์ จริงๆ
  • ต้องมี Side effects และความเชื่อมโยง ระหว่าง Abstractions ที่ชัดเจน
  • ควรจะ ง่ายต่อการตรวจจับ Logic ที่ซ้ำซ้อน โดยไม่รบกวนการ Implement ที่เป็นเอกลักษณ์
  • ไม่ควรมีการ กระจัดกระจายของ Logic ไปทั่วโปรเจกต์
  • ไม่ควรมี Abstractions และกฎที่หลากหลายเกินไป สำหรับสถาปัตยกรรมที่ดี

การควบคุม (Control)​

  • สถาปัตยกรรมที่ดีควร เร่งความเร็วในการแก้โจทย์ และการเพิ่มฟีเจอร์
  • ควรจะเป็นไปได้ที่จะควบคุมการพัฒนาของโปรเจกต์
  • ควรจะง่ายที่จะ ขยาย, แก้ไข, ลบโค้ด
  • ต้องรักษา การแยกส่วนและการ Decompose ของฟังก์ชันการทำงาน
  • แต่ละ Component ของระบบต้อง แทนที่ได้และลบออกได้ง่าย

การปรับตัว (Adaptability)​

  • สถาปัตยกรรมที่ดีควรนำไปใช้ได้ กับโปรเจกต์ส่วนใหญ่
    • กับ Infrastructure Solutions ที่มีอยู่
    • ในทุกขั้นตอนของการพัฒนา
  • ไม่ควรยึดติดกับ Framework และ Platform
  • ควรจะเป็นไปได้ที่จะ สเกลโปรเจกต์และทีมได้ง่าย และสามารถพัฒนาแบบขนานกันได้
  • ควรจะง่ายที่จะ ปรับตัวตาม Requirement และสถานการณ์ที่เปลี่ยนไป

ดูเพิ่มเติม​