『プログラミングの心理学』をコツコツと読み進める試み その2
gistでやるほがいいかと思いつつ、昨日の続き（読書メモ）。
『第2章 よいプログラムとは』についての読書メモ
よいプログラムとは何か？定量的に評価できるか？
時代背景まで含めて相対的に比較するのが関の山という結論かな。
『仕様』
プログラムが動かないなら、実行効率とか適応力とか開発費用とかいった尺度には何の意味もないのだ。
お説ごもっとも。御託はいいから動くものを作れというのはなんというかLinux的。
つまり、たった一人の利用者のために書かれたプログラムと「ソフトウェア」は、違ったものなのだ。
ステークホルダーが増えると、曖昧さが増すと言いたいのか？
他人に使ってもらおうと思うと、いろいろと付帯作業が発生すると言いたいのか。
『スケジュール』
プログラミングにおいて絶えず生ずる問題の一つは、スケジュールが間に合うかどうかである。遅れてできたプログラムは、しばしば無価値である。
機会損失という発想自体好きではないけど、タイミング次第なのは同意。 時代の先を行きすぎるのもまずかったりするのではないか。
最低限のことをいってもわれわれは、より効率のよいプログラムなら生み出したであろう潜在的節約額と、そのプログラムが手に入らなかったために 生じたコストの間の損得勘定をすることが必要である。
「生じたコスト」がプラスなのかマイナスなのかは一概に言えないと思う。
『適応力』
一度使われただけで捨てられてしまうプログラムがあることは確かだ。 一度も使わないうちに捨ててしまった方がいいプログラムが、それよりもっとたくさんあることも確かだ。 だが、作られたプログラムの大多数は、特にプロのプログラマが書いたプログラムは、ある一定期間生き延びるものだ。 そしてその大部分は、存続期間中に手なおしを受ける。（pp.54-55）
出荷するよりしない方がいいというケースがままあるというのは同意。「手なおし」というのはリファクタリング未満の改造か？
なぜプログラマは、プログラムの変更が不可避であることを十分知りながら、変更に関する考慮をすることなしにプログラムを書くのだろうか。
やっつけ仕事だから？締め切り圧力の前になりふり構っていられないとか。単に怠惰であるとか。職業意識が低いとか。あるいはまともな教育を受けていないとか。
デスマーチに心身を蝕まれているから？
「仕事なんてやっちゃおれん」という心境になったことはあるので。
プログラマにもいくつかタイプがあって、ズボラ系と几帳面系、そしてその中間がいるのではと考えたくなることもしばしば。 メンテナンス性と可読性のために「即値はいかん。定数にしろ。」というのは、まあ几帳面なプログラマは大好きですね。
関連する問題の一つに、ドキュメンテーションがあることはいうまでもない。 実際、プログラムの変更を容易にするためでないとしたら、われわれは一体なぜドキュメンテーションするのだろう。 プログラムやそれを書いたプログラマに点をつけるとしたら、計画的にそうしたか自然にそうなってしまったものかにはかかわらず、ドキュメンテーションの品質が高いかどうか、そして変更が容易であるかどうかが、大きな非常を占めることに異論はあるまい。
ドキュメントを書く目的についたは、一つではないと言いたい。ドキュメントの質はどちらかというと、利用者を獲得できるかにとって重要なのでは。
著名なプログラマの方々のほとんどは文章の執筆能力が高いように思うが、いわゆる「作文」の上手いことを期待されるのもどうか。
『効率』
要約すると、特定のハードウェアに特化したプログラムは移植性を失う。メモリ消費量か、CPU時間か。あるいは開発コストか運用コストか。 トレードオフの話。
『まとめ』
プログラムがよいプログラムであるためには何が必要か。
- 仕様を満たしているか。どの程度仕様を満たしているか。
- 開発スケジュール（開発期間？）
- 修正の容易さ（修正のためのコストも含む）
- （何を基準にするか、何を犠牲にするかはともかく）効率
『設問』
引用はしませんが、プログラムの評価基準とプログラマの評価基準についての設問。プログラムの出来の良し悪しと締め切り。
前任者を呪ったことは一度や二度ではないですが、締め切りの圧力に膝を屈して、ひどいコードにひどいコードを書き足したことがあるのも事実。
『第2章 「よいプログラムとは」へのコメント』
だが、お金を儲けることがプログラムを書く目的であるのなら、書いたプログラムがもっとも多くのお金を稼いだプログラマこそ、どう考えても最良のプログラマ、といわざるを得ない。要求仕様をもっともよく実現した以上、そういうことになる。
「プログラムを書く目的」というのは普段あまり意識していなかった。なんとなく「顧客の課題を解決する」という綺麗事に振り回せれていることが多いように思われる。というか、人月商売かそうでないかに限らず、「お金儲け」でしたね。そうですね。
今なお多くの管理者はすべてを求めたがり、最良の製品を得るために懸命なトレードオフを見出すことの重要性を理解していないように見える。
この管理者というのはプロジェクトマネージャーか。それにしてもトレードオフというのは難しい。 「上手な妥協」といってもいいのかも。そういう意味では、Appleはすごい会社だと思っている。
この章もなかなか考えさせられる文章の宝庫。ソフトウェアの品質についてはいろいろと書きたいことがあるけど、今日はここまで。また明日。
