読者です 読者をやめる 読者になる 読者になる

TDDBC Toyama にスタッフとして参加してきました

2月18, 19日に開催された、TDDBC Toyama #1 にスタッフとして参加してきました。(もう一ヶ月近くたってしまった...)

多くの方に参加して楽しんでいただけたようなので、よかったです。

@hikaruworld さん主催ありがとうございました。

@t_wada さんいそがしいところ遠いところまで来ていただきありがとうございました。

tddbc.connpass.com

このブログがなぜ1ヶ月後になったかというと、後述する2日目に使用したレガシーコード改善の題材としてソースコードを公開できるようにライセンスつけたり、git log にも意味を持たせたりしていたからです(言い訳です)

TDDBC Toyama 開催のきっかけは去年の 

Agile Japan 2016 北陸(富山)サテライト - AgileJapan北陸 | Doorkeeper で私が発表した内容から懇親会でもりあがって @hikaruworld さんがやろうと動いてくださったのがきっかけだったはずなので、とても思い入れのあるイベントとなった。

きっかけになったであろうスライド

speakerdeck.com

参加者として感じたこと

@t_wada さんの基調講演では、"重複あるテストコードはテストのメンテナンスコストがかかるので、テストコードもDRYにしていくことが必要になってきた" という内容が印象的で、デベロッパーテストとして書いたテストコードを整理してDRYにしておかないと後々テスト実行速度を遅くする原因にもなるし、テストコードのメンテナンスコストも高くなるということが響いた。自分は少し書きちらかすところもあったので、気をつけたいと思った。

ペアプロ時にはテストレポーティングとしてのドキュメントにあまり気をつけれていない感じだったので、日々の実行にも  rspec -fd で実行して気をつけていきたい。

スタッフとしてやったこと

2日目に利用するLifeGameのコードの作成を @hikaruworld さん @mugi-uno さんと相談しながら、Toyama.rb の meetup 中に作成した。それぞれの言語で各々作成するという感じだったが、最終的にはほぼ同じコードになるように書き方やコメントなどを調整した。このコードは意図的にブリンカーしか動かないようにバグが入れてあったり、コメントが嘘付いていたり、重複があったりと仕事としてコードを引き継いだときに「マジかよ」と言いたくなるようなコードに仕上げた。

当日は、これバグっぽいけどどう扱おうのような会話が聞こえて、そうそうと思いながら少しうれしかった。

ソースコード公開するにあたり

当日使用したコードから今後使われるならこういう風になっていた方がよさそうというのがスタッフふりかえりで出たので、以下を盛り込んだ。

  • 各言語のリポジトリに分けてgit logに意味をもったログにする
  • 各言語をまとめるリポジトリを作成して、submoduleとして各言語を保持する
  • まとめリポジトリにコードの背景やレガシーコード改善のお題としてのシナリオを追加する

まとめのリポジトリ

GitHub - tddbc/lifegame: TDDBCでのレガシーコード改善を行うためのサンプルコード

にあるので興味ある人はご覧ください。

 

最後には集合写真をとりました。皆様参加していただきありがとうございました。