コーディングの品質について
はじめに
これは僕が品質の高いコードを書くために意識していることをまとめたものです。
プログラムを書くための原則はいろいろあると思います。(SOLID, KISS, DRY, Rob Pike's 5 Rules, etc.)
そういった先人達の知恵から影響を受けながら少ない経験を元に自分の言葉で書いてみたいと思います。
品質の高いコードって
品質の高いコードってどういう物でしょうか？
僕は下記のような利点をもたらしてくれるものが品質の高いコードだと思っています。
- 再利用しやすい
- 読みやすい
- 変更しやすい
- バグが発生しにくい
品質の高いコードのためにできること
品質の高いコードを書くために下記のようなことに意識してます。
- プログラムを透明にする
- 使う人のことを意識する
- 仕様書として読みやすいようにする
プログラムを透明にする
プログラムに対する「透明」という表現はClean Codeで使われていて気に入ったので自分の中のキーワードになっています。
透明性が高いプログラムとはパッとみてそれが何をしているのかすぐにわかるようなコードの集まりです。 小さくて簡潔で一つのことだけを行うプログラムであれば透明性が高いプログラムであると言えると思います。
透明なコードの良さ
前述のように透明なプログラムは小さなプログラムとほとんど同義ですが、その利点は下記のようなものです。
- 見通しが良く、理解が簡単
- バグが目立つ
1 は割と自明かなと思います。
2 については実践しているとわかりますが、透明なコードにはバグが入り込む余地が少なくなります。
注意して見るべき場所が少ないためおかしなところが目立ちやすくなるのです。
逆に複雑で複数のことを同時に行うようなプログラムではバグが隠れやすくなってしまいます。
それを読んでいるときに意識が複数の箇所に分散してしまうからです。
馬鹿みたいに簡単にする
そのプログラムの仕様について最も詳しいのはそれを実装している人です。
ただその人も実装し終わればその仕様について忘れ始めます。
プログラムについてわかっているつもりでも後から見るとよくわからなくなることはよくあることだと思います。
それが他人が書いたものであれば尚更です。
だからこそ実装しているときは可能な限り簡単に見えるようにコードを書くべきだと思います。
アルゴリズムではなくデータ構造に労力をかける
複雑な処理をするために複雑なアルゴリズムを使うことはなるべく避けるべきだと思います。
これまでも書いているように複雑な実装はバグを生みやすく管理もしにくいです。
複雑なことをしたいときはそれに特化したデータ構造を定義することに努力します。
それが成功すればアルゴリズムはシンプルなものにできる可能性が高いです。
小さいプログラムを書くには頭を使う
大きくて複雑なプログラムを書くのは小さくて単純なコードを書くのに比べて簡単です。
大きなメソッドを書くときは頭を使う必要がありません。
そこから小さくメソッドを切り出していくのには設計が必要になります。
設計をするには頭を使います。
プログラムが動く・動かないのような具体的な基準ではなく抽象的な思考が求められるからです。
易きに流れるのが人間だと思うので放っておけば（急いでいる時とかは特に）大きなプログラムを書きがちになってしまうと思います。
使う人のことを意識する
これは再利用しやすいプログラムを作成するために必要な心構えだと思います。
インターフェイスをシンプルに
インターフェイスは可能な限りシンプルであるべきです。
例えばメソッドの引数です。2つよりは1つの方が良いし、1つよりも0の方が良いです。
引数を少なくするためにはそのメソッドが配置されるクラスのプロパティを正しく設計する必要があります。
また、引数の要素はメソッド名から容易に想像できるまたは納得できるものでなければいけません。
これらの理由は簡単でその方が使うのが簡単だからです。
使う人がいかに簡単にそれを使えるようにするかを考えると良いと思います。
あるべき場所にあるようにする
これも理由は簡単でその方が使いやすいからです。
整理された道具箱に道具を置いておくようなイメージです。
然るべきクラスに然るべきメソッドが置いてあれば他の人が探しやすく、再利用されやすくなります。
仕様書として読みやすいようにする
コードは仕様を最も詳細なレベルで記述したものでもあります。
これはつまりは可読性の高いコードを書くということです。
ビジネスロジックとデータの扱うレイヤーが行き来する流れを意識するべきだと思います。
そこにはグラデーションがあるので抽象のレベルを統一してそのレイヤーにマッチするメソッド名をつけるのが良いと思います。
名前を簡潔に
わかりにくいよりは長い方が良いがわかりやすさを保持できるなら短い方が良いです。 また、例えばメソッド名を考えるときはメソッド内でやっていることのみを考慮して考えるべきです。それがどんな文脈で必要とされるかはわからないからです。
高品質なコードを目指すことの落とし穴
上記のようないろいろを意識してプログラミングを行うわけですが、ここにも落とし穴があるように思っています。
それは最初から綺麗なコードを意識しすぎるあまりコーディングやその設計に時間をかけ過ぎてしまうということです。
良いコーディングは良い設計とある程度同じだと思います。
闇雲に品質の高いコードを目指すと簡単な機能や改修でさえ繰り返し手戻りが発生して終わりが一向に進捗しないような状態になってしまうことがあります。
こういった現象を避けるために下記のような工夫ができると思います。
- 大枠から考える
- テストコードを書く
目指したい在り方
やはり理想として目指したいのは早く綺麗なコードを生産できるプログラマです。
僕の場合はまだまだその域には到達できていません。
そのためには訓練が必要なのではないかと思います。
訓練をつめば良いコードの作り方や対象をパターンで捉えられるようになるのではないかと思います。そういったパターンマッチングの能力を訓練できればより早くより正確にただしいコーディングの在り方へ到達できるようになるはずと思ってその域を目指したいなと思います。
終わりに
この記事に書いたことは本で学んだ考え方が多いので紹介します。 また、こちらも本の紹介となっています。
