長編プログラミングの設計のコツ

質問

都合の良い話ですが、書籍や時間の取られる専門的な勉強を避け、
出来るだけ簡単にプログラムを設計するコツを知りたいのです。

今までは、どのような言語でも、数百行のコードを思いつくままに、
浮かんだアイデアを取り入れながら、コーディングして来ましたが
うまく行っていました。

数ヶ月前に、１万行程度のコードを書いていて、
コードを見やすくするために、汎用処理を別ファイルにまとめたり、
関数化したり、オブジェクトにしたりして、２０個以上のファイルに
分割されたコードが出来ました。
ブロック単位での挙動はテスト済みだったのですが、いざ完成直前に
バグが頻発しました。
デバッグに入り、１連の処理が複数ファイルに分散されている事や
複数の関数から参照される処理が多々存在するなど、修正した部分
が新しいバグを引き起こすような事態になり。
コーディングよりもバグを取り除く事に遥かに時間が掛かり過ぎて、
結局、１からつくり直す事にしました。

前回の失敗を無くすため、なるべく各関数の依存度を下げ、カプセル化
やコメントをまめに書く事にに勤めました。
すると、今度はコードが３割程度長くなった挙句、１つのファイルの
コードが長くなり、頓雑な、依存度を下げるために使った処理や変数の
数も倍以上に増えて、思いつくまま流れるようなコーディングが出来ず、
結局毎日作業開始時には、長々としたコメントを読むことから始めなく
てはいけません。
一日３時間位しか取れない作業時間のうち、その作業に１時間は取られて
はかどらず、挫折してます。

是非、主観的なご意見で構いませんので、お勧めの方法があれば
アドバイス頂けませんでしょうか？

○参考にしてください。
デバッグの際に複数ファイルに渡った変数や処理の参照が作業を
困難にしているのは解っているが結局出来上がるとそうなってしまう
か冗長なコードになってしまう。

記憶に頼る管理は極端に苦手(一日たつと、何を書いていたのか解らず、コード全体を読み直す事がしばしば)。

ファイル構造を始めに決めて処理の流れをある程度書き出して始めた
たが、実際にコーディングを始めると思いつくままにコーディングが
できす、構造管理に気を取られ頭が真っ白になる。

変数をハッシュなどでまとめて解りやすくしたつもりが、意外と読みにくい。

今までは、デバッグに関しては、記述ミスや、１つずつの変数や関数の
動作をトレースする事で事足りたので、今回も、それ以外のデバッグ
方法は取っていない。

回答No.2

zwi · ベストアンサー

私はプログラム全体の細かい構造などいちいち長いプログラムを書いているときは覚えていません。
なので、プログラミングするときは修正する箇所のコメントさえ見れば修正できるプログラム構造になっているのが望ましく、出来るだけそうなるように工夫しています。

１．変数を出来るだけ持ちまわらないほうが良いが、グローバル化したほうが単純化するなら、あえてそうする必要もある。
２．同じような処理は名前を統一する(名称でやる事が分かるように)。変数名も同様。
３．出来るだけ変数に対する操作を行う箇所を少なくする。同じような処理は関数化する。あちこちで修正するとバグの元。ただし無理やりひとつの関数にまとめるのもバグの元。
４．データは同じ関連の物をひとまとめにして構造化する。ばらばらにすると管理できません。
５．プログラム全体を階層化して管理する。
６．関数間のインターフェイスは出来るだけシンプルにする。

とりあえず、参考になるサイト
http://www.rsch.tuis.ac.jp/~sekiguch/lecture/oyoron/2005/siryo/program_design.htm
http://www.smg.co.jp/~toyo/Program/index17.html

>ファイル構造を始めに決めて処理の流れをある程度書き出して始めた
>たが、実際にコーディングを始めると思いつくままにコーディングが
>できす、構造管理に気を取られ頭が真っ白になる。

これも疑問です。ファイル構造を管理するモジュールは１つにすべきでファイル構造をファイル入出力している場所ごとに管理するなど無駄と言うかバグの元です。

一部でも良いので、ソースを見せてもらえると的確なアドバイスが出来るかもしれません。ファイル構造に関する関数と、それを呼び出している所など。

補足

