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

แรงบันดาลใจ (Motivation)

ไอเดียหลักของ Feature-Sliced Design คือการอำนวยความสะดวกและลดต้นทุนในการพัฒนาโปรเจกต์ที่ซับซ้อน โดยอิงจาก การรวบรวมผลการวิจัยและการหารือประสบการณ์จากนักพัฒนาที่หลากหลาย

ชัดเจนว่านี่ไม่ใช่ "กระสุนเงิน" (Silver Bullet) และแน่นอนว่าระเบียบวิธีนี้ก็มี ขอบเขตการใช้งาน ของมันเอง

อย่างไรก็ตาม ก็ยังมีคำถามที่สมเหตุสมผลเกี่ยวกับ ความเป็นไปได้ของระเบียบวิธีนี้โดยรวม

note

มีรายละเอียดเพิ่มเติมที่ พูดคุยกันในการอภิปราย

ทำไมโซลูชันที่มีอยู่ถึงยังไม่พอ?​

ปกติมักจะมีข้อโต้แย้งเหล่านี้:

  • "ทำไมต้องมี Methodology ใหม่ด้วย ในเมื่อเรามีแนวทางและหลักการออกแบบที่มีมานานแล้วอย่าง SOLID, KISS, YAGNI, DDD, GRASP, DRY ฯลฯ"
  • "ปัญหาทุกอย่างแก้ได้ด้วยเอกสารโปรเจกต์ที่ดี การทดสอบ และกระบวนการที่เป็นระบบ"
  • "ปัญหาคงไม่เกิดถ้านักพัฒนาทุกคนทำตามข้อข้างบนทั้งหมด"
  • "ทุกอย่างถูกคิดค้นมาก่อนคุณแล้ว คุณแค่ใช้มันไม่เป็น"
  • "ใช้ {ชื่อเฟรมเวิร์ก} สิ - ทุกอย่างถูกกำหนดมาให้คุณแล้ว"

แค่หลักการอย่างเดียวไม่พอ​

การมีแค่หลักการ (Principles) ไม่เพียงพอที่จะออกแบบสถาปัตยกรรมที่ดี

ไม่ใช่ทุกคนที่จะรู้หลักการทั้งหมด และมีคนน้อยลงไปอีกที่เข้าใจและนำไปประยุกต์ใช้ได้อย่างถูกต้อง

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

กระบวนการไม่ได้ได้ผลเสมอไป​

เอกสาร/การทดสอบ/กระบวนการ แน่นอนว่าเป็นสิ่งที่ดี แต่น่าเสียดาย ที่ถึงแม้จะลงทุนลงแรงไปเยอะ - มันก็ไม่ได้แก้ปัญหาที่เกิดจากสถาปัตยกรรมและการพาคนใหม่เข้าโปรเจกต์ได้เสมอไป

  • เวลาในการเริ่มงานของนักพัฒนาแต่ละคนไม่ได้ลดลงมากนัก เพราะเอกสารมักจะเยอะมาก หรือไม่ก็ไม่อัปเดต
  • การต้องคอยเช็คตลอดเวลาว่าทุกคนเข้าใจสถาปัตยกรรมตรงกันหรือไม่ ก็ต้องใช้ทรัพยากรเยอะมาก
  • อย่าลืมเรื่อง Bus-factor ด้วย (ความเสี่ยงเมื่อคนรู้ข้อมูลสำคัญหายไป)

เฟรมเวิร์กที่มีอยู่นำไปใช้ไม่ได้ทุกที่​

  • โซลูชันที่มีอยู่มักมีกำแพงการเรียนรู้ที่สูง (High Entry Threshold) ซึ่งทำให้หาคนมาทำงานด้วยยาก
  • บ่อยครั้งที่การเลือกเทคโนโลยีถูกกำหนดไปแล้วก่อนที่จะเจอปัญหาหนักๆ ในโปรเจกต์ ดังนั้นคุณต้องสามารถ "ทำงานกับสิ่งที่มีอยู่" ได้ - โดยไม่ยึดติดกับเทคโนโลยี

Q: "ในโปรเจกต์ React/Vue/Redux/Effector/Mobx/{YOUR_TECH} ของเรา - ฉันจะสร้างโครงสร้างของ Entities และความสัมพันธ์ระหว่างพวกมันให้ดีขึ้นได้ยังไง?"

ผลลัพธ์ที่ได้​

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

@sergeysova: "นี่คือสถานการณ์ที่เป็นอยู่ในวงการ Frontend Development ตอนนี้: Lead แต่ละคนจะคิดค้นสถาปัตยกรรมและโครงสร้างโปรเจกต์ที่แตกต่างกัน โดยที่ยังไม่ชัวร์ว่าโครงสร้างพวกนี้จะผ่านบททดสอบของกาลเวลาหรือไม่ ผลที่ได้คือ มีแค่ 2 คนนอกจากเขาที่พัฒนาโปรเจกต์ต่อได้ และนักพัฒนาใหม่ทุกคนต้องมานั่งเรียนรู้ใหม่หมด"

