RSpec 導入奮戦記その2 -決断編- / The struggle of introducing RSpec part 2

ESM Real Lounge 2019/12 の一幕

Transcript

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

   View Slide

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

   View Slide

3. プロジェクトの狙い
   3
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

17. ある日
    17
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

21. 発展形として...
    21
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide