アーキテクチャの「なぜ？」を記録する！ADRってなんぞや？ - Qiita
5月のThoughtWorksのTechnology RadarでもADOPTされたADRという手法について、面白かったので、ざっくり自分なりに調べたメモです。 Technology Radarでは以下のように述べられています。 多くのドキュメントは、読みやすいコードとテストに置き換えることができます。しかし、進化的アーキテクチャでは、将来のチームメンバーの利益と外部の監督のために、特定の設計上の決定を記録することが重要です。Lightweight Architecture Decision Recordsは、重要なアーキテクチャー決定を、そのコンテキストおよび結果と共に取り込むための技法です。これらの詳細は、WikiやWebサイトではなくソース管理に格納することをお勧めします。そうすれば、コードと同期したままのレコードを提供できるからです。ほとんどのプロジェクトでは、この手法を使いたくな
http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions
01_ADR.md アーキテクチャ設計のドキュメンテーション コンテキスト アジャイルプロジェクトのアーキテクチャは、別々に記述され定義されなければなりません。すべての意思決定が一度にされるわけでもなく、プロジェクト開始時にすべての意思決定がされてるわけでもありません。 アジャイル手法では、ドキュメンテーションに反対はしませんが、価値のないドキュメンテーションはいけません。チーム自身の助けになるようなドキュメントは価値がありますが、ちゃんと最新化し続けなければなりません。膨大なドキュメントでは、最新化されなくなることでしょう。小さくまとまりのあるドキュメントは少なくとも更新される可能性はありますよね。 また膨大なドキュメントはだれも読みません。たいていの開発者はソースコードサイズの合計よりも(byte的な意味で)大きな仕様書が書かれたプロジェクトを少なくとも1回は経験したことがあるでしょう
ADR(Architecture Decision Records)を書く
アーキテクチャの検討を記録するADR(Architectural Decision Records)の方式で、自身がADRを採用するか検討した。 ステータス: 承認 決定者: @niku 日付: 2020-05-19 文脈と問題点の説明 ソフトウェア開発中に、あるアーキテクチャを採用した理由を知りたいことがある。 幸運にもそのアーキテクチャを採用した開発者にインタビュー可能で、また開発者の記憶が定かであれば、当時どのような状況・どのような選択肢が用意されている中から選択したかを明らかにできる。 しかしそうではなかった場合、過去に採用したアーキテクチャを盲目的に受けいれたり、完全に無視するといった不健全な意思決定を強いられることになる。 そこで、決定の粒度が大きくかつプロダクトの品質に大きく影響を与えるアーキテクチャ上の変更の「なぜ」を記録し、時間が経過した後も簡単にアクセスできるよう AD
#1: デザインドキュメントを書こう - Qiita
この記事はMicroservices Advent Calendarの17日目の記事です。前回は#0: マイクロサービスの構築プロセスのお話でした。 はじめに マイクロサービス・アーキテクチャの話は多くありますが、実際にマイクロサービスを新たに設計・開発するとき、どのような手順を踏むか、と言ったことを扱った文献はそれほど多くない印象です。そこで、自身の経験を元に、マイクロサービスの設計をどのようにしているか、ポイントをかいつまんで説明したいと思います。 前回は、あるマイクロサービスの構築プロセスを外観しました。今回は、一歩踏み込んで、マイクロサービスの責務を定義する話になります。 デザイン・ドキュメントを書こう 新しいマイクロサービスを作る前に、1枚のデザイン・ドキュメントを書くべきです。まず、作ろうとしている マイクロサービスの目的（責務） を書きましょう。それ以上のフォーマットは設けて
デザインドキュメントについて
こんにちは、 @kz_morita です。 先日行われた勉強会 でデザインドキュメントというソフトウェア開発時に各ドキュメントについて聞いて，興味が湧いたのでしらべてみました． デザインドキュメントとは デザインドキュメントは Google などの企業でソフトウェア開発を行う際に一緒に書かれるドキュメントのことです． ソフトウェアがどのような問題をどのように解決するのかを，ソフトウェアよりより高いレベルで伝えるための手段としてもちいられます． 何を書くべきか このドキュメントには，実装のアプローチや，主要な設計上の決定事項，考慮されたトレードオフなどが書かれます． 何を書くべきかという明確なルールはないためそれぞれのプロジェクトに合った形で改造していくのが良さそうです． 以下に自分が参考にした一例を載せます． - プロダクト開発・機能開発・改善の背景 - 課題は何か＝何を解決するのか -
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
