【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG
Googleでの「Design Docs」とは 2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1～2週間をかけて書く」ものです。 今回は Google のソフトウェアエンジニアである @cramforce 氏が自身のブログで「Googleでの Design Docs」について解説している記事を公開されていたため、氏の許可を得て翻訳しています。 原文： www.industrialempathy.com 関連書籍： Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 読了目安：11分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
デザインドックで学ぶデザインドック | フライウィール
エンジニアの太田です。 皆さん、デザインドックはご存知でしょうか？いわゆる設計書ですが、エンジニアによって書かれ、書いた本人またはチームによって実装される点と、技術的な詳細を明確にし技術的な議論をすることにフォーカスがある点が特徴です。他人に開発を依頼するための設計書や、既存のシステムを解説するための文章とは性質が異なります。 デザインドックを書くことの利点としては以下のような点があります。 開発を始める前に全体のシステムを考察する機会を得る文章化することで、曖昧な部分が明確になる早い段階でチームメイトや専門家、関係者からフィードバックを得る機会を得るシステムの設計について明確な承認を得られる新しいメンバーがシステムの概略を理解する手助けになる弊社でもすでに多くのデザインドックを利用しており、エンジニア間での議論の活発化を担っています。 具体的にどのような内容を書けばいいのでしょうか？今回
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
