「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典
第三十八回：プログラミングの勉強を始めて1週間くらいの人が読むと幸せになるかもしれない豆知識3つ
今は2019年6月17日の午前5時くらいです。特に書くことが思い浮かばないので、早速、本題に入ります。それでは今回もゆるく行ってみましょう。超不定期連載「分かりそう」で「分からない」でも「分かった」気になれるITコラムでございまぁす。このコーナーでは、各用語の説明ページでは取り上げにくいIT関連のネタをテーマに、だらだらと思いついたことを書いていきます。みなさんが「あぁ、なんか役に立ちそうな気もするけど、役に立たないかなぁ。でも、もしかしたら役に立つかも」と思える情報を発信できるように頑張ります！
はじめに
栄えある三十八回目のテーマは……ピヨピヨピヨピヨ（ぴよぴよ的ドラムロール）……じゃん！
プログラミングの勉強を始めて1週間くらいの人が読むと幸せになるかもしれない豆知識3つ
です。
前回のコラム「プログラミングの勉強を始めて3日目くらいの人が読むと幸せになるかもしれない豆知識3つ」で豆知識を3つ披露しました。
新コンテンツ「ピヨちゃんの知恵袋」でまとめようと思って温めていたけどネタが集まらないから公開しちゃった選りすぐりの（ショボい）ネタたちです。
ところがどっこい、あの後ですね。
「あっ、これも豆知識かな？」と思えるネタが思い浮かんでしまったのです。
何だかんだで3つくらい溜まったので、それも公開してみることにしました。
……というのが今回のコラムを書いた動機です。
ちなみに、お忙しい人向けに先に結論を書いておくと
１．コピペで作ろう
２．先人の書いたコードをパクろう
３．こまめに動作確認しよう
の3つです。
最後まで読んでくださる方は、この結論を知らないことにして読み進めてください。
なお、ある程度プログラミングに慣れた人には今回のコラムは役に立たないと思います。
既に自分なりの方法論を持っているはずだからです。
今回は、まだ自分なりの方法論が出来上がっていない人に向けて、私が「プログラミング初心者は、こんなやり方を試してみても良いんじゃないかな？」と思う内容を取り上げてみました。
コピペで作ろう
今回、紹介する1つ目の豆知識は
コピペで作ろう
です。
プログラミングというのは横着してなんぼです。
だから、できるかぎりコピペで作るようにしましょう。
とはいえ、他の人が書いた処理を「何をやってるか分からないけど動くから良いや」でコピペしましょうと言っているわけではありません。
個人的に「これはコピペした方が良いよ」と思っているのは
変数名
です。
例えば、そうですね。
ピヨ太君が以下の処理を書きました。
namea = "piyota";
print namae;
ピヨ太君的には、画面上に「piyota」と表示される処理を書いたつもりでした。
ですが、実際に動かしてみると、画面上には何も表示されません。
何でだよ！（#￣д￣）
……みたいな失敗は「初心者あるある」でしょう。
画面上に何も表示されない原因は変数名を間違っているからです。
「namea」という変数に値を入れたのに、表示するときに指定している変数は「namae」です。
変数名が違いますよね。
分かってしまえば「なーんだ。それだけか」なケアレスミスですが、実際にやっちまうと意外に気づかないものです。
変数名をコピペにすることで、そのようなケアレスミスは避けられます。
ピヨ太君がやっちまった処理もコピペで作れば以下のようになるはずです。
namea = "piyota";
print namea;
本当は「namae」としたかったのだとは思いますけどね。
「namea」でも、とりあえず期待通りの動きはします。
後で「あっ！変数名が間違ってる」と思ったら、全部まとめて置換すれば良いだけです。
直すこと自体は難しくないでしょう。
ということで、個人的には
変数名はコピペで作る
のが横着する上でもミスを防ぐ上でも有効なやり方だと思っています。
手順でミスが防げるなら防ぎましょう。
小さな積み重ねが大きな成果につながります。
先人の書いたコードをパクろう
今回、紹介する2つ目の豆知識は
先人の書いたコードをパクろう
です。
主な理由は
１．読解力を鍛える練習になるから
２．作りを合わせる練習になるから
３．単純に勉強になるから
です。
順番に見ていきましょう。
まずは
１．読解力を鍛える練習になるから
について説明します。
お仕事でやるプログラミングは、新しいプログラムを作ることばかりではありません。
既にあるプログラムを変更する場合もあります。
変更する対象は自分が作ったプログラムとも限りません。
他の人が作った「うわー、ごちゃごちゃ書いてて、何やってるか分からないよー」なプログラムに変更を加える必要に迫られる場合もあります。
そんなときに最初にやることは他人の書いたソースコード（プログラムの元ネタ）を見て「これは何をやってるのかな？」を読み取ることです。
先人の書いたコードをパクることは、その際の読解力を鍛える練習になります。
大前提として、他の人が書いた処理を「何をやってるか分からないけど動くから良いや」でコピペするのは良くありません。
パクるときは中身を理解して自分のものにしてから活用しましょう。
それを意識してパクっていると、自然と他の人が書いた処理を読み込むことになります。
「何をやっているのか」や「それを何故やっているのか」などを考えるようになります。
それを繰り返していると、他人の書いたコードの内容を読み取るのが速くなります。
お仕事で他人の書いたソースコードに手を入れる際の時間短縮につながるはずです。
処理の書き方のクセは人によって違います。
他の人が書いたコードを理解するのは意外に大変です。
他の人が書いたソースコードを読み込むことは、（お仕事でプログラミングするつもりなら）慣れておいて損はありません。
次にいきましょう。
２．作りを合わせる練習になるから
について説明します。
誤解をおそれずに言うと、（一部の例外を除いて）お仕事でやるプログラミングにオリジナリティは不要です。
「書いた本人しか分からない画期的な処理」よりも「誰でも分かる凡庸な処理」の方が価値があります。
特に、あなたがフリーランスだったりして、システム会社さんから「このシステムの一部の機能をお願いしたいです」みたいな仕事をいただいたときは注意が必要です。
あなたが作りたいように作るのではなく、あなたに仕事を依頼した人が作ってもらいたいように作る必要があります。
「こう作ってください」なコーディングルールがあれば、それに合わせるだけですけどね。
コーディングルールがない場合も少なくありません。
そんなときに無難なのは、他のプログラムに作りを合わせておくことです。
その会社さんが作った過去のプログラムだったり、今回作る予定の他の機能だったりのソースコードを見せてもらって、その作りに合わせておくと文句を言われる可能性が少し減ります。
先人の書いたコードをパクることは、その際の作りを合わせる練習になります。
「パクる」とは言っても、そのまま丸ごとパクっては権利関係でうんちゃらだったりしますし、やりたいことに合わなかったりするでしょう。
きっとパクりつつ自分なりの手を入れることになるはずです。
そのような「ベースがあって、それに手を加えて目的の物を作る」練習をしておくと、仕事で他のプログラムと作りを合わせるときに少し楽だったりします。
次にいきましょう。
３．単純に勉強になるから
について説明します。
これは、そのまんまですね。
同じ処理でも、いろいろな書き方があります。
その「いろいろ」を多く蓄えておくことは損にはなりません。
選択肢の幅が広がるので、余裕につながります。
別に「先人の書いたコードをたくさん読む」でも良いのですけどね。
やっぱりプログラミングは動かしてなんぼだと思うので「パクる」としておきました。
あっ、そうそう。
「パクる」とは書いていますが、権利関係は意識してくださいね。
元のコードを書いた人があなたのやっていることを知ったときに「このやろう！」となるようなパクり方はいけません。
インパクト重視で「パクる」という表現を使っていますが「参考にする」とか「（尊敬をもって）模倣する」とか、そんなニュアンスです。
こまめに動作確認しよう
今回、紹介する3つ目の豆知識は
こまめに動作確認しよう
です。
最近のプログラミング言語は以前に比べて動かすのが簡単になりました。
開発環境も整っているので、ボタンを1つポチっと押せば動かせたりします。
だったら、ガンガン動かしましょう。
こまめに動作確認することで、うまく動かないときに「どこの処理で動かなくなったのかな？」を把握しやすくなります。
例えば、そうですね。
最終的に以下の処理を書きたいとしましょう。
namae="piyota";
if(namae != ""){
print namae;
}
そんなときは、まず以下の内容で動作確認します。
print "piyota";
もし、これで動かなかったら、画面に表示する処理の書き方に問題があると分かります。
スペルミスがないかとか、最後のセミコロン（;）を書き忘れてないかとかをチェックしましょう。
ちゃんと動いたら、処理の内容を以下のように書き換えて動作確認します。
namae="piyota";
print namae;
もし、これで動かなかったら、変数の扱い方に問題があるということです。
スペルミスとかのチェックはもちろん、そもそも変数の扱い方が正しいのか？などをチェックしましょう。
いよいよ、最後の仕上げです。
処理の内容を以下のように書き換えて動作確認します。
namae="piyota";
if(namae != ""){
print namae;
}
もし、これで動かなかったら、条件分岐（if文）の書き方に問題があるということです。
条件分岐（if文）の書き方が正しいのかをチェックしましょう。
今回の例では、全部の処理を書き終えるまでに3回、動作確認しました。
それぞれの動作確認における確認の観点は
１．画面に文字を表示できるか
２．変数に入れた値を画面に表示できるか
３．条件分岐させて画面に表示できるか
です。
このように、こまめに動作確認することで「どこの部分に問題があって動かないのかな？」を把握しやすくなります。
一見すると遠回りに思えるかもしれませんけどね。
「うまく動かない原因を探す」時間は「実際に処理を書く」時間とは比較にならないくらい長くなりがちです。
そして「うまく動かない原因を探す」時間は本来なくても良い時間です。
理想論ですが、最初から完璧なプログラムを作ればゼロにできます。
会社とかに入って先輩の働きっぷりを見ると「なんで、あんなにプログラミングが速いの？」と驚愕することもあるはずです。
そんなスーパーエンジニアの先輩たちも「実際に処理を書く」時間については、あなたとそこまでの差はありません。
タイピング速度があなたの3倍！なんてことは少ないはずです。
それでは、なんで、あんなに速いのか？
工夫次第で削れる時間を徹底的に削っているからです。
（※もちろん知識の蓄積とかもあります）
「うまく動かない原因を探す」時間も削れる時間のひとつです。
こまめに動作確認するようにすると、動かない原因が潜んでいる範囲を限定できるので、原因を探すのが速くなりますよ。
コツは
ちゃんと動く部分を少しずつ増やす
ように意識することです。
「ここは確実に動いているな」な部分を地道に少しずつ増やしていって、最終的に全部、動くようにします。
まぁ、それでもバグ（不具合）が隠れているのが普通ですけどね（－。－）ぼそっ
まとめ
今回は
プログラミングの勉強を始めて1週間くらいの人が読むと幸せになるかもしれない豆知識3つ
というテーマで好き勝手に語ってみました。
今回のコラムで言いたいことは
１．コピペで作ろう
２．先人の書いたコードをパクろう
３．こまめに動作確認しよう
の3つです。
ネタ集めを止めたらネタが増えるとは、皮肉なものです。
もし、この調子でネタが増えていくようだったら「ピヨちゃんの知恵袋」として、まとめ直します。
あっ、そうそう。
最後に大事な注意事項です。
「パクろう」とは書きましたが、怒られるようなパクり方は止めてくださいね。
ニュアンスとしては「（尊敬をもった）模倣」です。
イヤなパクり方をすると知識を公開してくれる人が減るので業界自体の元気がなくなって結局自分たちの首を絞める結果になると思います。
思いつきで始めて惰性で続けている「分かりそう」で「分からない」でも「分かった」気になれるITコラムですが、いかがでしたでしょうか。また何かネタがあったら、ちまちまと更新していきます。コンゴトモヨロシク。
