見出し画像

「簡単なバグ修正」の難しさ

以前作ったポケモンのダメージ計算機ですが、実はバグをずっと放置しています。

バグといっても実機と仕様が少し異なるというだけなのですが、そのバグというのが「急所によってランク補正が無視される仕様」が実装できていないというものです。

このバグですが、別に修正が面倒だから放置しているわけではありません。簡単そうに見える修正ですが、実は修正する上での問題点がかなり多く、厄介であるために着手できずにいるのです。

今回のように、一見簡単に見える修正でも、その一部分を修正するために他の多くの箇所に調整を入れなければならず実は非常に難しい修正である、ということがプログラミングの世界ではよく起こると言われています。今回は、ダメージ計算機の制作を通じて垣間見たその深淵の一端について少し話していこうと思います。

ダメ計プログラムの修正

新規 Microsoft PowerPoint プレゼンテーション

ダメージ計算プログラムの、修正部分を簡単に図にしてみました。

左に示したものが、現状の修正が必要なプログラムです。威力・攻撃・防御・ダメージを順に計算した後、通常時と急所の場合で結果が分岐しています。

「分岐」の部分でそこまで計算したダメージ値のコピーを取ることで、通常時のダメージと、急所の1.5倍補正がかかったダメージをそれぞれ別に計算できるようにしています。またこれらの計算順は、五捨五超入処理などの都合でこの順番に処理されなければなりません。

さて、ここで「急所がランク補正を無視する仕様」の実装を考えます。この仕様は攻撃力・防御力の計算に関係する仕様なので、図の「攻撃力計算」・「防御力計算」の部分に急所用の処理を追加することになります。それを踏まえた上での修正案が右の図です。

結果として、「急所攻撃力計算」・「急所防御力計算」という新たな処理が加わったうえ、値をコピーする「分岐」を挟む位置がかなり前になったことが見て取れます。これにより分岐以降の全ての処理に影響が及び、計算結果の上書き先などが変わってしまうため、この修正は予想以上に広範囲に影響が及ぶ厄介な修正になってしまうのです。

バグ修正が新たなバグを呼ぶ

バグ修正の影響範囲が広ければ広いほど、修正の難易度は加速度的に増大します。それは、バグ修正が連鎖的に新たなバグを呼び込んでしまうためです。

今回の例のように、バグ修正は一か所のみを修正すれば解決するものではありません。ある一か所を修正する場合、全体の整合性を取るためにその他の関係箇所にも修正を加えなければならず、さらにその関係個所に関係する箇所にも、というように修正箇所はどんどん広がっていきます。

このバグの無間地獄を避けるために、プログラマーは「各箇所の影響範囲が区切られた、修正しやすいコード」を書くことが求められたりもします。今回は僕の書いたコードが少し下手でしたね。


とはいえ、制作したダメ計ツールのプログラムはコードが短く、下手なりにも多少は影響範囲を限定できていたので、簡単ではないといえどバグ修正は不可能なものでは全くないようです。冒頭で否定したものの、結局修正しない理由は「面倒だから」なのかもしれませんね……。

ということで、今回は以上になります。

プログラミング経験が浅く不勉強な内容もあったかもしれませんが、今回の経験を糧にこれからも少しずつ勉強を続けたいです。

この記事が気に入ったらサポートをしてみませんか?