12
2011

最近読んだプログラミング本

CATEGORY
最近っていっても3月~5月ぐらいだけど感想。以下読んだ順(リンクはAmazonだけどNot AA)。

アジャイルな見積りと計画づくり 価値あるソフトウェアを育てる概念と技法

見積もりが苦手なので読んでみた。評判どおり非常に良い本だと思う。
小難しい理論だとかそういうものではなく、また見積もりが難しい・変化がある、といった実情を踏まえたうえで話が進められている。

  • チームメンバー全員で必要なストーリー(個別のタスクに分ける前の、こなさなければ成らない課題的な単位)を抽出していく。
    抽出した各ストーリーが別のストーリーの何倍ぐらいか?といった相対的な規模(ストーリーポイント)で見積もる。
  • 期間(理想日)では実際には割り込みや人によってこなせる量に差があるため、規模と期間は分けて見積もらなければならない。
  • 期間はチームが1イテレーションにどの程度のストーリーポイントをこなせるかから計算する。
    ある程度正確な期間はそのチームで数イテレーションをこなすまで判らない。
  • アジャイルな開発を成功させるためには、規模か期間を動的に調整する必要がある。
    1イテレーションでこなせるストーリー数が見えてきたら、期間を優先させるのであれば、ストーリー数を増減させる。ストーリーが欠かせないなら期間を調整する。
というような内容が書かれている。読んでいて、確かにその通りだと思えるものばかりだった。
そういった内容であるため、見積もり方法というかどちらかというと開発体制全体の話でもある。
まともなアジャイル開発の経験がなかったので、あぁアジャイル開発とはこういう風に進めていくのか、という観点からも非常に参考になった。

ただ、実際にこれをどう役立てていこうか考えると、ちょっと考えることは多い(汗
自社開発とかならともかく、業務系のシステム開発とかだと、要件も期間も決まっててお客さんも協力してくれなかったり、どうにもならないことが多そうなイメージが・・・orz
海外だとそんなことはないのかなぁ?
要素要素は間違いなく役に立つ本だと思う。

Clean Code アジャイルソフトウェア達人の技

綺麗なコードを書く為の本。クラスの上手な分け方とか学びたくて買ったけど、もうちょい入門書的な内容というか、ちと方向性が違った。
メソッドは細かく分けろとか、コメントは書くならこうしろと出来るなら書かなくてもわかるプログラムにしろとか、実際にリファクタリングしてソースを綺麗にしていく過程とか、そういう感じの本。
ある程度経験のある人なら知ってることも多いだろうけど、そういうのを整理した感じ。

全体的には良い内容。そういうところで迷ってる人は読んで見たらとても参考になると思う。
ただ、注意点として、本の中にも「ただし、我々が絶対的に「正しい」と勘違いしないように注意してください」とか「賛否両論のものがいくつもあります」とあるように、個人的には?って思うようなところが何箇所かあったりする。

特に自分が一番思ったところはコメント周り。
メソッドを細かく分け、各メソッド名を見ただけで意味がわかるようにすべき。そうすれば余計なコメントも要らない。
みたいなのとか。英語圏の人はそうだろうけど、日本語圏でやるのは無理がある。
鵜呑みにせず、一つ一つ意味やメリットを理解しつつ読むといいかな。

ダイアグラム別UML徹底活用 第2版

UMLの本。UMLの文法だけでなく、この図にはこういう内容を書く、よく間違えるこういう点に注意、みたいな書き方がされていて、非常に分かりやすい。
以前に別のUMLのリファレンス的な本を読んだのだけれど、書き方はわかっても書くべき内容がわからず、仕事上でユースケースにこれがあるのはおかしい!みたいに指摘を受けたりしてたので、この本の内容はベストマッチだった。
入門書的な本として良書だと思う。

ゲームのアルゴリズム 改訂版 思考ルーチンと物理シミュレーション

表題の通りの本。思考ルーチンとかに興味があったので。
これも入門書的な本だと思うけど、移動先ごとに有利度を算出して~とか、へーそうやってるんだ的な話が丁寧に書かれていた。
これ読んで試しに作ってみてそこからまた先を考える的な本。何かに役立てたい。


以上、こんな感じ。次は各所で評判の『体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践』辺りを読むつもり。
とはいえ、積んであったコンピュータ関係の本はだいぶ消化したので、しばらくはお腹いっぱい(´ー`)
スポンサーサイト

Tag: 書籍

0 Comments

Leave a comment