伝えようという意思をもってコードを書く。

自分のコードが本当に優れているか、なんて事は誰にもわからないし、多分自分が読みやすいと思っていても、全然相手には通じていない事もあると思う。でも、書いていない事はテレパシーみたいな超能力がない限り伝わらないし、コードを書く以上情報を共有しなくてはいけない人（未来の自分も含めて）が必ずいるはずだから、できる限りそのコードを見る事によって必要な情報が得られるように書かれている方がいい。

もちろん、情報の過多は人によって混乱を招く事もあるし、文章のように読みにくくなったり、読む気をなくさせたりする事もある。でも、何にもないよりは伝わるので明らかに良い。

これは、最初の段階ではプログラミングの能力がどうとかという問題ではなく、単純な意識の問題である。（ルールで縛られて工夫できない場合は仕方がないが...）。本当に伝えたい事が伝わるかどうかというのはともかく「伝えようという意思」があるのかどうかというものは伝わるものである。そして同時に、「伝えようという意志がない」「自分だけにわかればいい」というのも充分に伝わるのだ。技術なんかなくても、コメントでちょっと伝わりにくい場所に言葉を添えるくらいの事はできるはずだからだ。伝える方法はいくらでもある。

一人で作業をする場合はともかく、複数人で作業をする場合「伝えようと言う意志がない」という状態だと、一緒に作業をする人はとても困ってしまう。共有すべきものを共有しようという意志がなく「自分だけがわかっていればいい」というのは、「あなたと一緒には仕事する気はありません」「あなたが困っても私には関係ありません」という意思の表明でもある。

そして、結果的にではあるけど、その意識はプログラミングの技術的な部分にもつながってくると思う。デザインパターンや、MVCパターンのような設計パターンの多くは、多人数で作業をする時にどういうパターンで実装すれば、その実装の意図がきちっと伝わり、そうする事によってより正確なデータの扱い、より安全な運用のあり方を実現できるかという結果を生むためのものだ。

よく、あのフレームワークはMVCだのなんだのいいながら、コントローラーが膨らみすぎるとかモデルが大きくなりすぎるみたいな議論を聞くけれど、目的とする実装の意図がその設計パターンを伝える事によって伝わらないのならば、とてもくだらない議論だ。MVCがああだこうだとか言ってないで、実装のパターンを設計に落とし込むか、その場その場で設計方針を共有すればいい話だと思う。

結局、そういう自分が何を書いてなにをしているかというのが伝える意志がなければデザインパターンも、MVCのような設計パターンも何の意味も持たないと思う。自分が何かを伝えよう努力するようになれば、相手が何を伝えようとしているかの努力も同時にするようになるとおもうので、デザインパターンも次第に理解できるようになってくるような気がする。そして、それがある種の技術になっていくのだと思う。

だからこそ、そのコードが実際に伝わるかどうかという事はともかく、「伝えようという意思をもってコードを書く。」というのを常に意識してコードを書きたいと思う。