ถ้าไม่ได้สร้างและแก้เอง ก็ออกแบบซอฟต์แวร์ไม่ได้

• การมีส่วนร่วมในการออกแบบอย่างแท้จริงของระบบขนาดใหญ่ ทำได้เฉพาะวิศวกรที่ลงมือจัดการโค้ดนั้นโดยตรงเท่านั้น และคำแนะนำเชิงนามธรรมส่วนใหญ่มักแทบไม่มีความหมาย
• คำแนะนำด้านการออกแบบแบบทั่วไป (generic design) มักถูกเสนอโดยที่ไม่รู้จัก codebase แต่เข้าใจเพียงแค่โดเมน
• ในงานจริง ข้อจำกัดที่เป็นรูปธรรมและการรักษาความสอดคล้อง สำคัญกว่าหลักการออกแบบมาก และหัวใจสำคัญคือการเข้าใจสถานะปัจจุบันของโค้ด
• ในการ ออกแบบระบบใหม่หรือกำหนดทิศทางเทคโนโลยีทั้งบริษัท หลักการออกแบบทั่วไปยังพอมีประโยชน์อยู่บ้าง
• แต่ โครงสร้างการออกแบบที่ยึดสถาปนิกเป็นศูนย์กลางและแยกขาดจากหน้างานมักล้มเหลวง่าย และผู้ที่เสนอแบบควรต้องรับผิดชอบต่อผลลัพธ์

---

ข้อจำกัดของการออกแบบซอฟต์แวร์แบบทั่วไป

• การออกแบบระบบขนาดใหญ่จำเป็นต้องมี ความเข้าใจเชิงลึกในรายละเอียดที่เป็นรูปธรรมของโค้ด
  • คำแนะนำเชิงนามธรรมแทบไม่ช่วยในการแก้ปัญหาจริง
  • ในงานจริง ความสอดคล้อง (consistency) สำคัญกว่า ‘การออกแบบที่ดี’
• เนื่องจาก codebase จริงมีความซับซ้อนและก่อให้เกิดผลลัพธ์ที่คาดเดาไม่ได้ รูปแบบการ implement ที่เลือกใช้ได้เพื่อให้แก้ไขอย่างปลอดภัยจึงมีจำกัด
• codebase ขนาดใหญ่ที่ใช้ร่วมกันมักอยู่ใน สถานะกึ่งกลาง ที่มีหลายแนวทางการออกแบบปะปนกันอยู่เสมอ ดังนั้นสภาพการเชื่อมโยงของโค้ดในปัจจุบันจึงสำคัญกว่าเป้าหมายเชิงอุดมคติ
• ระบบส่วนใหญ่ไม่สามารถ rewrite ใหม่ทั้งหมดได้ จึงต้องพึ่งพา ความสอดคล้องภายในและความรอบคอบของวิศวกร

ลักษณะของการออกแบบซอฟต์แวร์แบบเฉพาะเจาะจง

• การพูดคุยเรื่องการออกแบบที่มีประสิทธิภาพเกิดขึ้นในการสนทนาระหว่างวิศวกรไม่กี่คนที่ดูแลระบบนั้นทุกวัน
  • ประเด็นที่คุยกันไม่ใช่หลักการทั่วไป แต่เป็น บริบทที่เฉพาะเจาะจง เช่น โครงสร้างรายละเอียดของระบบหรือการไหลของข้อมูล
• ตัวอย่างเช่น ไม่ใช่การถกเถียงว่า “DRY ดีหรือไม่” แต่เป็น การอภิปรายทางเทคนิคอย่างละเอียด เช่น “จะใส่ฟีเจอร์นี้ไว้ใน subsystem A ได้ไหม” หรือ “ข้อมูล B เข้าถึงได้ใน context C หรือไม่”
• การมีส่วนร่วมที่สำคัญมักมาจากการ แก้ความเข้าใจผิดเล็ก ๆ หรือผลกระทบเชิงรายละเอียดของการเปลี่ยนโค้ด

