不具合台帳が30件になった:直したバグを、消さずに残している

最終回です。

ここまで、予想モデル、買い方、公開方法、画面、選手タグと書いてきました。

最後は、その裏側で出てきた不具合の話です。

直したものも消さずに残していて、現在30件の台帳になっています。

直した不具合を、消さずに残している

普通、バグは直したら閉じます。

私も最初はそうしていました。

ただ、同じような間違いを何度も繰り返すので、消さないことにしました。

台帳には「症状」「原因」「対処」を残します。

さらに、再発しそうなものには「教訓」か「見張り」を付けます。

見張りというのは、同じ問題が再発したら失敗するテストです。

文章で「次から気をつける」と書くより、再発した瞬間にテストが落ちるほうが確実に効きます。

30件の内訳

区分件数中身
未対応・観察中6問題は把握しているが、すぐには直さず観察しているもの
修正済20修正後も原因と対処を残しているもの
回避済3サーバなど外部環境の制約を別の方法で回避したもの
判断の誤り1システムではなく、調べ方や判断を間違えた記録
最後の1件だけ種類が違います。システムは壊れていませんでした。間違っていたのは私の判断でした。

書いたコマンドと、実行されたコマンドが違った

いちばん気持ち悪かった不具合がこれです。

定時実行を登録するWindowsのバッチファイルが、なぜか行の途中から実行されました。

返ってきたのは、

'et.yaml' というコマンドは認識されません

というエラーです。

設定ファイル名の途中から、突然コマンドとして実行されていました。

調べていくと、この環境ではバッチファイル内の文字コード切り替えと日本語コメントの組み合わせによって、実行位置がおかしくなる状態が発生していました。

最終的には、定時実行用のバッチファイルを純ASCIIにしました。

日本語コメントも全部外しています。

原因が分かるまでは、自分が書いたコマンドを何度も見直しました。

しかし、そこに書いてある文字列そのものが問題ではありませんでした。

「書いてあるものが、そのまま実行されるとは限らない」という種類の不具合は初めてでした。

1つ止めたら、関係ない処理まで止まった

これは比較的新しい不具合です。

昼間の結果取得をサーバ側へ移したので、手元PCの常駐処理から結果取得を外しました。

結果を取る仕事だけを止めたつもりでした。

ところが翌日、詳細表示にある「4種類の買い方の比較」が空になりました。

データベースにはちゃんと結果が入っています。

なのに、公開ファイルには反映されていません。

原因は、止めた処理が結果取得以外の仕事も「ついでに」やっていたことでした。

新しい結果が入る。

公開ファイルを作り直す。

サーバへ送る。

この3つが1つの流れになっていて、しかも日中に公開ファイルを更新する経路はそこしかありませんでした。

結果取得を止めれば、その後ろにぶら下がっていた仕事も一度も動きません。

台帳にはこう書きました。

定期実行を止めるときは、それが「ついでに」やっている仕事を数える。

「動いていない」と早とちりした

これは不具合ではありません。

それでも台帳に残しています。

サーバ側の定時実行について、私は一度「動いていない」と判断しました。

7分待っても数字が変わらなかったからです。

しかし、その確認方法が間違っていました。

スクリプトには「前回実行から240秒以内なら処理しない」という制限を入れてあります。

そして、その直前に私自身が手動で実行していました。

つまり、その後の定時実行が処理を飛ばしたとしても正常です。

7分待ったという事実だけでは、「定時実行が動いていない」という判定には使えませんでした。

指摘を受けて確認方法を変えました。

自分では一度も触らず、制限時間より十分長く待つ。

11分後、ファイルが自動更新されていることを確認しました。

動いていました。

台帳には、不具合の原因ではなく「正しい確かめ方」を残しました。

コードのミス以上に、間違った確認方法は繰り返しやすいからです。

台帳から、効いた教訓を5つ

何が起きたか残した教訓
女子戦タグに男子が混ざった属性を名前の部分一致だけで近似しない
結果一覧が二重に増えたawait をまたいで可変のグローバル状態を読み直さない
4種類の買い目が一日中出なくなった定期実行を止めるときは「ついで」の仕事を数える
定数を書き換えたら項目が1つ消えた定数のかたまりを丸ごと置換しない
動いていないと早とちりした自分が触らない時間を、制限時間より長く取って確認する
どれも、実際に一度やってから台帳に入りました。文章だけではなく、可能なものは再発検知のテストにもしています。

未対応の問題も消さない

未対応・観察中は6件あります。

主なものは、第7回で書いた女子戦タグの歪み、優勝戦タグが「GP優勝戦」のような名前を取りこぼす問題、集計期間を月単位の区切りに変えたい件、速報ファイルが最大60秒古く見える問題、深夜に画面だけを直したいときの配信手順などです。

どれも存在は把握しています。

ただし、問題を見つけたからといって、すべてをその場で直すわけではありません。

影響が小さければ、他の作業を止めてまで触らないこともあります。

重要なのは「未対応であることを忘れない」ことです。

そのためにも台帳から消しません。

完成ではなく、勝手に記録が増えるところまで来た

サイトは、ひとまず手を離しても動くところまで来ました。

毎日156〜168レースの予想を自動で作り、結果を定期的に取得し、成績を積み上げていきます。

人間が毎レース結果を書き込まなくても、翌日にはまた新しい予想が出ます。

もちろん完成ではありません。

点数を増やした別モデルはまだ検証中です。

女子戦タグには経験量を拾っている疑いが残っています。

会場ごとの癖や、決まり手の予測もまだ試していません。

そして何より、まだ儲かっていません。

第1回は、公開開始3日で-40,030円という話から始まりました。

8回書いて分かったことをまとめても、「競艇AIで勝つ方法を発見した」にはなりませんでした。

むしろ分かったのは、期待値に見えた数字が消える場所、モデルが苦手な条件、データの分類を間違える場所、運用すると壊れる場所です。

どこで儲からないのかは、かなり分かるようになりました。

だから、ここから先も同じようにやります。

予想を先に出す。

結果を全部残す。

失敗した方法も消さない。

数字が良くなったら、本当に良くなったのかをもう一度疑う。

TAKENOKO BOATは、しばらくこのやり方で育てていきます。

Pocket
LINEで送る

コメント

タイトルとURLをコピーしました