会社員KNIGHTの趣味三昧(卓球・盆太鼓・色々！)

新ロジックを過去データに照らし合わせて見ていますが、過去のロジックに比べて
勝率が格段に上がっていると思います。
但し昨日も書いた通り売買頻度がかなり少なくなると思うので「今日は取引なしでした」と
いう日が増えてくる気がします。
手動売買なら我慢出来なくなる気がしますが、KATSが買わないと判断したのだから
それは良しとして我慢出来ると思っています。

いつの日か職場の後輩が教えてくれた「ど真ん中だと思った球だけ振れば良い。
株は野球と違うから見逃してもアウトにならない」の考えを思い出しました。

昨日から、KATSがしょーもないコーディングミスやオペミスにより異常終了する
リスクを軽減するためにリファクタリングしています。
売買ロジックを指定する画面で存在しないロジック名を入力した時には実行時に
エラーになるのですが、実行時ではなくて設定の保存を行う時に存在チェックをするように
したので「実行してみたらエラーになった」という事もなくなりました。

また、楽天RSSから取得する項目(いわゆるDDEのITEM)名は今までベタで書いていました。
例えば「現在値(現在の株価)」を取得する時には

client.StartAdvise("現在値", 1, True, 60000)

と書いてました。

それに対しイベントを拾って判断させる側は

Select Case e
Case "現在値"

など。
こういうコーディングが結構多いのですが、もし入力ミスで「現在地」などと
書いてしまったら大変です(笑)。
上の例だとエラーは出ず、株価の監視も行ってくれませんし、もちろんそれに対する
アクションもいつまで経っても呼び出されません。
「おかしいなぁ」と調べて、後になってから分かります。

そのミスを防止するため、楽天RSSの項目をDdeItemというクラスにまとめました。
こうする事によってケアレスミスの可能性がかなり減ります。

コーディングは

client.StartAdvise(DdeItem.現在値, 1, True, 60000)

Select Case e
Case DdeItem.現在値

という風に変わり、リテラルのベタ書きが無くなります。
名前を間違えるとコンパイルエラーになります(そもそもインテリセンスでコーディング
するので名前を間違えないようになりますし)。

クリック証券の発注に使う売買区分("1"が売り、"2"が買い)なども、今までは
そのまま「"1"」と使用していたために間違う可能性が高かったのですが、今回
「Order.買」という感じでコーディングするようにしたので直感的になりました。

その他、バグとは関係ないですが、無駄に何箇所も出てきたリテラル文字列を
リソースとして登録し、一本化しました。
KATSのソースから文字列リテラルがかなり減りました。

これからも修正や拡張を頻繁に行っていくKATSですので、ただ「動けば良い」だけでなく
修正容易性や生産性、バグの温床の低減のために積極的にリファクタリングすべきだと
思っています。

新ロジックについては引き続き過去データで検証したいと思います。