読者です 読者をやめる 読者になる 読者になる

Head Firstソフトウェア開発読了!

何回か取り上げてきたこの本も、ようやく読み終わりました。Head Firstシリーズは初めてだったけど、この本の雰囲気がダメな人はダメだろうな。私はこのライトな感じは結構楽しく読めましたが。

なお、題名はソフトウェア開発とありますが、従来からのウォーターフォール的開発ではなくてアジャイル開発を取り上げています*1

Head Firstソフトウェア開発 ―頭とからだで覚えるソフトウェア開発の基本

Head Firstソフトウェア開発 ―頭とからだで覚えるソフトウェア開発の基本


以下、いつものように気になった箇所を羅列。やっぱりシステム開発の後半フェーズの方が、色々目に付くことが増えているみたいです。

見積りを小さくする
(経験則ではという但し書きがありますが)15日以上のユーザストーリは正確性がかなり低くなるとのこと。15日というと、稼働日を含めると3週間か。タスクは、できれば2週間以内の粒度に収めたいものです。
見積りでは速度を使ってオーバーヘッドを考慮する(速度0.7で始める)
0.7という係数で始めること自体は、根拠も深い意味もないということ。反復(イテレーション)を何度も繰り返すのであれば、この係数も調整できるから問題は少なくなりますよね。逆に一発勝負のウォーターフォールでは、まったく根拠がないこの係数は危なっかしくて使えない><
バージョン管理の実施
一番の肝かも。というのも、今仕事で扱っているSAPのアドオン開発では、うまくバージョン管理が回っていない気がするんですよね。SAPの開発環境自体にバージョン管理システムは備わっているのですが、これが独特のシステムのためにSubversionなどのオープンなノウハウが使えてない。書評の一段落には収まりきらないので、後で書きたいな。
継続的インテグレーションの設定
CruiseControlはよく知りませんが)Hudsonでは、ビルドトリガの設定としてHudsonからのポーリングとバージョン管理側からのプッシュ通知の2種類が使えます。Hudson紹介記事であがっているように、プッシュ方式がよさそうですね。

このように,ソースコード管理システム側から変更をプッシュする方式は設定が環境依存で繁雑ですが,Hudsonの有用性はビルドの結果を如何に素早く報告できるかで大きく変わってきます。可能であればぜひこのような設定をしたいところです。

Hudsonを使ったアジャイルな開発入門:第2回 Hudson事始め|gihyo.jp … 技術評論社
モックオブジェクト
新しいものに取り組んでみた - @ikikko のはてなダイアリーで触ってみた、モックオブジェクト。感想はこの前と一緒。
バグ
(ビジネス上使わざるを得ない)サードパーティーのライブラリがひどいコードだったと判明したときの、開発者間の会話。↓のボブの気持ちが凄い分かる。いや、ローラやマークのような意識付けが実業務でもできるようにならないとなぁ…。

ローラ:だから合併後に彼らは解雇されたのよ。だけど、彼らがしくじったことはあまり重要ではないの。現在は私たちのコードだから……
ボブ:分かってる、でも下手なコードは頭にくる。このコードのせいで僕たちが間抜けだと思われるんだから。
マーク:先に進もうよ?次に何をする?

実行することの優先付け
↑のような状況下でやるべきこと優先付けの一例。まずは、自分たちの開発プロセス*2に問題のソースコードを組み込むということが最優先みたいですね。
    1. バグ追跡ツールに問題用の場所を作成する
    2. ソースコードを標準のsrc, test, docなどのディレクトリに分類する
    3. ビルドスクリプトを記述する
    4. コードをリポジトリに入れる
    5. コードをCI設定に組み入れる
    6. ソフトウェアをどのように使うかをシミュレートするテストを記述する


次なる本は、バグ管理について。特定のバグ管理ソフトについて説明した本はあるものの、バグ管理自体にフォーカスした本はありそで無かったので、ちょっとこれは気になってました。本屋で見て速攻で衝動買い。こんなことしてるから、お金が貯まらないのかもなぁ。ま、お金では買えないものを買ってるということで・・・w

実践バグ管理―プロジェクトを成功に導くための

実践バグ管理―プロジェクトを成功に導くための

*1:ですが、本書中ではほとんど「アジャイル」という言葉は出なかったと思います

*2:バージョン管理・ユニットテストの自動化・継続的インテグレーションなどのプロセスが正常に回っているならば、の話でしょうが。