忘れられがちなプログラマの真のしごと

誇大な感じのタイトルになってしまっている気がするけど気にしないでおこう。。。

大学で趣味でプログラミングを行い、自由気ままに好きなようにコードを書いていた頃とは違い、仕事でコードを書くようになって感じていたことの1つを書いてみます。

プログラマの仕事は単にマシン上で動く、仕様に定められた動作をするコードを書くことなのか

もちろん、必要なマシン上で動くコードでなければ意味が無いのは確かではあるけれど、それ以外にも重要なことはあると思います。これは単にそのコードを実行した時に仕様とは違う動きをするだとか、コードを書く以外にも要求の本質を理解するための仕事を行うだとか、そういうことを言いたいわけでもなかったりします。

何が言いたいかというと「そのコードは他の誰かとコミュニケーションできるか」ということです。

基本的に、誰かの書いたコードは他の誰かの書いたコードとコミュニケーションします (最近読んでいるオブジェクトデザインという本ではコラボレートする、という単語が出てきましたが、それに似ています)。そのとき、コードは書いたプログラマ以外のプログラマともコミュニケーションを取ります。 そこで作りこまれ、放置された設計の悪臭*1をもつコードは、コミュニケーション能力に欠けている、と言えると思います。

それはコードとコードのコミュニケーションにおいても重要な意味を持つように感じます。コードを書くのは結局のところ (今のところ、仕様から自動的にコードを書いてくれるような素晴らしいプログラムは基本的にないので) プログラマです。あるコードを書いたプログラマが意図したことを、別のプログラマが読み取れなければ、別のプログラマはそのコードを書いたプログラマの意図しない形で使ったり、変更を加えたりする可能性があるからです。(そもそも書いた本人が、明確な意図を持って書かれたか怪しい時もあるでしょうが…)

プログラマは本質的に何をすべきか

大抵の場合、問題を解決する際にプログラマはコードを書くことが多いと思います。そのときプログラマとして、その問題に関わる他のプログラマとコミュニケーションを取ること、そしてコミュニケーションが取れるようにすることを目標にすべきではないかと感じています。

書いているコードが不必要に複雑になっていないか、不要なお約束のもとに成り立つように作られていないか*2を今一度考えてコードを書くべきだと思っています。

「動けば良い」ではなく、「他の人にも理解しやすいコードを書く」ことがプログラマすべてにとっての目標となるべきではないかと思っています。*3

そしてコードだけでなく、プログラマ同士がコミュニケーションすることを重視しなければならないと感じています (これはアジャイルソフトウェア開発宣言に通じるものがありますね)。

*1:『設計の悪臭』を知らない人はぜひアジャイルソフトウェア開発の奥義を読もう

*2:こういった点に対しては、Design by Contract (契約による設計) と言った設計・実装における考え方があります。

*3:もちろん、プログラミングに対しての必要な知識がない故にコードが理解できない人にも理解できるように書け、と言っているのではないです。

広告を非表示にする