■
今回、使用した開発方法。
動作確認環境を作成して、メソッド毎、機能毎の動作検証をした上で
目的のプログラム動作環境に移植する方法。*1
テスト環境を作って、いろいろテストしてから本番を作りましょう〜っていうような開発手順です。
目的とするプログラムは一連の流れである。
流れをそのまま作ると、不具合が「構成要素」にあるのか「流れ」の中にあるのか迷うことになる。
「構成要素」を作り、100%思惑通りの動きをすることを確認した上で「流れ」に持ち込めば、
不具合はほぼ間違いなく「流れ」にあると推測できることになる。
不具合を特定することの確実性をあげることにおいて、
「推測ﾎﾟｲﾝﾄを即座に判断できること」これは重要なことである。
早い話が↑を踏襲したのです。
1度四苦八苦して作ったプログラムをもう一度作り直すと洗練されたものになる
っていう周知の事実を「時間がないから〜」という言い訳をせずに踏襲したのです。
コーディング時間＝開発時間だと思うことは勘違いである。
開発時間はコーディング＋テスト＋デバッグ＋再テストの合計時間である。
このうち、時間がかかるのはどれであるかを自分なりに考えてみると、削る時間を割り出せる。
多くの人々は「デバッグ＋再テスト」に取られているはずである。
「コーディングが30分でおわったー」≡≡ﾍ( ´∀`)ﾉ
とはしゃいで言ったところで、
テスト＋デバッグ＋再テストに5時間かかれば、開発時間は5時間10分なのである。
コーディング＋テストに2時間かけても、デバッグ＋再テストが30分なら開発時間は2時間半なのである。
ちなみに。
駆け出しのｺﾛのおいらは前者のタイプ。
今のおいらは後者のタイプ。
コーディングってかプログラミングに時間をかけて、潜在バグを排除する方向で組むのです。( ´∀｀)
そのための動作確認環境。
ちなみに見知らぬ言語や初めて試すこともココでやる。
小さな構成要素を積み重ねておけば後を引き継ぐものもやりやすい。
プログラマ自身が自由になんでもできる実行動作環境があるのとないのでは
学習効果はだいぶ違うと思うのだが実際のとこどうなんだろ。
