日本語版でいいと思うが英語版がセールだったので英語版を買った。 コードコンストラクションについてこれほど良く書かれている本も無いよなぁ、とは思うけれど、ハンドブックであるがゆえにフォーマル寄りに偏っている傾向はあると思う。
初版を何度も読み直したコードコンプリートだが、さすがに手元に残っていない（何回か買った記憶があるが…）。 二版は無職の頃二回くらい図書館で読んだが、手元に無かった。
その後セールの時にKindleの英語版を買ってたまに参照している。
カクヨムでできの悪いテンプレを大量に読んだ結果、これは不毛すぎるのではないか、という気分になり、代わりにCode Completeを読む事にする。 今回は目的は別段無いので、一日一章ずつ読んでいこうかな、と思っている。
ソフトウェアコンストラクションとはなんぞや（コーディングとかデバッグとかその辺の奴のこと）、それ以外にはどんなものがあるのか（要求分析とか保守とか）、なんでソフトウェアコンストラクションが重要と思うか（他のプロセスは省略されるがコンストラクションは必ず実行される、プロジェクトに占める割合が多い）といった話がされている。
現代的な視点だとフォーマルなやり方があってインフォーマルなプロジェクトがある、 という見方はちょっと偏りを感じる部分もある。 例えば一発当てるのが目的のサービス開発みたいなので、 何をやるのかと開発はそんなに分かれた話では無いし、それはインフォーマルというのともまた違ったもののように思う。
ただフォーマルな手法をハンドブックとしてまとめる事には多くのプロジェクトにとって意義があるとは思うが。
コードコンプリートを読んでいて、最初はぴんと来ない事もだいたいはあとでその重要性を理解し、使いこなせるようになった時にその良く書かれた内容に感動する、 という事を繰り返していたが、いまだにその体験が無いのがこの2章のメタファーの話。
ソフトウェア開発というのを理解するのにメタファーは重要で、いろんなメタファーを紹介して、建築のメタファーと工具箱のメタファーが良いという話をしていて、そのソフトウェア開発との対比からいろいろな示唆を引き出している。 また、メタファーはアルゴリズム的では無くヒューリスティック的だ、という話もしている。
Further Readingには、以下の２つが上げられていた。
前者を読んでみようかな。bookwalkerには無かった。
とりあえずBoss-Readiness Testまで読んだ。続きは明日かな。
今読むとやはりプロジェクトの形態が決めたものを作るという前提がある気がする。 何かのソフトウェアを10年くらい作り続ける、みたいな形態にそぐわない気がするんだが、その辺はどうなのかなぁ。
何を作るのを決めてからcodingをする、みたいな話は、 何を作るのかを決めるためにcodingを使う道を閉ざしてしまっている気がする。 何を作るべきか、コードを書いていると分かる事も結構あるからなぁ。
ただ誤ったものを上手く作っても仕方がないのは間違いない。 そして正しいものを作るべきでもある。 ただどうやったら正しいものを知る事が出来るかは良くわからないよなぁ。 客がいて要望を聞く、みたいなのは、toCではあんまりいい手段では無いよな。
フェーズを分けて調査するのではなく、もっと日常的にその問題について調査をしたり考えたり調べたりしているべきだよな。 なんかリリースしたものの反応とかを見てちょとずつ自分の中に何かが溜まっていって、それでどうすべき、 みたいなのが決まっていくのがtoC的だと思う。
昨今の開発は、終わらないでずっと続くものも多い。サービス開発とかはずっと続いていく。
どうもその現状に対し、3章の話は建築に引きずられていてあまり適切になっていない気がしたので、より適切なメタファーを考えてみる。
もっと組織を作るのに近いと思うんだよな。軍隊とか行政組織とか村とか学校とか円満な家庭とか。 良い学校を作る、というのは、何かをやって終わり、というものじゃない。 学校の中で何か問題が起きたらそれを改善していくような仕組みとか、 そうしたものを自動的になおしていくような文化を育むとか、 そういう事がソフトウェア開発と近い気がする。
何かおかしな機能を作ってしまっているとか、ユーザーの熱が逃げていっているとか、 なんかそういう間違ったシグナルみたいなのを捉えては道を修正していくような、不断のアクティビティが現代的なソフトウェア開発の主流…というと言い過ぎかもしれないがそれなりの範囲を占めるようになったものであり、自分が最近やっている仕事でもある。
上手く行ってない時というのは、何かおかしな事を実装したりしていながら、やっている人たちはそれがおかしいと思っていない、とか、 そういう状態になったりする。 そういうのが現代的な失敗で、それは要求が間違っているというのは表面的で、なんか開発組織の歪みのようなものが本質のように思う。 そういうのは、コーディングの前のフェーズで分析して解決出来る類の事では無いんじゃないか。 もっと開発組織を直さないといけない気がする。
ソフトウェア開発は、ゴールが無い、営みのようなものがメタファーとしては良いよな。
特定の客のために作る想定よりも、toC的な、もっと対象が良くわからないもやもやした何かに対してつくる前提で考え直した方が、自分の現状には合う気がする。 そうしないとtoCでもユーザーアンケートだとか市場調査だとかで特定の客につくるのと同じようなものになるかのような、 間違った印象を持ちやすくなる気がする。
市場というのは、もっと化学の実験みたいな感じで、試験管の中の良くわからないものにいろいろと混ぜたり熱したりして反応を見て、 そこから中を理解していくような何かだと思う。 そしてこの反応を見ていく何かというのがソフトウェアの変更とかだと思うんだよな。 どういう変更をしてどういう反応があるかをあらかじめ知るというのは本末転倒で、 変更の反応を見て理解を深めていく必要がある。
その時にどういう変更をすべきか？というのは、要求を分析する、というのとはちょっと違うと思うんだよな。 どういう反応を期待するか、どういう事を調べたいのか、 その負の影響はどのくらいに抑えたいのか、 というような事は注意深く決めたい気もするが、 そうはいっても試してみないと結局わからないのだから限界もあるし、 プランニングよりいろいろ試して知識を蓄積していく方がいい場合もある。
競合があって勝者がすべてを取り敗者は何も得られない、というような開発では、スポーツや戦争などの争いごとの方が近いかもしれない。 スポーツはルールがあってやれる事が決まっているという点で、ソフトウェア開発的では無い気がする。 戦争の方が近いようにも思う。
ただ戦争は戦争の事を良く知らないのでメタファーとしてどうなんだ？という気もする。ソフトウェア開発の方がむしろ良く知っているからなぁ。
勝つ事が目的であって決めたものを作るのが目的でない事は良くあると思う。 建築とかのメタファーではそういう重要なケースが漏れてしまっていると思う。