Software Architecture: the hard parts หนังสือที่มือใหม่จะไม่อิน
เป็น Review แบบภาพรวมๆจากการนั่งย่อยหนังสือเล่มนี้ไปเรื่อยๆ ครับ ไม่มี detail pattern ภายในสักเท่าไหร่
หนังสือเขียนโดยคุณ Neal Ford, Mark Richards, Pramod Sadalage, Zhamak Dehghani โดยเป็นเล่มต่อจาก Fundamentals of Software Architecture ซึ่ง Neal Ford และ Mark Richards เป็นผู้เขียน สั่งมาจาก Amazon โดยใช้ Promotion flat rate delivery 9 ดอลล่าร์
คนอ่านต้อง Feel It ถึงจะสนุก
ถ้าใครไม่มีประสบการณ์การทำระบบอะไรเลยมาอ่านได้ ไหม มันก็พออ่านได้ แต่มันจะอารมณ์คล้ายๆ กับที่ Steve Job พูดเรื่องงาน Consult ใน Lecture ที่ Slone MIT เมื่อปี 1992 อ่ะครับ ว่า
คุณจะมีรูปกล้วย รูปแอปเปิ้ล หรือผลไม้อื่นๆ เต็มกำแพง ไปหมดเลย รู้ว่ากล้วยหน้าตาแบบนี้ ด้านข้างเป็นแบบนี้ แต่ไม่เคยกินมัน…
เพราะนอกเหนือจากวิธีการ แผนการต่างๆแล้ว Story ก็เป็นส่วนสำคัญ ที่คนมีประสบการณ์จะ Get It มากกว่า เช่น
มันมีหลายครั้งที่ เราเคยออกแบบ แล้วมันตัน รู้ว่ามาถึงตรงนี้ แล้วเจอปัญหานี้ แต่หาทางไปต่อไม่ได้ อย่างเคส Granularity เมื่อบทความก่อน พอมาอ่านแล้วจะรู้เลยว่า เราพลาดอะไรไป หรือ อ่อ มันมีท่าแบบนี้ในการพลิกแพลง หรือ อ่อ ถ้าติดแบบนี้ต้องทำแบบนี้
ซึ่งพอคนที่ไม่มีประสบการณ์อ่าน เขาจะ Treat ทุกอย่าง เท่าๆกันไป ทำให้ เกิดสภาวะ เออ แล้วไง
แต่ก็ยังมีสิ่งที่ได้อยู่คือ คนที่ไม่เคยออกแบบก็จะได้เห็นท่าที่หลากหลาย แต่การเลือกใช้จะยาก เพราะปัจจัยสำคัญในหัวข้อถัดไป
ส่วนคนที่เคยทำมาบ้าง โดยเฉพาะคนที่เคยออกแบบแล้วติด หรือเถียงคน implement ไม่ค่อยได้ จะ sharp ขึ้น นอกเหนือจะจะได้รู้จักท่าที่ไม่เคยเห็นแล้ว
ดังนั้นคำแนะนำคือ ซื้อเก็บไว้ แล้ว อ่านหลายๆ รอบ แต่ละปีก็จะได้ Feel ที่ต่างกัน ถือเป็นหนังสือขึ้นหิ้งได้
ไม่มี Best Practice ใน software architecture
น่าจะเป็นสิ่งที่เขากล่าวไว้แรกๆ ในหนังสือเลยครับว่า
No silver bullet in Software Architecture
ตั้งแต่การเลือกใช้ data base, transaction model และแม้กระทั่งเรื่องของ code reuse
อย่างในบทเรื่อง code reuse การ copy code ก็มีที่ยืนของมัน และได้เปรียบกว่าทำ shared service มารับด้วย
ดังนั้น ในหนังสือจะมีคำๆ นึงที่เขาจะใช้ตลอดคือ Trade Off
และเขาจะนิยาม Software Architecture ที่ดีว่า
ต้อง Balance ให้ทั้งระบบ มี Trade off ที่ต่ำที่สุด
Software Architecture ไม่ใช่เฉพาะมุม Technical
คำถามถัดมาคือ คำว่า Trade off ที่ตำ่ที่สุดมันวัดยังไง
สิ่งที่เขาแนะนำอย่างแรก คือ Technical อาจจะไม่ใช่ตัวเลือกแรก
สาเหตุสำคัญคือ เมื่อเรา Focus Technical เราจะไม่สนใจ ประโยชน์ใช้สอยที่แท้จริง ไม่สนใจการ Maintain ระบบ
เราต้อง Balance ตามความสำคัญที่เรากำหนดไว้ และสำคัญที่สุดคือ
ฟัง Stakeholder ให้ครบ
ในหนังสือจะมียกตัวอย่าง 2 เคสที่น่าสนใจคือ
คุณออกแบบของไม่สนใจ DBA แล้ว DBA จะทำงานยังไง ถ้าต้อง maintain database เป็น 100 ตัว แถม database type ก็ไม่เหมือนกันเลย พอมีปัญหาก็ไม่สนใจ โยนไปให้ DBA ที่รับภาระมากเกินไปซึ่งไม่ควร เพราะสุดท้ายมันคือ ระบบที่ทุกคนต้องรับผิดชอบร่วมกัน
หรือ
มีกรณีตัวอย่างเกี่ยวกับแบบสอบถาม ซึ่งตอนแรกตั้งใจว่าจะใช้ Relational DB แล้ว Join แบบสอบถามกับชุดคำถามกัน ปัญหาคือ ผู้ใช้มีความจำเป็นต้องปรับแบบสอบถามบ่อยๆ ต้องเปลี่ยน schema หลายครั้ง ซึ่งเปลี่ยนแต่ละครั้ง ต้องกินเวลาไปหลายเดือน ทำให้ไม่อยากจะเปลี่ยน ทำให้คุณภาพแบบสอบถามไม่ดี ตรงนี้ ถ้ามีการไปถามผู้ใช้งานให้เลือก Trade off ระหว่าง ประสิทธิภาพกับ การเปลี่ยนแปลง ผู้ใช้งานเลือกการเปลี่ยนแปลง ทำให้เขาสามารถแก้คำถามได้ในเวลาที่รวดเร็ว โดยยอมเสียพื้นที่กับ computation เพิ่ม ตรงนี้ก็จะได้ประโยชน์ในทางธุรกิจมากกว่า
Software Architecture is for Full Business Stack
เช่นเดียวกัน ตลอดเล่มของหนังสือ เวลาพูดถึง Trade off วิ่งครบองค์ประกอบ เพื่อที่จะทำได้ทั้ง Business
ดังนั้น เราจะเห็นการ เชื่อมกันระหว่าง Business domain, Technical Design, ไปจนถึง Software Development Life Cycle ที่เขาพยายามเชื่อมกันทั้งระบบ ไม่มีการ Isolate ใดๆ
ในเล่มนี้ก็จะเห็นคำว่า Domain Driven Design , Bounded Context โผล่มาเชื่อม ในการออกแบบ Microservice อยู่บ่อยครั้ง
หรือเวลาพูดถึงการเลือกท่าที่ควรจะใช้ ก็จะเอาปัจจัยเรื่องการ test มาเกี่ยวข้องด้วย เช่น ถ้าปรับท่านี้ ต้องยอมรับให้ได้นะว่า ต้อง retest ยก stack ที่จะมีปัจจัยเรื่องเวลามาเกี่ยวข้องเพิ่ม
การคิด concern ในเรื่องต่างๆ อาจจะไม่ได้มาครบพร้อมกันในทุกบท แต่ก็แซมๆ มาเรื่อยๆ เพื่อกระตุกให้คิดถึง การเชื่อมโยงกันด้วย
Software Architects use Engineering Discipline
ตลอดทั้งเล่ม Scenarios ของเขาจะทำสิ่งที่เป็น routine เหมือนๆ กันตลอดเวลา ซึ่งทำให้ใครอ่าน ไปเรื่อยๆ ก็จะจำได้ว่านี่เป็น Practice Method ที่เขาแนะนำในช่วงต้นเล่ม นั่นคือ
- ศึกษาวิธีการ
- พิจารณา Trade Off
- ดึง Stakeholder มาช่วยพิจารณา Trade Off ถ้าสิ่งที่ทำส่งผลกระทบต่อ Stakeholder เหล่านั้น
- เขียน Architecture Decision Record (ADR)
ทั้งหมดนี้ ทำซ้ำๆวนๆ ไปใน 15 บท โดยเฉพาะ เรื่องของ ADR นั้นสำคัญมาก
เพราะจะมีการบันทึกว่า ในช่วงนั้น Context เป็นอย่างไร ทำไมเราถึงตัดสินใจอย่างนั้น แล้วมี Trade Off อย่างไร
การบันทึกสิ่งต่างๆ ไว้ จะทำให้เข้าใจการออกแบบมากขึ้นเมื่อมาทบทวนหรือ มีเหตุให้ต้องเปลี่ยนการออกแบบนั่นเอง
สรุป
ถ้าใครอยากรู้ว่าเวลาตัดสินใจเรื่องแบบนี้ เขาทำอะไรยังไง มีท่าไหนบ้าง เล่มนี้เป็นอะไรที่น่าสนใจ
ใครที่ไม่มีความรู้อะไรเลย แวะมาอ่าน แนะนำให้ไปอ่าน เล่มก่อนหน้าก่อน ไม่งั้น ธาตุไฟจะแตกเอา แค่ Pattern ต่างๆ ในเล่มมันก็เยอะแยะมากมายแล้ว
ไม่ได้สรุป Pattern อะไรไว้มากนะครับ ถึงเวลาใช้ คงเปิดหนังสือ มาดู reference detail กันอีกที
Reference:
- Software Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures, https://www.amazon.com/Software-Architecture-Trade-Off-Distributed-Architectures/dp/1492086894
- Problems with Consultants, Steve Job, MIT Sloan Distinguished Speaker Series 1992, https://www.youtube.com/watch?v=Gk-9Fd2mEnI&t=925s