2020-05-19 ADR(Architectural Decision Records)を書くと決めた理由を自分の言葉で書き出した
寿命の長いソフトウェアを開発をするとき、アーキテクチャに関して数多くの意思決定をしている。その意思決定がどういう状況下でどんな選択肢の中から行われたのか ADR という形で開発物に含んでおくと、ソフトウェアアーキテクチャの一部が現状にそぐわないと感じられたとき、過去に決定を積み上げて現在有用なソフトウェアとして動いている既存アーキテクチャの批評を上手く行える。
ADR は Architectual Decision Records の略で「アーキテクチャ上重要な機能や非機能要求に対処するソフトウェア設計の選択を記録したもの」を指している。満たしたかったものは何か、実現するための選択肢はどんなものを用意していたか、最終的にどれを選んだか、それはなぜかが書かれている
私は ADR を持たない ソフトウェア開発というのもそれなりに経験してきた。ADR を持たないソフトウェアのアーキテクチャを改善したいとき、どうするか。アーキテクチャ決定時の関係者に聞き取りができ、その関係者が覚えていれば ADR がなくても平気だ。関係者がいないとき、もしくは関係者がいても覚えていないとき、当時のアーキテクチャがどのように決定されたかはわからないままだ。その場合、過去に採用したアーキテクチャを現在も盲目的に受けいれる、現在は完全に無視してアーキテクチャの刷新をはかる、そういった両極端で不健全な決定を強いられることになる。
当時の状況や選択肢、過去のアーキテクチャ決定時の議論を利用できると、現在もそれらの状況や選択肢は有効か検討に幅が出て、穏当なアーキテクチャ改善が行いやすい。
というのを本やwebで読んではいたのだけれども、自分なりの言葉で表現できるか挑戦してみた。
自分なりの言葉で書いてみるのはむずかしいね。一度書いておけば改善しながら再利用できそう。
この記事が気に入ったらサポートをしてみませんか？