laravel.shibuyaって？
IRT(Interactive Round Table)をメインとした勉強会
そのため、持ち寄ったテーマの中からトピックを決めて相談・議論をすることが目的になります。
今回私が参加した回では、2つのトピックについて議論をしました。
Q1. 自分の職場はテストを書く文化がないんですが、テストやCIといったツールを会社に広めて導入につなげていったような体験談とか、うかがってみたいです。
質問の背景：上に話してみるが、工数がかかったり、変更が多く仕様が明確でないため承認されない。
テストを書くと安心できるが、それを全体に伝えることが難しい。（ただのコストと思われがち）
新しい文化を根付かせていくためにどうやればいいのか？
などの意見があがりました。
アプローチの仕方として出た意見は、
- テストコードはプッシュせず、自分のローカルで確認できればよいのでは。
- これに関しては、テストの目的はバグを減らすだけではなく、仕様書としても機能するので、自分だけではなく他の人に広める意味はあるのでは、という意見も。
- テストにも色々あるので、部分的に導入をしていくのもあり。（一気にやると）
まとめとして、
自分が快適に開発させるだけなら、ローカルにだけやるのはあり。
TDDで開発サイクルを早くするためにといったテストをやる目的を改めて整理して、目的を再確認する。
というものになりました。
Q2. 命名規則を定めるにはどのような観点から考えるべきか？
質問背景：社内にコーディング規約はあるが、命名にルールがなくコードの意味が人によって異なる可能性がある。
ルールの具体的な内容については以下のような意見がありました。
リポジトリクラスにはリポジトリとつけるとか。
SET GETはつけないとか。
多少冗長でも誤解のないようにする。
- 何を使って何を呼び出すのかを長くなってもつける。
関数に副作用があるかどうかで命名を具体化する。
- ドメイン辞書を作って、対応する英語を決めている。辞書を作る。
- 共通認識を作り上げている。
- メンテナンスが大変だけど、間違っても良いから辞書をつくる
- BackLogで作ったりする（履歴管理ができるものがよい）。
まとめとして、
- サイトを使ったり、話し合って使う単語の方向性を議論して決める。
- すでにあるコードをみて、これを使っていこうなどの合意を持つ。
というものになりました。
終わりに
持ち寄ったテーマについての議論は非常に有意義でした。
これは社外でのコミュニケーションの中で、かなり有意義なものだったんじゃないかと思います。