前回は、プログラミングの学び方（４）で、処理フローから実際のプログラミングを行う際のコツについてお伝えした。
今回は、実際にプログラムを書く際に、知っておいたほうがよいポイントと原則論についてお伝えする。

プログラミングの大原則

まず最初に、プログラミングの大原則を整理してみよう。Java、C#、PHP、Ruby、Python等、様々なプログラミング言語があるが、共通の原則が必ず存在する。その中でも重要な原則をいくつかお伝えする。

シンプルイズベスト

プログラミングの基本は、非常に単純だ。

大抵のプログラマは、実装量を過小評価してしまいがちだが、プログラミングの際に実装するソースコードの量は、その後のソースコード保守、システム保守にも影響する。
無駄な機能が多いと当然実装量も増えるし、機能結合点が増える。すると、バグの量も比例して増えることになる。
従って、できるだけソースコードは少なく書くのが原則だ。
実装する際は、

を自問自答しながらすすめるとよいだろう。

読みやすいコードを書くように努力する

次に、フリーランスで陥りがちなのが、ソースコードの可読性の欠落だ。

といった、フリーランス特有の悩みがあるのは、私も同業なのでよく理解できる。だが、ここで甘んじてはだめだ。
プログラミングするソースコードは、読みやすければその分修正もしやすくなる。
保守をしながら、新しい機能をお客さんに提案するときに実装にかかるコストを抑えられれば、その分お客さんにも喜んでもらえる。
そのためにも、ソースコードは読みやすくするべきだ。

コメントを最適化する

プログラミングする際に意外と軽視しがちなのが、コメントの記載だ。
先にコメントの原理原則をお伝えすると、

を意識するべきである。
ところで、一般的なプログラマは、他人が書いたソースコードを保守することを大いに嫌がる。
その最大の理由は、

からだ。
そのため、ソースコードには、適度のコメントが必要になってくる。
多すぎても読むのが大変だし、少なくても実装の意図をくみ取るのが難しい。

一度に一つのことをまとめて処理させない

プログラミング初心者の段階では、どうしても１関数や1クラス当たりのソースコード量が増えてしまう。
なぜそうなるのか？というと、主に以下の理由である。

初心者プログラマは、自分の書いたソースコードが1発で動くケースが少ないため、試行錯誤しながら処理を組み立てていくケースがほとんどだ。
特に納期が短いプロジェクトだと、どうしてもソースコードをリファクタリング（≒再構成）する時間が少ないので、どうしても処理が長くなってしまう。
だが、そうやってできたソースコードが長い処理、つまりロング関数やロングクラスこそ、プログラマ最大の敵だ。
なぜか？というと、主に２つの理由がある。

私も、ロング関数やロングクラスを数多く生み出してきた経験があるからわかるが、ロング関数やロングクラスを実装後に読み直してみると長すぎて、しばしば処理を正しく理解できないこともある。
原則として、

といった、シンプルさを心がけるべきだ。

プログラミングの流れ

プログラミングを行う際は、主に２つのステップを踏むとよいだろう。

STEP1. まずは、動くようにする

まず最初に、機能要求に対しては動くようにすることだ。つまり、求められている動きが一通りできるように実装する。
システム開発のプロジェクトでは、ソースレビュー（コードレビュー）といった、第三者によるソースチェックが行われることが一般的だ。
その際に、実際に動作しないプログラムをレビューすると、チェックする側される側を含め、大幅な時間ロスを生んでしまう。
最低でも、まず動くソースコードを書くようにしよう。

STEP2. プログラミングの原則に従って、ソースコードをきれいにする

動くようになったら、次はソースコードの再構成（リファクタリング）を行う。
先ほどのプログラミングの大原則に従って、読みにくいところや処理が複雑なところを、別の関数やクラスで切り出したり、変数名に統一性を持たせたりする。
このリファクタリングは、ある一定の原則があるので、後日詳細を解説する。

STEP3. 再度動作確認する。

STEP2が終わったら、再度動作確認をする。
特に、修正したところは必ずと言っていいほどバグがあるので、修正した個所を中心に再度動作確認をする。

最後に

ここまでプログラミングの大原則を中心に解説した。
ここでお伝えした原理原則を元に、自分の書いたソースコードを再度見直してみよう。きっと数々の気づきがあるはずだ。
ところで、今回ではお伝えしきれなかった、

の細かい部分については、この連載シリーズで引き続きお伝えする。