🌱

プログラミングができるようになるために必要な10のこと

2023/05/16に公開

初心者

学習

idea

はじめに

私は情報系の学部に通う大学生で、あるサークルでちょっとしたアプリ開発のようなこともしている。もちろん情報系の学部なのでプログラミングの授業がある。そしてこんな環境であれば当然プログラミングができる人とできない人がいる。
この記事は、サークルに入ってきてプログラミングつよつよになりたい新入生に向けて書いた記事である。既にある程度のコードを書ける人向けではなく、本当のプログラミング初心者を対象とした記事であることをご了承願いたい。

プログラミングができないってどういうこと？

プログラミングができない、とだけ聞くと人によって様々なイメージが思い浮かぶだろう。しかし、この記事を読んでいる人のほとんどが想像する「プログラミングができない人」はそこまでプログラミングができないわけではないと思う。
悲しいかな、大学生のプログラミングの授業レベルではプログラミングの概念を理解していない人がそこそこいる。例えるなら、算数の問題で繰り上がり繰り下がりが理解できないとかのレベルではなく、数字と演算子の違いを理解していないとかそんな次元になる。
とまあ、ここまでこんなことを書いたわけだが、この記事に書いてあることが理解できればもう一人でプログラミングができるようになっているので安心して欲しい。何を言っているのか分からない人は理解できるようになれば良いだけの話なので頑張ろう。

おしながき

間違いを認めよう
エラー文を読もう
作りたいものを分割しよう
引き出しを増やそう
コメントを書こう
ちゃんと名前を付けよう
デバッグをしよう
分からなかったら人に聞こう
コピペの寄せ集めはやめよう
公式ドキュメントを読もう

間違いを認めよう

プログラミングは思った通りに動かないし、どんなに気持ち悪い書き方でも書いた通りに動く。書いた人がどう動かしたいと思っているかなんて関係ない。
コンピュータは機械であってエスパーではないし、プログラミング言語は自然言語ではない。動くものと動かないものが明確に定義されており、コンピュータが歩み寄ってくれはせず、我々が歩み寄るしかない。
そして、プログラミングができない人は思った通りに動かないとそこでパソコンを睨みつけるかパソコンを閉じてしまう。エラー文が出ても出ていなくても思った通りに動いていないならそれはプログラムを書いた人が間違っている。
まず自分が間違っていることを認め、どこが間違っているのか、なんで間違っているのかを考えられるようになろう。これすらできない人が多すぎる。

エラー文を読もう

プログラミングができる人は必ずエラー文を読む。エラー文を読まないのにプログラミングができる人は存在しない。もしそんな人がいたらそいつは今この記事を読んでいるあなたよりもプログラミングができないのにそう思い込んでいるだけの悲しい奴だ。
プログラミングが出来ない人はよく「なんかエラー出たんですけど」と言う。エラーが出たことは認識しているのにエラー文を読もうとしない。

Error: variable 'a' is undefined [line:23]

これは架空のエラー文だが、多くのプログラミング言語のエラー文はこんな感じになる。変数aが未定義です、ただそれだけだ。ご丁寧に[line:23]とエラーが23行目にあることまで教えてくれている。多くのエラー文は英語だが、共通テストに比べるとはるかに易しいだろう。というか、分からなかったら調べてくれ。
この文を読んで23行目を見に行くのと、パソコンを睨みつけるのと、どっちが解決するのか早いかなんて考えるまでもないだろう。エラー文を読んでも意味が分からないならまずはGoogleかChatGPTに聞こう。

作りたいものを分割しよう

プログラミングというのは小さな部品を組み合わせて大きな機械を作るようなものだ。例えば「与えられた2つの整数の和を出力するプログラム」を書こうとすると、

2つの変数を用意する
入力を受け取る
2つの変数の和を求める
和を出力する

