- INDEX -
プログラミングは簡単
ソース（料理じゃない）
仕様書？
変数の型って？
関数とサブルーチン
無限ループ
あっちいけ！(GOTO文)
とりあえず動けばいい
シンプル is ベスト
| プログラミングは簡単 どうも「プログラミング」と聞くと難しそうだと思う人が多いようですが、全然そんなことはありません。 言語によって命令文は違ってきますが、だいたい１０くらいの命令を覚えるだけで簡単なプログラムは 作ることができます。 表計算の式を使いこなしている人なら絶対プログラミングできます。 マクロを使っている？あなたは既にプログラマです（笑）。 コンピュータはやらせたいことを順番に教えていけば 基本的にその通りに動いてくれるものなのです。 難しいのは何をプログラミングしたいか、という動機です。 最近はフリーウェアがたくさんあってやりたいことを既に実現してくれるので、わざわざ自分で作る必要を 感じることは少ないでしょう。それでも自分で工夫して作ったプログラムは機能が劣っていても愛着があって 可愛いものです。 是非自分だけのプログラムを作ってみましょう。 |
| ソース（料理じゃない） ソースといってもブルドッグもイカリも関係ありません。英語の辞書では「源泉」とかいう意味だったと思います。 プログラミングでは「ソースリスト」などといわれるものです。 開発言語にはいろいろな種類がありますがコンピュータが理解できるのは「機械語」という言葉だけです。 開発言語は人間がわかりやすい言葉で記述できるように工夫して「コンパイル」という作業をすることで 機械語に変換しているのです。コンパイルする前の人間にわかりやすく記述したものを「ソース」と言うのです。 ソースには人柄が出てきます。きれいなソース、汚いソース、シンプルなソース、難解なソース。 「ソースがスパゲティ」という言葉があります。ごちゃごちゃしててこんがらがって理解するのに苦労する ソースリストのことです。できるだけ、きれいにシンプルに美しいソースを書きたいものです。 |
| 仕様書？ プログラミングが難しく見える要因のひとつに仕様書があります。流れ図（フローチャート）や画面設計、 出力設計、オブジェクト一覧、オブジェクト関連図などなど・・・。こんなものを見ていたらうんざりして 嫌になることうけあいです（笑）。 私はずいぶんプログラムを作ったり、他人のプログラムを修正したり しましたが、仕様書が役に立った経験は全くありません。本当に要るのはファイルレイアウトとソースだけ です。特にソースこそ仕様書だと思います。仕様書はメンテナンスを忘れることが多いですがソースが メンテナンスされていないことは考えられません。だからこそソースは読みやすく分かりやすく書く必要が あります。別にフローチャートを作るぐらいなら、ソースにコメントを書くくらい苦痛ではありません。 何よりも後で自分が修正するときに役に立ちます。 プログラミングの世界に「自分のプログラムも １カ月経てば人のプログラム」というのがあります。作っている最中はどんな複雑なコードも頭の中に 入っているものですが、完成してしばらく経つともう人の作ったプログラムのように忘れてしまっている ということを意味しています。これは本質を見事についている言葉です。仕様書など要りません。 それよりも人に見てもらえるソースを書きましょう。 |
| 変数の型って？ 変な数、ではなくて変化する数ですね。算数か数学で習うんだっけ？連立方程式で使うＸやＹが変数です。 定数というのもあります。値が定まっている数です。プログラミングでは変数が主役で活躍します。 常に同じ数字を使って同じ計算をして同じ結果を出すのならプログラムする必要はありません。 ここにこの数字が入ったら結果がどう変わるのだろう？という変化があるからプログラムの価値があるのです。 さて、この変数ですが「型」というものを宣言する必要があります。簡単に言うと「文字」か「数字」かを あらかじめ決めておかなければいけないのです。しかも「文字は何文字か」、とか「数字は何桁までか」、とか 「小数点以下は？」とかで違ってきます。ＶＢ(Visual Basic)のように桁が足りないと「オーバーフロー」する こともあれば、Ｃ言語のようにある数値を超えたらマイナスになることもあります。 使う数字の範囲を最初に考える習慣をつけると型の間違いによるエラーはだいぶ防げます。 あ、今やっているCGIは型の宣言を省略することができます。楽チンですね。 |
| 関数とサブルーチン 言語によって呼び方が違ったり、意味が違ったりするのですが、よく似た機能です。プログラムの中で同じような 計算や処理を何度も実行する必要がある時、その計算や処理をひとかたまりに独立させて記述しておいて必要な場所で 呼び出すようにするものです。プログラムのパーツだと考えるとよいでしょう。私がプログラミングするパターンでは メインルーチンの大まかな流れを記述し、ここでチェックをするとか、ここでマスタを見るとか、処理の部分には とりあえずサブルーチン名だけを書き込んでおきます。あとでサブルーチンの中身を考えていけばプログラムが だんだん形になってくる訳です。一つの処理しか考えなくて済むので結構楽チンです。 また、似たような処理だけどちょっと違う処理が発生する場合がよく出てきます。それを２つにわけるかひとつの サブルーチンで記述できるか、がプログラマの腕の見せ所だと思っています。 パラメータをうまく生かして汎用的に使えるサブルーチンを書けるようにしたいのもです。 いいサブルーチンはどのプログラムでも使うことができるオールマイティカードのようなものです。そういう サブルーチンをたくさん持っているほど、よいプログラムが早く作れる秘訣だと思います。（私の憧れです） |
| 無限ループ 私が最初にプログラミングで「しまった！」と思ったのは、この無限ループをやってしまったときでした。 オフコンのプログラム言語で終了のルーチンを記述し忘れたため何度もプログラムが際限なく実行されオフコンの CPUが100%稼動して他の業務が動かなくなってしまったのです。ＶＢでデータベースを処理するときも時々やって しまいます。レコードの最後でループを抜ける条件にしているのに次のレコードを読みに行く命令を忘れて何度も 同じレコードを処理してしまい、プログラムが異常終了してしまいます。 逆にＣ言語のメニュープログラムなどはユーザーの入力待ちを監視するためにわざと無限ループをさせることも あります。この無限ループは確実にＣＰＵを消費しますのでwhile文やdo文を使う時には十分注意すべきです。 特にCGIではサーバをダウンさせてしまいますので多くの人に迷惑をかけることになってしまいます。 ローカルサーバで十分テストするようにしましょう。 |
| あっちいけ！(GOTO文) 初期のBASICは短いプログラムを書いている時は感じないのですが、少し長いプログラムになると後からプログラム を追いかけていくのが非常にやっかいになります。 ソースリストを印刷して赤鉛筆で矢印を書いていって理解しようとしても矢印が交錯して読めなくなるのです。 この困難さの原因が「GOTO命令」です。 初期のBASICでは「GOTO 1000」とか「GOTO 3000」とかが頻繁に出てきてソースリストの1ページから5ページに飛んで そこから10ページに飛んで、次は2ページに戻って、また10ページに飛んで･･･…あー！！もうわからん！！ ということになります（号泣） でも、制御系ではどうしてもGOTOを使ってしまうのです。使わないとプログラムは書けないと信じていました。 ところが、私が初めて使ったC言語ではGOTOに相当する命令がなかったのです（ガーン！）記憶があいまいになって いますがC言語の開発者は新しい言語を作るにあたり、分岐命令をまとめた結果、if(条件分岐)とfor、while、until (条件繰り返し)があればGOTOのような無条件ジャンプは不要だという結論に達したということです。 私も、その言葉を信じてプログラミングしてみました。するとGOTOがなくても書けるではないですか！ しかもifやwhileはブロック化されてまとまっているのでソースも読みやすい！ …それ以来、私はGOTOを使うのをやめました。皆さんも一度試してみてはどうでしょう。 |
| とりあえず動けばいい プログラミングをやっていると「ひとつの目的を実現するための方法はたくさんある」ということがわかってきます。 どの方法が正しくて、どの方法が間違っているのか。私は目的に合う動きをするのであれば、どの方法も 正しいと思ってます。ただ、より使いやすいかどうか、という視点で望ましいプログラムという理想像が できてくるのだと思います。 一度作ればそのまま絶対に修正が不要であれば、プログラムを再び見る必要はないので、どんなソースでも 構いません。動きさえすれば、それでいいのです。しかし今後まったく修正が要らないプログラムというのは なかなか存在しません。それが使いやすく便利であればあるほど、使っていくうちに新たな要望が生まれて きます。プログラムに「これで最後」はないのです。だったら開発する側としてはまず必要最低限の機能が 満たされるプログラムを作って、それを幹として、それから発生する要望という枝葉を随時付け加えていく ほうが作りやすいと思います。開発の前に仕様をかっちり固めてから開発を開始することも大切かもしれません が、私はまず動かして使う人のわかりやすい形を見せて次のステップのつなげていくことが、開発者にとっても 使用者にとっても幸せなことだと思っています。 まず、動かすことです。 |
| シンプル is ベスト プログラミングをしているといろいろなことの仕組みを考える習慣ができてきます。コンピュータに処理の説明をするのが プログラマの仕事ですから、仕組みが理解できてないと説明することができない、つまりプログラミングができないのです。 この説明が簡単にできるかどうかでプログラムの品質が変わってきます。 簡単な説明ができるということはキチンとパターン化されているということです。処理の流れが大きなひとつだけなので プログラムも組みやすく大きなバグも出にくく理想的です。 イレギュラー処理がひとつあるとどうなるでしょう。まず、イレギュラーかどうかを判定するルーチンが必要になります。 それからイレギュラーの時の処理を組み込みます。そのためプログラムはふたつの流れに分けれてしまいます。 ルーチンが増えるのでソースも長くなり変数も増え、バグが発生しやすくなります。 １００のうちたった１を特別扱いにするだけでプログラムは複雑になってしまいます。 何かをプログラム化したい場合は、まず仕組みを整理してできる限り例外処理をなくすことが大切です。 （なんだか今回はプログラム以前の話ですね(^^; |