- 2015/07/01 19:00 ~ 21:00
- 発表者
- テクノロジックアート 長瀬嘉秀
- マーチンファウラーが友達だと！？
- エンジニアに要求される能力
- 設計技術
- プログラミング技術
- ツール
- デリバリー
- テスト技術
- エンジニアに要求される能力
- アジャイル開発は必須
- 要件を短時間で掴む
- 要件をブレークダウン
- テスト駆動開発
- 短い開発サイクル
- 日本ではスクラムが有名。比較的ゆっくりした開発サイクル。設計書も作るし
- ユーザーとのコミュニケーション
- チーム開発
- 日本は小学生くらいからグループワークをやっているので比較的得意なはず。海外の場合は、個人でやっているのが当たり前だったりするので違いはあると思われる。
- 瞬時に設計（基本設計、詳細設計はない）
- 書かない。または、書くけど手書きでふわっと。
- 一週間で作るのを前提だと、設計書を書いていたら間に合わない
- 頭の中で設計する。このくらいまで能力を高める
- いきなりやると、ぐちゃぐちゃになる。なので、UMLなどを利用した設計を行って、掴んでからコードベースでやると良いのでは
- 設計技術
- 要件定義
- (前回のUMLのハンズオンのときと同じもの)UMLを使って、商品受注システム
- アクティビティ図作って、ユースケース作って。
- ユースケース図を作ると、そのシステムに必要な機能が一目でわかる
- アジャイルの場合、UMLを使うか？ NO. 使う人もいるが、言及はしていない
- アジャイル開発での扱い
- ストーリー（ユーザーストーリー）
- ユースケース、フィーチャーなど
- 瞬時に整理する
- 数時間で多くのストーリーを作成する
- 要件定義に、何ヶ月もかけてはいけない
- 漏れていても良い。あとで追加していけばいいので。
- 開発しながらブレークダウン
- チームメンバ全員が理解する
- WFだと他人の機能知らない場合もあるが、アジャイルの場合はチーム全員で作っていくので、こんなことにはならない
- アジャイル開発
- ストーリー
- 単位はユースケースと同じ。そっちで慣れておくと一発でストーリーを出せるようになる
- カンバン
- ストーリーを管理
- 進捗を管理
- プライオリティ付き(特急、普通など)
- バッファによるプロセスの最適化
- タスクの間隔を詰め過ぎない(ストーリーをタスクに分割)
- 要員の最適化
- タスクの見える化(タスクが詰まっている場所は要員不足)
- シナリオ
- 具体的にその機能が何をしているかをステップとして示す
- 例) 交通費を入力する
- TDDではこのシナリオをベースにテストを作っていく。テストを作ってからコードを書く
- ある程度貯まったらグチャグチャになってくるのでリファクタリングする
- いきなりやるのは難しいので、一度シナリオを書いてからやるとよいのでは。
- シナリオの書き方はネットで転がってるのであとよろ
- Ruby だと RSpecを使ってやる
- 具体的にその機能が何をしているかをステップとして示す
- ストーリー
- 設計とコードの関係
- モデルによる設計(例えばUMLなど)
- コードベースの開発
- いきなりコードの考え
- モデルベースの開発
- モデルすればコードは自動生成だろの考え
- 命に関わるようなしっかりしたものを作る場合はこちらを利用してしっかり設計する
- モデル、アーキテクチャ、フレームワーク
- アーキテクチャとのマッピング
- TDDはPOJO(ドメインロジック)に対して書くことが多い。 逆に言うと,UIのところにやったらえらいことになる
- MVC (MVCC w/ Microsoft)
- アーキテクチャとのマッピング
- アーキテクチャ別、ドメイン別など分割技術
- ドメイン分割
- ドメインとは、機能とか業務とかってこと。
- ドメイン分割
- 要件定義
- プログラミング技術
- 綺麗なコードを書きましょう
- 読みやすい ＝＞ 設計もよくできてる
- アジャイルはみんなで、みんなのコードをいじる。他の人でもわかることが重要
- クラス分割
- リファクタリング
- デザインパターン
- コンポジットパターンとか
- 名前付け
- テストコード
- モック
- 日本ではあまり流行ってない？ヨーロッパでは流行っている
- テスト駆動開発
- テスト書く ＝＞ 動かす(赤) ＝＞ 内容書く ＝＞ 動かす（緑) ＝＞ リファクタリング
- テスティングフレームワークを使う
- ターゲットロジック(内容を書くと＝)
- リファクタリング
- 関数型プログラミング
- 最近流行ってる。欧米で。Scalaとか
- マイクロサービスのサービス一つ一つはimmutableでなくちゃいけない
- 綺麗なコードを書きましょう
- ツール
- デリバリー
- 継続的デリバリー(Continuous Delivery)
- Chef, Puppet
- Jef Hunble (Chefの副社長。もともとはマーティンファウラーの同僚)
- ツール
- 要件整理
- 看板ボード
- TDDができるIDE(Eclipseなど)
- ソースコード管理(Gitなど)
- ビルド管理(Jenkins)
- クラウド環境(Herokuなど)
- クラウド実行環境
- リリースツール(Chefなど)
- テストツール
- 全部自動でやる必要がある。テストがないとだめ。
- 日本では手でテストをやっている。欧米に遅れているところ。
- うまくやるためにはテストを最初から作っておくのが大事。
- 欧米ではQA(Quality Assurance)のメンバーが初期から入ってくる。日本の場合は、あとで集めてなので手作業のテストなどが出てくるのでは。
- テスト技術
- チームビルディングが大事。人事の人とかはよくわかってたりする。開発現場ではないがしろにされがち？
- ペアプログラミング
- 知識の伝搬が目的。半日に一回とかのペースでやる。仕様変更などが伝搬してく。
- スタンドアップミーティング
- 疲れてくるので早く終われる。すわると軽く1時間くらいつかっちゃう。
- ストーリー
- 壁に張り出すことで、見える化。チームで共有される
- 遅れがわかるのでチームで助け合える
- レトロスペクティブ
- 反省会。うまく回せる人を入れるのがポイント
- パナソニックでは、専門の人がいたりする
- ビジネスアナリスト、エンジニア、テストエンジニア(QA)、ユーザ（顧客）
- 分業化は終了
- 各自がすべての技術を持っている必要がある
- 多能工（フルスタックエンジニア）
- 開発技術が多岐にわたるため、かなりの勉強が必要
- 従来の基本設計のように、コードをかけない人が設計するなどはなくなる
- 使えない技術者にならないために