ทำไมนักพัฒนาถึงต้องการ Methodology?​

โฟกัสที่ Business Features ไม่ใช่ปัญหา Architecture​

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

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

โซลูชันที่พิสูจน์แล้วด้วยประสบการณ์​

ระเบียบวิธีนี้ออกแบบมาเพื่อนักพัฒนาที่มองหา โซลูชันที่ผ่านการพิสูจน์แล้วสำหรับการออกแบบ Business Logic ที่ซับซ้อน

อย่างไรก็ตาม ระเบียบวิธีนี้โดยรวมคือชุดของ Best-practices และบทความที่พูดถึงปัญหาและเคสต่างๆ ระหว่างการพัฒนา ดังนั้น มันจึงมีประโยชน์สำหรับนักพัฒนาคนอื่นๆ ด้วย ที่ต้องเจอกับปัญหาระหว่างการพัฒนาและการออกแบบ

สุขภาพของโปรเจกต์ (Project Health)​

ระเบียบวิธีจะช่วยให้ แก้ปัญหาและติดตามปัญหาของโปรเจกต์ได้ล่วงหน้า โดยไม่ต้องใช้ทรัพยากรจำนวนมหาศาล

บ่อยครั้งที่ Technical Debt สะสมพอกพูนตามกาลเวลา และความรับผิดชอบในการแก้ไขก็ตกอยู่ที่ทั้ง Lead และทีม

ระเบียบวิธีจะช่วย เตือน ถึงปัญหาที่เป็นไปได้ในการสเกลและการพัฒนาโปรเจกต์ล่วงหน้า

ทำไมธุรกิจถึงต้องการ Methodology?​

Onboarding ที่รวดเร็ว​

ด้วยระเบียบวิธีนี้ คุณสามารถจ้างคนที่ คุ้นเคยกับแนวทางนี้อยู่แล้ว และไม่ต้องมาเทรนใหม่

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

โซลูชันที่พิสูจน์แล้วด้วยประสบการณ์​

ด้วยระเบียบวิธีนี้ ธุรกิจจะได้รับ โซลูชันสำหรับปัญหาส่วนใหญ่ที่เกิดขึ้นระหว่างการพัฒนาระบบ

เนื่องจากส่วนใหญ่ธุรกิจต้องการเฟรมเวิร์กหรือโซลูชันที่ช่วยแก้ปัญหาส่วนใหญ่ระหว่างการพัฒนาโปรเจกต์ได้

การนำไปใช้ในระยะต่างๆ ของโปรเจกต์​

ระเบียบวิธีสามารถสร้างประโยชน์ให้โปรเจกต์ ทั้งในระยะ Support และ Development และรวมถึงระยะ MVP ด้วย

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

เรื่องการทดสอบก็พูดได้แบบเดียวกัน

เมื่อไหร่ที่เราไม่ต้องการ Methodology นี้?​

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

ขนาดของธุรกิจ​

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

แผนงาน (Plans)​

เป้าหมายหลัก ระบุไว้ที่นี่ แต่นอกจากนั้น ยังคุ้มค่าที่จะพูดถึงความคาดหวังของเราที่มีต่อระเบียบวิธีนี้ในอนาคต

การรวมประสบการณ์​

ตอนนี้เรากำลังพยายามรวมประสบการณ์ที่หลากหลายของ core-team และผลลัพธ์คือระเบียบวิธีที่แข็งแกร่งจากการปฏิบัติจริง

แน่นอนว่าเราอาจจะได้ Angular 3.0 เป็นผลลัพธ์ แต่มันสำคัญกว่ามากที่จะ สืบสวนปัญหาที่แท้จริงของการออกแบบสถาปัตยกรรมของระบบที่ซับซ้อน

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

ชีวิตนอกเหนือจาก Specification​

ถ้าทุกอย่างไปได้สวย ระเบียบวิธีจะไม่จำกัดอยู่แค่ Specification และ Toolkit

  • อาจจะมีรายงาน (Reports) และบทความ (Articles)
  • อาจจะมี CODE_MODEs สำหรับการย้าย (Migration) ไปยังเทคโนโลยีอื่นๆ ของโปรเจกต์ที่เขียนตามระเบียบวิธี
  • เป็นไปได้ว่าในท้ายที่สุด เราจะสามารถเข้าถึงผู้ดูแล (Maintainers) ของโซลูชันเทคโนโลยีใหญ่ๆ ได้
    • โดยเฉพาะ React เมื่อเทียบกับเฟรมเวิร์กอื่น - นี่คือปัญหาหลัก เพราะมันไม่ได้บอกวิธีแก้ปัญหาบางอย่าง

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