自己診断ですが、
出来ている箇所１、２、４
出来ていない箇所３、５、６
３は、関数化の基準をもって無い。
５は、始めに考えた階層が変更になってしまう。
　つまり、これも基準が無い＋コーディング中の思いつきで
　構造が変わる事が多々ある。
６は、僅か数行の関数に対して引数が６つなどと間抜けな
　関数になってしまって、シンプルにと思い結局カプセル化
　を断念して他の部分に依存してしまう事が多々。

そもそもトップダウンで物事をやったり考えた事が
無いので、それが一因かも・・・。

その他頂いた回答や情報に関しては、検討調査しています。
少し、時間が掛かりそうなのでまずは、この回答へのお礼を
申し上げます。

回答No.3

digh

よくわかります。
私も似たような状況で挫折中のプログラムがあります。
そしてやはり、扱うデータを整理して、分析して、
データ構造をまとめた後、そこからデータ構造を見返すばかりで
頭の中が整理できなくなっています。

そこで、私も No.2 の方の参考 URL の下段
（http://www.smg.co.jp/~toyo/Program/index17.html​）
を一通り読んでみたのですが、どうも「ボトムアップ」による設計が苦手なんだとわかりました。質問者様も同じようなタイプではないでしょうか。

もしそうであるなら、私なりに考えた手法があるのですが、
参考までに如何でしょうか。私もこの後、以下の方法を試してみる予定です。
まず、データの量が多くて混乱しているので、一つのデータに絞って、それに関連する部分だけを作ってしまう。
一つのデータ（一つのファイル）を受け取り、なんらかの結果を返すプログラムを作ってしまうのです。プログラムの設計という観点から言えば、モジュール（機能単位）のプロトタイプ（試作品）を作る、といったところでしょうか。モジュール（機能単位）の単体テストを行うようなイメージにも近いかもしれません。

一つのデータをうまく処理できたら、次のデータも同様にして単独で処理をするようなプログラムを作り、そして、最終的にそれらを組み合わせてつなげる、という形です。

一つのデータごとにモジュールのプロトタイプ（試作品）を作って、正常な動作を確認したらそれを完成品（プロトタイプではなく、正規のモジュール）としてFixさせ、最後にそれらをつなげる。

私は、普段、プログラムを作るとき、機能毎に「分割」して関数などを作っていく手法（「アップダウン」）を用いていますが、その逆の手法（「ボトムアップ」）は経験が少ないです。そのため、「つなげる」という行為になれておらず、データ量が多いプログラムをデータ部分から設計した時にどうしても混乱してしまうのだと気づきました。

参考になりましたでしょうか。

お礼

回答ありがとうございます。
>一つのデータをうまく処理できたら、次のデータも同様にして
　単独で処理をするようなプログラムを作り最終的に
　それらを組み合わせてつなげる

まさにこれを、試していた最中でした。
一つ、面倒なのが、他の処理で得られた結果(加工済みのデータ)
を中間処理データとして持つか、テストデータを作成するか
と言う作業が増えてしまうことです。
さらっと書きましたが、結構骨が折れます。
正直申し上げますと、複数段階に別けての
データ加工は精神衛生上少し苦痛ですｗ
(不恰好なイメージが抜けません。)
テストデータ作成はかなり困難なデータフォーマットです。
しかし、最終的に完成しないよりましですね。
愚痴ってすみません。

他の問題も出てくるかもしれませんが、今の所この方法が一番自身
のスキル的には実現できそうです。
No.2 様から頂いた情報も今理解に勤めているので共に参考に
させていただきます。

思考錯誤中で直ぐには、結論がだせませんので、
まずはこの回答へのお礼をさせていただきました。

回答No.1

tatsu99

言語は何ですか？又開発環境はどのようなものでしょうか？
その辺のこともわかると、より良い回答が得られやすくなるかと思います。

お礼

言語は、主にスクリプト言語系やPHPが多いですが悩みは同様です。

今回は、日本語プログラムなでしこで作成しています。
開発環境は付属エディタのみで、
プロジェクト・バージョン・フォルダ管理等はありません。
自身で階層フォルダをつくり管理する形態です。

特徴としては、
構造体、関数、オブジェクト指向ぽいグループ機能は使えます。

なでしこ選択の理由は、
ステップ数が他の言語の３分の１程度で済む。

ですが、どの言語を使っても同じ状況に陥入り挫折してしまうので、
出来るだけ、どの言語を使うかと言う以前の部分での
アドバイスを希望しています。