[B! ドキュメント][プログラミング] kei

kei_0000 id:kei_0000

ドキュメントとプログラミングに関するkei_0000のブックマーク (2)

【翻訳】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分 (目次) デザインドキュメントの解剖学文脈と範囲目標と非目標実際のデザインシステ
kei_0000 2022/04/22
この手のドキュメント指針において、「デザインドキュメントを書いてはいけない時」という章があるのは珍しいのでは。無駄なことは極力避けると言う文化が根付いている結果と思われる。羨ましい。

ドキュメント

google

ソフトウェア

エンジニア

開発

プログラミング
リンク
設計書には何を書くべきなのか - terurouメモ
設計とは、要求（やりたいこと）をヒアリングする要求を要件（何を満たさないといけないのか）に落とし込む要件を実現するために考えられる手段を洗い出す手段の検証を行う検証結果を元に、どの手段を使うかを選定する選定した手段を合意する（一部要件を満たさない事項がある場合は、代替策や妥協ラインについても合意する）合意内容を元に、実装や設定に落とし込むをやることである。画面設計や機能設計のように、3-5の検証/選定が薄くなったり曖昧になったりするものはあるが、一般化するとこの流れになる。設計書には、上記の設計でやってきたことを順番に書いていけばよい。これを文章構成のテンプレに落としていくと、要求要件方式対応案（いわゆる比較表で書いていくのが楽）検証結果選定・合意結果（合意した代替策や妥協ラインについても記載する）詳細設計（どういう実装にするとか、パラメーターにするとか、細
kei_0000 2020/07/30
自分なりのまとめ 1.要求(やりたいこと) 2.要件(やると決まったこと) 3.方式(実装方法の概要･方針) 4.詳細設計(実装方法の詳細)

設計

開発

エンジニア

プログラミング

ドキュメント
リンク
1