#あすみかんの上にあすみかん

#たのしいことしかかかないことをここに決意します

#phpconkagawa で #phpcon_odawara のふりかえりを登壇した(PHPカンファレンス香川2024)

phpcon.kagawa.jp

2024年 5月10日(金)〜2024年 5月11日(土)で開催されたPHPカンファレンス香川2024で PHPカンファレンス小田原2024」を実行委員長がふりかえる という登壇をしてきました。

speakerdeck.com

実行委員長のちゃちいさん、香川という場でぺちこん小田原のふりかえりの機会を与えてくれて、本当にありがとうございます🙏

今日はぺちこん香川をふりかえっていくぞ〜🐸

続きを読む

PHPUnitで「特定のキーたちがあること」をいい感じに書きたかった(assertArrayHasKeys)

どんなテストコードを書きたかったか

検証したいこと

<?php

class Subject {
    public function getAsumikamKudamono(): array
    {
        // ...

        return [
            'ringo' => [
                'color' => 'red',
                'kamu' => 'syaku',
            ],
            'mikan' => [
                'color' => 'orange',
                'kamu' => 'mogyu',
            ],
        ];
    }
}

上記のような配列が返ってくるとする。

この時、asumikamが好きな果物がちゃんと入っているか、というのをキー名のみ(ringo, mikan)で判定するようなテストコードが書きたいな〜となった。 (この時の観点としてringoやmikanが値として持っている配列自体は興味がないので)

取れる選択肢

assertArrayHasKeyを使う

<?php

$expectedList = [
    'ringo',
    'mikan',
];

$actual = $this->subject->getWorldKudamono();

foreach ($expectedList as $expected) {
    $this->assertArrayHasKey($expected, $actual, '必要なキーがない');
}

パッと思いついたのはassertArrayHasKeyだったが、これはキーが1つしか参照できないので、foreachと合わせて使うという書き方。

ただ、テストコードにforeachが入ると、若干ロジックが入っているみたいで嫌か??う〜ん、と考えて、こっちは採用しなかった。*1

array_keysassertEqualsCanonicalizingの合わせ技

<?php

$expectedList = [
    'ringo',
    'mikan',
];

$actual = $this->subject->getWorldKudamono();
$actualKeys = array_keys($actual);

$this->assertEqualsCanonicalizing($expectedList, $actualKeys, '必要なキーがない');

最終的にこの書き方を選択したが、果たして100点の回答なのかな〜🤔の顔になった。

array_keysを使ってるし、可読性で言えば上の書き方の方が良いのかも。

assertArrayHasKeysというひらめき

う〜んと考えていると「assertArrayHasKeysが実はあるのでゎ・・・!?」と閃いた。

そこで、インターネットで調べてみると以下Issuesに遭遇した。

github.com

要約すると、マジで同じようなことを考えて「assertArrayHasKeysが必要なのでゎ・・・!?」と閃いている方のIssuesだった。 Issuesの中身を見てみると「実装してみたぽよ〜」と提示している人もいる。

おお!?とおもって実際にPRを見に行ってみた

github.com

sebastianbergmannさんの回答

「マージしないことを決めたよ〜」か〜〜〜!!!なるほど〜〜〜!!!

理由が知りたいが、とりあえず、やはりそんなものはないという結論になった。

結局なんでassertArrayHasKeysがないのかわからなかった&array_keysassertEqualsCanonicalizingの合わせ技でよかったのだろうか〜(普通にもっといい感じの書き方ありそう)、という気持ちになったのであすみめもとしてブログに残しておこう〜。オワリ。

追記

id:o0h さんがリプライでめちゃくちゃ一緒に考えてくれた。 人と話すと自分の思考が整理されたり進んだりするので、反応もらえて嬉しかった。

github.com

▲ Composerのテストでも同じような書かれ方をしているのを見つけてくれた(たしかにちょっと安心した、というか探し出してくるのすごいな)

ドメインで頻出ならカスタムアサーションありかもね!(たしかに〜〜)

▲ なんで入らないんだろう〜の推測たち(メタ視点で何かを考えるのがうますぎる)

*1:今思えば、ifは明確にいやだが、foreachならそこそこ問題ない?

「知識の呪い」、チームメンバーと以心伝心しているという思い込み

私たちはスクラムを採用していて、プロダクトオーナーの私と、3人の開発者、そしてスクラムマスターというチームでやっている。

初期段階の頃は、頭の中のユーザーストーリーを開発者に伝えるのをめちゃくや丁寧にやっていた。 リファインメントでたくさん会話して、バイブスを伝えることに多くの時間を費やしていた。 たくさんの会話をしそれを簡潔にテキストに落とし込みバックログを完成させていた。 プランニングの時も開発者の帽子を被り、必要があったら口を挟みつつラジオ参戦していた。

数ヶ月も一緒にやっていると「今ある機能をもっと良くするならこうだよな」というのが開発者の中に思い描けるようになっていたし実際合っているので、リファインメントでたくさんの会話しなくても「あとはお任せ」の様にやれるようになっていた。 バックログを積み、リファインメントで意思疎通できてるな、ヨシ、をシュッと確認して、その後のテキストへの落とし込み、プランニングは「お任せ」でやっていた。

今日、デザイナーの方と最終のUIの相談をした後に「もうあとはああしてこうするしかないっしょ!」と思い、いつもの様に「お任せ」をしようと思っていたが、ふと思い立って「このバックログで何をするか復習しておこうか」と提案した。 なんなら提案を口にする直前に「わかりきったこと確認する時間になっちゃうかな」と、やることを一瞬戸惑ったが、まぁ5分くらいならいっか、と思い今話したことを確認しながらテキストを書き始めた。

すると、私と開発者たちに少しだけ認識の齟齬があることがわかった。 ずれていた認識について会話をし、方向性を決め、いつもの様に簡潔なテキストがを添えたバックログが完成した。

で、今。 本を読んでいて、今日のエピソードこれと同じ話じゃんという記述をたまたま発見した。

1980年代後半、「人間は他人が自分と同じ知識をもっていると思い込んでいる」ことをハーバード大学の経済学者グループが発見しました。彼らはこの認知バイアスを「知識の呪い」と名づけました。

ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング

めちゃくちゃハッとした。 チームの呼吸が合っているので、たくさん話さなくてもなんとかなるっしょ〜と思っていたが、それはまさに自分の甘いところで、「知識の呪い」にかかっていたんだなと思った。

そして、よく思い返してみれば.........最近「あれ?ここはこうする予定じゃなかったっけ」「そう思っていませんでした」という細かなズレがたまにあったなと。そしてそれを大きな問題だとおもっていなかった...。

確かに初期と比較したら格段に以心伝心率は上がっているので、あまりにも多くの会話は費やさなくていいだろうが「これはこういうことをするバックログである」の最終確認が毎回5分で終わるんだったらそこは省略すべきじゃないな、という反省をした。

省略して効率が良いところと、省略しない方が効率が良いところ、見極めるのがんばろう〜。

読書していると急に内省できて良い、というブログ。おわり。