ในโปรเจ็คที่มีขนาดใหญ่ มีคนเกี่ยวข้องเยอะ และมีผลกระทบเยอะในทุกการตัดสินใจ น่าจะเคยเจอการประชุมที่มีการถกเถียงกันเรื่องเหตุผลของผลลัพธ์ต่างๆ เช่น ทำงานไปเกือบเสร็จแล้ว แต่ลูกค้าหรือทีม Infrastructure ถามกลับว่า ทำไมเราตัดสินใจเลือก Architecture แบบนี้ หรือ Technology นี้? ตอนนั้นคิดอะไรอยู่? มีข้อจำกัดอะไร ถึงต้องเลือกแบบนี้?
สิ่งที่เราทำคือ ไปค้นหาหลักฐานการประชุม เช่น สมุดที่จดไว้ส่วนตัว หรือ Minute of Meeting ซึ่งในเอกสารเหล่านั้น มักเป็นการบันทึกเฉพาะผลลัพธ์ที่คุยกัน และน้อยคนมากที่จะจดละเอียดถึงเหตุผลของการตัดสินใจ
ดังนั้น เรามาทำความรู้จักกับ Architecture Decision Record (AR) กันดีกว่าครับ เพื่อใช้เป็นไกด์ไลน์บันทึกในการตัดสินใจเรื่องต่างๆ ที่มีประสิทธิภาพมาก
Architecture Decision Record (ADR) คืออะไร
โลกของธุรกิจมีความเปลี่ยนแปลงอยู่ตลอดเวลา ซอร์ฟแวร์เองก็ต้องพัฒนาปรับปรุงตามไปด้วย สิ่งที่เคยเหมาะสม ณ เวลาหนึ่ง แต่ปัจจุบันอาจจะไม่เหมาะสมแล้ว และทุกครั้งที่เปลี่ยนแปลงไป มันมีผลกระทบเสมอ
ADR เป็นเครื่องมือหนึ่ง ที่เป็นรูปแบบการบันทึกการตัดสินใจ เพื่อให้คนอ่านเข้าใจได้ว่า เพราะอะไร ทีมที่ทำงานถึงมีการตัดสินใจแบบนั้น เพื่อให้รู้ถึงแนวคิดในขณะนั้น
ประโยชน์ของ Architecture Decision Record
ประโยชน์หลักๆ นอกเหนือจากการเป็นตัวบันทึกเพื่อติดตามการตัดสินใจในขณะนั้น ก็คือ ใช้ในการทบทวนเพื่อการพัฒนาปรับปรุง (improvement)
เราสามารถใช้เป็นข้อมูลได้ว่า อดีตตัดสินใจด้วยบริบทอะไร ข้อจำกัดอะไร เพื่อให้ได้ผลลัพธ์แบบใด ปัจจุบันเรายังยืนบนบริบทเดิมและข้อจำกัดเดิมไหม บางครั้ง คณะทำงานเปลี่ยนไป (หรือคณะเดิม แต่ลืมการตัดสินใจนั้นไปแล้ว) ข้อมูลการตัดสินใจในอดีตจะเป็นอีกทางเลือกหนึ่งที่ไม่ต้องเสียเวลารื้อฟื้น หรือคิดใหม่ เพื่อทำให้คณะทำงานใหม่(หรือเก่า)ได้รู้ว่า เรื่องเหล่านี้เคยผ่านการคิดมาแล้ว แต่ติดด้วยเงื่อนไขบางอย่าง ผลลัพธ์จึงเป็นเช่นนี้
สรุปประโยชน์ คือ
- เพื่อให้มีบันทึกดูย้อนหลังได้
- เพื่อใช้ในการ Improvement
- เพื่อ Transfer Knowledge
- เพื่อเพิ่มทางเลือกที่ “จะใช้แบบเดิม ไม่เปลี่ยนแปลง”
- ลดเวลาในการหาปัญหาที่มีในปัจจุบัน
การทำ Architecture Decision Record
ด้วยคอนเซ็ปตามที่กล่าวมา ถ้าอยากเริ่มต้นทำ ADR ก็มี Template ให้หลากหลายรูปแบบ เช่น
- ADR template by Michael Nygard (มีรูปแบบที่ง่าย และเป็นที่นิยม)
- ADR template by Jeff Tyree and Art Akerman (มีรายละเอียดหลายหัวข้อให้อธิบายมากขึ้น)
- ADR template for Alexandrian pattern (มีรูปแบบที่ง่าย และเน้นอธิบายเรื่องของบริบท)
- ADR template for business case (มีความเป็น Business เพราะมีการบันทึกเรื่อง Costs, SWOT, Opinions)
- ADR template MADR (มีรูปแบบที่ง่าย บันทึกข้อดีข้อไม่ด้อย และเป็นตัวอย่างที่ใช้ในรูปแบบ Markdown)
- ADR template using Planguage (เขียนในรูปแบบ Planguage)
รูปแบบที่นิยมที่สุด คือ ADR template by Michael Nygard หรือเราอาจจะเคยเห็นในชื่อ Lightweight Architecture Decision Records ที่ทาง ThoughtWorks Technology Radar ได้นำเสนอไว้ โดยมีองค์ประกอบดังนี้
- Title: ชื่อหัวข้อ ควรกระชับ ว่าเป็นการตัดสินใจของเรื่องอะไร
- Status: สถานะของการตัดสินใจ เช่น proposed (นำเสนอ), accepted (ยอมรับ), rejected (ไม่ยอมรับ), deprecated (เลิกใช้), superseded (ถูกแทนที่), หรืออื่นๆ
- Context: เป็นการอธิบายบริบทในขณะนั้น ว่าอยู่ในสถานการณ์อะไร ที่ทำให้เกิดเรื่องที่จะต้องตัดสินใจ
- Decision: ผลการตัดสินใจ
- Consequences: ผลที่ตามมาจากการตัดสินใจ
ซึ่ง อย่างที่เกริ่นไว้เบื้องต้น สามารถดัดแปลงใช้เป็นไกด์ไลน์ได้ ซึ่งบางทีเราอาจจะรู้สึกว่ามันน้อยไป หรือมากไป ก็เพิ่มในหัวข้อที่เราต้องการได้ โดยส่วนตัวผมแล้ว ผมชอบแบ่งอธิบายเป็นหัวข้อ ผมอาจจะแตก Context ออกไปเป็น ข้อจำกัดที่มี, เป้าหมายที่จะให้เกิด, ทางเลือกอื่นๆ ณ ขณะนั้น, เหตุผลที่เลือกตัดสินใจใช้หนทางนี้ เป็นต้น
รายงาน ADR ควรถูกเก็บไว้ที่ไหน
สามารถเก็บไว้ในเครื่องมือที่ทีมทำงานใช้งานร่วมกันได้เลย เช่น Google Drive, MS Team, Jira Confluence แต่ถ้าหลายๆ ท่านแนะนำ (และผมเห็นด้วยนะ) เก็บไว้ที่เดียวกับ Sourcecode นั่นแหละครับ เพราะมันเป็นเหมือนบันทึก Changelog ประเภทหนึ่ง ที่เมื่อเราต้องการจะพัฒนาระบบต่อ เราก็สามารถเข้ามาอ่านที่มาที่ไปและความเปลี่ยนแปลงได้จากใน Repo ของโค้ดเลย (เครื่องมือบางตัว มี Wiki และ Sourcecode อยู่ภายใต้ Project เดียวกัน ก็ไว้ใน Wiki ได้นะ สะดวกดีครับ แต่ลำบากตอนย้ายและตอนเปิดอ่านนะ)
สรุป
ใช้เถอะ
ปล. ใครสนใจรายละเอียดที่มากกว่านี้ มีตั้งแต่ขั้นตอนที่จะเริ่มคุยกัน ไปถึงจนบันทึกการตัดสนใจ รูปแบบการเขียนที่ดี การตั้งชื่อไฟล์ แนะนำไปอ่านที่นี่ได้ครับ https://github.com/joelparkerhenderson/architecture-decision-record
