デブサミ2010
ただただ、自分向けのメモ。
三周遅れのXP
- つたわりにくいこと(TDDとUnitTestは違う)
- 網羅的にテストを書いてしまう
- ×テストが肥大化する。コストが高い
- ○不安をテスト
- カバレッジが...品質が...テスト計画が
- 違う
- 導入
- ペアプロでいきなりテストを書いた
- TDD写経会をやった
- 個人で導入してみる。
- ペアプロで重要なこと
- コードの共有
- 人の書いたコードを直しても問題ない
- コードはチームのもの
- ★コードの指摘は人格批判では無い。教育みたいなもの
- 新人は学んだことはブログに書く(コードをさらすことに慣れる)
- CI
- テストを自動化してくれる(Hudson)
- 1日に1回は少ない。5分に1回に変更
- ★SLOW TEST問題
- テストが遅いのでテストをしなくなる
- ローカルでテストを走らす時はH2DBでテストをしている
- UPDATE/INSERTしないものはDBの入れ替えをしていない
- 本来はモックを使うべきかも。カイエンを使ってたのでH2DBを使った
- CIサーバではOracleを使っている。テストに3時間くらいかかる。
- 計画と見積もり
- ★アジャイルな見積もりと計画づくり(書籍)
- ユーザーストーリに分割
- プランニング効果
- 5SP(ストーリーポイント)。ポーカー。みんなで見積もり
- 2週間で1イテが調子がいい
- 自分のチームが1週間で何ポイント使えるかわかる
- 理想時間
- 誰が何をやっているかを付箋で管理
- 見えるか
- Tracと付箋の2重化を使っている
- バーンダウンを使っている(タスクの消化率を)突発で発生する作業を追加している
- 正直に書く
- ユーザーストリーではなく、機能ベースになっている
- ★「プラクティスを採用するのが困難なら、その障害にアジャイルに対応する!」
- DRY(Dont repeat yourself)
- ★「大きなものは把握できるよう小さく分ける(五輪書)」
- 感想
- やはりXPは楽しいから好き
- 来て良かったと思えるセッションだった
- 自社サービスゆえに飛び込み作業は少ない気がする。SIの保守では差し込み作業が多くスプリントのタスク量を維持するのが困難な場合がある。
- 企業内システムをクラウドサービスで再構築する
- SIer的な話
- 世の中のシステム全てがクラウドになるわけではない
- 簡単に接続したい
- クラウドインテグレーション
- 問題:プロトコルギャップ,接続数が多い,1対1とは限らない
- 開発時の盲点
- デプロイ先が多い
- デプロイが多い
- とりあえずつながる
- エレガントにつなげる
出張 DDD難民救済キャンプ 〜ドメイン駆動設計をあきらめない〜
- 会場アンケート。読んだ人3割。読み切った人1人
- 海外ではDDDが人気。2009年飛躍的にMLの投稿数が増えている
- The Bookエッセンス
- 推進派
- 冷静派
- 明日から始めるDDD
- 敷居は高い
- アジャイルが必要
- 1.オブジェクトの広場の記事を読む
- パターンの説明が中心
- 2.InfoQ Domain-Driven Design Quickly日本語版
- 3.ドメイン駆動。実装(C#,NHibernate)。
- The Bookの翻訳してほしいなぁ
- DAOからRepositoryにリネームする(冗談)
- 実装者向け
- 冗談だけど名前が表す。
- Daoはデータアクセス
- Repositoryはエンティティの集合をとる
- ハンズオンモデラー
- 実装者兼モデラー
- DaoからRepositoryへ
- SourceforgeにDDDのサンプルあり(DDDSampleで検索)
- 設計者向け
- マネージャ向け
- チームを編成するか、アサインするか
- 業務のまとまりでチームを作る。
- ストラジティックデザイン。The Bookの3分の1
- 大規模なプロジェクトでは優秀な人をFW基盤チームに入れるが、DDDはアプリケーションエンジニアに注視している。基盤が充実してきたのなら、アプリケーションに注目する
- 終わりに
- 感想
- 複雑なシステム開発ではDDDは必要になってくるだろう
- ブレイクスルーとなるべき100%完璧なシステムを目指すという思想は好きだ
- 基盤チームは花形なことが多いけどアプリチームを最重要するべきかも
★はなるほどと思ったこと。