RSpec 導入奮戦記 その2 - 決断編 - ESM Real Lounge 2019/12 2019/12/23 muryoimpl

今回は↓で行った決断や葛藤の話をします。 https://speakerdeck.com/muryoimpl/the-struggle-of-introducing-rspec 2

プロジェクトの狙い 3

本プロジェクトのねらい 3本柱 ● テストを作成する文化を根付かせたい ● 本体コードが になっているので、リファクタリングして意図 のわかるコードにしたい ● 上記2つを通して、メンバーのスキルアップを図りたい RSpec導入奮戦記p3: https://speakerdeck.com/muryoimpl/the-struggle-of-introducing-rspec?slide=3 4

テスト作成初心者には これはやることが多過ぎる ならば… 5

1. 順番に一つずつやる 6

1. 順番に一つずつやる ● 教育的側面があるので、目先のスピードは元々捨てるつもりだった ● まずテストだけ先に作成しようと決めた ○ リファクタリングには相応の経験が求められる(難易度高) ○ Pull Request作成・マージのスピードをある程度保ちたい ○ 指摘でマージされずPR が溜まっていくのは精神衛生上避けたい ○ あれもこれも中途半端でどれも破綻、というのは避けたい 7

1. 順番に一つずつやる ● 新しいことができるようになった、という自信を早くつけさせたいという気持 ちがあった ○ 発端がそもそもマイナスからのスタート ○ 「テストだけ作成する」のはモチベーションの維持が難しそう 8

テスト作成+リファクタリング ほぼ同時にやってみたのですが… 9

テスト作成 + リファクタリングやってみたが…　 リファクタリングの事前準備なしでやったので、設計レベルの指摘で二転三転し た。運の悪いことに非機能要件でも問題が発生したので、一気に考えることが 増えた。 複数の判断が一気に必要になった上、対応に時間がかかり、他のメンバーお いてけぼりに。 10

順番に一つずつ 着実にやりましょう 11

どうやってテスト作成する？ 実践していく？ 12

2. 徐々に世界を拡げていく 13

2. 徐々に世界を拡げていく ● 経験が浅いので作成・確認が容易なmodel/decoratorのテストから作成し ていく。後に request spec -> system spec をつくっていく ● モブプロ形式でテストと対峙する => 知識の底上げ ○ 基礎知識に差がつかないように、得た知識を共有できるように ○ ドライバをころころ替える ■ 当事者意識の演出、退屈しないように ○ 様子をみて各自の作業のほうを増やしていく=>経験を増やす 14

2. 徐々に世界を拡げていく ● 慣れてきたら各自でテスト作成 => モブプロで仕上げ ○ PR で完結させることが可能なものは PR だけで完結させる ○ 仕様に関する問題は事前に調査=>モブプロをスムーズにするため ○ 問題解決だけでなく、チームの合意形成の場としても利用する ● 私は難易度の高いモデルのテストを作成して参考実装を作成する ○ 困ったときに参考にできる生の参考資料を作成する ○ いわゆる「進研ゼミで見たやつだ！」をつくりあげる 15

現時点での計画 ● 機能のエンハンスは期間限定で停止 。　ただ し、調査・修正は実施する。 ○ なるべくテスト作成に力を注ぐため ● 本体をリファクタリングしたい欲をぐっと堪え てテスト作成に専念する 。 ○ 実行単位の難易度を下げる ○ いろんなところに波及しがちなのでテスト揃え てからやる ● 難易度を考え、model のテストから順に作成 していくこととする。 ○ テストのフィードバックが一番速いはず ○ 容易なメソッドが多かったため ① ② ③ 当作戦は3期計画を予定している。 ① model/decorator/uploader テスト作成期 ② request spec, system spec作成期 ③ リファクタリング期 ※現在 ① 期後半戦 (作戦開始後ほぼ1ヶ月) RSpec導入奮戦記p5: https://speakerdeck.com/muryoimpl/the-struggle-of-introducing-rspec?slide=5 16

ある日 17

テスト作成作業をすすめていると… テストの作成ペースは以前よりも上がっている気がするが、妙に 同意を求められる回数が多いことに気がつく。 判断がつかずに止まったところでモブとしてガヤを入れているが、 あまり減っていないような、改善されていないような気も… 18

3. 私から答えを言わない 19

3. 私から(すすんで)答えを言わない 絶対にだ ● 考える機会を奪わない。必ず一度は考えさせる。 ○ 経験差がある、実装に不安があるので答えを求めがち => わかる ○ ただし目の前の作業をこなすのが目的ではない ■ 教育的側面が大きいので、目先のスピードは捨てている ○ 問題を解決”できるようになる” のが目的。 ○ 判断力、調査力を活用してもらう ● 相談はOK。いつでもバンバンして！ ○ 私は自ら答えを決して言わないが、ヒントや意見は伝える 20

発展形として... 21

4. 選択に理由を求める 22

4. 自分のした選択に理由を求める ● 「結果がうまくいく」ところまで慣れたら、よりよい選択を求める ○ 「〜のほうが読みやすい」、「〜のほうが意図が伝わりそう」 ○ 指摘、説明の際はこちらも必ず理由を添える ● どうしてそのパターンを適用したのか？を訊く ○ PR にコメントする。モブプロ中に質問する。 ○ 意図をもってコードを書く => 判断力を養成するため ○ コピペ癖の防止 => 思考停止させない 23

まとめ ● 「順番」は大事。一つずつ、確実にこなすような計画を ● まずみんなで基礎力を上げつつ、徐々に個々にシフト ● 考える機会を奪わず、判断力・調査力を鍛え ● 意図を持ってコードを書くように導く 24