"Just Enough Software Architecture" ที่ตีพิมพ์ในปี 2010

 (georgefairbanks.com)
1 คะแนน โดย GN⁺ 2024-06-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

แนะนำหนังสือสถาปัตยกรรมซอฟต์แวร์

จุดเด่นของหนังสือ

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

โครงสร้างของหนังสือ

Part I: สถาปัตยกรรมซอฟต์แวร์ที่ยึดความเสี่ยงเป็นหลัก

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

Part II: การทำโมเดลสถาปัตยกรรม

  • โครงสร้างของโมเดลเชิงแนวคิด: ประกอบด้วย domain model, design model และ code model
  • การสร้างขอบเขตการห่อหุ้ม: ซ่อนการทำงานภายในของคอมโพเนนต์หรือโมดูลเพื่อให้สามารถมุ่งแก้ปัญหาอื่นได้
  • การสร้างโมเดลอย่างมีประสิทธิภาพ: อธิบายวิธีผสานเทคนิคสถาปัตยกรรมหลากหลายแบบที่เน้นคุณลักษณะด้านคุณภาพและฟังก์ชันการทำงาน เพื่อสร้างและดีบักโมเดลที่ใช้งานได้จริง
  • คำแนะนำในการใช้โมเดล: กล่าวถึงทั้งข้อดีและข้อเสียของโมเดล พร้อมเสนอวิธีใช้งานอย่างมีประสิทธิภาพ

อีบุ๊กและปกแข็ง

  • อีบุ๊ก: วางจำหน่ายบน Google Play ในเวอร์ชัน DRM-free ($9.99)
  • ปกแข็ง: สามารถซื้อได้ที่ Amazon

รีวิวและสื่อเพิ่มเติมเกี่ยวกับหนังสือ

  • รีวิว: มีรีวิวและบทความเชิงความเห็นหลากหลายจาก IEEE Software และแหล่งอื่น ๆ
  • สื่อเพิ่มเติม: มีวิดีโอและสิ่งพิมพ์ในหัวข้อต่าง ๆ เช่น continuous design, architecture style และ modeling

ความเห็นของ GN⁺

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-06-16
ความคิดเห็นบน Hacker News
  • ต้องแยกความแตกต่างระหว่าง ความเสี่ยงด้านการจัดการโครงการ กับ ความเสี่ยงด้านวิศวกรรมซอฟต์แวร์ เพราะหลายครั้งทักษะทางวิศวกรรมไม่สามารถแก้ปัญหาความเสี่ยงด้านการจัดการได้
  • คุณภาพโค้ด การจัดระเบียบ การทดสอบ การทำเอกสาร และการใช้เครื่องมือมาตรฐาน ช่วยได้กับทั้งสองด้าน
  • เหตุผลที่มักใช้สมมติฐาน "ถูกรถบัสชน" ก็เพื่อสร้างซอฟต์แวร์ที่ทำซ้ำได้และเข้าใจได้ง่าย
  • เพื่อหลีกเลี่ยงความหมายเชิงลบ การใช้สำนวน "ถูกรางวัลลอตเตอรี่" น่าจะดีกว่า
  • สถาปัตยกรรม เพื่อสถาปัตยกรรมเองนั้นแย่ที่สุด เพราะเพิ่มความซับซ้อนโดยไม่จำเป็น
  • เป้าหมายสูงสุดของสถาปัตยกรรมที่ดีคือการลดต้นทุน หากใช้เวลามากขึ้นทั้งในการพัฒนาและบำรุงรักษา ก็ถือว่าเป็นสถาปัตยกรรมที่ล้มเหลว
  • สงสัยว่าหนังสือที่ตีพิมพ์ในปี 2010 เล่มนี้ยังคงใช้ได้ดีแค่ไหน
  • หนังสือ "Design It" ดีตรงที่กิจกรรมเวิร์กช็อปมีประโยชน์กับคนสายเทคนิค และไม่เอนเอียงไปทางรูปแบบสถาปัตยกรรมเชิงเทคนิคแบบใดแบบหนึ่ง
  • หนังสือ 'A Philosophy of Software Design' ของ John Ousterhout มีประโยชน์มาก เพราะมีคำแนะนำและตัวอย่างที่เข้าใจง่ายจำนวนมาก
  • คิดว่าคำว่า "ขึ้นกับความเสี่ยง" น่าจะเป็นชื่อเรียกที่ดีกว่า และสงสัยว่าทำไมโปรแกรมเมอร์ถึงชอบใช้สำนวนแบบ "[X]-based"
  • ไม่รู้จักหนังสือเล่มนั้นโดยเฉพาะ แต่บทความของผู้เขียนเรื่อง "การควบคุมทางปัญญา" มีมุมมองที่ลึกซึ้งมาก
  • เมื่อหลายปีก่อนที่บริษัทเคยทำชมรมอ่านหนังสือ และรู้สึกว่าเนื้อหาค่อนข้างซ้ำไปซ้ำมา
  • สงสัยว่านี่เป็นทรัพยากรที่ดีสำหรับคนที่กำลังเริ่มโครงการโอเพนซอร์สที่มีน้ำหนัก หรือสำหรับ solopreneur หรือไม่ และขอคำแนะนำหนังสือหรือทรัพยากรที่มีประโยชน์สำหรับนักพัฒนาเดี่ยว
  • สถาปัตยกรรมซอฟต์แวร์คล้ายกับสถาปัตยกรรมทั่วไป แต่ในซอฟต์แวร์ไม่มีบุคคลแบบ Isaac Newton จึงไม่มีสิ่งที่เทียบได้กับวิศวกรรมโยธา บุคคลที่ใกล้เคียงที่สุดคือ Claude Shannon
  • เป็นแนวทางในการอ่านคำศัพท์ที่ตั้งขึ้นตามอำเภอใจ ต้องการแบบจำลองทางคณิตศาสตร์ เพราะคำศัพท์กำกวมที่มนุษย์สร้างขึ้นเป็นเพียงการดัดแปลงเพื่อถ่ายทอดแนวคิดเท่านั้น