Readable Code その１ - coma2n’s diary

いいコード書いてますか？
最近読んだ「Readable Code」という本が面白かったので、その感想とためになったことを紹介したいと思います。

この本ではいいコードを読み易いコードと定義付けて、そういったコードを書くためにはどうすればいいかという事を具体的なコード例を交えて解説しています。

コードのインデントや書式などの見た目を整えるといった事から、変数の命名や意味付け、関数の構造化、デザインパターンの導入まで、その内容は多岐に渡ります。今回はその中でも特に使えそうな内容について説明したいと思います。

と、その前に個人的にいいコードの条件として考えているポイントについて説明しておきます。

俺的いいコードの条件

いいコードの条件としては、まずバグが無いというのが理想でしょう。
しかしプログラムは書いた通りに完璧に動作しますが、それを実装する人間は完璧とは程遠い不完全な代物です。バグの無いプログラムを書く事は不可能と言えます。
では、いいコードの条件としてバグが無いというのを挙げるのは非現実なことでしょうか？
確かにそうかもしれません、しかしこう考える事もできます。

バグを無くす事は出来ないがバグが発生した時、原因の発見、修正の迅速化、修正による影響範囲を局所化する事はできる。
間違いは必ず起こることを認めて、それをいかにして迅速に確実に収束させるかを目指す。

これがエンジニアとして目指すべき姿勢だと思いませんか？そのためにできる事ならなんだってする。それが在るべきエンジニア像でしょう。

少し話がそれますが、プログラミングはどこまで行っても結局のところ職人技です。そこにはどうしても属人性が含まれてしまいます。
しかし、チーム・組織で働く以上、属人性はなるべく入り込まない方が不確定要素が減り、色々とコントロールし易くなります。
実際私もフレームワークやドキュメントを作る時は、誰でも使えるように、誰でも理解出来るように注意しています。
これはチーム・企業で働く以上、当たり前の行動規範でしょう。

しかし、いちエンジニア・いちプログラマとして見た場合、こんなことはクソくらえとなります。
属人性が排除されたコードなんてものは、魂のこもらない人形みたいなもの、ようするにクソだということです。
こんなことは公には言えないですが、いち企業人といちエンジニアとで思想や信条を使い分ける必要はあるが、エンジニアとしての魂や誇りといったものは捨てる必要はなく、持ち続けて欲しい、持ち続けたいと思う今日この頃です。

閑話休題

では、ここから本書に書かれている内容に触れていきます。

俺的いいコードの条件

目次