ADR(Architecture Decision Records)を書く
アーキテクチャの検討を記録するADR(Architectural Decision Records)の方式で、自身がADRを採用するか検討した。 ステータス: 承認 決定者: @niku 日付: 2020-05-19 文脈と問題点の説明 ソフトウェア開発中に、あるアーキテクチャを採用した理由を知りたいことがある。 幸運にもそのアーキテクチャを採用した開発者にインタビュー可能で、また開発者の記憶が定かであれば、当時どのような状況・どのような選択肢が用意されている中から選択したかを明らかにできる。 しかしそうではなかった場合、過去に採用したアーキテクチャを盲目的に受けいれたり、完全に無視するといった不健全な意思決定を強いられることになる。 そこで、決定の粒度が大きくかつプロダクトの品質に大きく影響を与えるアーキテクチャ上の変更の「なぜ」を記録し、時間が経過した後も簡単にアクセスできるよう AD
〜その意思決定を刻め〜「アーキテクチャ・デシジョン・レコード(ADR)」を利用した設計の記録 - スタディサプリ Product Team Blog
こんにちは。スタディサプリのWeb開発をやっている@highwideです。 今日は、自分の所属する"コーチングチーム"(個別指導コースや合格特訓コースの機能開発を行っています)が、最近のプロジェクトで利用した「アーキテクチャ・デシジョン・レコード」、通称「ADR」について紹介したいと思います。 アーキテクチャ・デシジョン・レコード(ADR)とは 「ADR」「アーキテクチャ・デシジョン・レコード」という概念を知ったのは、社内で行っていた「Design It! プログラマーのためのアーキテクティング入門」(以後「Design It!」)の読書会でのことでした。 www.oreilly.co.jp 最初にそのキーワードが登場する「11.2.3 必要なときだけ形式的な記述に投資する」では、「"膨大な量のドキュメントになる傾向"がある形式的なドキュメンテーション」に対比して、以下のように紹介されます
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
