Kosuke Yamashita
Kosuke Yamashita
ソード・ワールド2.0、2.5のレーティング表部分の解析結果（rating_parsed.rb）の冗長な部分を簡潔にする。 ### 現状 rating_parsed.rbでは、各インスタンス変数を `nil` で初期化しており、またそれらを正規化するメソッド（`nil` ならば `0` 等の既定値に変換したり、範囲内に収めたりするメソッド）を用意している。 https://github.com/bcdice/BCDice/blob/c833464bf4e9db8d35b4adc170a9f662a762842b/lib/bcdice/game_system/sword_world/rating_parsed.rb#L34-L41 正規化メソッドの例： https://github.com/bcdice/BCDice/blob/c833464bf4e9db8d35b4adc170a9f662a762842b/lib/bcdice/game_system/sword_world/rating_parsed.rb#L55-L58 以下に示すように、これらはうまく使われていない。 rating_parsed.rbの `#to_s` には、必要なパーツを文字列に追加する処理が書かれているが、必要性の判断は `nil` との比較ではなく、`0` 等の既定値との比較で行われている。また、条件判定と式展開で正規化メソッドが2回呼び出されているため、インスタンス変数と既定値の比較が最大で3回行われている。 https://github.com/bcdice/BCDice/blob/c833464bf4e9db8d35b4adc170a9f662a762842b/lib/bcdice/game_system/sword_world/rating_parsed.rb#L81-L95 レーティング表の処理はSwordWorld.rbに書かれているが、ここでも必要性の判断は `nil` との比較ではなく、`0` 等の既定値との比較で行われている。 例1： https://github.com/bcdice/BCDice/blob/c833464bf4e9db8d35b4adc170a9f662a762842b/lib/bcdice/game_system/SwordWorld.rb#L82-L95 例2： https://github.com/bcdice/BCDice/blob/c833464bf4e9db8d35b4adc170a9f662a762842b/lib/bcdice/game_system/SwordWorld.rb#L325-L341 以上の例のように、各インスタンス変数の `nil`...
関連：bcdice/bcdice-irc#34 CardTraderをBCDice IRCに移す。 CardTraderはBCDice本体からはクラスとして分離されているので、作業はしやすい。基本的にはCardTraderのファイルの移動と関連コマンドの削除で大丈夫なはず。 ダイスボットのうちカオスフレアとバルナ・クロニカは、トランプのデッキの準備を `DiceBot#postSet` で行っているので、そこを削除する。デッキの準備以外のCardTrader依存部分はなかったので、この修正だけでよい。
ログ・ホライズン（[v2.04.00時点](https://github.com/bcdice/BCDice/blob/v2.04.00/src/diceBot/LogHorizon.rb)で3551行）に代表される、巨大なダイスボットファイルを分割して、処理を探しやすくしたい。 # 背景 一般に、表が多いダイスボットのファイルは大きくなり、変更時に対象の処理を探しにくい。 対策として、[v2.02.73](https://github.com/bcdice/BCDice/tree/v2.02.73)以前のダイスボットについては、`extratables` ディレクトリを利用して、表のみ別ファイルにされている場合があった。 しかし、「起動時に必ずテーブルを読み出すから処理が重い」などと（**処理時間測定なしの**）苦情が来たため、v2.02.74（2017年8月）でダイスボット本体にマージせざるを得なくなった。 1ダイスボットにつき1つの（場合によっては巨大な）ファイルとなったことには、このような事情があった。 現在は、以下の理由のため、高速化を目的として無理に「1ダイスボットにつき1ファイル」とする必要性は薄れている。 * 開発終了に伴い、どどんとふの個別サーバ設置が減っている → どどんとふの起動時間が問題となることが少ない。 * 表のクラスが作られたため、Rubyのコードで（＝追加の構文解析処理なしで）ある程度分かりやすく表を記述できる。 * そもそも、処理時間測定なしでの苦情だったため、本当に別ファイルの表が原因で遅くなっていたのかが怪しい。 したがって、現在は、大きなダイスボットファイルの分割によって処理が探しやすくなる利点の方が、処理速度低下という欠点より大きいと思われる。 # 方針案 各項目ともに、採否は未決定。 * 特殊処理が入るコマンドは今まで通りのファイルに書いて、extratables相当の処理を外だしできるテーブルだけ別ファイルに書く。（@ysakasin 案） * 長いテーブルとクラス内クラスを別ファイルに書く。その際、厳密に1個ずつ別ファイルでなくてもよい。各ファイル200〜300行以内を目標にする。（@ochaochaocha3 案） * 分割したファイルのパス：`diceBot/ゲームシステム名/*.rb`（@ochaochaocha3 案）...
refs #132 テーブルのクラス（Table、D66Table、RangeTableなど）について、以下のようにインターフェースを統一したい。これにより、どのクラスを用いても処理を同様に書けるようになると期待できる。 * `#roll` で、表を振った結果の文字列を返すようにする。 * `#roll_in_detail` で、表を振った結果の詳細（出目の配列、取り出した項目など）を返すようにする。結果はできるだけ同じ名前のメンバを持つ構造体で返す。 * （可能ならば）RangeTableのように、結果の文字列の整形処理を変更できるようにする。
Webインターフェースを呼び出したとき、`parseWebIfMessageData()` に進んでいないようです。意図的かどうかはっきりしませんでしたが、一応報告いたします。 # コマンド解析までの順番 「printResult() 以下」の階層が深くなっているので、ここを単純化できると見通しがよくなりそうに見えます。 ## トップレベル 1. executeDodontoServerCgi() 1. getCgiParams() - ここで DodontoFServer::getMessagePackFromData() に進まない 2. main() 1. printResult() ## printResult() 以下 1. DodontoFServer#getResponse() 1. DodontoFServer#analyzeCommand() 1. DodontoFServer#getRequestData('cmd') -...