ソフトウェア開発におけるプログラムの不具合修正を
デバッグといいます
（不具合とは、意図したとおりに動作しない・表示上の崩れなどで、バグと呼んだりもします)。
カラーミーショップをいじっていて、デザインがくずれたり、意図したとおりに表示しなかったり、jQueryがうまく動作しなかったり、トラブルに見舞われることがよくあります。
ご自身でショップ制作をされている方も多いと思いますが、デバッグも自分自身でとなると、それなりに経験がないと難しかったりします。
とはいえ、デバッグのセオリーというものがあって、知識としてインプットすることはできます（そして、本職でないかぎり、知らないままやり過ごしている場合が結構あります）。
デバッグに興味がございましたら、少々長くなりますが最後までお付き合いください。
0. 軽微な不具合について
単純な記述ミス（スペルミス・閉じタグがない）、ブラウザの種類・デバイスによる表示の崩れ、CSSが効いていないなど、軽微な不具合は多種多様です。
いくつかあたりをつけて、デベロッパーツールで問題箇所を特定することになります。
問題箇所からキーワードを検索するなりして、ヒントをもらい修正します。
ヒントが見つからない場合は、とにかく試行錯誤します（慣れが必要）。
デベロッパーツールで、HTMLのブロックを見たり、追加したり・消したり、CSSの順番をみたり、CSSの設定箇所を把握したり、具体的な使い方は検索すると見つかります。
デベロッパーツールはやれることが多くて、解説記事を読むのも大変ですが。
・パッと見で問題箇所がわからない場合
動いていた／動かなくなった、表示されていた／表示がおかしくなった、二つの状況がどのように生じたか把握できている場合があります。たとえば、
いついつまでは動いていた
ここまでは動いていて、ここからは動かない
どこそこをいじったら動かなくなった
「いついつまでは動いていた」は、時期の前後で何かしら作業を追加したことに起因していると推測できます。
「ここまでは動いていて、ここからは動かない」は、その境目に問題箇所があると推定できます。
「どこそこをいじったら動かなくなった」は、それが問題箇所だとすぐに分かります。
ただ、ショップ制作の規模が大きくなって作業量も増えていた場合、不具合が気づかないうちに生じていて、どの作業が影響を及ぼしたか判然としないことはしょっちゅうあります。
次は、もっとやっかいな場合について考えてみます。
1. 原因不明の不具合について
原因不明な場合は、まず不具合の問題箇所を見つける必要があります。
そして、下の考え方こそが、デバッグの最も重要なセオリーです。
不具合の再現条件を明確にする
これだけだと、ちょっと分かりにくいですね。
不具合の再現条件を明確にするために、こんな風にします。
1. できるかぎり小さくして試す（範囲を明確にする）
2. 正常・異常時の差を見て、差異から問題箇所を推定する（条件を明確にする）
このセオリーは知識と経験がほとんど不要で、問題箇所を見つける際に大変有効です。
頭を使うのではなく黙々と手を動かし、試行錯誤を繰り返すことで、不具合の問題箇所を発見します。
もう少し具体的に説明してみましょう。
2. そもそも、一度も正常に動作していない場合
あるページを参考にして自分のページに機能を設置して動かなかった場合、他人のコードを
カラーミーショップにコピペして設置して動かなかった場合、自分でコードを書いて動作しなかった場合など。いずれも、一度も自分で動作させていない場合についてです。
たとえば、
カラーミーショップにjQueryプラグインを設置したら思ったように動かなかった場合、jQueryの問題か、
カラーミーショップの問題か、どこから生じている問題なのか切り分ける必要があります。
カラーミーショップにいきなり設置したりせず、最小構成で動作させる環境を用意して、一度動作させるところから試します（PC上で最小限のHTMLを書いて、そこに設置したりします）。
問題の切り分けは、再現条件を明確にするために非常に重要で、デバッグの基本です。
カラーミーショップ上でしか動作確認できない部分（Smartyの箇所など）も、可能な限りコードを減らして動作テストをします。これも不具合の再現条件を明確にするために重要です。
自分で書いたコードなら、コードを削れるだけ削って、一度動作させるところからです。
一度動作したのなら、 そこから、
やるべき作業を一つずつ積んでいきます。
動作しなくなるポイントから、問題箇所を推定します。
そのあと、適切な検索キーワードを選び、ネットで調べ、修正します。
3. 原因不明で動作しなくなった場合
取っ掛かりが見つからない場合に使う方法がこれ。
正常・異常時を比較して、不具合の再現条件を明確にする方法です。
たとえば、
動く／動かない、表示される／表示されないの二つの間には、なにかしら差があるはずです。
その差（両者の違い）の部分には、不具合の問題箇所があると推定されます。
その差異を一つずつ確認していくことが、すなわち、不具合の再現条件を明確にすることになります。
・追加した作業を一つずつ巻き戻す
たくさんの作業をして気づかないうちに崩れていた・正常に動作しなくなっていた、数日経ってから気づいたが原因が思いつかないなど、そういうことはよくあります。
追加した作業を一つずつ削っていき、正常に動作していたところまで巻き戻しながら、不具合の再現条件を明確にします。
・大きく戻して、作業を一つずつ積んでいく
どのタイミングまで動いていたか分からない場合は、大きく戻しましょう。
正常時のバックアップが必要になりますので、あらかじめこまめに取っておきます。
大きく戻した上で、追加した作業を一つずつ積んでいき、不具合の再現条件を明確にします。
いずれの場合も、ある時点で、不具合が再現する・しないの境目に行き当たるはずです。そこから問題箇所を推定し、推定される理由から、適切な検索キーワードを選び、ネットで調べ、修正します。
4. その他
デバッグの最も重要なセオリーはすでに紹介しましたが、その他で押さえるべき点を補足します。
・いったん冷静に。エラーは出ていないか？
エラーが出ているのに見逃していることがあります。デベロッパーツールのコンソールを見ましょう。
・その再現条件は本当に明確か？ 推定される理由は間違っていないか？
自分の予想が間違っていることはしょっちゅうですので、自分のなかの理屈に固執しないこと（自分の先入観で延々ハマることがよくあるのです）。
ハマっているときは、問題箇所まわりをいじって、手がかりを探しましょう。愚直に試行錯誤することで取っ掛かりを掴むことも必要です。
・実はデータが間違っている
コードでは正しくて、実はデータが間違っていることもあります。
・コードに注釈をつける
困難なデバッグの末に対応方法を編み出したとしても、一年も経つと、なんでこんな風になっているか忘れます。コメントはきっちり付けておくこと。
・検索しても、解決のヒントが得られない
問題箇所が推定できても、理由を考えて直さなければいけません。
直し方がわからなければ、検索することになります。そこでヒントが見つからなければ、お手上げです。
それ自体をあきらめるか、別の手段を探すか、頼れる人がいるなら聞くか。
5. おわりに
行き詰っているなと感じたら、セオリーに立ち返ります。
たくさん試行錯誤すれば、おのずと勘所がわかるようになります。
デバッグには、達成感があります。
悩んで、調べて、たくさん時間をかけて、そして実際に経験して知識を得た、という成長の証でもあります。
デバッグは、自分で解決することで、大きく成長します。何度も経験していくうちに、成長の機会だと思えるようになります。そうなると、しめたものです。
記事の構成が難しくて、すこし置いてから読み直してみます。
こんど書き直すことがあったら、デバッグ・フローチャートを作ろうと思います。
