ddd × 新人教育
TRANSCRIPT
DDD × 新人が学んでみたレシピ共有
DDDを新人になんとなくでもわかってもらうためにやってきたこと
アジェンダ
1. アイスブレイク + 自己紹介2.弊社新人教育の黒歴史3.では今年からどう教育をしたの?4.まとめ
教育の結果は 2年目がプレゼンしてくれます!
0.アイスブレイク
0.アイスブレイク新人教育とは、
新人に教養を与えることです。
0.アイスブレイク
つまり
0.アイスブレイク新人教育とは、
新人に今日、用を与えることです。
だじゃれかよっ!
0.アイスブレイクいえいえ、コレが今回の目的教育担当者は、忙しく新人を放置してしまうことが多いその中で、今回の勉強会の内容が一つの「用」になって貰えるそういうご提案になれば、幸いです。
1.自己紹介
名前:原田侑亮(まぐろ(鮪)みたいな字の人で覚えてください)
仕事: コード書く。たまに、ビジネスやる。教育する。 あとは、 DDDとかをおもしろ可笑しくやってます。
2. 弊社新人教育の黒歴史
結局、教えれてないじゃん
2. 弊社新人教育の黒歴史
2012年
サービスを企画して、作れ! コードレビューはもちろんない。
…⇒強い人材は育った。けれども
2. 弊社新人教育の黒歴史
・ 2013年 新人教育: PHPをやって OJT プロジェクト:
PHPでソーシャルゲーム開発受託Railsで自社サービス
TDDやら、チケット駆動はまだ曖昧
コード研修はいれたけ
ど、
…
現実との乖離が
2. 弊社新人教育の黒歴史
・ 2014年 新人教育: PHPをやって OJT プロジェクト:
PHPでソーシャルゲーム開発受託Railsで自社サービス
TDDやら、チケット駆動はまだ曖昧
スライドもコピペで作れる
から楽ちん~これではだめだーーー!!!
いかん!革命じゃー!3.では今年からどう教育をしたの?
3.では今年からどう教育したの?
ゴール設定(今回の施策一部抽出版)● ScalaでWeb開発ができる
o PlayFrameworkで簡単なWeb開発ができるo Scalaで開発できる
● DDDを理解できるo DDDのワードが分かるo DDDでユビキタス言語が定義できるo ドメイン層の実装ができる
3.では今年からどう教育したの?ScalaでWeb開発ができる
⇒ 何かいいお題は? ⇒ 掲示板( PlayFramework)
⇒ 拡張性が高い(個人に合わせたフレキシブルな対応可能)
⇒ どこにでもある(伝えやすい)⇒ スモールな機能なので、コードレビューしや
すい ⇒ 実は中途向けに Ganmaでやってた
3.では今年からどう教育したの?DDD理解
⇒ どうやって理解してもらう?⇒ 読書会をやって理解してもらう。
⇒ どうやって実践してもらおう?⇒ PO(トレーナー)を立てて、ドメインをつくりあげてもらう⇒ ユビキタス言語構築実践
⇒ 自ら作り上げたドメインをコードに落とす⇒ ドメイン駆動設計をコードで実践⇒ レイヤードアーキテクチャ
3.では今年からどう教育したの?
大まかな流れ
1.好き勝手に作ってもらう2. domain-driven-design-quickly読書会をする3. DDDでリビルドしてもらう
3.では今年からどう教育したの?
お題掲示板のストーリーを出す
⇒ できるだけ曖昧に。嫌らしく ⇒ 掲示板ドメインはこうですよね?の提案を誘う
1 ユーザーは掲示板の投稿を一覧できる。
2 投稿者のメアドと投稿内容が閲覧できる。
3 ユーザーは掲示板に文字列を投稿できる。
4 ユーザーは、メアドとパスワードを入力することでログインできる。
5 ログイン後であればユーザーは自分のメアドを入力せずに投稿できる。
6 新規ユーザー登録を行うことが出来る。
3.では今年からどう教育したの?
1. 好き勝手に掲示板を作ってもらう目的:トレーナーのための試金石
⇒ Frameworkとか言語理解度をみるやり方:
⇒ DDDを意識させずに好き勝手に作ってもらう
⇒ その時点での君の最強のコードを見せてみくれっ
⇒ Scalaやテストコードに対する指摘のみ ⇒ OOPの指摘をしておくと次の工程が楽
3.では今年からどう教育したの?
2. domain-driven-design-quickly読書会目的: DDDを理解してもらう本はこちら
http://www.infoq.com/jp/minibooks/domain-driven-design-quickly
やり方:通しで読んでもらって、 1章~ 4章までを解説
3.では今年からどう教育したの?
3. DDDでリビルドしてもらう目的: DDDを実践してもらう
DDDのないと
き
DDDのあると
き
4.まとめ
1.新人には教養(今日、用)が必要です。OJTに任せるだけではだめっ!きっちり育てたい!
2.しっかりと、現場にあったものを伝える。Javaや Scalaのプロジェクトの中 PHP …教えても
3.変化を見て、体験して、考えてもらう。自分だけのコードと DDDの知識を学んだあとのコードの比較自分だけのコードと DDDの知識を学んだあとのコードに受けた指摘の比較
…などなど
4 . まとめ
次は、これらの教育を受けた2年目からの学びです。
一旦、原田からのプレゼンは終わりです。ご清聴ありがとうございました。
セプテーニ・オリジナル 新人教育 内容
新人教育開始前の状態言語:
開発経験:OJTスクラム・アジャイル
トレーニング課題掲示板
トレーニング課題掲示板
ユーザーストーリー
1 ユーザーは、掲示板に投稿できる
2 ユーザーは、掲示板の投稿を閲覧できる
3 ユーザーは、自分のメールアドレスを入力せずに掲示板に投稿できる。
4 ユーザーはログインして投稿できる
分からないこと
特になかった
使ったもの
分からないこと(Scala)
・どうやって書くの ?
・ Scalaのメリット、デメリットは?
・ ScalaDocの見方がわからない。。。
・「 javaではこう書く」 javaで置き換えても理解が難しい。。。
実際やってみた感想
動くものをつくるので精一杯だった、、、、
前提知識がなさすぎて、質問ができない
できあがったもの
Scala、フレームワークについてや、設計についての指摘をたくさんもらいました。
プルリクエストにてレビューしてもらったら
プルリクエストにてレビューしてもらったらScala、フレームワークについてや、設計についての指摘をたくさんもらいました。
先輩に質問に行けるチャンス !!
掲示板リファクタリングDDD実践
DDD講習
DDD講習のあと。。
???
?
???
????
?
???
?
???
?
???
?
で、 DDDの何が良いの ?経験がないから分からない。汚いコードに頭を悩ませた日々がないから。
プログラマ1年目・ようやく一人でハイハイ
DDDの説明を受けての感想
座学だけではいまいち理解できなかった
DDD実践
使ったもの
ユーザーストーリーを POに確認して修正する。その際にユビキタス言語を決定する
細分化以前 細分化後
1 ユーザーは、掲示板に投稿できる
2ユーザーは、掲示板の投稿を閲覧できる
3ユーザーは、自分のメールアドレスを入力せずに掲示板に投稿できる。
4ユーザーはログインして投稿できる
難しかったことPOとユビキタス言語を決めること-ログイン中の「ユーザー」って曖昧なので、アカウントとして ユビキタス言語にしてはどうですか?
-投稿は、作成と保存の2つのことをやるので、複雑だと思います。 ユーザーストーリーを分割して良いですか?
-ログインにはメールアドレスとパスワードが必須ということですので、 ユーザーストーリーを修正しても良いですか?
ユーザーストーリーを POに確認して修正する。その際にユビキタス言語を決定する
細分化以前 細分化後
1 ユーザーは、掲示板に投稿できる• アカウントは発言できる• アカウントは、発言を作成する• 発言を保存する
2ユーザーは、掲示板の投稿を閲覧できる
• ユーザーは、掲示板の発言を閲覧できる• 発言をすべて取得する
3ユーザーは、自分のメールアドレスを入力せずに掲示板に投稿できる。
• ユーザーはアカウントを作成できる
4ユーザーはログインして投稿できる
• ユーザーは、メールアドレスとパスワードでアカウントになる
コンテキストマップを作成する
コンテキストマップを決めたメリット
POとの認識の相違による手戻りの発生リスクをなくす
コンテキストマップに書いたものだけを実装していくので、不必要な実装をしなくなる
自分なり DDDでの再構築アプリケーション層 ドメイン層 インフラ層
プルリクエストからの学び
チームでの GIT運用
マージにはプルリクエストで全員の承認必要
ツール:
ルール:
運用方法: Git Flow
プルリクエストを使った改善サイクル
プルリクエスト
レビュー指摘
リファクタリング
フィードバック
先輩 新人
プルリクベースでのコード改善
プルリクの具体的な指摘を紹介しつつScala×DDDの学習の難しさを共有
についてScala
問題: nullを使ってしまう 原因: Optionの使い方が理解できていない解決策:実践を通して先輩社員からナレッジ共有
問題:記述が冗長になる 原因:イディオムを知らないため、自由に書いてしまう解決策:チームメンバーがチームとしての方針を共有
についてScala
についてScala
問題:コンパニオンオブジェクトなのに newしてる 原因:試しに使っていたけど、よくわかってない解決策:プルリクのレビューに時間をかけて、 あやしい匂いのところを指摘
問題:フォルダ構成が適当になってる 原因:気付けていない解決策:コード以外の部分も先輩がチェックする
DDD について
DDD について
問題:ドメインが誰が読んでも理解できるものになっていない 原因:ドメインのチームでの運用について知らない解決策:ドメインの運用方法をチームで共有する
DDD について
問題:作成したコンテキストマップと実装がずれてる 原因:実装に合わせてドメイン層を変更してしまっていた解決策:ドメインの変更をチーム全員が把握できる仕組みを作る
まとめ・ DDDもチーム内のコミュニケーションが大事
→ DDDの実現に必要な文化そのものも共有できる仕組みが教育には必要
まとめ
まとめ・チーム開発ではユビキタス言語の統一が大事
→ チーム内で認識の相違が起きないようにするため