日: 2010年7月30日

前回の記事でチラリと書いたプログラミングと心についてツラツラと。

プログラミングとは作るのに十分が技術を得た後はただ心との戦いとなる。
もちろん技術や知識が上がればよりよい解決策を見に付け、よりスマートに解決できるのかもしれない。
だがそれは大体のプログラムにおいて二の次に過ぎない。

例えばテスト駆動開発という開発手法が存在する。
これはプログラムをテストするプログラムを書く事によりよりよいプログラムを書こうというものだ。
だがこのテストを書くという作業は精神的に非常に辛く、この開発手法を導入しても満足にテストが書かれていないのは業界内では日常茶飯事であったりする。

他にもコメント、コピペコード、ペアプログラミング、コードレビュー、極端な話をしてしまえばオブジェクト指向や手続き型や関数型言語といった区分けなども含めて様々
それらは実際にコードを書くための方法ではなく、プログラマーによりよいコードを書かせるための手法のようなものは上げていけば限が無いほど存在する。
これら全て完璧に実践できれば完璧だとまでは言わないが、間違いであるとうすうす感じつつもその間違いを続けてしまっているのはほぼ全てのプログラマーに対して言える事だと思う。

もし仮に、これら全ての誘惑に負けず、プログラマーとしてあるべき理想像とでも言うべき物を追求できる人が居たとすれば
その人は、ただ技術力が高いだけのプログラマーとは比べ物にならないほど素晴らしいプログラマーといえるだろう。

武道では最終的には技術力ではなく精神力が物をいう世界だとよく聞く。
そういう意味では、プログラミングも武道のようなものなのかもしれない。

心配性、もしくは臆病というのかもしれない。

たとえば仕事中の仕様策定の時、どれほど見直そうとどれほど議論を交わそうと、常に仕様漏れしている予感に苛まれ
何かあるたびに全仕様のレビューしなおしを提案したくなる、というか実際している。

これはバグの無いプログラムが存在しないのと同じぐらい当然のことで、仕様漏れは実装が終わるまで、いや終わった後ですら0になることは無い。
なので、不安に思うのは当然で、でも0にすることは不可能なのだから、見つかっても対応出来るよう備えておくしかない。
これは何度も注意を受けたし頭では理解しているのだが、それでもつい不安で、理由もなく問題があると騒ぎ立ててしまう事すらある。

どうなればその不安はなくなるのか、それすらも判らないうちから行動を起こしてはいけないことはわかっている。
せめて問題提示する際は、解決すべき点なり、目指すべき点について明確になっていなければいけないこともわかっている。
だが、それらを持たない不安は一体どうしたら良いのだろうか？

仕様に抜けがあることを恐れている、経験則として仕様抜けが0ではないことも断言できる。
だが仕様抜けを見つけだす手段はなく、仕様抜けがない事を証明する手段も無い。
アプリケーションを設計する上でこれらは当然の事だ、当然の事だが無視して進めるほど割り切る事もできない。
一体自分はどうすればいいのだろうか？
皆は一体どうしているのだろうか？

プログラムを書く上で重要なのは、技術や知識よりも心なのかもしれない。

自分は物事を客観的に考えるのが特に苦手だと思っていたが、実は自分が思っているよりよほど酷かったことに気づいた。

とある事情でAPIの設計をし、何度も抜けが無いかを確認した上で他人にレビューをお願いする事があった。
結果、API仕様はまるで使い物にならないことがわかり、ほぼ一から書き直すことになった。

この情報の足りて無い具合は本当に酷く
* NVP(ネームバリューペア)な方式だったにもかかわらず、実際に渡す際の引数名が書かれていない
* 引数の呼び名だけで、説明が一切書かれていない
という、仕様とよべる最低限すらクリアできていない有様。

だがそれよりもひどいのは、散々チェックしたにも関わらず指摘されるまでちらりとも気づかなかった事。
人間ってここまで主観的になれるものなのかと逆に感心してしまったほど。

もちろん他人の文章なら気づいたはず。
けれど、試しにモック的な実装を書いてみるまでしても気づかなかったのだから、自分ひとりでは実装終わっても気づかなかったかもしれない。
(引数名も意味も脳内にはあったので、書かれていないことに気づかなかった)

こりゃ文章書いたり意思疎通が苦手なわけだと納得。
他人のものをレビューする際は細かすぎるぐらいだというのに、なぜ自分相手にもあの細かさが発揮できないのかなぁ。
ある意味、これが一番根本的な意味での短所なのかもしれない。