HSPTV!掲示板

はじめまして。BomXTと申します。
プログラミングを進める上で少し困ったことが出てきたので、
ぜひ皆さんのご意見をお伺いさせて頂きたいです。

プログラミングというのは最初に仕様をガッチリ決めて、
出来ることなら作っている最中に仕様変更をするのは良くないと聞きました。
ソースが乱雑になってしまう、とのことでした。
ですが、実際何かを作っているとどうしても、
「こうした方がいいかなぁ」とか「あんな機能も欲しいなぁ」となり、
結局新しい要素を付け加えることになってしまっています。

このような場合、皆さんはどのように対処なさっているのでしょうか。
また、仕様変更が出来るだけ起きないようにするにはどうすればいいでしょうか。
ご教授頂けるとありがたいです。

基本的にプログラムは１人でやっているので仕様をガッチリ作らずに作ってます。

何をどう組めばどういう結果になると言うのが分かっているので、
そこで新しい仕様が出来たら頭の中で組みなおしながら作ってます。

ただ大風呂敷を広げてから組み立て出すと難しいので、
それぞれの処理の核に部品を足して小さい所から大きくしたり組み替えたりしてます。

こんなんでアドバイスになるか分かりませんが自分はこんな感じです。

設計らしい設計なしで組める程度の規模のプログラムならどうしたって構わないのですが、
ある程度の規模をもったプログラムは最初に設計が必要です。
※それをしないでソースが乱雑になるのは仕様変更以前の問題ですね。

ソースが乱雑になるのは、仕様が変わったからではなく、仕様が変わったのに設計を適切に変えないからです。

たとえば、せっかく図面をひいて家を建てているのに、図面を無視して実際の施工でアレコレと変更を加えていったら、何をどうしたんだったか分からなくなってしまいます。
ヘタをすると、変更点どうしが干渉し合って施工が立ち行かなくなることもあるでしょう。
変更をしたくなったときに必ず図面を確認して、図面に反映することをかならずしていれば、無理のある変更にはあらかじめ気がつくこともできます。もしかしたら、既存の部分をどう変更したら無理がなくなるかを、見つけ出すことができるかもしれません。


大抵において、仕様が変更できないプログラムはよいプログラムとはいえませんし、
仕様の変更がヘタなプログラマーは、よいプログラマーにはなれないでしょう。

仕様を決め設計し順調に開発が進んでいたが、追加仕様が出て来てしまった…。
そんな時、俺は設計をやり直す事が多いです。

これまで一貫性のとれていた設計が、一部のコードの修正により崩れてしまうと、
コードが煩雑になるだけでなく、バグを持ち込む事になりかねないからです。

しかし、仕様変更の度に、設計をやり直すのは非常にバカらしいので、
最初の設計の段階で、後々追加されたり変更されそうな機能が考えられるのなら、
それらを含めた上で設計します。こうしておけば、予想範囲内の変更に対しては
ほとんどコードは弄らなくて済みます。

そうでない変更があった場合は、設計を見直します。
他のコードに影響が少ない変更なら部分的に設計を見直しますが、
それでは対処出来ない大きな変更なら、既に設計が破綻していますので、一からやり直します。

面倒なように思えますが、修正に次ぐ修正でコードがめちゃめちゃになって、
プログラムがどう動いているのか分からなくなり、修正の度に指数関数的に
作業時間が増えていく事を考えれば幾分マシだと思います。
変なバグも入りにくいでしょうしね。
この辺りの判断は、経験を積んで覚えていくしかないでしょう。

それから、設計の際はモジュール化を意識しています。
#module 〜 #global を使って、関係あるものはひとつにまとめ、関係ないものと切り離す。
こうする事によって、プログラム全体が理解しやすくなるし、コードの再利用も可能になります。
さらに、設計が破綻する可能性を低減させる事が出来ます。
修正によってプログラムがどう動いているのか分からなくなる、という事もめっきり減ります。

ということでまとめ。俺の方針をば。

・設計対象は「決定した仕様 + 将来追加・修正される可能性のある仕様」!!
・モジュール化を意識しよう!!

> 仕様変更が出来るだけ起きないようにするにはどうすればいいでしょうか。

機能拡張しようなどと思わない事です。それ以外に方法はありません。

と言っても、良いアイディアがあれば誰でも機能拡張したいもの。
やっぱり、最初の段階でこれ以上アイディアが出ない位、先を見越して考えておく事が
大事なのでしょうね。


以上、長々とスミマセン…。
もっとすっきり説明出来んモンかな〜。

もしスキルアップ第一でプログラムしてる場合は、バッチリ仕様を決めなくてもいいし、
機能の追加もどんどん考えてもいいんじゃないかなと思います。
でも、作品は絶対完成させるよ！ってことを考えた場合は、
機能の追加は見直した方がいいと思います。

