読む。

今日、帰りの電車の中で、眠いながらも少し気づいたこと。

この人物は、どうすれば良いプログラムを書けるか長い間考えて、それを反映して、次のように述べている。「優秀なプログラマになる最良の方法は、自分でプログラムを書き、ベテランの作った素晴らしいプログラムをじっくり読むことだ。･････ 私は、コンピュータ・サイエンス・センターへ行き、ゴミ箱の中からオペレーティング・システムのソースコードを漁ったものだ。」 他人の書いたプログラムを読むことが以下に重要かを十分に理解しているこの人物は、誰もが知っている、あのビル・ゲイツである。

「ソフトウエア開発 55の真実と10のウソ 」 事実 44 保守 より引用。

ソースコードをじっくり読むと言う行為を通じて、人の仕事を理解して、自分の意図をどうすれば伝えられるか。そうしたことを考えることは非常に大切だと思う。追い込まれた状況だけど、生産するソースコードの量と、システムの品質は比例しない。むしろ逆だろう。人の仕事をいかに有効に活用して、少ない仕事量で、仕様を満たすシステムを組むことを考えたほうが実は効率はよい。
ソフトウェア開発では、プロジェクトが火を噴き始めると、プログラマは追い込まれ、耳を閉ざし、ひたすら大量のソースコードを書き始め、書き続けようとする。しかし大抵の場合、もたらされるのは混乱であって秩序ではない。ソースを読むという行為は、一見すると生産的に見えないかもしれない。しかしチームでシステムを組む以上、必要なのはソースコードの量ではなく、相互理解の深さだと思うのだ。 だから、焦りや不安はあったけど、徹夜で作業する羽目になっても、あせらずソースを読んでいくことにしてみた。

理解しづらいコードも、そうでないコードも、区別無くソースコードを読むうちに、苦痛も、感心も、発見も、あまた苦楽を両方含んだ行為を通じて、多分理解でき始めたような気がする。如何にして、自分の仕事の成果を人に伝えれば良いのかということを。読む立場、使う立場という違うはあっても、それは設計ドキュメントでも、フレームワークの API でも、ライブラリパッケージでも同じだと思う。

プロセスやツールやモデル化の技法とか、ソフトウェアを作る上で、効率や品質を実現する為にいろいろな要素が語られているが、案外と「読む」と行為の、質の深さに、何か本質的なものがあるように感じる。錯覚ではないだろう。そういう意味で、ソフトウェア開発作業の本質は保守にあるという指摘は、傾聴に値する意見だと考えられる。保守はまず「読み」、そして「理解する」という行為から始まるからだ。「言語」とは、語る以上に理解する為の手段でもあるはずだ。

明日もまた、徹夜覚悟で、デスマーチまで後一歩な状況かもしれないが、焦らずにソースコードやドキュメントをじっくり読むことにしよう。

・・・・・・・・・・・
時計が回って、変わって行く二人は、恥らう事を恥ずかしがって
夜景の見えるレストランが 昨日の残りご飯に変わってきた毎日

何回も 何回も 繰り返した数を数えてみよう
ここにある普通な物 見失わないように
・・・・・・・・・・・・

何回も 何回も 繰り返した数を数えてみよう
ここにいる 大事な人を 見失わないように
・・・・・・・・・・・

数えてみよう二人の事 どっちの方が多いのか
怒った数はあなたで 泣いた数は私だね
笑った数は それだけは 二人同じ数だね
笑った数は同じだね

今日の BGM 「笑った数」 in vol.best by 奥 華子

ソフトウエア開発 55の真実と10のウソ