2008年3月の読書 つづき
人月の神話―狼人間を撃つ銀の弾はない (Professional computing series (別巻3))
- 作者: Jr.,フレデリック・P.ブルックス,Frederick Phillips,Jr. Brooks,滝沢徹,富沢昇,牧野祐子
- 出版社/メーカー: ピアソンエデュケーション
- 発売日: 2002/11
- メディア: 単行本
- 購入: 8人 クリック: 167回
- この商品を含むブログ (175件) を見る
新しいキーワードとしては「セカンドシステム症候群」がありました。新しいシステムを作るにあたり、既存システムの機能を意味無く捨てられない。よくある話ですが、概念として上手くまとまっています。
また「ガレージプログラム」をプログラミングシステムにする労力が「システム統合インターフェイス」、「文書化、テスト等」を考慮すると9倍に達するという話は個人的に共感できるものの、近年のWebサービスにはあまり当てはまらない気がする。システムに対するイメージが異なるために、テストと文書化のコストを削っても平気なんでしょうね。全てがそうだとは思いませんが。
アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣
- 作者: Venkat Subramaniam,Andy Hunt,木下史彦,角谷信太郎
- 出版社/メーカー: オーム社
- 発売日: 2007/12/22
- メディア: 単行本（ソフトカバー）
- 購入: 35人 クリック: 995回
- この商品を含むブログ (291件) を見る
掲げてある原則が練れていることもさながら、それとあわせて記述してある個人の経験や「バランスが肝心」として記述されている注意事項が分かりやすい。例によって備忘としていくつかあげます。
- 「コードが汚い！きれいにするんだ」という原則に対して、「経営陣や事業家に納得する理由を示すこと。コードがすっきりするから、では理由にならない」という注意事項が書いてある。
うーん、まったくそのとおり。最近同じような主張を聞いたなぁ。 - 「設計とは指針であって指図ではない」。「最初に詳細に要件定義を行い、続いて詳細な設計を行い、それから実装、統合をすませてから、最後に、(天に祈りつつ)テストする」というのはウォーターフォールの誤解された姿。
そうだった。局面は戻らないといっている分けじゃない。全てのステークホルダーの合意を得て、そこを基点とするだけなんだ。アジャイルな開発と局面開発は対比するものでは無く、補完するものもしくは発見させるものなんだな。 - 「Planに価値は無く、planningが肝心なのだ」設計する事で得られた知見こそが重要なのだ。
最近これは実感しています。問題は得られた知見を以下に次の工程につなげるかです。知見をドキュメント化しないことで失われる事は少なくない。それでは設計していないのと一緒だ。 - 継続的インテグレーションツールを活用しよう。コードのチェックアウト、ビルド、テストをバックグラウンドで定期的に実行する
いい気がするのだけど、やったこと無いから良く分からない。一度試してみたいな。 - インクリメンタルに開発するんだ。NASAですら、スペースシャトルの複雑なソフトウェアをイテレーティブかつインクリメンタルに開発したんだ。*3
インクリメンタル開発を嫌がる人への反証として抑えておきたい。でも無条件では使えないはずだから、リンク先は読まないと。でも、英語か。 - コードよりも先にテストを書く。いわゆるテスト駆動開発(TDD:Test Driven Development)。テストを先に書くことで、実装者としての視点ではなく、利用者としての視点コードに接する事になる。
この具体例が書いてある。テスト駆動開発とかテストファーストって言われた時に、コードをとりあえず書いてテストする意味だと想像したのは私だけですか? - パスカルの言葉、「長い手紙をお許し下さい、短くする時間が取れなかったのです」
- ブタとニワトリ。レストランで朝食にベーコンエッグを出すとすれば、ニワトリは卵を産むだけでいいが、ブタの方は命がけだ。チームメンバー=ブタとマネージャ=ニワトリは明確に区別すべき。
いいネーミングだけど、実際に使ったら揉め事が起きるかな。 - スタンドアップミーティングをしなさい。長さは10から15分くらい。一人は2分程度。
興味はあるんだけど、使う機会が無い。次にチームを作ったときは必ずやろう。 - PowerPointでコードは書けない。アーキテクトとは設計と指導はその本分であるはずなのに、肩書きに値しない人が多い事。小ぎれいな図を描いたりパターンをやたらと使うのはアーキテクトじゃない。
パワーポイントで書かないなんて当たり前じゃん、と思ったら自分を指していた。ガツンときました。そうだplanningで得られた知見は必ず次の工程につなげなきゃいけないんだ。 - ペアプログラミングは効果的なメンタリングを自然に行える環境である。
ペアプロの価値が少し分かりました。ペアプロで稟議を通す自信は無いけど。 - コードをレビューする。
レビューするのは当たり前。でもどうやって？その効果はどれくらいあるのか？が理解できた。 - アジャイルへ踏み出す。一気に導入してはいけない。胸の痛みを訴える患者に、「さっさとベッドから出てランニングマシンで一汗かけ」とは言わないよね。
そうですね。でも自分の仕事に少しずつ取り入れたいと思います。
けっこう気づきが得られましたね。いい本でした。