仮に、どんな機能の追加にも耐えられるようなプログラムを作りあげたとしても、
例えばゲームを作ってる場合、機能を追加することに夢中になっちゃうと、
ほかのこと(ゲームの基本データづくりとか、グラフィックとか)
に手が回らなくなっちゃうんですよね。
そのうちモチベーションが下がってきちゃって、企画は倉庫にポイ……。

私自身、プログラミング始めたばかりのころは自分の技術が上がっていくにつれて
あれもこれもと機能を詰め込んでたのはいい思い出です。
確かにスキルは上がったけど、完成できた作品は……ごほごほ。


ちなみに私が今作ってる作品は、追加したい機能は山ほどあるけど、
ぐっとガマンで見送ってます。
おかげで、無駄にたくさんの時間かかりそうにありませんし、
心なしかスッキリしたプログラムになってます。…‥ひねりが無くて寂しいですけど。
でも、デバッグはしやすいんですよ…。^^;

>もしスキルアップ第一でプログラムしてる場合は、バッチリ仕様を決めなくてもいいし、
>機能の追加もどんどん考えてもいいんじゃないかなと思います。

光さんのこの意見が正論じゃないかと思います。
知ってるけど手が届かないと思っていたテクニックを
「組み込める！」と気付いた瞬間と言うのは、
お宝の山を掘り当ててウハウハ気分といってもいい感覚でしょう。
そう言う場合には貪欲になる事も間違っていないと思います。
「親がこの分野に積極的だったので、既にある程度把握してる」と言うような人なら、
「ああ。まあね」と細かい要素をサワヤカにパスして、
「今ボクはトラブルの少ない書き方を見極めようとしている所で、、」と、
仕様の設計を優先するかも知れません。
この辺は本人によって事情が違うと思いますので、一概には言えない事でしょう。
貪欲になってしまう気持ちと完成を急ぐ気持ちは、
どちらも大事でいい事なんだからその時の自分の判断で進めるしかないでしょうね。
これでは何も言っていないのと同じと言う気もしますが、
まあ他の人も結構そんな感じでやってるみたいですよ。という事で。

私の場合。
初期段階で妄想の限り詰め込みたい要素をリストしつつ使用を決めていきます。
製作の段階で案の定、時間が足りないことがわかってくるのでどんどん仕様からはずしていきます。
新しい要素の付け加えはあんまりしないのですが、付け加えても他に影響がないような簡単なもの（構造上の許容範囲）なら実装しますが、そうでない場合は次回以降に持ち越します。

私の場合は仕様から機能が減ることはあっても増えることはあまりないので、どんどんスリムに…そしてボリュームに欠ける作品になって行きます。ｗ

他の方々がおっしゃるように将来追加・修正される可能性があることを考慮した構造を目指すのがベストですね。

トラブルの少ない書き方と言う意味では、
「データベースに要素を格納してSQLで管理！」と考える人もいるようです。
それは別に間違っていないと思うんですが、
そう言う人は、どうも「我々の方が優秀だから何も考えずに命令に従え！」と言うような、独特の雰囲気があったりします。
数学や優秀と言うキーワードを追いかけてしまっているような感じです。
コンピュータの専門学校の先生になった人が生徒を押さえ込んで、
命令に従うように必死になっているようにも思えます。
実態は「もともといい加減な人がグーグル大躍進を見て、情報管理とかそっちに流れただけ」だと思いますけど。
具体的な内容について、気になるので一応調べて見ました。
リレーショナルデータベースとか質問（クエリ)を命令(キュー)して答え(レスポンス)を引き出すとか、それっぽい用語は見られます。
が、リレーショナルデータベースと言っても、HSPの多次元配列で実現されている事と同じに見えます。
クエリとかカッコイイ単語を使っても、ソート機能を自分で書いた方が勉強になる気がします。
SQLiteを使った方が高速で高機能かも知れませんが、それらを偏愛するグループが異様に感じられて気持ち悪いんですよね。
使う分にはいいものだと思うんですが、数学や管理と言ったキーワードにエリートっぽいイメージを持ってしまうのは危険だと思います。
そう言う道具に使われている人には関わらない方がいいですよ。と思いました。マル。

ある程度切り離した部分は#includeでファイル分割していきますけど、
オフィシャルのエディタはシンプルなのでファイルがとっちらかっちゃいますね。
どうしても。

一人で開発する時は仕様なんか考えないで適当かなぁ〜。
一つのファイルに雑多にスクリプトを記述していって、
α版が完成したら、ちゃんと整理していくってかんじ。

沢山のレス、ありがとうございます。

設計からの流れは十人十色のようですね。
皆さんの意見を聞いて、色々と学ぶことが出来ました。
私なりの考えのまとめを描かせて頂こうかと思ったのですが、
とても長くなりそうですので、割愛させて頂きます。

何はともあれ、このような質問に答えて頂き本当にありがとう御座いました。
今後の開発にぜひ活かさせて頂きたいと思います。