Fukabori.fm ep13メモ「ペアプロやテストの疑問」

概要

最近気に入って通勤中に聞いているFukabori.fmというポッドキャストから第9回のメモと所感など。

注：
この記事は気になった部分のメモに自分の解釈や所感を加えたものです。
正確な記録を目指したものではないので興味を持った方はぜひPodcast聞いてください。

13. ペアプロやテストの疑問とか、ソフトウェアエンジニアの育成とか | Fukabori.fm

twadaさんをゲストに、ペアプロやソフトウェアテストの疑問、エンジニア組織の内製化、ソフトウェアエンジニアの育成などについて語っていただいたエピソードです。

ゲスト

@t_wadaさん。説明不要。

ペアプロの組み合わせ

ビギナーxビギナー

お互いに何が正解か分からないので開発としては効果が出にくい。
コミュニケーションを促すチームビルディングとしては有効。

ベテランxベテラン

開発時の戦力としては最高。
リアルタイムに複数の観点から意思決定できるのが強い。
アーキテクチャや全体の設計を決めることになる開発序盤に、迅速かつ効率のいい判断をしてもらいたい。

ベテランxビギナー

ベテランのドライバー比率が高くなりがちだが、ビギナーにベテランのスキルを伝承する点で効果的。
またベテラン自身の作業も教えながら喋りながら作業することになるため、普段サボりがちな部分(コメントとかコミットメッセージとか)を丁寧に作業することになり、結果的に品質は上がる。

コードレビューのインフラ投資

GitでもRedmineでもいいので、コードレビューが発生する環境を整えるだけで品質は上がる。 必ずしも全コードが見られるわけではないが、見られる可能性があるというだけで丁寧に書くようになる。 また開発が軌道にのったらツール導入というのは導入コストが高くつくので、最初から導入すべき。

非専門ドメインでのペアプロ

自分にドメイン知識がなくても相手の知識を引き出すことはできる。
ペアプロはひたすら喋る。喋っている本人も気付きがあるので、それを引き出すことが重要。ドメイン知識だけでなくベテランxビギナーのペアプロでも同様。

テスト時にスタブやモック使う？

t_wadaさん的にはPCにインストールできるものは本物を使う。
モックやスタブは自分の妄想で都合よく書いてしまう。 自分が信頼できないので使えるなら実物を使うようにしている。

private関数をテストするか？

private関数はテストしない。
振る舞い、使用に対するテストではなく実装に対するテストになってしまう。
テストしたいということはなにかしらの責務をもたせてしまっているのでは？その場合、違うクラスのpublic関数として定義するべきではないか検討する。
組織の都合などでどうしてもテストが必要なら黒魔術的に頑張る。

単体テストの指標

ブラックボックス、ホワイトボックスとあるが単体テストでも仕様、振る舞いに基づいたブラックボックステストの考え方のほうがよい。

テスト指標にカバレッジが使われることがあるが、テストの強度に対する指標にはならない。 カバレッジ100%ならバグがない、とはならない。

カバレッジの数字時代ではなく、実行されていないコードを見つけるツールとして有用。 開発者の思い込みや勘違いに気づかせてくれる。

カバレッジの値ではなく傾きを見る。
現在のカバレッジは高いが低下傾向なら問題ありだし、今が低くても上昇傾向なら改善されている。こういう見方なら管理者の指標としても役立つ。
CIのたびにカバレッジをとって蓄積することが重要。