期限を決めてアプリを作る
イントロダクション
2019/6/1までにCHaserServverクライアントアプリを作ることにしました。 まだ出来ていませんが、感想と反省を記載します。
こんな感じで動きます
ダメだったところ
- ソースがぐちゃぐちゃでデバックするのが大変
- 見た目に美しくない
- カスタム(新機能をる追加)しづらい
- 気に入らない
・
・
・
【実際のソース】
private String checkAround(String res) throws Exception { String cmd = null; Double[] bufMap = data.getBufMap(); // 相手プレーヤの有無 if (data.isPlayer()) { System.out.println("isPlayerAction staert"); for (int i = 0; i < bufMap.length; i++) { if (bufMap[i] == 1) { // プレーヤがいる時の処理フラグを設定 cmd = isPlayerAction(); break; } } if (cmd == null) { cmd = isPlayerAtFar(); } return cmd; } // アイテムがある時 if (data.isItem()) { System.out.println("isItemAction staert"); for (int i = 0; i < bufMap.length; i++) { if (bufMap[i] == 3) { // プレーヤがいる時の処理フラグを設定 cmd = isItemAction(); break; } } if (cmd == null) { cmd = isItemAtFar(); } return cmd; } /// 上記の条件に当てはまらない場合はMap作成に走る /// // 進行方向が決まっていない時はSearchコマンドで広域確認 int direction = data.getHandler().getDirection(); if (data.isDebug) { System.out.println("direction: " + direction); System.out.println("isSearched: " + data.isSearched(direction)); System.out.println("isLooked: " + data.isLooked(direction)); } if (direction == -1 || data.allSearched() == false) { System.out.println("*** IN: Search Method ***"); cmd = ClientData.SEARCH_CMD + decideDirection(ClientData.SEARCH_CMD); data.setSearched(direction); } else { if (data.isLooked(direction)) { cmd = isWalkAction(direction); } else { cmd = ClientData.LOOK_CMD + decideDirection(ClientData.LOOK_CMD); data.setLooked(direction); } } return cmd; }
アプリを作る時には設計をちゃんとやらないとソースがぐちゃぐちゃになる。
これは、大きなプログラムにならないと舐めてかかっていました。 「もっと計画的に!」「仕様を整理して!」などと言われる感じになってしまいました。言い訳はたくさんありますが、しても仕方ないのでこの問題が起きた原因と対策を考えたいと思います。 クラスの役割分担をするだけでは不十分 いつも、クラス分けして実装しているので、ちょっとくらいなら設計なしでイケルと思ってましたが、細かい部分でまとまりがなくなり…今回のような末路を歩む事になりました。つまり
対策1
一度、処理フローのイメージを作ったらそれをノートなどに書きながら作成したイメージの処理をシュミレートしてみるのが良いと思った次第です。
<対策内容>
1.大雑把でいいので、何をどう動かすか?を決める。
2.決まらない時は不明点を明らかにする。
<ダメなところ>
・デバッグしながら実装
・不明点は実装しながら解決しようとした
今回の場合は、サーバーから送信されるデータがわからなかったので、とりあえず実装して、デバッグしながら実装しました。 通信内容に関しては、動かしてみないとわからなかったのですが、今にして思うと通信テストクラスを作り先に通信内容を理解してから実装すればこの様な事にはならなかったであろうと思います。
期限付きの実装
今回は、期限を決めてやりました。やはり、中途半端になってしまいましたが、大きな収穫としては以下の事に気がついた事です。
期限付きのプロトタイプ実装をやる
これは自分的に良いアイディアだと思っています。メリットとしては作って上手く行けばそのまま使えば良いし、上手くいかない時はそのまま反省点として機能するので、自分自身の成果物として意義のあるものになると思います。 ちなみに自分はこれをGitに上げているので、いつでも今回の反省を思い出す事が出来ます(泣)
でわでわ。。。