プログラムの設計書について

[wasawasa]

こんにちは、いつもお世話になっています。
設計を殆ど決めずに行き当たりばったりでウィンドウズのアプリのプログラムを組んでいたのですが、データの流れ方や関数や定義の置き場所や変数の名前といった物ががぐっちゃぐちゃになり把握しきれなくなってしまったので今度はちゃんと設計を書面に起こしてから一から作り直そうと思いました。
そこでふと思ったのですが、皆さんはプログラムを作り始める前に設計を決める時、どういった部分に重みを置いてどの程度詳しく設計をしていらっしゃるのでしょうか？
リスタートの参考にしたいのでお話を聞かせて頂ければ幸いです。

[softya（ソフト屋)]

いっぺんにやっても破綻すると思いますんで、モジュール分け(クラス分け)のルール徹底と名前ルールを決めてから始めてからどうでしょうか。
初心者のおちいりやすい罠としては、
・モジュール名と動作内容が一致しない
・モジュール名から機能が想像できない
・モジュールが異様に大きい。
・関数名が機能を表していない
・関数名から想像できない機能がある。
・引数が異様に多い。
・関数が画面何ページもある。
・名前から機能が想像できない識別子がある。
などがあります。

>皆さんはプログラムを作り始める前に設計を決める時、どういった部分に重みを置いてどの程度詳しく設計をしていらっしゃるのでしょうか？

主要な外部ファイルや内部構造体・クラスのデータ構造設計から始めます。
ここがちゃんとしていれば、それに付随する処理を書いていくだけです。

[TOMY]

自分もこの手の内容はよく起こしますので、まずプログラムを組むときに
・どんな処理がいるのか？(大雑把な処理分け。クラスにまとめるか、ただの関数群で済むのかもこの時点で考えます。)
↓
・その処理をするのにどんなアルゴリズムを適用すればいいのか？(要するに卓上の理論。どんな数式でどう処理するか等、プログラム知識が必要ない部分)
↓
・上記２つを行うのにどんな技術が使えるか(標準関数が使えるか、はたまた自作する必要があるか・・・)
この時点で自分がよく起こす失敗があるのですが、技術は何に使うかではなく、何に使えるかを意識して下さい。
新しい事を勉強すると、(自分の例だとSTLを勉強してそれを使って何かしたいと思い、使い慣れてもないのに大規模なマネージャークラスを作ったりしてものすごいエラーとメモリリーク吐き出した挙句スパゲッティ化して修正しきれずにプロジェクトを破綻させたことがあります。)プログラム初心者はよくやりがちなんですヨこれ、勉強がてら覚えたてで使い慣れてもない技術を使おうとする行為。
↓
・大体やりたいことと、アルゴリズム、そして使う技術を固めたら次は必要な変数、関数、定義等の数や命名をします。
(命名には注意。此処で間違えると色々と面倒くさいことになります。自分は変数名で反転を意味するReverseと命名するつもりがうっかり再生を意味するRebirthと名付け、そのままミスに気が付かなかったことがあります。)
(また、命名は他の人が見てすぐに理解できるようにした方がいいです。場合によっては名前が長くなっても自分は人がわかり易い名前を選びます。ただ、自分の場合ローマ字だけは絶対に避けます。読みづらいし、汚らしいので。理想は一言の単語で収められるようなものでしょうか・・・一単語が長い場合は省略したりしますが、座標(position)なら、Posなど・・・省略してわかりにくい場合は多少長くてもそのまま書きます。)
コーティングルールは人それぞれなので一概には言い切れません。上記はあくまで自分の例です。チーム制作をしているのであれば真っ先に他の人とコーティングルールを決めておきましょう。ここをすっぽかすと、後半にプログラマー同士の激しい殴り合い(言葉と物理の複合)が待っています。(個人経験ですが、前にチーム制作をした際に、命名ルールやデータへのアクセス方法が統一されておらず、エラーを吐き出した際、激しい口論の末に仲間のプログラムをデバッグするときにものすごく長いローマ字の関数名を泣きたくなるほど見させられたこともあります。終わった後はコーティング先に決めときゃよかったという後悔とともに死にたくなりました。ちなみに他のチームではコーティングルールを決めていたらしく開発とデバッグがスイスイ進んでいました。ルールが決まっていると、その人以外のメンバーがプログラムを見てもスイスイ読めるらしいです。)
↓
・制作スケジュールを決める。
目星でいいので自分の技量に合わせてその日にこなす作業を決めるといいです。例えば今日はこの処理まで完成させる。等・・・
自身の技術力を図るのにも便利ですし、モチベーションが続いて着実に先に進みますから。失敗した時は自分の技術力をもとに再びスケジュールを再構築という流れで。
↓
・組む。その過程で何か追加したい要素が出たら、本当にその要素がいるのか考えた後に必要なら追加し、設計書に追加した内容を全部書いときます。後で見返した時に何これ状態を避けるためです。

とまぁ生意気にたくさん書きましたが、実際の開発なんてこの通りに進まないものですよ。経験です経験。痛い目を何度も見て、他の人の話を聞いて、そうやって一歩ずつ覚えていくものです。自分でも設計書書いたのに後半グチャッたりますから。(たいてい設計書が殴り書きのメモだったせいで読み返せなかったのが原因ですが。)

後、一度組んだことがある処理だからと言って、同じ処理をまた組むときに設計書を書くのをすっぽかして頭のなかで思い出した処理だけで組まないほうがいいです。
前に書いた設計書がちゃんと保管されていてリサイクル出来るのなら別ですが、アインシュタインでもない限り、自分の脳の中なんてそこまで信用できるものじゃないですから。

[wasawasa]

返信ありがとうございます。

お二人の話を聞く限りでは、記述を打ち込み始める前にはデータの流れ方やプログラム全体の構造、ファイルや関数の数や名前のルールまで詳しく決めるべきだと承りました。
TOMYさんの生々しい体験も参考にしつつ設計していきたいと思います。

[softya（ソフト屋)]

名前のルールはプログラムを見失わないように重要です。
最初に関数の数はきちっと決めるのは難しいです。大まかなグループ分けぐらいでやめておいたほうが良いでしょう。
名前のルールがしっかりしていればグループとして追加できます。
Enemyグループがあるとしたら、EnemyShotを追加とかね。