『プログラミングの心理学』をコツコツと読み進める試み その13
第13章はプログラミングの周辺ツールについて。
『第13章 その他の道具』
だが現実には「小さい誤り」などというものはない。というのは、「たった一つのハイフン」すら大損害に結びつくからである。 プログラミングという仕事の性質がそういう物である以上、誤りの「大きさ」とその結果生じる問題の間には何の関係もない。 だからプログラムのテストにおける目標何かと問われても、「誤りを根絶すること」という以外には答えようがない。 そしてそれは不可能事なのだ。
至極まっとうな話。ただ最後の不可能事ってのを理解してくれない人が多すぎる。
プログラムのテストにおいて信頼感を得るためには、その時点までになされたテストによって、プログラムのどれだけの部分が実際にテストされたかを知りたいと思う、というのは自然なことである。
今でいうところのカバレッジ測定ツール。この本が執筆された1970年代初頭から考えられていたのか。
一様性や簡潔性を測ることはそれよりもう少し難しいかもしれないが、コーディングを始める以前に一定の仕事に対してプログラムの長さはどの程度が妥当か、見当をつけることができれば、簡潔性を値踏みする助けになるだろう。
ダウト。「一定の仕事に対して」というのは上手くいかない。それができるなら既存のプログラムをわずかに改修するだけで事足りるはず。
未だに存在しないプログラムを書くからお金になるはずで、それは人類にとってではないにしても、未踏の部分、つまり不確定要素を含むはず。 仕様書が何ページだからプログラムがどのくらいの行数になるはずだ、という見積もりがデスマーチの元。
この発想は危険すぎてどういできない。
簡単な例として、同じプログラムの中で、N1、N2、N3、N4、N5といった似たような名前が使われている、という場合を考えてみよう。 そうした名前は、まずもって誤りを犯してくれといっているようなものだ、ということをわれわれは知っている。 というのは、そのどれか一つを他の一つと書き違ったり読み違ったりすことは、たやすいことだからである。
まともな話。記述が冗長であるとか、見るからにダサいという場合は、そこが不具合の温床である兆候と見なせるだろうが、それは主観の判断。
ただ何処かの会社でこういう変数の名前つけ方をしている、という噂を聞いたことがある。勘弁してほしい。
プログラムのテストについていえば、自分のプログラムについて早期に「成功」を収めたプログラマはとにかくテストをあまりに早くやめてしまうものだ。 この過ちから身を守るための一つの方法は、テスト問題をテストをはじめる前に、いやそれどころかもし可能ならばコーディングをはじめるまえに作っておく、というものだ。
こんなに昔からテスト駆動開発の源流とでもいうべき発想があったってこと？
某社でも理想的な開発工程では仕様策定完了段階でテスト項目を作成することになっていたんだよね。理想的な場合には。
まあ実際はお察し下さいなんだけど。
テスト自動化システムにも言及されているのは意外。
自動的虫取りシステムの場合には、プログラマが同じ場所を一定時間以上見ていたときは、彼の注意を強制手にプログラムの別の局面に向けさせるという方法があろう。 次にどこを見せるかについては、ありとあらゆるアルゴリズムが考案できようが、もっとも大切なことは彼を突っかかっている場所から引き離すことなのだ。 実は単にしばらく端末をオフにし、彼に樹木や芝生やミニスカートや、そのほか何にせよプログラムの見当違いの場所ではない何かを眺めるチャンスを与えるというのは一つの良いやり方である。（p.379、強調は引用者）
どうみてもセクハラですよ、ワインバーグ先生。樹木や芝生とミニスカートを同列に扱うとは恐れ入る。というかこの場合、女性の大腿部では？
気分転換の有効性は否定しませんが、プログラマに女性が少ないとは言っても、この表現はいかがなものかと。
『オベレーティングシステム』
OSの一部として性能評価ツールを提供することの重要性を論じている。また、パンチカードの時代の逸話があれこれ紹介されているが、省略。
現代で言うところのシェルスクリプトの必要性についても言及しているところは興味深い。
『TSSとバッチ』
まあこれも昔話。当時の時代背景を知るという意味では貴重なのか。
『ドキュメンテーション』
ドキュメンテーション（解説文書）はプログラミングにおけるヒマシ油である。管理者たちはそれがプログラマのためになる、と思っている。 そしてプログラマはそれを忌み嫌っている。
下剤ってことなのか、それとも民間療法ってことなのか。迷信の類と言いたいのかな？
だがドキュメンテーションは、それが優れたものでない限り現実の価値を持たないのだ。ダメなドキュメンテーションは、ドキュメンテーションがないよりもっとまずい。
まあ不正確なドキュメント資料が極めて迷惑なのは認める。それでもアリバイ工作の手段としては有用ではないかな。
どんなドキュメンテーションにも決してできないことがある。 早い話、あるプログラムについて知るべきことのすべてを、訓練を受けたことのない人に二十五語以内でわからせることなどできるわけがない。
まったく仰せの通りです。何か要約しろと言われて困った経験でもあるのだろうか。
最良のドキュメンテーションを伴っていてさえ、いつかはそのプログラムを捨てて、もう一度作りなおしたほうが得、という時がやってくる。
ドキュメント云々はともかく、ソフトウェアには寿命があるというのは同意。ハードウェアの進化であるとか、環境の変化によって基本設計自体が時代遅れになる時がある。ただそれを、中間管理職が理解していないケースが多いのではないか。
少なくとも某社の執行役員は理解していたけれど、事業部長クラスには伝わっていなかったように思う。まして課長クラスは完全に逃げ腰だった。 闇雲に作りなすのは論外だけど、5年なら5年、10年なら10年の間、拡張が可能な基本設計、アーキテクチャを考えないといけない。
誰でも、どんな経歴の持ち主であっても、どんな訓練を受けてこようとも、きちんとしたプログラミングの仕事ができる、などということはないことがわかってきた。プログラマたちはそのことを知っている。 だが、だとしたらなぜ彼らは、街で手当たりしだにひっ捕まえてきた人物にドキュメンテーションができると信じるのか。
プログラミングが誰にでも「ちゃんと」できる仕事ではない、とプログラマが主張するように、「ドキュメント作成」も誰にでもできるわけではない、と主張している、のであろう。
ドキュメント作成を軽視するプログラマへの痛烈な一撃、といったところか。個人的には同じことはプログラムのテストにも言えると思う。 ドキュメント作成ととテスト作業（動作確認）は花形の仕事とされることはない、という点で共通している。
どちらも設計やコーディングに比べると下等な仕事とされ、私のいたSIerではプログラマに向いていないとか、大きな納期遅延を引き起こした担当者がアサインされることが多かった。そういう場面を見てきた人間からすると、不思議な納得感がある。
『まとめ』
この章でいおうとしたのは単純なことである。それは「システムは複雑だ」ということにほかならない。
ハードウェアとソフトウェア、そしてそれを取り巻く人間達と文化も含めてシステムだ、と言いたいらしい。 人間心理を左右するのはハードウェアだけではないし、ソフトウェアだけでもない。様々な人々が関係すると、それぞれに相互作用が生じてくる、と言いたいのだろう。
『第13章 「その他の道具」へのコメント』
近年、様々な開発補助ツールが登場しているにもかかわらず、それが浸透していないことへの著者の嘆き節。
（前略）今日残る大問題は、エゴ丸出しプログラミングという問題、および専業のプログラムテスト要員が置かれている社会的地位という問題である。 明らかにこれらの問題への回答は、テストの道具の改善によっては得られない。管理の側における改善が必要である。
エゴ丸出しプログラミングというのはちょっとよくわからないが、インターネットによるコミュニケーションの大きな変化がこの問題をクリアしているように思う。テスト要員の地位についても、MicrosoftやGoogleにおいては改善しているのではないだろうか。
統合が進むにつれてどんな行動が起こってきそうか予見することはできそうもないが、いまわれわれプログラミング作業の本質的部分と思っているものが、将来は本質的でない記帳作業と見なされるようになるだろう、というところまでは予想できる。 なぜそんな予測ができるのか。 プログラミングの発展しは、本質的部分と思われていたものが非本質的部分に変換されることの繰り返しだった、ということを思えば、である。
これは確かにその通り。アドレス管理、プログラムのメモリへの配置。近年の例だとメモリ管理かな。プログラミング言語とOS、ツールの進化で抽象的な概念に集中できるようになってきている。
さらに言えば、仮想化技術の普及によって、ハードウェアを意識しなくなり、さらにはサーバー管理さえツールにより自動化されようとしている。 泥臭い下位レイヤからプログラマのみならずエンジニアのほとんどが遠ざけられている。
ほんの一握りのスーパーエリートプログラマ（or エンジニア）と、それ以外の二極化が進行しているのだろう。
だがコンテントが一番大切、ということは変わっていない。そして真にコンテントを向上させるような道具はほとんどない。
それはその通り。DTPの普及で見た目はきらびやかになっても、中身の文章の価値は変わらない。
あとはエピローグだけ。
続きます。
