プログラミングの学び方(5) – プログラミングの大原則

プログラミングの学び方(5) – プログラミングの大原則

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

プログラミングの大原則

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

シンプルイズベスト

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

ソースコード量が多いほど、バグ(不具合・動作不良)が発生する可能性も高くなる。

大抵のプログラマは、実装量を過小評価してしまいがちだが、プログラミングの際に実装するソースコードの量は、その後のソースコード保守、システム保守にも影響する。

無駄な機能が多いと当然実装量も増えるし、機能結合点が増える。すると、バグの量も比例して増えることになる。

従って、できるだけソースコードは少なく書くのが原則だ。

実装する際は、

それが本当の必要とされている機能なのか?

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

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

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

  • プログラミングはあくまで手段だ。動けばいいんだ。
  • ソースコードをきれいに実装する時間がない

といった、フリーランス特有の悩みがあるのは、私も同業なのでよく理解できる。だが、ここで甘んじてはだめだ。

プログラミングするソースコードは、読みやすければその分修正もしやすくなる

保守をしながら、新しい機能をお客さんに提案するときに実装にかかるコストを抑えられれば、その分お客さんにも喜んでもらえる。

そのためにも、ソースコードは読みやすくするべきだ。

コメントを最適化する

プログラミングする際に意外と軽視しがちなのが、コメントの記載だ。

先にコメントの原理原則をお伝えすると、

コメントは、プログラマがなぜその実装をしたのか?その目的を読み手に伝えること

を意識するべきである。

ところで、一般的なプログラマは、他人が書いたソースコードを保守することを大いに嫌がる。

その最大の理由は、

なぜ、その実装になっているのか?意図がわからない

からだ。

そのため、ソースコードには、適度のコメントが必要になってくる。

多すぎても読むのが大変だし、少なくても実装の意図をくみ取るのが難しい。

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

プログラミング初心者の段階では、どうしても1関数や1クラス当たりのソースコード量が増えてしまう。

なぜそうなるのか?というと、主に以下の理由である。

動作確認するたびに、あれもこれも手当たり次第に処理を追記したり修正したりするから

初心者プログラマは、自分の書いたソースコードが1発で動くケースが少ないため、試行錯誤しながら処理を組み立てていくケースがほとんどだ。

特に納期が短いプロジェクトだと、どうしてもソースコードをリファクタリング(≒再構成)する時間が少ないので、どうしても処理が長くなってしまう。

だが、そうやってできたソースコードが長い処理、つまりロング関数ロングクラスこそ、プログラマ最大の敵だ。

なぜか?というと、主に2つの理由がある。

  • ソースコードの読みやすさ(可読性)が著しく低下する。
  • 1つの関数やクラスに数多くの処理が実装されていると、修正を加えた際に他の機能への影響(バグの発生、想定外の挙動の変更)が発生しやすい。

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

原則として、

  • 1タスク=1関数(orクラス)
  • 1つの機能を1つの関数やクラスでまとめて処理しないこと。

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

プログラミングの流れ

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

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

まず最初に、機能要求に対しては動くようにすることだ。つまり、求められている動きが一通りできるように実装する。

システム開発のプロジェクトでは、ソースレビュー(コードレビュー)といった、第三者によるソースチェックが行われることが一般的だ。

その際に、実際に動作しないプログラムをレビューすると、チェックする側される側を含め、大幅な時間ロスを生んでしまう。

最低でも、まず動くソースコードを書くようにしよう。

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

動くようになったら、次はソースコードの再構成(リファクタリング)を行う。

先ほどのプログラミングの大原則に従って、読みにくいところや処理が複雑なところを、別の関数やクラスで切り出したり、変数名に統一性を持たせたりする。

このリファクタリングは、ある一定の原則があるので、後日詳細を解説する。

STEP3. 再度動作確認する。

STEP2が終わったら、再度動作確認をする。

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

最後に

ここまでプログラミングの大原則を中心に解説した。

ここでお伝えした原理原則を元に、自分の書いたソースコードを再度見直してみよう。きっと数々の気づきがあるはずだ。

ところで、今回ではお伝えしきれなかった、

  • 読みやすいソースコードの書き方
  • コメントの書き方のコツ
  • 関数のリファクタリング

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