| Top Page | プログラミング | PIY 目次 | 前へ | 次へ |
教科書の例題ではない，自分のためのプログラムを書きはじめるときの 心構え．
まずはすべてを理解して，それから完成版のプログラムをいきなり書きはじめて， というやり方よりも，少しずつ，限られた知識を使いながら，書けるプログラム を書いてみましょう．
何度も書きましたが，勉強途中の限られた知識でも有用なプログラムは書けます． ちょっとしたデータ処理などに挑戦してみましょう． 小さなワザをうまく組み合わせると，思っているよりもずっと 多くのことができます． パズルを解くような思考パターンでいろいろ工夫してみましょう．
頭をしぼった末にプログラムが思った通りに動くと嬉しいものです。 簡単なプログラムをいじりながら、工夫して制御するよろこびの感覚を ぜひ味わってみてください。 これを楽しいと思えるようになればしめたものです。 工夫を重ねながら最終目標を目指しましょう．
よいプログラマーは制御フリークだと言われます． 何かをこんなふうに動かしたいと思い、そのためにはこうすればよいはずだと推論し、 実際に試してみて、思ったとおりに動くととても嬉しい、という感覚でしょうか。 動かしたい対象はプログラムやコンピュータである必要はありませんが、 こうしたらこう動くという関係が理詰めで決まってることは制御フリークに とって重要な要素です。 あてずっぽだの山勘だのが当たっても嬉しくありません。 頭を使って動かしてください．
コンピュータは非常に高速で数値計算を行います． 人間が手計算でやってやれないことはないけれど，それでは１日かかるとか， 何万年かかかるとか，何十億年かかるという場合に，コンピュータに具体的な 計算方法を指示してやらせると能率がアップします． それだけです．
人間はとても融通がきくので，「さっぱりしたものを食べさせてくれ」 「なんでもいいからおもしろい文章を書いてくれ」「ここらへん，適当に 片づけといて」なぞといったファジーな依頼にもなんとか対応します． （すくなくとも今のところ）コンピュータではこうは行きません． きっちりと細部まで具体的な指示を与えなければいけません． その指示書がプログラムです．
「シカの個体群の動態をシミュレートするプログラムを書きたい」 とか「データロガーから吸い上げた気象データを統計処理するプログラムを 書きたい」とかいった希望は，「さっぱりしたものが食べたい」と同様に ファジーです．このままではプログラムは書けません．もっと具体的な 仕様書が必要です．
「シカの個体群動態をシミュレートしたい」という希望は， 「シカの齢ごとの死亡率，産仔数，そして 初期状態として各齢ごとの個体数を与えて，その後の毎年の 齢ごとの個体数を計算させたい」 「死亡数や産仔数を年変動させて，その影響を調べたい」 というように具体化する必要があります． この具体化の作業は，プログラミングの作業というよりも， 研究者の問題意識を整理する作業といってよいでしょう． いったい自分は何を知りたいのかをじっくり考えて， コンピュータにやらせたいことを整理しましょう． プログラムを書くことで自分の理解を整理したり深めたりする効果も期待できます． はっきり分かってることしかプログラムで表現できませんから （＞参考：計算機とものごとの理解 in KuboWeb ）．
（余談） あなたがプログラミングに習熟し，シミュレーションモデルを動かしはじめると， 他の研究者からモデル作製の依頼が来るかもしれません． そのときは注意が必要です．依頼者の頭のなかには「さっぱりしたものを食べたい」 レベルの問題意識しかなくて，あとはモデル作成者がやってくれる と思っている場合が時としてあります． あとで後悔しないように，じっくり話しあって，だれが何をどこまで考えるのかを はっきりさせてから，共同研究をするかどうか決めましょう．
プログラムにさせたいことが整理できたら， いきなりコーディング（プログラムを書くこと）を始めずに， どんな手順で目的の動作を実現するかを考えます．設計の段階ですね．
まずは大筋の流れを考え，全体の処理をいくつかの要素に分解し， それぞれの要素にやらせたいことを明確にします．ファジーな表現では コーディングのときに困ります．具体的なプログラムがイメージできる 程度にはっきりさせましょう． それぞれの要素が，いきなりコーディングするには大きすぎると思ったら， さらにその中での処理の流れを考えて，必要に応じて要素に分解します． 基本は「いきなりそんなの書けないよー」と思うようなプログラムを， 「それだけなら書けるな」と思える程度の要素に分解することです．
最初から機能フル装備のプログラムを書こうとせず，機能限定版から はじめるのが無難だし，能率もよいです． いきなり千行のプログラムを書いてみたもののうまく動かないと， いったいどこがまずいのかと途方に暮れてしまうでしょう． まずはコンパクトな機能限定版を書いてちゃんと動くようにして， それから徐々に必要な拡張をします． 限定版では動いたのに，拡張版ではうまく動かなかったら， 拡張部分に原因が潜んでいるはずです．それだけの手掛かりでも， バグ（プログラム中にひそむ間違い）の発見ははるかに容易になります．
機能限定版を書くときは，将来の拡張を念頭においておくことが重要です． まったく拡張性のない書き方をして，機能を足すにはまたゼロから 書きなおし，というのでは限定版から始める意味がなくなってしまいます． あとでここにこんなことを書き加えれば機能拡張ができるな，という ことを意識しながら書きましょう．
Perl の世界には "There's more than one way to do it." という標語があります． ひとつだけ正しいやりかたがあるわけではない，同じ目的の実現のためにも いろんな書き方があるよ，だから臆せずどんどん自分流に書いていいんだよ， という励ましです．
でも，どうせなら，いろいろあるやり方のなかでもより簡単に書けるもの， スマートで読みやすいもの，実行速度が速いもののほうが 望ましいのは間違いありません． 目的の動作をするプログラムが書けたら，もっと賢いアルゴリズムや 表現方法がないか，ちょっと考えてみる習慣をつけると上達に役立ちます． とくに，見た目がごたごたして読みにくいところは，プログラムの設計や アルゴリズムがごたごたしてる兆候です．もっと賢く，もっとスマートに 書けないか考えてみましょう．