週刊tdd(社内tdd勉強会) 紹介 #agilesamurai

13
Copyright Drecom Co., Ltd. All Rights Reserved. 週刊TDD(社内TDD勉強会)の 紹介 Go Sueyoshi (a.k.a. sue445) Agile Samurai Basecamp 2015.06

Upload: go-sueyoshi-aka-sue445

Post on 05-Aug-2015

745 views

Category:

Technology


1 download

TRANSCRIPT

Copyright Drecom Co., Ltd. All Rights Reserved.

週刊TDD(社内TDD勉強会)の紹介

Go Sueyoshi (a.k.a. sue445)Agile Samurai Basecamp 2015.06

Copyright Drecom Co., Ltd. All Rights Reserved.

● 末吉 剛 (a.k.a sue445)● 所属:株式会社ドリコム 基盤技術部

○ Railsでソーシャルゲームなど● 自分の普段のお仕事は何でも屋

○ 社内ツール○ 社内ライブラリ

■ 社内外あわせて2年間でgem(rubyのライブラリ)を計33個作ってたw

○ サーバサイド全般(インフラ〜アプリ横断)● Ruby界隈に出没することが多い

○ RubyKaja2014● プリキュアおじさん

自己紹介

Copyright Drecom Co., Ltd. All Rights Reserved.

● ドリコムの社内勉強会文化について● 週刊TDDの発端● 週刊TDDの目的● 週刊TDDの概要● ふりかえり

Agenda

Copyright Drecom Co., Ltd. All Rights Reserved.

社内にDATND(Drecom版のATNDクローン)が立っていて、社員みんなが気軽に社内勉強会を開催する文化が根付いている

● だいたい月に8〜10個くらい● エンジニアだけでなく他職種開催のイベントも開催されてい

る● 新しいイベントが立ったり開催直前になると社内チャットに通

知が出るので拡散されやすい

ドリコムの社内勉強会文化について

Copyright Drecom Co., Ltd. All Rights Reserved.

DATND

Copyright Drecom Co., Ltd. All Rights Reserved.

● エンジニア同士の雑談から生まれた○ 前職で週刊TDDをやってたらしい

● その後いきなりDATNDにイベントがたった● 社内チャットに通知が流れて気になった人達が参加ボタン

ポチった

週刊TDDの発端

Copyright Drecom Co., Ltd. All Rights Reserved.

● テストは「書き慣れている」状態にならないと書き続けられな

● テストを書き続けるための条件 (guard による保存時自動テ

スト等) が整っていない人を押し上げる

● 弊社だとテストを書き続けられず定期的にテストコードを全

消ししている現状(rm -rf spec/)

● 仕様変更によりテストコードのリファクタリングが必要になるこ

とを実感してもらう

● 継続するために「毎週」必ず1時間時間を取り,業務と切り離

した。

目的:テストを書くときの障害を減らす

Copyright Drecom Co., Ltd. All Rights Reserved.

麻雀のルールを題材にして、毎週出題者(持ち回り)がルールを

1つ付け加えていきます。

1. 今回のお題を提示

2. お題を満たすコードを TDD で実装する

3. 次の週に新たなお題(≒仕様変更)が提示される

4. 今まで書いてきたコードでは満たせなくなるので構造を変え

ながら修正する

を繰り返し、TDD という開発手法に対しての理解を深めるのを

目的としています。

週刊TDDの概要(DATNDから抜粋)

Copyright Drecom Co., Ltd. All Rights Reserved.

1. 環境構築 + 数牌と刻子(コーツ)と雀頭(ジャントウ)のみで 3, 3,

3, 3, 2 の組ができていることを判定する

2. 一気通貫(同じ種類の数牌で 123, 456, 789 が揃っているこ

と) を判定する

3. 順子(シュンツ)があること (和了形である必要はない) を判定

する

4. 和了形であること

5. 終わってる人が少なかったので引き続き和了形

6. 中間発表

7. 字牌

だいたい毎回5〜6人ずつくらい参加

各回のお題

Copyright Drecom Co., Ltd. All Rights Reserved.

● TDDが「設計技法」であるというイメージを共有でき、「わかっ

ていることを積み上げる安心感」という言葉も出てきた

● 「当然テストは書くもの」という意識を発信できた

● (麻雀のルールを知っていれば)麻雀の仕様を実装していく

のは楽しかった

● カジュアルに勉強会ができた

● そこそこ続いた

ふりかえり(良かったところ)

Copyright Drecom Co., Ltd. All Rights Reserved.

● ロジックを想像して1時間で終わるお題を出すスキルが要る

○ 持ち回りでお題を出すの,不可能に近い。

● 自動テスト環境の作り方等のドキュメントがなく,参加する

ハードルが高かった

● メンター必要。詰まった人を置いていかない施策が足りな

かった

● 開催ごとにコードをどんどん育てていくため,途中から参入

する障壁が高すぎてユーザが減っていった

○ リファレンス実装となるコードベースを一つ指定しておけ

ば良かった

ふりかえり(悪かったところ)

Copyright Drecom Co., Ltd. All Rights Reserved.

● 麻雀知らないときつい

○ ルールを知らないと麻雀のルールをググるところからなの

○ とは言えみんながルール知ってるお題を探すのも難しい

(ポーカーくらい?)

ふりかえり(悪かったところ)

Copyright Drecom Co., Ltd. All Rights Reserved.

https://github.com/sue445/weekly_tdd

【参考】自分のソースコード