パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

スラッシュドットに聞け:ソフトウェア開発の現場で設計書は必須か」記事へのコメント

  • ソース自体が設計書(の一部)なんですが。
    大体、他の物作りでも、自然言語だけでは正確な指示は出来ないので、その仲介として図面などが存在して、それらはとてもじゃないけど、シロート(あえてカタカナ)には書くことどころか、読み取ることも出来ない。(ソースよりは判ったふりはしやすい)

    要するに、「セッケーショがぁ」と騒ぐ上司は、他の物作りの場面で図面とか判ったふりをする奴。ポンチ絵でも描いてわたしゃ納得しますって。

    • Re: (スコア:0, 興味深い)

      by Anonymous Coward

      >ソース自体が設計書(の一部)なんですが。

      こういうこという奴は「私はバカです」
      って言ってるのと同じだと思ってる。

      要求書とそれを実現する実装方法を抽象化した「設計書」がない限り「実装のミス」はわかりません。

      ある値 a と b を合計する値を求めるのが要求と仕様だったとして、
      実装が a - b になっていた場合、「ソースだけ見ても実装のミスとわかる人はいない。」

      ソースを設計書というなら「a - b」が正となり、それしか資料がなくなるのだから。

      • by Anonymous Coward

        あなたの理屈で必要なのは要求仕様書であって、設計書ではない。
        そして要求仕様書は設計者が書くものじゃない。

        • by Anonymous Coward

          要求仕様書なんて

          「なにがしたい」(ものを買いたい、売りたい。)

          レベルで「実現方法(機能仕様、機能設計)」はないでしょうが。

          必要なのは「機能と実装の設計」

          「コーディング仕様書なんていらない」のは同意できますが「機能実現の為の実装設計書」は必要です。

          「どういうDBでどのテーブルはどういう意味を持ち、どのフィールドは何のためで、
          どういう計算で入るべきか。」

          それが「要求仕様書?あほか」

          上記がない限り実装でミスってもけっしてわかりません。

          • by Anonymous Coward

            >「機能実現の為の実装設計書」は必要です。

            >「どういうDBでどのテーブルはどういう意味を持ち、どのフィールドは何のためで、
            >どういう計算で入るべきか。」

            機能を上から下まできっちり詰めることができるのなら、それは即ちそのまま
            ソースコードに落とし込めるということで、それなら最初からソースコードに
            そういうことを書けばいい。

            そういう意味で『ソースコードは設計書』なんです。

            # それにね、だいたい同じ頭で「機能実現の為の実装設計書」と「ソースコード」を
            # 書いたところで、両方に同じ間違いをするのが関の山でしょ。

            • by Anonymous Coward

              フィールドを計算する関数ごとに「テーブルの意味」「関連する別のフィールド」「別のテーブルの意味」
              すべてかくんですか?

              そもそもシステム全体でDBを複数使用している場合、
              「システム全体では使用してもそのクラスでは使用しない
              が値としては関連してくる」

              とかいくらでもあるわけで。

              # それにね、だいたい同じ頭で「機能実現の為の実装設計書」と「ソースコード」を
              # 書いたところで、両方に同じ間違いをするのが関の山でしょ。

              だからこそ
              「コーディング設計書」でなくて「なにをしたいか、何をするべきか、システム全体の中で何を担って、
              なにを行って、返す値は何で、システム全体でどういう意味を持つか」

              の「設計書」が必要なんですよ。
              後で他の人間がみて、「ここでバカやってる」ってわかるように。

              そもそも「何を求められていたか、そこで何するべきだったか」

              がわからなくてどうやって「やっていることのミス見つけるの?」

              • by Anonymous Coward

                >「コーディング設計書」でなくて「なにをしたいか、何をするべきか、システム全体の中で何を担って、
                >なにを行って、返す値は何で、システム全体でどういう意味を持つか」

                もしかして知らないのかもしれないけれど、まともなプログラマならそういうこともソースコード中に
                ある程度ちゃんと書いておくものなのです。

              • by Anonymous Coward

                もしかして知らないのかもしれないけれど、まともなプログラマならそういうこともソースコード外の
                ドキュメントにある程度ちゃんと書いておくものなのです。

              • by Anonymous Coward on 2015年03月03日 18時33分 (#2771070)

                ソースコードの中に書いておいて自動生成すればその要件は満たせるね。
                ドキュメントと突き合せずにソースで直接突き合せられるからソースに書くほうが合理的。
                別に書いてたら整合性を保つ手間も増えるし、同じことを2セット書くとかミス増えるだけじゃん。

                にもかかわらずドキュメントで同じことをもう一度書くことの意義はどこにあるんですかね。

                親コメント
              • by Anonymous Coward on 2015年03月03日 19時13分 (#2771086)

                ソースコードと一対一で対応しているドキュメントじゃカバーできない、
                全体を俯瞰する情報のために設計書が必要なんですよ。

                親コメント
              • by Anonymous Coward

                ○○画面の××ボタンの処理の仕様が知りたいというシチュエーションがあったとしましょう。

                ソースコードから自動生成したドキュメントしかない場合、
                まず○○画面のソースがどれかをドキュメントツリーを掘って探す必要があります。
                首尾よく○○画面のソースから作られたドキュメントを見つけ××ボタンの処理だというA関数の項を見つけました。
                しかしA関数のドキュメントを見ても概要は書いてあるが詳細が何も書いていない。
                さて困った、仕方ないからA関数のソースを探してきて読んでみて謎が解けました。
                A関数ではB関数を呼んでいて主要な処理はB関数で行っていたのです。
                B関数のドキ

あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー

処理中...