DevLove名古屋「オブジェクト設計とリーン開発、その実践」
参加しました。
DevLoveとはなにか 市谷さん
- 開発の楽しさを発見しよう。ひろげよう
- 開発の現場を前進させよう
- 現場のハブ
第一部 オブジェクト設計エクササイズ [13:10〜14:00] 増田亨氏
- 抽象的なことを言っても現場は変わらない。実践的なことを話したい
- 正しいものを正しく作る
- 正しいとは
- 絶対的・静的なものではない
- 設計とは、
- 変更コストを下げるために
- コードを整理整頓する工夫
- 実践的：動きながらバランスを取る
- 変更コストの要因
- 最大の敵は重複したコード
- 重複の臭いの判定基準
- クラス100行
- メソッド5行
- 引数1個
- 基準を越えたら一息入れて設計の見直し
- コード整理の基本パターン
- Value Object
- 振る舞いを持った区分
- ファーストクラスコレクション
- ドメインモデルに業務ロジックを集める
- ドメインモデル設計のコツ
- 画面や機能単位で設計しない
- なぜ変更が簡単か？
- コードが業務の関心事単位になっており、変更は業務の変更から起こるから
- すごいあたりまえに聞こえるが、盲点だった
- ドメイン駆動設計ちゃんと読もう
第二部 リーン開発の現場 [14:10〜15:00] 市谷聡啓氏
- システム開発は揉める
- 正しさを求めているので揉める
- 正しさとは
- 関係者同士で探索するもの
- 期待マネジメント
- チーム、プロジェクト、プロダクト、ビジネス、組織のレイヤーモデル
- レイヤーの壁と期待
- 時間とともに変化する期待
- 期待もリスクもあるべきもの
- 暴走しないようにマネジメントし続ける
- インセプションデッキ
- 思っていることを可視化して共有する
- 不確実性コーンの左側で仮説検証、右側で最短距離で正しく作る
- Planフェーズでは：
- Doフェーズでは：
- 反復の目的を思い出す
- 仮説検証ならば、意思決定
- 最短距離ならば、???
- カンバンの使用
- 反復の目的を思い出す
- ソフトウェア開発は難しい
- 誰が、誰と、誰のために、どのような制約下で、開発するのか
- 正しいものを正しくつくろう
- リーン開発の現場P109：理想とはたどり着くべき場所のことではなく、ありたい姿に向かいつづけることなんだ
- 道具立てはある
- よりよくあろうとし続ける
第三部 Q&A
- レガシーなコード
- オブジェクト指向じゃない
- 設計の方針を共有するにはどうしたらいいのか
- 既存コードの設計は変えられない
- ウォーターフォールでもアジャイルでもない
- ドメイン駆動設計を身につけるには
- 4年かかった
- 今は現場で実践した報告があるので参考にするといい
- DDDにゴールはない。ドメインを追求し続けること。その態度が身につけばOK
- コード自動生成と重複のないコードの衝突
- ある程度仕方がない
- チームでどう折り合いをつけるか
- クラスを小さく作るとクラス数が爆発しないか
- やってみて感覚的に理解しよう
- 自然だから、それほど大変には感じない
- 新人には大変だが、業務が分かってくればスッと分かる
- 丸投げにどう対応するか
- 丸投げといっても期待がある
- 期待感を明確にして整理して優先度をつけて応える
- バッファを顧客に見せるか・どう見積りに入れているか
- そもそもドメインとはなにか
- サービスとかビジネスの領域
- どの範囲なのか合意しよう
- ドメイン用語でカタカナを使わない
- インフラチームから開発に移るために学ぶべきことは
- 今インフラはSoftwareDefinedなので、そのあたりから。どうだろうか
- チームが持っている設計の価値をメンバーが共有するには
- 経験を共通言語として共有する
- 人のコードで苦労させられたという被害者意識だけでは難しいので気をつけよう
- 顧客の期待をまとめていく方法
- インセプションデッキ!
- 設計の考え方を共有するには
- 正しい設計にこだわりすぎるとうまくいかない気がする
- 共有する意識が重要では
- カンバンをみんなで使うには
- 導入のパターンがあるよ
- クラス100行、メソッド5行、引数1個はキビシイ
- 発想を転換して、体感してみよう
