トム・デマルコほか「アドレナリンジャンキー」 その4

付箋はったところが多すぎて、なかなかまとめられませんが、相変わらず少しずつ気になったことをば。

クライアントは、実物を見るまで、そして「これは違う」と思うまで自分が何をほしいのかわからない。 (p.80)

まあ、そんなものだと思います。新しいことするなら、なおさら。いろいろ考察しますが、結局、そこまで想像力を働かせることはできないし、その間にモックを作るほうが生産的な場合だってあると思います。後戻りがむずかしい建築なんかも、外観モデル（なんていうのか知りませんが）を作ったり、モデルルームがあったりするわけです。


なのでモックを作る、サンプルを作る、というような作業のスピードを上げ、コストを下げるような工夫が必要なんでしょうねぇ。ソフトウェアの場合はコードがあることは、ほとんど機能が揃っている≒開発がおわっているってことなので。

チームが適切に処理できないほどの仕事を受けることは、マネジャーとして卑怯な行為である。個人的な批判を避けるために、チームが成功できない状況をつくっているのだ。マネジャーに最初にノーと言う勇気がなかったために、チームは無理な仕事を強いられたうえ、組織内で評価を落とす。(p.114)

これは非常に耳が痛い。痛すぎて、冷静に考察ができない。

この [インタフェースの欠陥が少なくとも2つのコンポーネントに影響する] パターンを知っているチームは、早い段階でインタフェースに取り組む。すべてのコンポーネントのコードをコミットする前に、インタフェースを使うコードのスレッドを構築する。早くから各人のコードを統合し、頻繁にテストする。 (p.43)

ダミーでもなんでもいいから、インタフェースは定義しないとだなぁ。ウェブは結合度が弱いんだから、これをやるのはさらにやりやすいはず。


というわけで、まだ半分くらいしかメモができてません。いや、半分おわったのだ。

「Webアプリケーションテスト手法」

「Web アプリケーションテスト手法」なる本を読みました。内容は広く浅く、あんまりテストの経験がない人がテストを始めるとっかかりになりそうです。RoR とか、フレームワークを限定しているので、即物的/具体的なことが書かれています。


Selenium をちょこっと使うことがあったので、読みました。

使いわけとして、たとえば、正しいページに遷移したことを assert で確認し、ページの内容は verifyで確認する、といったことができます。こうすると、ページ遷移が間違っていたら、続けても無駄なのでその場でテスト中断し、ページのの内容は部分的に間違っていても最後まで確認することができます。(p.238)

XP のユニットテストでは100%か0%だけど、どうなんだろ。と思いましたが、acceptance test では、そういうわけではないからいいか。

・要素のロケータは、idが一番テストしやすいので、ページを作るときに適宜id要素を指定しましょう。動作上必要ないところでも、idが入っているとテストが便利になります。

 ・開発とテストを一人てでやっているなら、テストを書きながら必要に応じてidをページのほうに追加していってもいいでしょう。 (p.241)

class での指定は、たしかにやりにくいですね。テストしやすい HTML にする、というのも重要かと思いました。HTML をいじれないときは困るんですけどね。

「ソフトウェアアーキテクトが知るべき97のこと」

「プログラマが知るべき〜」が流行っているようですが、そのシリーズで以前に出ていた「ソフトウェアアーキテクトが知るべき97のこと」のほうを読みました。テーマは多岐に渡るのですが、3つほどピックアップ。

問題解決

ユーザが必要だという機能や特徴に、実は何を求めているのかをたずねれば、アーキテクトは本当の問題を考えることができますし、おそらくクライアントがいう解決策よりも安くてより良い方法を考え出せるでしょう。本当に大切なものに力点を置けば、優先順位もシンプルになります。 （p.12 アイナー・ランドル）

普通の人は、実際に手にするまで自分がほしいものが何かわからないものです。 （p.71 デーブ・クイック）

結局、もっとも安くで済むのは、複数のソリューションを試してみる方法なのです。 （p.59 エリック・ドーネンバーグ）

問題とは何か、その解決策は何がよいか、というのは、ワインバーグの「ライトついてますか？」の主要なテーマで、ときどき読み返しています。

誰かの立場から見た問題と解決策は、単純なロジックツリーで表されるほど単純な関係ではありません。解決策の知識がある場合とない場合とでは、問題自体の捉え方が異なるので、実物を見たときにコレジャナイって場合も当然あります。だからこそ、モックや、頻繁なリリースが有効なのでしょう。少しずつ最適解に近づけていけばよいわけです。

パフォーマンス

なぜ、パフォーマンステストがそんなに大切なのでしょうか。最大の理由は、どのような変更を加えたときにパフォーマンスが急降下したかがわかるということです。（p.26 レベッカ・パーソンズ）

この発想はありませんでした。言われてみれば当たり前の話です。

普段かかわる仕事において、パフォーマンスの細かい測定にはあまり価値を見出していません。でも、10倍とか、1/10 とかは気になります。開発の初期から、パフォーマンスを測定していればよさげです。

トレードオフ

「十分よい」というのはどこのことなのでしょうか？ それは、不備が残っていても、システムの機能、メンテナンス性、パフォーマンスにこれといった影響を与えないことです。 （ p.140 グレッグ・ナイバーグ）

[...] いかに魅力的に感じたとしても、すでにわかっている要件やユーザーが希望している特性以上に大規模なシステムを設計するのは避けましょう。 （p.194 ビル・デオーラ）

ここで言う不備は、アルゴリズムが最速ではないとか、余計な処理が残っているとか、そういう話です。その前提で、不備はイコール不十分ということではない、ということです。その時点での、最小セットであればよい、と。どうせ変更はあるし、あらゆる変更に対処することはできません。

一方で、こういう話も。

設計の判断として2つの選択肢のどちらを選んでもよさそうな感じがするときには、アーキテクトは1歩下がって考えなければなりません。選択肢AとBのどちらを選ぶかではなく、A、Bのどちらを選んでも、それほど重大な意味を持たないようにするために、どう設計するかを考えるのです。 （p.48 ケブリン・ヘニー）

どっちにしょう？　って思ったら、その決定にロバストな解決策を考えてみるということです。もちらん、常にそんなアプローチがとれるわけじゃないですけどね。基本的な姿勢として、です。

というわけで、いろんな人のプラクティスや考え方に触れられて、役に立ちそうな本でした。