ADRの必要性
こんにちは、シニアソフトウェアエンジニアのriddleです。このポッドキャストでは、IT業界のいろんな話やリアルをお届けします。
今回はですね、皆さんこんなことありませんか?このコードベース、もしくはこのアーキテクチャー、なんでこれ採用してるんだろう?
うーん、前任者いなくて全然わからんなぁ。うーん、過去のスラックとかログとか多いか。みたいなことありませんかね。
これね、私も今まで散々遭遇してきました。世の中の人もですね、たくさん遭遇してきたんだと思います。
これをですね、解消するにはどうすればいいか。もう簡単です。書いとけばいいんですね。どっかに。
めちゃくちゃ単純なんですけど、その当時の人はね、何かしらの理由があってそれを選んだんで、俺が今最適だっていうことで選んだんですけども、
残念ながら後世にはそれが引き継がれなかったということで、我々は苦労しているわけです。
でですね、じゃあ書いとけばいいんだって話なんですけれども、これなんか、書いとくってもうちょっとなんかいい感じにならないの?みたいなことがあるんですけれども、
そんな時に使えるのがですね、ADRと呼ばれるアーキテクチャーデシジョンレコード、アーキテクチャーの決定記録と呼ばれるものがあります。
これね、すごい簡単に言うとですね、なぜこの技術を選んだのかとか、なぜこのサービスを選んだのか、もしくはなぜあれを選ばなかったのか、
いったことをドキュメントに残してGitで管理するっていう本当にシンプルな内容です。
一般的にはですね、ソフトウェアの設計とかシステム構成に関するいわゆるアーキテクチャーですね、そこに関する重要な意思決定を記録するドキュメントと言われています。
なんでこのアーキテクチャーを選んだのかとか、他に何を検討したのか、でその結果これを選んでそれはなぜか、みたいなところを書いています。
これを書くことでですね、コードとか構成ファイルとかだけだと表せない、判断の理由とか背景とかその時の状況とかそういったものがわかる。
そしてそれを後に残った人が見たときに、あ、こういう意思決定をしたからこれになったんだってことがわかるわけですね。
これがあると何が嬉しいかって皆さんもご存知の通りですね。これなんかこのシステムAって製品使ってるけど、これなんかAじゃないといけない理由あんのかなみたいな。
リプレイスのタイミングでBに変えちゃいたいけど、なんか問題あんのかなみたいな問題とかね。そういうことがこのADRを見ることで一発で解消するということです。
じゃあADR何を書くんだって話なんですけども、本当にシンプルでタイトルですね。まずこういう内容です。で、ステータスこれは提案中承認済み廃止とか、
この意思決定が最終的にどうなったのかって表すステータスですね。で、コンテキスト。どんな問題や背景があったか。で、ディシジョン決定ですね。
なんで、なんでじゃないですね。どの選択をしたかですね。で、根拠。なぜそれを選んだのか。で、まあオプショナルで影響というか、メリットやデメリットとか
ADRの実践方法
将来的な影響みたいなことを書くと良いかなということです。別にですねこれ決まった形式あるわけじゃない。
あるかもしれないんですけど、そんな別に決まった形式を書く必要もないので、自分たちが必要だと思うもので、かつ残った人たちが今後開発や保守を
し続けられるような流度で書いていくっていうのがいいかなと思います。またですね、先ほどお伝えした通りGitでマークダウンで管理する
みたいなのが一般的だと思いますので、チーム開発でよく使われるプルリクエストとかマージリクエストでこのADRというものを作って
みんなにレビューしてもらったりとかですね、承認者にまあいいよみたいな、もしかしたらダメだよとか、これでいこうねみたいなものの意思決定として
まあok、出ればアプローブされればマージされて、それがGitで管理されていくので、新しい書いた人はそれを見ればいいという感じですね。
はい、ということで今回はですねADRご紹介しました。まあこれを使うとね、なんでうちのデータベースはMySQLじゃなくてPostgreを使っているんだとかね
RDBMSじゃなくてNoSQLを使っているんだとか、そういうことがですねパッと見えすぐわかるということになりますので、ぜひですね途中からでも全然入れられるものではありますので
もしプロジェクトで意思決定がなんでっていうことがよくわからなかったりとか、意思決定したけどその結果どこにも残せないなと思う方はですね
ADRをぜひですね導入してみてください。このPodcastはハッシュタグでITで皆様からの感想やコメント募集しております。
またチャンネルの概要欄にGoogleフォームのリンクもありますのでそちらからのご投稿も大歓迎です。ありがとうございました。