กรณีที่คำแนะนำการออกแบบแบบทั่วไปมีประโยชน์

• เมื่อออกแบบโปรเจกต์ใหม่ตั้งแต่ต้น หลักการทั่วไปมีประโยชน์เพราะยังไม่มีข้อจำกัดที่เฉพาะเจาะจง
• เมื่อเลือกได้ยากระหว่างหลายแนวทางการ implement หลักการทั่วไปสามารถทำหน้าที่เป็น เกณฑ์ตัดสิน (tie-breaker)
• ยังช่วยในเรื่อง การรักษาความสอดคล้องในระดับทั้งบริษัท ซึ่งเป็นหนึ่งในบทบาทอย่างเป็นทางการของ software architect
• แม้ในการเลือกเทคโนโลยีวงกว้างอย่าง cloud vs on-premise, AWS vs Azure ก็สามารถอ้างอิงหลักการทั่วไปได้ แต่ก็ยัง ละเลยข้อจำกัดที่เป็นรูปธรรมไม่ได้

สถาปนิกและปัญหา ‘local minima’

• หลายบริษัทตกอยู่ใน โครงสร้างการออกแบบเชิงนามธรรมที่ยึดสถาปนิกเป็นศูนย์กลาง ทั้งที่ไม่มีประสบการณ์หน้างาน
  • วิธีนี้ดูเหมือนมีประสิทธิภาพภายนอก แต่ในความเป็นจริงกลับก่อให้เกิด แบบออกแบบที่วิศวกรหน้างานนำไป implement ไม่ได้
• เพราะสถาปนิกไม่ได้ลงมือ implement เอง จึงขาด ความรับผิดชอบต่อผลลัพธ์ (skin in the game)
  • ถ้าการออกแบบสำเร็จก็รับเครดิต แต่ถ้าล้มเหลวก็มักโทษทีมปฏิบัติการ
• โครงสร้างแบบนี้มีแนวโน้มจะ เสริมกิจกรรมการออกแบบเชิงพิธีการ มากกว่าสร้างคุณค่าจริง

บทสรุปและข้อเสนอ

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

[khris]

> ในงานจริง ข้อจำกัดที่เป็นรูปธรรมและการรักษาความสอดคล้องสำคัญกว่าหลักการออกแบบมาก และหัวใจสำคัญคือการเข้าใจสถานะปัจจุบันของโค้ด

เป็นความเชื่อที่ผมยึดถือมาตลอด เลยรู้สึกอบอุ่นใจเลยครับ

[cshj55]

ถึงว่าเดี๋ยวนี้กูรูทั้งหลายถึงพูดกันว่า พวกมือใหม่กลับใช้เอเจนต์ได้เก่งกว่ามาก แบบนี้นี่เอง ของที่เคยทำเงินให้มานานก็เลยยังไม่ยอม unlearn กัน

[coremaker]

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

[GN⁺]

ความคิดเห็นจาก Hacker News

• อธิบายสถานการณ์ที่ในการประชุมทีมไม่ได้คุยกันทำนองว่า “DRY ดีกว่าไหมหรือ WET ดีกว่า” แต่กลับเป็นการคุยเรื่อง dependency ที่ซับซ้อน เช่น “จะเอาฟีเจอร์นี้ใส่ใน subsystem A ได้ไหม? ไม่ได้ เพราะฝั่งนั้นไม่มีข้อมูล B แล้วถ้าจะเปิดเผยข้อมูลนั้นก็ต้องเขียน D ใหม่...”
  บอกว่าเป็นภาพที่คุ้นเคยมาก พร้อมล้อเล่นด้วยการไล่ชื่อระบบสมมติหลาย ๆ ชื่อ และปิดท้ายด้วย ลิงก์ YouTube

  • คำว่า “Wingman” นี่ตลกดี แต่ถึงตอนนี้ก็ยังมี ซอฟต์แวร์จำนวนมาก ที่ไม่รองรับ ISO8601 แม้แต่ Git เองก็ยังไม่เข้ากันได้อย่างสมบูรณ์
  • ดูเหมือนงานเสียดสีที่สมจริงเกินไป ตามอุดมคติแล้วคิดว่าหนึ่งทีมควรรับผิดชอบ เพียงหนึ่งบริการ เท่านั้น แต่ทุกวันนี้กลับเป็นยุคที่นักพัฒนาหนึ่งคนต้องดูแลไมโครเซอร์วิสคนละสี่ตัว เลยเหนื่อยล้ามาก
  • สถานการณ์แบบนี้มักเกิดขึ้นเมื่อ โปรแกรมเมอร์ต้องรับหน้าที่ออกแบบระบบธุรกิจ ไปด้วย นักวิเคราะห์ระบบควรเป็นฝ่ายนำการออกแบบ

