てきとうなさいと べぇたばん

PHPerKaigi 2018に行ってきた

PHPerKaigi

話相手が欲しかった。サイトのアイコンは文字だということは見た時に照らし合わせて解読して知ってた。

練馬に行ったのも5年ぶりくらいだったかな。

テストしてますか

主にTrack Bで話し込んでた。テスト(ユニットテスト)してますか〜という話だった。話を聞いてると大事でも難しいのもあったなあと。

例えば、そのバグが直接機会損失につながってしまうというものなどの性格を持った事業などで、手作業でのテストの方が確実といったケースである。確認作業の基本は、予め決められた順序を守って項目に従って正しいか間違っているかを確認する。たとえ手作業だとしても存在しているのならそれは効果がある手法ではないかということである。

我々Webエンジニアは、上記の問題に対して、たたき台として、その順序があるならそれをプログラムに落とし込んで自動化を試みたほうがよいなと考える。しかし、ブラウザなどで自動化を行えるのかというところである。例えば、Seleniumを使おうとすると、画面(HTML)を変えただけで動かなくなったりするのでメンテナンスが難しい。それが理由で、これは手で確認したほうが良いのではないかという元も子もないことを言ってしまったが、人が把握しきれないほど順序を追って確認していく必要があるのならSeleniumなどで組んでしまったほうが後々には良いのかなという後悔もあった。

論理的な間違いを見つけるためだったり、仕様の間違いなどを確認する時にテストを鵜呑みにすれば、テストそのものが間違っているかもしれないので結局は意味がなくないかという内容もあった。確認してくれとしても正とを照らし合わせて順序を追っていくのが確認のはずだから、テストが必ずしも正ではない。この話もよく分かる。とはいえ、ここでいうテストとはユニットテストのはずであり、開発効率を高めるのが主な目的とすれば、正とは何かというのも曖昧である事が多いから、適宜テストも修正していけば良いのではないかという話だった。修正すればプログラムが勝手に確認してくれるわけだし。

最も単純な話として、テストコードを記述するのは記述する量が増えるだけで時間がなくなってしまうのではないかという指摘もあった。結論から言えば、書いたほうが品質が良くなり、結果として納期も早く済ませられることが多い。テストコードには、仕様を整理する役割もある。デバッグする時間がなくなるので効果が高い。

先程のブラウザで自動化の話や、テストコードの工数自体の話に共通している例え話をしたい。皆さんは、今この場で100万円もらえるのと一ヶ月待てば150万円もらえるのとどっちのほうがよいだろうか。多くもらえるのは後者なのに、今もらえるほうが得と考えてしまうことはないだろうか。

このちょっとの投資をすれば後で大きな利益を得られるのに目に見える利益で動いてしまう現象は、時間割引 (temporal discounting)で説明できる気がする。こうした考え方がテストコードを回避してしまうのではないだろうか。

ただし、記述量の問題が単純に損失になってしまうこともあるだろう。あまりにも短納期だったりすればテストを書く物理的な時間がなくなるし、頻繁な仕様変更があればテストそのものの価値がなくなってしまうこともある。また、開発だけして運用は手を付けないといった受託ならではの悩みもあるだろう。

人によってテストとは何かという部分から、何を課題としているのか、何をやってよくて何をやってはいけないのかによっても話が変わってきそう。しかし、やったほうが色々と幸せになる。これは強調しないといけないし、難しい内容にも果敢に挑戦していかないと行けないなと思った。

時間割引について

http://www.osaka-u.ac.jp/ja/news/storyz/storyz_research/201209_special_issue4

引用すると、以下のような感じ

1年後にドーナツ100個あげるといわれたらどうでしょう。割引率(価値が減少する割合)がとても大きいと、価値は少しの時間でも急降下して、「すぐもらえないと、ほとんどうれしくない」という状態になり、目の前のドーナツ1個を選びがちです。

技術者の話にこういう話をしだすとどんどん難しい話になっていきそう

懇親会について

懇親会で話しかけてくださった皆様ありがとうございました。うれしかったです。

この規模でのカンファレンス楽しいですね。QRコードの確認を手作業で行った話などの小回りのきいたPHPerKaigiの話を聞けたのは楽しかったですね―。