はじめに
読みやすいコードを書きたい人と願う方のために執筆しました。
誰もが良いコードを書きたいと願っているはずだからです。（と私は信じています）
というもの、後で自分が読み直した時、誰かにレビューを依頼する時、逆に自分がコードレビューを依頼されたときなど、読み難いコードはそれだけでイライラするし、仕様を読み解くのに時間がかかって頭を抱えることになるからです。
そういう経験はありませんか？
私の経験
私にはこんな経験がありました。
私は設計書を渡されて、実装を行なっていました。
設計書に目を通しロジックを確認すると、2次元配列としていたデータは3次元配列で保持する必要があることに気づきました。
発注元にも確認し、3次元配列であることは明確になりました。
ただこれはどう考えてもArrayIndexOutBoundsExceptionを引き起こす可能性（嫌な臭い）がしました。
私は独自のオブジェクトを定義することを提案し、完全コンストラクタでオブジェクトを生成するように変更しました。
保持するデータは変えず、保持する方針のみを変更したのです。
結果、データを扱うことがとても簡単になりました。
もし3次元配列にしていたら、デバッグも出力処理の実装ももっと大変になっていたに違いないと、今でも思っています。
読み難いコードを書く人
そのプロジェクトでは、発注元が他の会社にも発注していました。
つまり、私の会社を含めて複数の会社で設計書を分担して実装していたのです。
結合試験工程で、私の会社は他の会社の結合試験を一部引き受けることになりました。
他の会社の進捗が遅く、少しでもいいから対応してほしいということでした。
バグが出てきてコードを追いかけると、とんでもないものを目にしました。
・ロジックの重複
・配列の嵐
・if文の中に長文の判定文（2行以上もありました）
これらは以下のちょっとしたテクニックで対処できるものばかりでした。
・privateメソッドにロジックを移して流用できるようにする。
・配列はオブジェクトにして入出力とデータ保持を簡潔にする。
・判定ロジックをメソッドに移し、メソッド名で判定内容を明示する。
おそらく他の会社の実装が遅延したのは、これらのほんのちょっとした手間を惜しんだことによるものだと思います。
私の会社では私を筆頭に、ほんのわずかな工夫を所々に取り入れることでロジックが肥大化しすぎないようにし、ロジックを簡潔に保つように意識していました。
もちろんそのおかげで実装に多少の時間はかかったものの、バグの発生は適度に抑えられ、バグ修正に思った以上の時間を費やすということはありませんでした。
私の会社とその会社の違いは、「ほんのわずかな読みやすさ、修正のしやすさにこだわったか？」だけでした。
ここを妥協する人が読み難いコードを書いてしまうのです。
読みやすいコードを書けるようになるには？
あなたはどちらでしょうか？
・与えられた設計書通りに実装することだけを考えて、コードの読みやすさや、修正のしやすさは後回しにするのか？
・多少時間がかかっても、小さくてわかり易いロジックを丁寧に実装していき、バグの発生を抑えつつ、修正をしやすいようにするのか？
……
聞くまでもの無く、誰もが後者を選ぶはずです。
でも、それをどうやって身に着けるのか？
それを学ぶためにリーダブルコードがあります。
全てのをノウハウがすぐにできるようになるわけではありませんが、日々の仕事の中で少しずつ実践していくことで身についていきます。
今のコードの現状を変えたい（自分自身やチームのために）のであれば、リーダブルコードを手に取ってみて下さい。
最後までお読み頂き、ありがとうございました！
ご意見・ご要望がありましたら、遠慮なくコメント下さい！
もし内容が良かったらランキング評価を頂けると励みになります（＾＾）
⇒ランキング評価する