• ทำงานพัฒนามา 30 ปีแล้ว แต่แทบไม่เคยเห็นกรณีที่มี ความพยายามอย่างสม่ำเสมอด้านการออกแบบและสถาปัตยกรรม จริง ๆ
  ‘สถาปนิก’ ส่วนใหญ่ไม่ได้ออกแบบเอง แต่เป็นโครงสร้างที่นักพัฒนาระดับอาวุโสออกแบบแล้วค่อยรับฟีดแบ็ก
  ถ้าระยะเวลาทำงานเฉลี่ยอยู่ที่ 2 ปี คนก็จะออกแบบทั้งที่เข้าใจเพียงบางส่วนของระบบ และสถาปนิกก็มักแค่คอยอนุมัติ

  • John Ousterhout พูดถึงปัญหานี้และสอนที่ Stanford ก่อนจะขยายเป็นหนังสือ 『A Philosophy of Software Design』 และยังมี วิดีโอบรรยาย
  • เคยร่วมโปรเจกต์ที่มี ‘สถาปนิก’ อยู่ แต่จริง ๆ แล้วเป็น คนที่มีแต่นั่งประชุม ไม่มีใครให้คำแนะนำด้านการออกแบบจริง ๆ
  • 2 ปีมากพอที่จะเปลี่ยน subsystem ไปทั้งหมด หรือทำพังได้เลย ซอฟต์แวร์สมัยนี้เปลี่ยนเร็วขนาดนั้น
  • ใน 2~3 ปี เราสามารถเข้าใจ codebase ของทีมขนาด 50~100 คนได้ค่อนข้างลึก ถ้าหลังจากนั้นเปิดโอกาสให้คนเหล่านี้เป็นผู้นำการปรับปรุงสถาปัตยกรรม บริษัทก็จะเติบโตด้านเทคนิคได้ สถาปนิกควรมีหน้าที่ ประสานแนวคิดเหล่านี้และรักษาความสอดคล้อง

• ‘Generic Software Design’ มีประโยชน์ในการกำหนดทิศทางการลงมือทำ เพราะช่วยให้มี ภาษาและกรอบร่วมกัน ทำให้แก้ปัญหาได้ง่ายขึ้น
  แต่การลงมือทำจริงอาจต่างจากแผน และตามทฤษฎีการเขียนโปรแกรมของ Naur ความรู้ที่แท้จริงของระบบอยู่ใน หัวของนักพัฒนา

