【プログラミング】ミスを見逃さないパラメータチェック方法

こんにちは、Unity勉強中のみやびのです。
Unityの勉強を始めました」で触れていたprefab暴走問題がようやく解決しました。

蓋を開けてみたらものすごい凡ミスで、ただ単にパラメータの設定個所が間違っていただけ。
何日もハマった結果がこれかい!

「俺は悪くねえ」とか言っていたやつがおるらしい。

上記の私のように一度正しいと思い込んでしまうと何度チェックしても間違いに気づきにくいです。
正しくチェックする仕組みを考えるようにしましょう。

本記事の内容は以下の通り。

・Unity開発中に私がやらかしたパラメータのザルチェック
・パラメータミスを見逃さないための仕組みづくり

一度正しいと思い込むとなかなか見つけるのが難しいです。
ミスを見つけるための仕組みを作るようにしましょう。

Unity開発中に私がやらかしたパラメータのザルチェック

失敗
何日もハマっていましたが、原因はたった一つの凡ミスです。
本来、REGのTransFormに設定するところをオブジェクトのTransFormに設定してしまいました。

誤)
slimeのパラメータは「1」のままでよかった
誤

正)
RIGのパラメータを「30」に書き換えるのが正しい
正

恐ろしいなことにSlimeのTransFormでもサイズ調整はできるんですよね。
ぱっと見では何の問題がないので間違えると原因特定がかなり困難。

目を皿のようにしてサンプルコードと比較したところようやく上記原因に辿り着きました。

上記の修正だけで以下の3つの問題が解決。

1.prefabで複製した時の暴走
2.本とのパラメータの違い
3.Nav Mesh Agentの敵が複数いる時の暴走(1と同じ原因)

しかしまあ、以下のことがわかったのでよしとします。

・オブジェクトのサイズを大きくすると「Nav Mesh Agent」が暴走する
・オブジェクトのサイズが変わると関連パラメータの値が変わる

プログラミングと思わぬ凡ミスで長時間使うのも醍醐味です(笑)。

失敗にへこたれるのではなく失敗から多くを学びましょう。

パラメータミスを見逃さないためには?

調査
一度正しいと思い込むとミスを見つけるのが非常に難しくなります。
参考書やドキュメントを何度読み返しても問題を見つけられる可能性は低いですね。

同様にソースコードやエディタを何度見直しても見つけることは困難です。
なので客観的にミスを見つけられる仕組みを考えましょう。

例えば以下のような方法があります。

・サンプルコードと徹底的に見比べる
・チェックリストを作る
・時間を置いて見直す
・誰かに見てもらう

サンプルコードと徹底的に見比べる

サンプルコードがあるならサンプルコードと徹底的に比較しましょう。
今回の私のケースはこの方法で見つけることができました。

自分のコードだけを見るとどうしても「自分のコードに問題があるわけない」と思い込んでしまうのでミスを見つけるのが非常に難しいです。

しかし、サンプルコードと比較すれば「自分のコードとサンプルコード」の違いからミスを見つけることができます。

できれば目視だけではなくコンペアツールを活用するとよいです。
C#の場合はRiderで簡単にソースコードのコンペアができます。

有料のエディタですが、予算に余裕がある方は活用してみてください。

簡単にミスが見つけられるのでかなりおすすめな方法です。
また、正しく動いているように見える場合でも思わぬミスが見つかるかもしれません。サンプルコードとの比較はできる限りやっておきましょう。

チェックリストを作る

マトリックスなどのチェックリストを使う方法です。
参考書を元にパラメータ名と値を書き出してチェックします。

チェックリストは多くの現場のプログラムテストでも用いられいる方法であり、かなり有効な方法でもあります。

機械的にチェックできるのでただコードを読むよりも客観的なチェックがしやすいです。
作成は手間ですが、一度作ってしまえば何度も使いまわせます。

チェックリストは作成に知識やスキルが必要です。
初心者がチェックリストだけでチェックするのは難しいので最初は他の方法も併用しましょう。

時間をおいてから見直す

人間は何か行動をした後は一種のハイ状態になっているので自分の行動を冷静に見直すのが難しいです。
プログラムを書いた後も同様で「間違いなどあるはずがない」と思い込んでしまい冷静に自分のコードを見直せません。

例え凡ミスであっても見つられない可能性があります。

しかし、時間を置くとだんだん冷静になってくるので第三者の視点で自分のコードを見直すことができます。
3日くらいは空けた方が良いですが、「そんな待てない」という人も多いと思うので最低でも1日は空けましょう。

誰かに見てもらう

友人・同僚・上司など誰でもいいので第三者に見てもらう方法です。
「3日も待てない」という人はこちらの方法がおすすめ。

自分のミスを見つけるのは嫌でも人の粗を探すのは楽しいですよね(爆)。

終わりに

不具合の大半の原因はつまらない凡ミスだったりします。
しかし、プログラミングにおいては凡ミスでも影響はものすごく大きく致命的になることも少なくありません。

そして今回の私のように何日も原因がわからず調査続けなけばならないケースもあります。
素早く原因を特定するためには仕組みづくりが大事です。

今回紹介した方法も参考にしつつ、パラメータチェックの方法を改善していきましょう。

関連記事>>迷ったらビルドせよ~静的解析の限界~

コメント

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