コメント（10/1 コメント投稿終了予定）
Unknown
(
Unknown
)
2011-06-02 10:24:54
デバッグに時間がかかるのは、プログラムをちゃんと分けれて無いからかと。
主の放送をタイムシフトで見たけど、trace("接続開始")とかが幾つかあったのが気になった。
・変数の名前だけが違う、全く同じ処理があちこちにあるなら、それはさっさと関数でまとめて、共通で使うようにする。
・内部の処理の組み合わせが、何通りにもなってる関数は、もっと細かく処理を分けた方がいい。
ちなみに、既にデバッグされて動いてる部分には、別にやらなくていい。（動いてるから）
今作ってる部分、もしくはデバッグしないといけない部分で、目に着いたらやればいい。
て、訳でがんばれー。
Unknown
(
ME By960
)
2011-06-03 04:25:22
コメありがとうございます。
それは、だいぶ前からやっているんですけどね。
ちなみに"接続開始"のコメントは1箇所にしかありません。
ただ、接続を5つとかやるから、再接続も含めて大量に出力されますけど。
構造的な変化としては、分化と統合が行われた結果、色々増えたにもかかわらず、
クライアントのコード量が 初期→壊 で2万2千→1万4千まで減りました。
Flashはデバッガが優秀なので、書く時間と同じ位の時間でデバグが済んでいるのがありがたいです。
それ以降のデバグに掛ける時間は気休めみたいなもので、安心感のためといった感じです。
ただ、問題はサーバーの方で、
これのデバグが長いのはサーバーがマルチスレッドで走るからというのが大きいです。
デバグツールのエラー報告の3歩手前あたりで実際のエラーが起きていたりしましたし、
なにより、まだまだC++に不慣れといったところが災いしています。
ただ、よくあるバグが、簡単なミスってのが多いですね。
構造がどうとかではなく、ポインタに＆付けて関数のvoid*の引数に渡していたりとか、
あるいは、もっと簡単に名前を間違っていたり、初期化の値を違えていたり、
< と書くつもりが > とかになっていたり、!= と書くつもりが == になっていたり。
長い時間悩んだ原因のうち、設計のミスや構造的な問題だった経験がほとんどありません・・・。
うっかりの達人 タグは伊達じゃないです・・・。
Unknown
(
ME By960
)
2011-06-03 04:48:26
って、勝手に苦労話を盛り上げてしまいました。すみません・・・。
Unknown様（というか、名無し様？）ご心配下さりありがとうございます。
より素晴らしいものになるよう、力を込めてまいりますので、よろしくお願いいたします。
Unknown
(
Unknown
)
2011-06-03 13:16:11
＞あるいは、もっと簡単に名前を間違っていたり、初期化の値を違えていたり、
＞ < と書くつもりが > とかになっていたり、!= と書くつもりが == になっていたり。
大丈夫、それは俺もよくやるからｗｗｗ
むう、マルチスレッドか・・・
俺にはまだ経験が無いからあまり力になれないけど、スレッド間の通信を最小限にすると、やりやすいとか何とか。
もう、知ってるか。
あとは、単体テストをちゃんとやってみるとか。
関数別にテストコードを書いて、関数への入力に対する出力が正しいかテストする。（これはブラックボックステストと言う。）
これは、単純に自力で仕組みを作ってみるのもいいし、単体テストのツールの助けを借りてもいい。
最初は本当に効果があるのか疑問に思うかもしれないけど、単体テストのバグ特定率はすごい。
複雑なプログラムになればなるほど、効果が高くなる。
慣れてくれば、ほとんどのバグを単体テストで発見できるだろう。
やればきっと、「やってよかった単体テスト」となる。
というか、俺はなった。
・・・もうやってたらスマソ。
Unknown
(
shimalis
)
2011-06-04 02:35:08
ある程度大きくなるとテストは必要不可欠ですね。
コアな部分はテストを書いておかないとあとで悲惨な目に遭う。
しかしテスト用コードを書き始めるときりがないという問題が。
作業量が倍になりますよね。
コメントを投稿する
名前
タイトル
URL
コメント
※絵文字はjavascriptが有効な環境でのみご利用いただけます。
▼ 絵文字を表示
携帯絵文字
リスト１
リスト２
リスト３
リスト４
リスト５
ユーザー作品
▲ 閉じる
コメント利用規約
に同意の上コメント投稿を行ってください。
コメント利用規約に同意する
数字4桁を入力し、投稿ボタンを押してください。
サービス終了に伴い、10月1日にコメント投稿機能を終了させていただく予定です。
主の放送をタイムシフトで見たけど、trace("接続開始")とかが幾つかあったのが気になった。
・変数の名前だけが違う、全く同じ処理があちこちにあるなら、それはさっさと関数でまとめて、共通で使うようにする。
・内部の処理の組み合わせが、何通りにもなってる関数は、もっと細かく処理を分けた方がいい。
ちなみに、既にデバッグされて動いてる部分には、別にやらなくていい。（動いてるから）
今作ってる部分、もしくはデバッグしないといけない部分で、目に着いたらやればいい。
て、訳でがんばれー。
それは、だいぶ前からやっているんですけどね。
ちなみに"接続開始"のコメントは1箇所にしかありません。
ただ、接続を5つとかやるから、再接続も含めて大量に出力されますけど。
構造的な変化としては、分化と統合が行われた結果、色々増えたにもかかわらず、
クライアントのコード量が 初期→壊 で2万2千→1万4千まで減りました。
Flashはデバッガが優秀なので、書く時間と同じ位の時間でデバグが済んでいるのがありがたいです。
それ以降のデバグに掛ける時間は気休めみたいなもので、安心感のためといった感じです。
ただ、問題はサーバーの方で、
これのデバグが長いのはサーバーがマルチスレッドで走るからというのが大きいです。
デバグツールのエラー報告の3歩手前あたりで実際のエラーが起きていたりしましたし、
なにより、まだまだC++に不慣れといったところが災いしています。
ただ、よくあるバグが、簡単なミスってのが多いですね。
構造がどうとかではなく、ポインタに＆付けて関数のvoid*の引数に渡していたりとか、
あるいは、もっと簡単に名前を間違っていたり、初期化の値を違えていたり、
< と書くつもりが > とかになっていたり、!= と書くつもりが == になっていたり。
長い時間悩んだ原因のうち、設計のミスや構造的な問題だった経験がほとんどありません・・・。
うっかりの達人 タグは伊達じゃないです・・・。
Unknown様（というか、名無し様？）ご心配下さりありがとうございます。
より素晴らしいものになるよう、力を込めてまいりますので、よろしくお願いいたします。
＞ < と書くつもりが > とかになっていたり、!= と書くつもりが == になっていたり。
大丈夫、それは俺もよくやるからｗｗｗ
むう、マルチスレッドか・・・
俺にはまだ経験が無いからあまり力になれないけど、スレッド間の通信を最小限にすると、やりやすいとか何とか。
もう、知ってるか。
あとは、単体テストをちゃんとやってみるとか。
関数別にテストコードを書いて、関数への入力に対する出力が正しいかテストする。（これはブラックボックステストと言う。）
これは、単純に自力で仕組みを作ってみるのもいいし、単体テストのツールの助けを借りてもいい。
最初は本当に効果があるのか疑問に思うかもしれないけど、単体テストのバグ特定率はすごい。
複雑なプログラムになればなるほど、効果が高くなる。
慣れてくれば、ほとんどのバグを単体テストで発見できるだろう。
やればきっと、「やってよかった単体テスト」となる。
というか、俺はなった。
・・・もうやってたらスマソ。
コアな部分はテストを書いておかないとあとで悲惨な目に遭う。
しかしテスト用コードを書き始めるときりがないという問題が。
作業量が倍になりますよね。