• คำพูดที่ว่า “ใน codebase ขนาดใหญ่ ความสอดคล้องสำคัญกว่าการออกแบบที่ดี” ก็คือกับดักของ คำแนะนำแบบเหมารวม นั่นเอง
  ถ้าเน้นแต่ความสอดคล้อง นิสัยแย่ ๆ ก็จะถูกรักษาไว้เหมือนเดิม

  • บริษัทเรากลับมีปัญหาตรงข้าม คืออิสระมากเกินไป แต่ละคนทำในแบบของตัวเองจนมีทั้ง มุมหนึ่งเป็น Redux และ อีกมุมหนึ่งเป็นไลบรารี query อีกตัว ปะปนกันไป สุดท้ายยิ่งดูแลรักษายากขึ้น
  • นี่ไม่ใช่แค่ปัญหาคุณภาพโค้ด แต่เป็นปัญหา ประสิทธิภาพของทั้งองค์กร ถ้ามีความสอดคล้อง ความเร็วในการพัฒนาก็จะสูงขึ้น การรีวิวและ onboarding ก็ง่ายขึ้น แถมบั๊กยังแก้ทีเดียวได้ด้วย
  • เห็นประโยคนี้แล้วสะดุ้งเลย แต่ถ้าอ่านบทความจนจบจะเห็นว่า แก่นแท้ของความสอดคล้องคือความเป็นหนึ่งเดียวและความถูกต้อง
  • ควรรักษาความสอดคล้องไว้ แต่ การปรับปรุงแบบค่อยเป็นค่อยไป ก็สำคัญ เวลาจับโค้ดแต่ละครั้งให้ปรับเล็ก ๆ น้อย ๆ เก็บ ‘ชัยชนะง่าย ๆ’ ไปเรื่อย ๆ จะดีกว่า
  • คำพูดว่า “ความสอดคล้องสำคัญกว่าการออกแบบที่ดี” ขัดกับ Boy Scout Rule เพราะถ้ายึดแต่ความสอดคล้อง ก็อาจลากไปสู่การ refactor ทั้งระบบจนเสี่ยงเกินไป

• ฝั่งหนึ่งคือ ‘สถาปนิก’ ที่ไม่เข้าใจโลกความจริง อีกฝั่งคือ Real Programmer ที่หมกมุ่นกับการ optimize รายละเอียดเท่านั้น
  ทั้งสองสุดโต่งล้วนเป็นปัญหา และคนตัดสินใจต้องเข้าใจทั้งรายละเอียดและบริบท
  มีการอ้างถึง The Story of Mel ที่เกี่ยวข้องกับประเด็นนี้

• เห็นด้วยกับประโยคที่ว่า “คนที่ออกแบบควรต้องรับผิดชอบต่อความสำเร็จและความล้มเหลวของโปรเจกต์”
  เรื่องนี้ควรใช้กับ คนที่เลือก methodology การพัฒนา ด้วย Scrum master ไม่ได้มีความรับผิดชอบเท่ากับหัวหน้าวิศวกร

• แอปที่ดีที่สุดที่ฉันเคยร่วมทำมีลักษณะร่วมกันอยู่ 3 ข้อ

  1. ให้ความสำคัญกับ ระบบที่เรียบง่ายและมีประสิทธิภาพ
  2. นักพัฒนาเข้าใจทุก use case เพราะเป็นผู้ใช้งานจริงเอง
  3. มี อิสระในการแก้ปัญหา ที่พบได้ทันที
     อิสระนี้ช่วยยกระดับทั้งความพึงพอใจของนักพัฒนาและคุณภาพของผลิตภัณฑ์

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

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

  • นักพัฒนาควรมี ช่องทางที่มองเห็นปัญหาของผู้ใช้ได้โดยตรง โดยไม่ต้องผ่านขั้นตอน customer support เพราะ insight ที่ได้จาก ticket, forum, SNS มีคุณค่ามาก
  • การที่ XP รวมลูกค้าไว้ในทีมเป็นไอเดียที่ยอดเยี่ยม การเอาสิ่งนั้นไปแทนที่ด้วยตัวแทนฝั่งธุรกิจคือหนึ่งใน บาปกำเนิด ของ Scrum

• การมี สถาปนิกซอฟต์แวร์แยกต่างหาก ที่ไม่เข้าร่วมการบำรุงรักษาเป็นเรื่องไม่สมจริง
  โปรเจกต์เปลี่ยนตลอดเวลา ดังนั้นบทบาทที่คอยสั่งการจากระยะไกลจึงไม่ได้ช่วยอะไร

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