|
1 - プログラミングは簡単 |
どうも「プログラミング」と聞くと難しそうだと思う人が多いようですが、全然そんなことはありません。言語によって命令文は違ってきますが、だいたい１０くらいの命令を覚えるだけで簡単なプログラムは作ることができます。
表計算の式を使いこなしている人なら絶対プログラミングできます。マクロを使っている？あなたは既にプログラマです（笑）。
コンピュータはやらせたいことを順番に教えていけば基本的にその通りに動いてくれるものなのです。
難しいのは何をプログラミングしたいか、という動機です。最近はフリーウェアがたくさんあってやりたいことを既に実現してくれるので、わざわざ自分で作る必要を感じることは少ないでしょう。それでも自分で工夫して作ったプログラムは機能が劣っていても愛着があって可愛いものです。
是非自分だけのプログラムを作ってみましょう。 |
|
2 - ソース（料理じゃない） |
ソースといってもブルドッグもイカリも関係ありません。英語の辞書では「源泉」とかいう意味だったと思います。プログラミングでは「ソースリスト」などといわれるものです。
開発言語にはいろいろな種類がありますがコンピュータが理解できるのは「機械語」という言葉だけです。開発言語は人間がわかりやすい言葉で記述できるように工夫して「コンパイル」という作業をすることで機械語に変換しているのです。コンパイルする前の人間にわかりやすく記述したものを「ソース」と言うのです。
ソースには人柄が出てきます。きれいなソース、汚いソース、シンプルなソース、難解なソース。「ソースがスパゲティ」という言葉があります。ごちゃごちゃしててこんがらがって理解するのに苦労するソースリストのことです。できるだけ、きれいにシンプルに美しいソースを書きたいものです。 |
|
3 - 仕様書？ |
プログラミングが難しく見える要因のひとつに仕様書があります。流れ図（フローチャート）や画面設計、出力設計、オブジェクト一覧、オブジェクト関連図などなど・・・。こんなものを見ていたらうんざりして嫌になることうけあいです（笑）。
私はずいぶんプログラムを作ったり、他人のプログラムを修正したりしましたが、仕様書が役に立った経験は全くありません。本当に要るのはファイルレイアウトとソースだけです。特にソースこそ仕様書だと思います。仕様書はメンテナンスを忘れることが多いですがソースがメンテナンスされていないことは考えられません。だからこそソースは読みやすく分かりやすく書く必要があります。別にフローチャートを作るぐらいなら、ソースにコメントを書くくらい苦痛ではありません。何よりも後で自分が修正するときに役に立ちます。
プログラミングの世界に「自分のプログラムも１カ月経てば人のプログラム」というのがあります。作っている最中はどんな複雑なコードも頭の中に入っているものですが、完成してしばらく経つともう人の作ったプログラムのように忘れてしまっているということを意味しています。これは本質を見事についている言葉です。仕様書など要りません。それよりも人に見てもらえるソースを書きましょう。 |
|
4 - 変数の型って？ |
変な数、ではなくて変化する数ですね。算数か数学で習うんだっけ？連立方程式で使うＸやＹが変数です。定数というのもあります。値が定まっている数です。プログラミングでは変数が主役で活躍します。常に同じ数字を使って同じ計算をして同じ結果を出すのならプログラムする必要はありません。ここにこの数字が入ったら結果がどう変わるのだろう？という変化があるからプログラムの価値があるのです。
さて、この変数ですが「型」というものを宣言する必要があります。簡単に言うと「文字」か「数字」かをあらかじめ決めておかなければいけないのです。しかも「文字は何文字か」、とか「数字は何桁までか」、とか「小数点以下は？」とかで違ってきます。ＶＢ(Visual Basic)のように桁が足りないと「オーバーフロー」することもあれば、Ｃ言語のようにある数値を超えたらマイナスになることもあります。使う数字の範囲を最初に考える習慣をつけると型の間違いによるエラーはだいぶ防げます。
あ、今やっているCGIは型の宣言を省略することができます。楽チンですね。 |
|
5 - 関数とサブルーチン |
| 言語によって呼び方が違ったり、意味が違ったりするのですが、よく似た機能です。プログラムの中で同じような計算や処理を何度も実行する必要がある時、その計算や処理をひとかたまりに独立させて記述しておいて必要な場所で呼び出すようにするものです。プログラムのパーツだと考えるとよいでしょう。私がプログラミングするパターンではメインルーチンの大まかな流れを記述し、ここでチェックをするとか、ここでマスタを見るとか、処理の部分にはとりあえずサブルーチン名だけを書き込んでおきます。あとでサブルーチンの中身を考えていけばプログラムがだんだん形になってくる訳です。一つの処理しか考えなくて済むので結構楽チンです。また、似たような処理だけどちょっと違う処理が発生する場合がよく出てきます。それを２つにわけるかひとつのサブルーチンで記述できるか、がプログラマの腕の見せ所だと思っています。パラメータをうまく生かして汎用的に使えるサブルーチンを書けるようにしたいのもです。いいサブルーチンはどのプログラムでも使うことができるオールマイティカードのようなものです。そういうサブルーチンをたくさん持っているほど、よいプログラムが早く作れる秘訣だと思います。（私の憧れです） |
|
6 - 無限ループ |
| 私が最初にプログラミングで「しまった！」と思ったのは、この無限ループをやってしまったときでした。オフコンのプログラム言語で終了のルーチンを記述し忘れたため何度もプログラムが際限なく実行されオフコンの CPUが100%稼動して他の業務が動かなくなってしまったのです。ＶＢでデータベースを処理するときも時々やってしまいます。レコードの最後でループを抜ける条件にしているのに次のレコードを読みに行く命令を忘れて何度も同じレコードを処理してしまい、プログラムが異常終了してしまいます。逆にＣ言語のメニュープログラムなどはユーザーの入力待ちを監視するためにわざと無限ループをさせることもあります。この無限ループは確実にＣＰＵを消費しますのでwhile文やdo文を使う時には十分注意すべきです。特にCGIではサーバをダウンさせてしまいますので多くの人に迷惑をかけることになってしまいます。ローカルサーバで十分テストするようにしましょう。 |
|
7 - あっちいけ！(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を使うのをやめました。皆さんも一度試してみてはどうでしょう。 |
|
8 - とりあえず動けばいい |
プログラミングをやっていると「ひとつの目的を実現するための方法はたくさんある」ということがわかってきます。どの方法が正しくて、どの方法が間違っているのか。私は目的に合う動きをするのであれば、どの方法も正しいと思ってます。ただ、より使いやすいかどうか、という視点で望ましいプログラムという理想像ができてくるのだと思います。
一度作ればそのまま絶対に修正が不要であれば、プログラムを再び見る必要はないので、どんなソースでも構いません。動きさえすれば、それでいいのです。しかし今後まったく修正が要らないプログラムというのはなかなか存在しません。それが使いやすく便利であればあるほど、使っていくうちに新たな要望が生まれてきます。プログラムに「これで最後」はないのです。だったら開発する側としてはまず必要最低限の機能が満たされるプログラムを作って、それを幹として、それから発生する要望という枝葉を随時付け加えていくほうが作りやすいと思います。開発の前に仕様をかっちり固めてから開発を開始することも大切かもしれませんが、私はまず動かして使う人のわかりやすい形を見せて次のステップのつなげていくことが、開発者にとっても使用者にとっても幸せなことだと思っています。
まず、動かすことです。 |
|
9 - シンプル is ベスト |
プログラミングをしているといろいろなことの仕組みを考える習慣ができてきます。コンピュータに処理の説明をするのがプログラマの仕事ですから、仕組みが理解できてないと説明することができない、つまりプログラミングができないのです。この説明が簡単にできるかどうかでプログラムの品質が変わってきます。
簡単な説明ができるということはキチンとパターン化されているということです。処理の流れが大きなひとつだけなのでプログラムも組みやすく大きなバグも出にくく理想的です。
イレギュラー処理がひとつあるとどうなるでしょう。まず、イレギュラーかどうかを判定するルーチンが必要になります。それからイレギュラーの時の処理を組み込みます。そのためプログラムはふたつの流れに分かれてしまいます。ルーチンが増えるのでソースも長くなり変数も増え、バグが発生しやすくなります。１００のうちたった１を特別扱いにするだけでプログラムは複雑になってしまいます。
何かをプログラム化したい場合は、まず仕組みを整理してできる限り例外処理をなくすことが大切です。（なんだか今回はプログラム以前の話ですね(^^; |
|
10 - 作る喜びを大切に |
これまでいろいろとプログラムを作ってきました。
よく飽きずに作ってるなあ、と自分ながら感心しています。
今回はあらためてプログラミングの何が楽しいのかを考えてみました。
まあ考えるまでもなく自分の思い通りにコンピュータに処理をさせることができることが最大の喜びだと思います。
物を創る喜びと同じです。模型作りや日曜大工あるいは編み物や手芸品のように「こういうものを作りたい」という気持ちで作り始め、思い通りの物が出来上がっていく過程が楽しいのです。
創っていくうちにいろいろと工夫をしたくなります。自分で考えた工夫がなんとかかんとか形になって動いた時は本当に嬉しいです。
最初はできないことがたくさんあります。いろいろ創っていくことでたくさんの技術を学ぶことができます。そうしているうちに気がつくと以前できなかったことができるようになっていたりします。
それがまた嬉しいです。
パソコンは次々に新しいことが出てきます。もっともっと挑戦したいことがたくさん出てくると思います。
まだまだ楽しみが尽きることはなさそうです。
|
|
11 - 動かしながら作る |
最近、Ｗｅｂで動かす業務系のプログラムを「VBScript」で書いてます。
まだ覚えはじめて日が浅いので、あちこちのサイトを巡って関数を調べながら作ってます。
作りながら思うことはプログラミングの基本ステップです。
私の場合、作成するプログラムはできるだけ早い段階から動かせることに主眼を置いてコーディングします。
例えば、画面に30くらい入力項目があって、データベースから5つくらいテーブルを参照して入力チェックして、データベースに書き込みをして、変更結果を画面に再表示するプログラムを作るとします。
私はまず画面に入力欄をひとつとボタンをひとつ作って表示させます。次にデータベースの接続処理を書いて、入力値をチェックするルーチンを追加します。
うまくチェックできたら、もう少し入力項目を増やしたり、実際にデータの書き込み処理を追加したりしていきます。
まだどのように実現させればよいか分からない部分は、後で調べることにして、とりあえずサブルーチンの枠だけ作ったりします。
つまり、どの時点でも「ちゃんと動く」という確認をしながら安心して作っていくのです。
こうして最初の頃から少しずつ作っては動かしながら、徐々に形を整えて機能を充実させていくのが私のやり方です。
このやり方だと次に作らなければならない場所や調べなければならない技法が把握できますし、割と見通しの良いプログラムが組めているような気がします。
|
|
12 - 変更する勇気 |
プログラムは進化します。
事前にどんなに考慮し、検討を重ね、思いつく全ての事象を網羅して作成したシステムであっても、すぐに新しい要求や、運用方法の変更や、新しい技術の導入によって修正をすることになります。
このプログラムの修正作業は楽しい反面、不安に頭を悩ませることが多いです。
人は知らないでしょうが、プログラムを変更するというのは本当に勇気の要ることなんです。
簡単なシステムで、関連プログラムが全然ないプログラムなら、それほど苦になることはありません。でも複雑で、いくつものシステムに関連して、しかも毎日動き続けているシステムを修正するのは大変です。
ソースを直して、いよいよコンパイルする時には、何度もためらいます。最悪の結果が頭をよぎります。ダミーデータで何度もテストしていても、やっぱり不安です。見落としがあるような気がするのです。
「でも、これをやらねばならない！」という決意でコンパイルのボタンを押すのです。
こうした経験をすることで、システムでの「モジュールの独立性」を意識するようになりました。
プログラムの変更の影響ができるだけ他に及ぼさないように、処理をひとつにまとめていくのです。
そうしておくとミスがあっても、小さい範囲の影響で済みます。確認するプログラムを少なくなります。
「データの入力はひとつのプログラムでしか実行しない」「データの更新は必要最小限のプログラムで実行する」。データの更新ポイントを明確にしておくとともに、ポイントを少なくすることが大切です。
常に万全の準備とバックアップとテストをして、勇気を持ってシステム修正に立ち向かいたい自分です。
|
