NW屋的日常徒然日記

ネットワークを専門にする元社内SEの日常とITネタ諸々を綴って行きます。

プログラミング喰わず嫌いから脱出するヒントみたいなもの

 こんばんは。今回はちょっと緩めのネタですがお付き合い下さい。

 最近、シェルスクリプトを書く機会が増えてまして。正確には、他人が書いたシェルスクリプトを手直ししているといったところでしょうか。

 追い込まれるとなんとか出来るものですよね

 私自身、プログラミング(シェルスクリプトですけど、ここでは広い意味での「プログラミング」としてお話を進めます)自体はそんなに得意ではないんです。それでも、ネットワーク関係の仕事をしていると、単純作業を自動化したいということはあります。なので、避けて通れない場面もあるんですよね。

 私自身の話で恐縮ですが、「克服」とまでは行きませんが、どうにかこうにか対処出来た経験に基づいて書いてみようかと思います。数年後に小学校でプログラミング教育が始まります。「どうやってプログラミングを克服すればいいのだろう…」と悩んでいる小学校の先生方のお役に少しでも立てれば…という想定で書いてみます。

(具体的な対象者を設定した方が書きやすいかと思いました。もちろん、小学校の先生に限りません。「どうもプログラミングが苦手だ」という方の一助になればと)

 ざっと一連の流れを追ってみました

 自分自身でやってみたことをつらつらと書き出してみました。

  1. まず、最終目的(何をやりたいか)を書き出す
  2. そのために何が必要かをとりあえず書き出す
  3. すべき内容をパーツ毎に細かく分割してみる
  4. 全体の流れを考えて、大枠を作ってみる
  5. 3.で作ったパーツを仮に当てはめてみる
  6. 流れにおかしな点がないかを確認してみる
  7. 実際に動かしてみる
  8. エラーメッセージを基に該当箇所を調べる
  9. 手直しする
  10. 7.に戻る
  11. 正常に動作するまで繰り返す
  12. 動作確認完了

 といった流れになろうかと思います。別にプログラミングだからといって特殊なことはないんじゃないかと思えてきました。何をしたいのかをはっきりさせて、おおよその流れを理解してから設計図を書いてみる。設計図に基づいて個々の部品(モジュール)を作る。個々の部品がちゃんと動いたら、その部品をどの順番で組み合わせればいいかを確認する。そして、継ぎ目のチェックを行い、ひたすらテスト。

 「とりあえず設計図を描く」から始めてみる

 そんな感じだと思います。プログラミングに苦手意識を持ってしまうのは、案外1.の部分で躓くケースが多いんじゃないかと勝手に推測してます。「何をしたいのか?」ということを書き出してみましょう。そうすると、「そのためには何が必要か?」「そのためには何をしないといけないか?」が見えてくるはずです。

 プログラミング恐れるに足らず。まずはやってみましょう!(^^;;