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
2. 今回は↓で行った決断や葛藤の話をします。 https://speakerdeck.com/muryoimpl/the-struggle-of-introducing-rspec 2
3. プロジェクトの狙い 3
4. 本プロジェクトのねらい 3本柱 • テストを作成する文化を根付かせたい • 本体コードが になっているので、リファクタリングして意図 のわかるコードにしたい • 上記2つを通して、メンバーのスキルアップを図りたい RSpec導入奮戦記p3: https://speakerdeck.com/muryoimpl/the-struggle-of-introducing-rspec?slide=3 4
5. テスト作成初心者には これはやることが多過ぎる ならば… 5
6. 1. 順番に一つずつやる 6
7. 1. 順番に一つずつやる • 教育的側面があるので、目先のスピードは元々捨てるつもりだった • まずテストだけ先に作成しようと決めた ◦ リファクタリングには相応の経験が求められる(難易度高) ◦ Pull Request作成・マージのスピードをある程度保ちたい ◦ 指摘でマージされずPR が溜まっていくのは精神衛生上避けたい ◦ あれもこれも中途半端でどれも破綻、というのは避けたい 7
8. 1. 順番に一つずつやる • 新しいことができるようになった、という自信を早くつけさせたいという気持 ちがあった ◦ 発端がそもそもマイナスからのスタート ◦ 「テストだけ作成する」のはモチベーションの維持が難しそう 8
9. テスト作成+リファクタリング ほぼ同時にやってみたのですが… 9
10. テスト作成 + リファクタリングやってみたが…　 リファクタリングの事前準備なしでやったので、設計レベルの指摘で二転三転し た。運の悪いことに非機能要件でも問題が発生したので、一気に考えることが 増えた。 複数の判断が一気に必要になった上、対応に時間がかかり、他のメンバーお いてけぼりに。 10
11. 順番に一つずつ 着実にやりましょう 11
12. どうやってテスト作成する？ 実践していく？ 12
13. 2. 徐々に世界を拡げていく 13
14. 2. 徐々に世界を拡げていく • 経験が浅いので作成・確認が容易なmodel/decoratorのテストから作成し ていく。後に request spec -> system spec をつくっていく • モブプロ形式でテストと対峙する => 知識の底上げ ◦ 基礎知識に差がつかないように、得た知識を共有できるように ◦ ドライバをころころ替える ▪ 当事者意識の演出、退屈しないように ◦ 様子をみて各自の作業のほうを増やしていく=>経験を増やす 14
15. 2. 徐々に世界を拡げていく • 慣れてきたら各自でテスト作成 => モブプロで仕上げ ◦ PR で完結させることが可能なものは PR だけで完結させる ◦ 仕様に関する問題は事前に調査=>モブプロをスムーズにするため ◦ 問題解決だけでなく、チームの合意形成の場としても利用する • 私は難易度の高いモデルのテストを作成して参考実装を作成する ◦ 困ったときに参考にできる生の参考資料を作成する ◦ いわゆる「進研ゼミで見たやつだ！」をつくりあげる 15
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
17. ある日 17
18. テスト作成作業をすすめていると… テストの作成ペースは以前よりも上がっている気がするが、妙に 同意を求められる回数が多いことに気がつく。 判断がつかずに止まったところでモブとしてガヤを入れているが、 あまり減っていないような、改善されていないような気も… 18
19. 3. 私から答えを言わない 19
20. 3. 私から(すすんで)答えを言わない 絶対にだ • 考える機会を奪わない。必ず一度は考えさせる。 ◦ 経験差がある、実装に不安があるので答えを求めがち => わかる ◦ ただし目の前の作業をこなすのが目的ではない ▪ 教育的側面が大きいので、目先のスピードは捨てている ◦ 問題を解決”できるようになる” のが目的。 ◦ 判断力、調査力を活用してもらう • 相談はOK。いつでもバンバンして！ ◦ 私は自ら答えを決して言わないが、ヒントや意見は伝える 20
21. 発展形として... 21
22. 4. 選択に理由を求める 22
23. 4. 自分のした選択に理由を求める • 「結果がうまくいく」ところまで慣れたら、よりよい選択を求める ◦ 「〜のほうが読みやすい」、「〜のほうが意図が伝わりそう」 ◦ 指摘、説明の際はこちらも必ず理由を添える • どうしてそのパターンを適用したのか？を訊く ◦ PR にコメントする。モブプロ中に質問する。 ◦ 意図をもってコードを書く => 判断力を養成するため ◦ コピペ癖の防止 => 思考停止させない 23
24. まとめ • 「順番」は大事。一つずつ、確実にこなすような計画を • まずみんなで基礎力を上げつつ、徐々に個々にシフト • 考える機会を奪わず、判断力・調査力を鍛え • 意図を持ってコードを書くように導く 24