のように分けてそれぞれの機能を実装することになる。この記事を読んでいる人には何を今さらという感じだろうが、プログラミングが出来ない人は「なんかごちゃごちゃしたやつ」を書くと「与えられた2つの整数の和を出力するプログラム」になると思っている。
これは極端な例だが、分割したあとの小さな機能それぞれは実装できるのに、分割という概念を持っていないが故にプログラミングができないと思い込んでしまっている人は存在する。どう分割すればいいのか分からなければ、他人が書いたコードを見てみるのも良いだろう。

引き出しを増やそう

さて、上で述べたようにプログラミングというのは部品を組み合わせて作る機械のようなものな訳だが、当然その部品の種類が豊富であればあるほど様々な機械を作ることができる。
例えばPythonでアルファベットの順番に対応した数字を出力するプログラムを書きたい場合、プログラミング初心者ならこう書く。

a = input()
if a == 'A':
    print(1)
if a == 'B':
    print(2)
......
if a == 'Z':
    print(26)

しかし、文字列が文字の配列ということと.index()で配列の引数を取得できることを知っていればこのように書ける。

alphabet = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
a = input()
print(alphabet.index(a) + 1)

プログラミングは本当に最低限の知識さえあれば理論上は何でも実装できる。しかし、さらに知識があれば綺麗に、そしてなにより楽にコードが書ける。どんな言語でどんなものを作るにしても、引き出しは多いに越したことはない。
気が向いた時に程度でかまわないので、上手くいったコードのもっと綺麗な書き方を探してみるのも良いだろう。~~筆者はPythonの標準ライブラリすら使いこなせていないが。~~

コメントを書こう

自分しか読むこともないからといってプログラム中にコメントを一切書かない人は存在する。そう、筆者のことだ。そして一か月くらい経ってそのプログラムを見ると何を書いていたかを全然思い出せない。
授業で書くような高々数十行のプログラムならまだしも、数百行、数千行のプログラムを忘れたからといって一から読み直すのは苦行以外の何物でもない。もしコメントがあればそこを読むだけで良いにも関わらずだ。複数人で開発していればなおのことで、コメントがなければ自分が書いてすらないコードを読まないといけなくなる。
コメントを書くのに必要な時間は一行あたりせいぜい数十秒だ。未来の自分のためにも、一緒に開発しているメンバーのためにも、コメントくらいは書き残しておこう。

ちゃんと名前を付けよう

コメントと同じくらい重要なものとして、変数や関数、ファイルの名前がある。必要な理由はコメントと大体同じだ。
これまた極端な例だが、数百行のプログラムの変数が全部アルファベット一文字だったらそのコードを読みたいと思うか？関数の名前が全部myfuncとかだったら読む気が失せないだろうか？
年齢を表す変数ならageで良いし、配列の合計を求める関数ならsumArrayで良い。その名前を見て何を表しているのかをすぐに理解できるということが一番重要だ。
ファイル名やディレクトリ構造にも言語によってはお作法があったりする。個人開発ならともかく、チームで開発する時くらいはちゃんとチームの規則や言語のお作法に則った名前を付けてあげよう。

デバッグをしよう

プログラミング初心者が詰まる点として、「エラーが出る」以外に「エラーは出ないのに思った通りに動かない」というものがある。そういった時に使われるテクニックがデバッグである。
実際にこんなプログラムを書くことはないだろうが、for文を用いて24を2で4回割るプログラムをCで書くとこのようになる。

#include <stdio.h>

int main() {
    int n = 24;
    for (int i=0; i<4; i++) {
        n /= 2;
    }
    printf("%d\n", n);
}

計算結果は1.5になるはずだが、このプログラムは1を出力する。for文の中に問題文があるのは明らかなので、デバッグをしてみる。デバッグとは以下のプログラムのようにprintf()などを用いてログを出力し、プログラムがどこでどう動いているのかを詳しく見ていくというものになる。

#include <stdio.h>

int main() {
    int n = 24;
    for (int i=0; i<4; i++) {
        n /= 2;
	printf("%d\n", n);
    }
    printf("%d\n", n);
}

このプログラムは最後のprintf()も合わせると12, 6, 3, 1, 1を順に出力する。ここから、3を2で割っているのに計算結果が1になっているということが分かる。そして調べてみると割り算の結果をint型にキャストする時、小数点以下を切り捨てているからということが分かるだろう。このような流れでプログラミングの動作を追い、意図していない動作の原因を特定することをデバッグという。

分からなかったら人に聞こう

プログラミングができない人はよくパソコンを睨みつける。睨みつけてもプログラムは完成しない。自分で調べて考えても分からないなら詳しい人に聞くしかない。
聞いてみたらものすごく単純なことかもしれないし、そもそも知らなくて一人じゃ絶対に考え付かないことかもしれない。そうでなくても、自分で考えたら解決に一時間かかるはずだったものが人に聞いたら五分で解決するかもしれない。是非周りにいる詳しい人を有効活用して欲しい。そして、プログラミングができる人は教えたがりな人が多い。
ただ「なんかエラー出たんですけど」とか聞いてくるのはやめろ。それは有効活用じゃなくて無駄遣いという。思考停止で人に聞く前に自分で考えるということをしないと成長は無い。

コピペの寄せ集めはやめよう

ここまでこの記事を読んでくれたあなたはエラーを自分で解決し、大抵のものは自分で調べながら実装できるようになっているだろう。ここで言いたいのが、適当なブログなどからプログラムをコピーして貼り付けるのをやめて欲しいということだ。
数十行のオウム返しBotレベルの小さいものならともかく、数百行を超えるような自分のプログラムに複数のサイトからコピペしたらどうなるのか、というのを考えて欲しい。別のブログから持ってきたコードは当然書いた人も異なる。そして書いた人が異なれば変数や関数の名前、コメント、インデントなどの規則も異なっていることが多い。そして当然ながら自分で書いた場合と比べてそのコードへの理解も浅くなる。そんなコードを後から見返して読みたいかということを考えて、それでも大丈夫そうなら流用すれば良い。
近頃はChatGPTなどAIがコードを出力してくれることも多く、筆者は開発にもそれらを活用すべきだと考えている。しかし「プログラミング初心者が何も考えずコピペすること」に限って言えば、学びになるかどうかという観点であまりおすすめできない。

公式ドキュメントを読もう

正直、これについてはここまでの9つと比べてかなりハードルが高い。プログラミングは小さな部品を組み合わせて大きな機械を作るようなものだという話は既にしたが、その部品の一覧や使い方が全て載っているのが公式ドキュメントになる。その言語やライブラリなどの開発元が出しているものなので、極論これだけ見ていれば実装に必要なほとんどの知識を得られる。
ではなぜハードルが高いかというと、大抵の場合公式ドキュメントは全て英語だからである。稀に日本語のドキュメントがある場合もあるが、その場合も英語版を読むことを推奨する。なぜかというと、この界隈は情報更新が速い。ものすごいスピードでアップデートが入るし、場合によっては後方互換性を失うような変更が入ることもある。そしてその更新にドキュメントの翻訳が追い付くというのはかなり難しい。有名な言語そのもののドキュメントなどならともかく、一ライブラリなんかのドキュメントは翻訳サイトを使いながらでも英語版を読んだ方が良い。
話がそれてしまったが、公式ドキュメントには公式が出している「正解」が載っている。いつの情報かもわからない個人ブログの間を右往左往するくらいなら、まず公式ドキュメントへ一歩踏み出してみよう。

おわりに

ここまでこの記事を読んでくれたあなたはもうプログラミングができない人ではない。偉そうな口ぶりの記事になってしまって少しいたたまれない気持ちだが、後輩たちが来年の新入生に同じような説明をしてくれるようになってくれることを期待している。
最後に、筆者をこんな偉そうなことが言えるようになるまで鍛えてくれた全ての方々、最後までこの記事を読んでくれた全ての方々に感謝の意を述べるとともに、この文章を締めくくりたいと思う。