詳しすぎる詳細設計書 - SiroKuro Page
「詳細設計書」と呼ばれるドキュメントがあります。各処理の入出力や処理概要を記載した文章です。 入力： 「性別と身長のペア」のリスト 出力： 男性の平均身長」と「女性の平均身長」の差 処理概要： 変数「男性の合計身長」「女性の合計身長」「男性の人数」「女性の人数」を 0 で初期化する 入力を受け取る 入力されたリストから要素を読み込む 入力されたリストの要素数だけ以下を繰り返す 要素を１つ読み込み、条件分岐する もし要素が男性なら、変数「男性の合計身長」に身長を加算し、変数「男性の人数」を１増加させる もし要素が女性なら、変数「女性の合計身長」に身長を加算し、変数「女性の人数」を１増加させる 次の要素を読み込む 「男性の合計身長」÷「男性の人数」−「女性の合計身長」÷「女性の人数」を、変数「計算結果」に代入する 出力する イメージとしては、こんな感じ。各社それぞれ、どんな詳細設計書を書いてい
Martin Fowler's Bliki in Japanese - コードがドキュメントだ
http://www.martinfowler.com/bliki/CodeAsDocumentation.html アジャイル手法はプログラミングをソフトウェア開発の中心的役割に押し上げた、とよく言われる――ソフトウェア エンジニアリング コミュニティがやってるようなことよりもずっと優秀だよなあ。 プログラミングが中心的役割となったのは、コードをソフトウェア システムにおける「（最）重要なドキュメント」と位置付けたことが理由なんだと思う。 おっと、よく誤解されるので先に反論しておこう。 先ほどの「コードは重要なドキュメントだ」という原則だけど、 「コードが"唯一の"ドキュメントだ」とは言ってない。 「XPではコードがドキュメントだ」とよく耳にするけど、 XPのリーダー達がそんなことを言ってるのは聞いたことがないなあ。 コードを補完するには、他にもドキュメントが必要なんだ。 なぜコードが重
価値ある設計書かどうかはIPOで決まる - 現場のためのソフトウェア開発プロセス - たかのり日記
昨日のエントリで、ドキュメント（設計書）の有用性について書きましたが、これはよくある話。 では、どうすれば価値のある設計書になるのかについて、もう一歩踏み込んで考えてみます。 まず、設計書とは、最終的にコードを作成するための成果物であり、価値のない設計書とは、コードを作成するのに役に立たないものだと言えるでしょう。 「顧客にレビューしてもらうため」とか「エンジニア間でコミュニケーションを取るため」といった意見もあると思いますが、それも最終的には、コードまで落とし込むための過程と考えられます。 その設計書を作成する上で、設計技法としては、以下のようなキーワードが必ずと言ってよいほど挙げられます。 構造化設計、DFD、ER オブジェクト指向設計、UML、デザインパターン 設計に関する書籍では、大抵このような設計技法を扱っているのですが、これらのものは、分析や表現に重きがあり、どうすれば良い設計
ドキュメントは本当に無駄か？ − 設計とは整理すること - 現場のためのソフトウェア開発プロセス - たかのり日記
ドキュメントを書くのは時間がかかるから省略する ソースコードを見れば分かるので、ドキュメントは不要 後からどうせ変わるので、ドキュメントは実装後に書く というような、「ドキュメントは無駄」という旨の意見を見かけることがあります。 さすがに、仕事においては納品物ともなるため、一切ドキュメントを書かない、という人はいないと思いますが、詳細設計などの実装に近いドキュメントになればなるほど、そのような意見が多く出てきます。 ドキュメントを軽視している人の8割は、設計ができない人であり、そのような人が書くコードは、場当たり的で、拡張性が無かったり、共通化されない無駄なコードが多かったりします（あとの2割は、天才で、ドキュメントを書かずとも素晴らしいコードが書けるだけの能力がある人）。 何年も繰り返されている議論だろうけど、「ドキュメントは無駄」なのではなく「無駄なドキュメント」を書いているのが問題。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
