สิ่งที่เราทำคือ ไปค้นหาหลักฐานการประชุม เช่น สมุดที่จดไว้ส่วนตัว หรือ 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

Reference

• https://adr.github.io/
• https://github.com/joelparkerhenderson/architecture-decision-record
• When Should I Write an Architecture Decision Record