2024/11/25
よもやま
チャットで質問できるAIのサービス便利
「MySQLのソースから、関数定義の部分をどう探せばいいの？」という質問から始まり ↓ その結果はちょっと実態と違ったけど、だいぶヒントを得た事で別の場所に定義箇所を発見できて ↓ 関数定義の箇所を貼り付けて「このコードを解説して」「んでPHPに変換して！」とまくし立てて ↓ 実際のMySQL上での実行結果ともらったPHPの結果がチゲぇ〜〜互換性〜〜〜〜ってなっていたけど ↓ ”あなたのコードの実行結果は hogehogeです。期待している結果(※実際に別箇所でMySQLに叩かせた結果を収集している)はfugafugaです。コードを修正して、その計算結果が fugafuga になることを自身でチェックし、まだ結果が違うようだったら再度修正してから回答するようにできますか？ " って投げたら
本当に結果が合うようになった！ 浮動小数点を扱うものなので精度の問題とかそういうのがあるのかな〜〜っておぼろげに思ってたし、そういう回答を得られたなら「まぁそんなもんか」ってなりそうだったんだけど。行けるもんなんだな〜
難しい〜〜ってなったら建設的に諦めたい
プログラミンでいうところの「カプセル化」のように、過度に複雑だったり高度だったりするものは、あまり単純化・平易化して扱うべきじゃないな〜って感じる場面があり。
「ちょいゴチャ計算のロジック」のテストで、その正解データどうする？みたいな時とか。この場合、単体テスト的な位置づけで「システムの中のモジュールの中の最小の単位についての検査」であっても、もし「実物」が使えるならそっちの方が健全じゃないかな〜って判断もあり得る。・・・と思う。
逆に、極めて単純化を推し進めると、「どっから飛んできたかわからんハードコードされた値と、actualが一致するかを見る」とか。逆に、SUTと同じロジックがテスト側に流れてきたりとか。
抽象的に物事を記述するために「構造化」とか「LL」とかを使っているのに、色々が暴露されている様は見るにつけ興ざめである。 後は、「何をどういじったらどこがどうなるかわからん」みたいなコードが生まれた結果、テスト結果に対しても「確かにそうだね、正解だよね」と言えない状況とか。
複雑なものは、複雑なまま扱うのも大事。
概念的にはPBTに近いのかな。例えば「2」っていう具体を渡すんじゃなくて、「ありえる量」っていう属性を扱っている気がする。
気になった記事・読んだ記事など
- https://note.com/sotarok/n/nb1b6af9c781e
- https://blog.okashoi.net/entry/2023/12/09/060000
- 知らない内容だ！これが見たかった、助かる！！！って感じでもないのだけど、別のことを調べていてちょいちょい出てくるw