"Just Enough Software Architecture" ที่ตีพิมพ์ในปี 2010
(georgefairbanks.com)- Just Enough Software Architecture ของ George Fairbanks เริ่มต้นจากโจทย์ที่ว่า เพียงแค่รู้ไวยากรณ์ของภาษา หรือมีความรู้ UML ก็ยังออกแบบระบบเชิงวัตถุและสถาปัตยกรรมที่ดีได้ยาก
- แกนสำคัญคือ risk-driven architecting โดยเมื่อความเสี่ยงต่ำก็หลีกเลี่ยงการออกแบบที่มากเกินจำเป็น และเมื่อมีความเสี่ยงที่คุกคามความสำเร็จ ก็ใช้เทคนิคที่เข้มงวดมากขึ้น
- หนังสือมองว่าสถาปัตยกรรมไม่ใช่สิ่งผูกขาดของผู้เชี่ยวชาญบางคน แต่เป็น ความสามารถที่นักพัฒนาทุกคนควรเข้าใจ พร้อมอธิบายว่าข้อจำกัดและการเปลี่ยนแปลงเล็กน้อยส่งผลต่อคุณสมบัติของระบบอย่างไร
- เน้นที่ เทคนิคเชิงวิศวกรรม มากกว่ากระบวนการพัฒนาหรือการบริหารองค์กร เพื่อให้ใช้การทำโมเดลและการวิเคราะห์สถาปัตยกรรมรับมือกับ trade-off ในการออกแบบของปัญหาขนาดกลางถึงใหญ่
- โครงสร้างแบ่งเป็น 2 ส่วนคือ risk-driven software architecture และ architecture modeling โดยครอบคลุม domain model, design model, code model, encapsulation และนามธรรมอย่าง component กับ connector
ความสามารถด้านการออกแบบที่มีมากกว่าความรู้ภาษาและ UML
- ผู้เขียนเริ่มจากความตั้งใจว่าจะสร้างหนังสือที่ตัวเองเคยต้องการตอนเริ่มต้นพัฒนาซอฟต์แวร์
- ในเวลานั้นมีหนังสือด้านภาษาโปรแกรมและการเขียนโปรแกรมเชิงวัตถุอยู่แล้ว แต่หนังสือที่ว่าด้วย การออกแบบ ยังมีน้อย
- แค่รู้ความสามารถของภาษา C++ ก็ยังไม่พอจะออกแบบระบบเชิงวัตถุที่ดีได้ และแค่รู้ UML ก็ยังไม่พอจะออกแบบสถาปัตยกรรมระบบที่ดีได้เช่นกัน
การทำสถาปัตยกรรมที่ปรับตามความเสี่ยง
- หัวใจของหนังสือคือ risk-driven architecting
- เมื่อความเสี่ยงต่ำ ก็ไม่จำเป็นต้องออกแบบอย่างละเอียดมาก แต่เมื่อมีความเสี่ยงที่คุกคามความสำเร็จ การออกแบบแบบคร่าว ๆ ก็ไม่เพียงพอ
- ผู้สนับสนุน Agile หลายคนมองว่าการออกแบบล่วงหน้าบางส่วนมีประโยชน์ และหนังสือเล่มนี้พูดถึงวิธีทำ “สถาปัตยกรรมเท่าที่จำเป็น”
- หนังสือชี้ทางให้หลีกเลี่ยงกระบวนการแบบ “one size fits all” และปรับความพยายามด้านสถาปัตยกรรมกับการออกแบบให้สอดคล้องกับความเสี่ยงที่เผชิญอยู่
- เทคนิคส่วนใหญ่สามารถปรับระดับความเข้มได้ตั้งแต่ quick-and-dirty ไปจนถึงระดับที่เข้มงวดมาก
ทำให้สถาปัตยกรรมเป็นภาษาของนักพัฒนาทุกคน
- หนังสือมีเป้าหมายในการ ทำให้สถาปัตยกรรมเข้าถึงได้สำหรับทุกคน
- ในองค์กรอาจมี software architect อยู่ หรือผู้อ่านเองก็อาจเป็น architect ก็ได้
- architect จำนวนมากต้องการให้นักพัฒนาทุกคนเข้าใจสถาปัตยกรรม
- หากนักพัฒนาไม่เข้าใจเหตุผลของข้อจำกัด และไม่เข้าใจว่าการเปลี่ยนแปลงเล็กน้อยส่งผลต่อคุณสมบัติของระบบอย่างไร การตัดสินใจด้านการออกแบบก็อาจสั่นคลอนได้
- สถาปัตยกรรมไม่ใช่เรื่องของ architect เท่านั้น แต่เป็นเรื่องที่เกี่ยวข้องกับนักพัฒนาซอฟต์แวร์ทุกคน
ความรู้เชิงกระบวนการและความรู้เชิงประกาศ
- หนังสือมุ่งเน้นการสร้าง ความรู้เชิงประกาศ
- ความสามารถในการตีลูกเทนนิส กับการรู้ว่าทำไมจึงตีได้ เป็นคนละเรื่องกัน ซึ่งสอดคล้องกับความต่างระหว่างความรู้เชิงกระบวนการและความรู้เชิงประกาศ
- หากคุณเป็นผู้เชี่ยวชาญที่ออกแบบและสร้างระบบอยู่แล้ว คุณอาจเคยใช้หลายเทคนิคในหนังสือเล่มนี้มาก่อน
- หนังสือจะช่วยให้คุณตระหนักชัดขึ้นถึงสิ่งที่ทำมาโดยตลอด และตั้งชื่อให้กับแนวคิดเหล่านั้น
- ความรู้เชิงประกาศแบบนี้ช่วยเพิ่มความสามารถในการเป็นพี่เลี้ยงให้นักพัฒนามือใหม่ได้
เน้นวิศวกรรมมากกว่ากระบวนการ
- ผู้ที่ออกแบบและสร้างระบบซอฟต์แวร์ต้องรับมือกับปัญหาหลายด้านพร้อมกัน เช่น กำหนดการ ทรัพยากรที่ผูกพันไว้ และความต้องการของผู้มีส่วนได้ส่วนเสีย
- หนังสือด้าน software architecture จำนวนมากได้พูดถึงกระบวนการพัฒนาและโครงสร้างองค์กรไปแล้ว
- หนังสือเล่มนี้ต่างออกไป โดยเน้นที่ ส่วนทางเทคนิค ของการพัฒนาซอฟต์แวร์ และงานวิศวกรรมที่ทำให้ระบบทำงานได้จริง
- หนังสือช่วยให้สามารถสร้างโมเดลและวิเคราะห์สถาปัตยกรรม เพื่อทำ trade-off ด้านการออกแบบอย่างมีหลักการ
- อธิบายเทคนิคที่ใช้ให้เหตุผลกับปัญหาขนาดกลางถึงใหญ่ และยังชี้ทางไปสู่แหล่งเรียนรู้เทคนิคเฉพาะทางที่ลึกขึ้น
การออกแบบเชิงปฏิบัติที่สลับไปมาระหว่างหลายระดับนามธรรม
- หนังสือมองสถาปัตยกรรมเป็นกิจกรรมการออกแบบเชิงปฏิบัติ
- software architecture เป็นการออกแบบซอฟต์แวร์ประเภทหนึ่ง โดยการตัดสินใจด้านการออกแบบส่งผลต่อสถาปัตยกรรม และสถาปัตยกรรมก็ส่งผลต่อการออกแบบเช่นกัน
- นักพัฒนาที่เก่งจะเจาะลึกอุปสรรคเพื่อทำความเข้าใจอย่างละเอียด แล้วเชื่อมธรรมชาติของอุปสรรคนั้นเข้ากับสถาปัตยกรรมโดยรวม
- เพื่อสะท้อนพฤติกรรมแบบ drill-down/pop-up นี้ หนังสือจึงครอบคลุมโมเดลในหลายระดับนามธรรม ตั้งแต่สถาปัตยกรรมไปจนถึงการออกแบบโครงสร้างข้อมูล
โครงสร้างและรูปแบบการให้บริการ
- หนังสือแบ่งเป็น 2 ส่วน
- Part I: Risk-Driven Software Architecture
- Part II: Architecture Modeling
- สามารถดาวน์โหลดบางบทตัวอย่างเป็น PDF ไฟล์เดียวได้
- e-book วางจำหน่ายผ่าน Google Play โดยมี 3 รูปแบบคือ ePub, Mobi และ PDF แบบไม่มี DRM ในราคา $9.99
- ฉบับปกแข็งมีให้ที่ Amazon
- Google Books และ Amazon Search Inside มีเวอร์ชันที่ค้นหาข้อความทั้งเล่มได้
ขอบเขตที่ครอบคลุมและสิ่งที่ไม่ครอบคลุม
- หนังสือเน้นที่ software architecture ที่เกี่ยวข้องกับการสร้างซอฟต์แวร์
- อธิบายเทคนิคที่ทำให้ซอฟต์แวร์ตอบโจทย์ข้อกำหนดเชิงวิศวกรรม
- เนื่องจากเทคนิคเชิงวิศวกรรมเหล่านี้โดยมากเป็นอิสระจากกระบวนการ หนังสือจึงแทบไม่ยึดติดกับกระบวนการเช่นกัน
- หนังสือไม่ครอบคลุมคำแนะนำด้านงานบริหาร เช่น
- ความรับผิดชอบเชิงการเมืองของ architect
- ควรจัดประชุมบางประเภทเมื่อใด
- วิธีเก็บ requirement จากผู้มีส่วนได้ส่วนเสีย
Part I: risk-driven software architecture
- แม้นิยาม software architecture ให้แม่นยำจะทำได้ยาก แต่ลักษณะบางอย่างนั้นชัดเจน
- นักพัฒนาซอฟต์แวร์แก้ปัญหาขนาดใหญ่และซับซ้อนด้วย นามธรรมและโมเดล เช่นเดียวกับวิศวกรในสาขาอื่น
- software architecture ทำหน้าที่คล้ายโครงของระบบ ส่งผลต่อคุณลักษณะเชิงคุณภาพ ตั้งฉากกับฟังก์ชันการทำงาน และส่งผลต่อคุณสมบัติของระบบผ่านข้อจำกัดต่าง ๆ
- สถาปัตยกรรมมีความสำคัญเป็นพิเศษในสถานการณ์ต่อไปนี้
- เมื่อพื้นที่ของคำตอบมีขนาดเล็ก
- เมื่อความเสี่ยงของความล้มเหลวสูง
- เมื่อต้องเผชิญข้อกำหนดด้านคุณลักษณะเชิงคุณภาพที่ยาก
- วิธีการออกแบบสามารถเลือกได้ระหว่าง architecture-indifferent design, architecture-focused design และ architecture hoisting
- ขั้นตอนหลักของโมเดลที่ขับเคลื่อนด้วยความเสี่ยงนั้นเรียบง่าย
- ระบุและจัดลำดับความสำคัญของความเสี่ยง
- เลือกชุดเทคนิคแล้วนำไปใช้
- ประเมินการลดลงของความเสี่ยง
- บทที่ 4 แสดงการประยุกต์ใช้โมเดลนี้กับตัวอย่างระบบ Home Media Player
- การสื่อสารภายในทีม
- การผสานรวม COTS component
- การทำให้ metadata มีความสอดคล้องกัน
- Part I ปิดท้ายด้วยคำแนะนำเกี่ยวกับการใช้โมเดลและ software architecture
- ใช้โมเดลเพื่อแก้ปัญหา
- เพิ่มข้อจำกัดอย่างรอบคอบ
- โฟกัสที่ความเสี่ยง
- กระจายความสามารถด้านสถาปัตยกรรมไปทั้งทีม
Part II: architecture modeling
- Part II มุ่งช่วยให้ผู้อ่านสร้าง conceptual model ของ software architecture
- โครงสร้างโมเดลพื้นฐานมี 3 แบบ
- domain model: สอดคล้องกับสิ่งต่าง ๆ ในโลกจริง
- design model: แสดงการออกแบบของซอฟต์แวร์ที่กำลังสร้าง
- code model: สอดคล้องกับ source code
- สามารถสร้าง view ซึ่งเป็นโมเดลเพิ่มเติมที่แสดงรายละเอียดที่เลือกไว้ และ view เหล่านี้สามารถจัดกลุ่มเป็น viewtype ได้
- การสร้างขอบเขตของ encapsulation เป็นทักษะสำคัญของ software architecture
- ผู้ใช้ component หรือ module สามารถละเลยการทำงานภายใน แล้วไปโฟกัสกับปัญหายากด้านอื่นได้
- ผู้สร้าง component หรือ module ที่ถูก encapsulate ไว้ มีอิสระในการเปลี่ยน implementation โดยไม่กระทบผู้ใช้
- อิสระนี้จะเกิดขึ้นได้ก็ต่อเมื่อ encapsulation มีประสิทธิภาพจริง หนังสือจึงครอบคลุมเทคนิคที่ช่วยรับประกันเรื่องนี้
- หนังสือผสานเทคนิคด้าน software architecture จากหลายแหล่ง
- เทคนิคที่เน้นคุณลักษณะเชิงคุณภาพ
- เทคนิคที่เน้นฟังก์ชันการทำงาน
- วิธีเชิงปฏิบัติในการสร้างโมเดลที่มีประสิทธิภาพ
- วิธี debug โมเดล
- Part II ยังพูดถึงคำแนะนำในการใช้โมเดลอย่างมีประสิทธิภาพ พร้อมทั้ง กับดัก ที่อาจพบเจอในเทคนิคเหล่านี้
- เป้าหมายสุดท้ายคือการมี conceptual model ที่ลุ่มลึกเกี่ยวกับนามธรรมและความสัมพันธ์ เพื่อให้มองระบบซอฟต์แวร์ได้เหมือนโค้ชที่มองการแข่งขัน
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
มีคนบอกว่าถ้าความเสี่ยงด้านการจัดการโครงการคือ “นักพัฒนาคนสำคัญถูกรถบัสชน” และความเสี่ยงด้านวิศวกรรมซอฟต์แวร์คือ “เซิร์ฟเวอร์อาจขยายรองรับผู้ใช้ได้ไม่ถึง 1000 คน” ก็ควรแยกสองเรื่องนี้ออกจากกัน แต่จากประสบการณ์ของฉัน มันแทบไม่ได้แยกขาดกันแบบนั้น
คุณภาพและโครงสร้างของโค้ด การทดสอบและเอกสารประกอบ รวมถึงการใช้เครื่องมือมาตรฐานที่เป็นที่รู้จัก ล้วนช่วยได้ทั้งสองด้าน
เพราะแบบนี้ฉันเลยหยิบสมมติฐานว่า “ถ้าถูกรถบัสชนล่ะ?” ขึ้นมาคุยกับเพื่อนร่วมงานหรือหัวหน้าหลายครั้ง และมันกลายเป็นแรงกดดันให้สร้างซอฟต์แวร์ที่ทำซ้ำได้และเข้าใจได้
ถ้าอยากเลี่ยงนัยลบเรื่องการบาดเจ็บหรือความตาย ใช้คำว่า “ถ้าถูกลอตเตอรี่ล่ะ?” ก็น่าจะดีกว่า
แก่นของคำว่า “ถูกรถบัสชน” คือ ไม่มีเวลาเตรียมตัวเลยแม้แต่น้อย ไม่ว่าเจ้าตัวจะนิสัยแบบไหนก็ตาม และนั่นแหละที่สร้างแรงกดดันให้ต้องแชร์ข้อมูลกันตั้งแต่วันนี้
น่าเสียดายที่ฉันยังหาคำเชิงบวกที่ให้ความหมายเดียวกันไม่ได้
ทั้งสองคนกลับมาทำงานหลังจากนั้นประมาณหนึ่งสัปดาห์ เลยต้องหาตัวอย่างภัยพิบัติมาตรฐานแบบอื่นแทน
เวลาจะสื่อประเด็นนี้ ฉันมักใช้คำว่า “คนถัดไป” มากกว่า
สถานการณ์ที่แย่กว่านั้นคือภาวะหมดไฟ เพราะจำนวนคนยังเท่าเดิม แต่ในทางจิตใจเขาออกจากงานไปแล้ว
ฉันเคยเห็นหลายบริษัทที่แม้แค่นั้นก็รับมือไม่ไหว ทั้งที่ไม่ใช่การลาออกถาวร
หรือจะใช้ถ้อยคำแบบ “เพิ่ม bus factor” ที่โฟกัสแรงจูงใจเรื่องการกำจัดจุดล้มเหลวเพียงจุดเดียวก็ได้
ถ้าจะทำการวิเคราะห์สาเหตุรากจริง ๆ ก็ไม่ควรหยุดแค่ “Larry ถูกรถบัสชน / ถูกลอตเตอรี่” เพราะนั่นไม่ใช่ปัญหาที่แท้จริง
สถาปัตยกรรมเพื่อสถาปัตยกรรมเองเป็นสิ่งที่แย่ที่สุด เพราะมันเพิ่ม ความซับซ้อน โดยไม่จำเป็น
เป้าหมายสูงสุดของสถาปัตยกรรมที่ดีคือการลดต้นทุน
ถ้าสถาปัตยกรรมทำให้การพัฒนาและบำรุงรักษาโค้ดใช้เวลามากขึ้น สถาปัตยกรรมนั้นก็ล้มเหลว
มันเป็นเรื่องของการ หาสมดุล เสมอ
เพราะฉะนั้นจึงไม่มีสถาปัตยกรรมที่ถูกต้องเพียงแบบเดียว การเลือกขึ้นอยู่กับบริบท และบางครั้งก็ต้องประเมินใหม่
ความยืดหยุ่นมีประโยชน์เป็นพิเศษ เพราะช่วยให้ปรับสถาปัตยกรรมได้ในระดับหนึ่งและยังคงประสิทธิภาพไว้ได้แม้สถานการณ์เปลี่ยนไป
การลดต้นทุนอาจเป็นหนึ่งในนั้น
“โมเดลขับเคลื่อนด้วยความเสี่ยงนำทางให้นักพัฒนาใช้เทคนิคทางสถาปัตยกรรมเท่าที่จำเป็นเพื่อลดความเสี่ยงที่เร่งด่วนที่สุด ‘ความเสี่ยงของฉันคืออะไร? เทคนิคที่ดีที่สุดในการลดมันคืออะไร? ความเสี่ยงถูกบรรเทาแล้ว และตอนนี้ฉันเริ่มหรือกลับไปเขียนโค้ดต่อได้หรือยัง?’ นี่คือกระบวนการตั้งคำถามอย่างต่อเนื่อง โมเดลขับเคลื่อนด้วยความเสี่ยงสรุปได้เป็นสามขั้นตอน: 1. ระบุและจัดลำดับความสำคัญของความเสี่ยง 2. เลือกและใช้ชุดเทคนิค 3. ประเมินการลดลงของความเสี่ยง”
เราไม่อยากเสียเวลากับเทคนิคที่มีผลกระทบน้อย และก็ไม่อยากมองข้ามความเสี่ยงที่คุกคามโครงการ
การจะสร้างระบบที่ประสบความสำเร็จได้ ต้องเลือกเส้นทางที่ใช้เวลาอย่างมีประสิทธิภาพที่สุด ซึ่งหมายถึงการใช้เทคนิคด้านสถาปัตยกรรมและการออกแบบเพื่อจัดการความเสี่ยงก็ต่อเมื่อมีความเสี่ยงเป็นแรงขับ
ตัวอย่างเช่น “สถาปัตยกรรม” อาจรวมถึงการใช้รูปแบบไคลเอนต์-เซิร์ฟเวอร์ที่เซิร์ฟเวอร์ไม่เริ่มทำงานก่อน แต่เพียงตอบสนองต่อคำขอจากไคลเอนต์
วิธีนี้อาจเหมาะกับปัญหานั้นมากหรืออาจไม่เหมาะก็ได้
https://www.georgefairbanks.com/assets/jesa/Just_Enough_Soft...
สถาปนิกเทคนิคที่รับเงินสูงจำนวนมากแทบไม่ได้ทำอะไร แต่กลับยัดเยียดแพตเทิร์นเลวร้ายให้วิศวกรซอฟต์แวร์ต้องไปแก้ภายใต้ข้อจำกัดไร้เหตุผลอย่างเส้นตาย
สถาปัตยกรรมที่ดีช่วยให้มีคนเข้ามามีส่วนร่วมกับผลิตภัณฑ์ได้มากขึ้น
ถ้าตีพิมพ์ออกมาตั้งแต่ปี 2010 ก็สงสัยว่าหลังจากนั้นมันยังใช้การได้ดีแค่ไหน
ชอบ “Design It” เพราะมีเวิร์กช็อปและกิจกรรมที่ดีสำหรับคนสายเทคนิคที่ต้องโต้ตอบกับผู้มีส่วนได้ส่วนเสียหรือลูกค้า
ยิ่งเกี่ยวข้องมากขึ้นเพราะทำงานในบทบาทที่ปรึกษา และก็ดีที่มันไม่พึ่งพา architecture style ของเทคโนโลยีเฉพาะที่เปลี่ยนบ่อยจนเกินไป
พูดในแง่ของ หลักการ ที่แท้จริง ไม่ใช่ตามกระแส
ผู้เขียนใช้เวลาไปกับงานเขียนเชิงแนวคิดเรื่อง mindset ค่อนข้างมาก และแตะเรื่องเทคนิคเฉพาะแบบเบา ๆ แต่ก็มีแหล่งให้อ่านต่อ
มันช่วยให้ทีมจัดการกับแนวคิดด้านสถาปัตยกรรมผ่านกิจกรรมที่เป็นรูปธรรม และสุดท้ายก็เผยให้เห็นว่าอะไรสำคัญจริง ๆ
หนังสือของผมพยายามพูดถึงแนวคิดใหญ่ ๆ แบบนั้นตรง ๆ แต่ก็เห็นชัดว่ามันสอนยากเพราะหัวข้อนี้เป็นนามธรรมมาก
มีแนวคิดอะไรบ้างที่ยังอยู่รอดมาตั้งแต่ปี 2010? บางระบบปฏิบัติการเป็น microkernel และบางระบบปฏิบัติการเป็น monolithic
ฐานข้อมูลบางตัวเป็น relational และบางตัวเน้นเอกสาร
แอปพลิเคชันบางตัวเป็น client-server และบางตัวเป็น peer to peer
การแบ่งแบบนี้น่าจะคงอยู่ยาวนาน และถึงจะย้อนกลับมาอีก 100 ปี ตัวอย่างอย่าง Windows, Oracle, Salesforce อาจหายไปแล้ว แต่เราก็น่าจะยังเห็นระบบที่มีการออกแบบแบบนั้นอยู่
และเราก็ยังจะพูดถึงคุณภาพอย่างความง่ายในการแก้ไขหรือ latency อยู่ดี
สาขา software architecture คือการระบุ นามธรรมที่คงอยู่ยาวนาน เหล่านี้
มีคำอธิบายที่กระชับใน [2]
“บทคัดย่อ: software architecture คือชุดของนามธรรมที่ช่วยให้เราใช้เหตุผลกับซอฟต์แวร์ที่กำลังจะสร้างหรือที่สร้างไปแล้วได้ ในสาขาของเรา นามธรรมขนาดเล็กมีมานานมากแล้ว แต่ต้องใช้เวลาหลายสิบปีกว่าที่นามธรรมขนาดใหญ่กว่า เช่น quality attributes, information hiding, components and connectors, multiple views, และ architecture styles จะสะสมขึ้นมา เมื่อออกแบบระบบ เราจะถักทอนามธรรมเหล่านี้เข้าด้วยกันเพื่อคงสายโซ่ของความตั้งใจ และทำให้ระบบที่ออกแบบทำงานในสิ่งที่เราต้องการ เมื่อ 20 ปีก่อน Martin Fowler ได้ตีพิมพ์บทความทรงอิทธิพล ‘Who Needs an Architect?’ ในวารสารนี้ ถึงเวลาแล้วที่นักพัฒนาจะมอง software architecture กันใหม่ และมองมันเป็นชุดของนามธรรมที่ทำให้เราใช้เหตุผลกับซอฟต์แวร์ได้”
[1] Michael Keeling, Design It: From Programmer to Software Architect, https://pragprog.com/titles/mkdsa/design-it/
[2] George Fairbanks, Software Architecture is a Set of Abstractions Jul 2023. https://www.computer.org/csdl/magazine/so/2023/04/10176187/1...
A Philosophy of Software Design ของ John Ousterhout ก็มีประโยชน์
มีคำแนะนำที่เข้าใจง่ายและแข็งแรงดีมาก พร้อมตัวอย่างมากมาย
ไม่รู้จักหนังสือเล่มนี้โดยตรง แต่รู้จักบทความของผู้เขียนเกี่ยวกับ Intellectual Control และมองว่าลุ่มลึกมาก
https://www.georgefairbanks.com/ieee-software-v37-n3-may-202...
https://johnwhiles.com/posts/programming-as-theory
ที่บริษัทเก่าเคยส่งต่อกันอ่านหนังสือ Software Architecture for Developers ของ Simon Brown: https://leanpub.com/b/software-architecture
ผมยังมีมันอยู่แค่ในรายการอ่าน แม้ว่าจะย้ายออกจากบริษัทนั้นแล้ว แต่ก็ได้รับคำแนะนำอย่างหนักแน่น
บริษัทนั้นยังใช้ C4 model ในการทำเอกสารสถาปัตยกรรมด้วย
เลยสงสัยว่ามีใครที่นี่เคยอ่านไหม
งานบรรยายด้านสถาปัตยกรรมของเขา [1] และเวิร์กช็อปมีประสิทธิภาพมากเป็นพิเศษ และภาษาโมเดลสถาปัตยกรรม C4 [2] ก็เริ่มได้รับแรงส่งจริง ๆ แล้ว
ผมก็มีวิดีโอ YouTube อยู่เหมือนกัน [3] แต่ไม่ได้มีประสิทธิภาพเท่าเขา
[1] https://www.youtube.com/results?search_query=simon+brown+arc...
[2] https://c4model.com/
[3] https://www.youtube.com/playlist?list=PLRqKmfi2Jh3uoMnZdaWmC...
สำหรับ methodology นี้ ผมว่าชื่อ “ขึ้นกับความเสี่ยง” น่าจะดีกว่าเยอะ
ทำไมนักเขียนโปรแกรมถึงชอบคำว่า “[X]-driven” กันนักนะ?
เหมือนเพลานี้ขับเฟืองนั้น แล้วเฟืองนั้นก็ขับล้อนี้
เป็นการพูดแบบย่อของคำว่า “อะไรคือกลไกที่ทรงพลังที่สุดในเครื่องจักรแห่งความคิดอันซับซ้อนนี้”
เมื่อหลายปีก่อนที่บริษัท เราเคยทำชมรมอ่านหนังสือเล่มนี้ และรู้สึกว่ามัน ซ้ำไปซ้ำมา มาก
สงสัยว่าหนังสือเล่มนี้เป็นแหล่งข้อมูลที่ดีไหมสำหรับคนที่กำลังเริ่มโปรเจกต์โอเพนซอร์สที่ไม่เล็กน้อย
หรือสำหรับผู้ก่อตั้งเดี่ยวจะได้ประโยชน์คุ้มค่าหรือไม่ และอยากได้คำแนะนำหนังสือหรือแหล่งข้อมูลอื่นที่มีประโยชน์สำหรับ นักพัฒนาเดี่ยว
สถาปัตยกรรมซอฟต์แวร์คล้ายกับสถาปัตยกรรมทั่วไป แต่ในโลกซอฟต์แวร์ยังไม่มีบุคคลแบบ Isaac Newton จึงเหมือนยังไม่มี วิศวกรรมโยธา อยู่จริง
จนถึงตอนนี้คิดว่าคนที่ใกล้เคียงที่สุดคือ Claude Shannon
เพราะเราไม่มีแม้แต่ หน่วยวัด
เรายังอยู่ในขั้นของวิศวกรรมซอฟต์แวร์ที่แค่ “หวังว่ามันจะไม่พัง”
สิ่งนี้ส่งผลอย่างมากต่อผลิตภาพที่รายงานด้วยตนเอง
ตัวอย่างเช่น การปั่นจักรยานอาจให้ความรู้สึกว่าเร็วกว่าการขับรถด้วยความเร็ว 30 ไมล์ต่อชั่วโมงบนถนนชานเมืองสายเล็กที่มีป้ายหยุดถี่ ๆ โดยปิดกระจกไว้
แต่โดยทั่วไปแล้วคนขับรถจะไปถึงจุดหมายที่ห่างออกไป 20 บล็อกได้เร็วกว่าอย่างมาก
ถ้าไม่มีหน่วยวัด ทุกคนก็คงเถียงกันว่าจักรยานเร็วกว่า
ตอนนี้วิศวกรรมซอฟต์แวร์ก็อยู่ในสภาพแบบนั้น
การสร้างซอฟต์แวร์ไม่ได้เหมือนกับการสร้างสะพานหรือตึกสูงเลย แต่ใกล้เคียงกับการ ออกแบบ สิ่งเหล่านั้นมากกว่า
ในโครงการก่อสร้างขนาดใหญ่ จะออกแบบก่อนแล้วค่อยสร้าง และการออกแบบนี้เป็นงานมหาศาล
ต้องคิดทุกอย่าง รันการจำลอง ปรึกษาผู้มีส่วนได้ส่วนเสีย ทำความเข้าใจข้อกำหนดและข้อจำกัด และคำนึงถึงต้นทุนวัสดุ น้ำหนัก ฯลฯ
ในโครงการก่อสร้างขนาดใหญ่ อาจใช้เวลาเป็นเดือนหรือเป็นปีไปกับการทำแบบเพียงอย่างเดียว และผลลัพธ์คือแบบพิมพ์เขียวที่ละเอียดมากซึ่งครอบคลุมแทบทุกด้านของการก่อสร้าง
ที่จริงแล้วสิ่งนี้ค่อนข้างคล้ายกับการสร้างซอฟต์แวร์
โครงการออกแบบแบบนี้มีความไม่แน่นอนและความเสี่ยงสูง
ถึงอย่างนั้น การรู้ให้ได้ตั้งแต่ก่อนเริ่มใช้ทรัพยากรราคาแพงอย่างแรงงานจำนวนมาก คอนกรีต และเหล็ก ว่าทั้งหมดนั้นผิดพลาด ย่อมดีกว่า
แต่คุณเคยได้ยินสถาปนิกบอกไหมว่าจะทำแบบสำหรับการทำแบบเพื่อบรรเทาความเสี่ยงนี้? ไม่มีเรื่องแบบนั้น
อย่างมากที่สุดก็อาจมีภาพสเก็ตช์หรือรูปวาดบนกระดาษเช็ดปากในช่วงใดช่วงหนึ่ง
SpaceX ได้นำองค์ประกอบแบบ Agile บางส่วนเข้าไปใช้ในงานวิศวกรรม ซึ่งเป็นสิ่งที่เรียนรู้มาจากการพัฒนาซอฟต์แวร์
ในซอฟต์แวร์ แบบพิมพ์เขียวที่เสร็จสมบูรณ์สามารถนำไปรันได้
กระบวนการสร้างแบบพิมพ์เขียวนั้นทำด้วยมือ แต่กระบวนการสร้างซอฟต์แวร์จากแบบพิมพ์เขียวนั้นมักถูกทำให้เป็นอัตโนมัติด้วยคอมไพเลอร์และเครื่องมืออื่น ๆ และมีต้นทุนต่ำมาก จึงเป็นสิ่งที่นักพัฒนาทำอยู่ตลอด
แน่นอนว่าในอดีตก็ไม่ได้เป็นแบบนี้เสมอไป
กระบวนการสร้างแบบพิมพ์เขียวที่รันได้ย่อมมีความเสี่ยงมาก และอาจมีการออกแบบบนกระดาษเช็ดปากหรือไวต์บอร์ดอยู่ประปราย
แต่แนวคิดที่จะทำการออกแบบให้สมบูรณ์ก่อน แล้วค่อยทำการนำไปสร้างจริงให้สมบูรณ์ทีหลัง หรือก็คือแนวทางแบบ Waterfall นั้น ไม่เคยใช้ได้ผลอย่างแท้จริงกับซอฟต์แวร์
ยกเว้นบางกรณี โดยปกติแล้วจะไม่มีแบบสำหรับแบบพิมพ์เขียวอีกที
ถ้าไปอ่านบทความต้นฉบับเรื่อง Waterfall ของ Royce จะพบว่าแท้จริงแล้วไม่มีคำว่า Waterfall ปรากฏเลย และเพียงแค่เสนออย่างเลือนรางว่าการทำซ้ำอาจเป็นความคิดที่ดี
อย่างน้อยก็ในทำนองว่าควรลองทำมากกว่าหนึ่งครั้ง
เขาเข้าใจอย่างชัดเจนว่าการออกแบบครั้งแรกมีโอกาสผิดพลาดสูง
Agile คือการปรับให้เหมาะสมโดยตัด ขั้นตอนมูลค่าต่ำ ของการสร้างแบบสำหรับแบบพิมพ์เขียวออกไป ซึ่งจะเห็นชัดเมื่อมีการทำซ้ำหลายครั้ง
เพียงแต่โดยทั่วไปเรามักเมินมันนอกเหนือจากบางโดเมน
ตัวอย่างเช่น ถ้ามองสรุปและสารบัญนี้แบบผ่าน ๆ ดูเหมือนแทบไม่มีหรือไม่มีเลยการกล่าวถึงเมตริกด้านประสิทธิภาพ
ถ้าไม่คำนึงว่าคอมพิวเตอร์ทำอะไรจริง ๆ แล้วสถาปัตยกรรมจะมีประโยชน์อะไร?
แม้ในแง่ผลิตภาพของนักพัฒนาหรือส่วนติดต่อผู้ใช้ ทำไมถึงไม่มีโมเดลทางคณิตศาสตร์ที่อธิบาย mental stack ที่จำเป็นต่อการพัฒนา เปลี่ยนแปลง ขยาย และที่สำคัญกว่านั้นคือการใช้งานซอฟต์แวร์?
ทรัพยากรการคำนวณ ไม่ว่าจะของมนุษย์หรือของเครื่องจักร ต่างก็มีผลกระทบจริงและวัดได้ต่อการปฏิสัมพันธ์กับซอฟต์แวร์ในฐานะนักพัฒนาหรือผู้ใช้ แล้วทำไมจึงแทบไม่ถูกนำมาพิจารณา?
ตัวอย่างเช่น Westminster Palace มีองค์ประกอบด้านวิศวกรรมโยธาอย่างชัดเจน แต่ลักษณะสำคัญอย่างพื้นผิวที่วิจิตร หอนาฬิกาเชิงสัญลักษณ์ และผังภายใน ส่วนใหญ่ถูกกำหนดโดยการเลือกเชิงหน้าที่และเชิงสุนทรียะ
ซอฟต์แวร์จำนวนมากก็เป็นเช่นเดียวกัน