個人開発を継続するための工夫を振り返ったあと、改めて自分の開発スタイルを見直していて気づいたのが、「バグが出るたびにprint文を大量に埋め込んで消し忘れる」という悪習慣でした。今回は、そこから脱却してXcodeのデバッグ機能をちゃんと使えるようになるまでの過程を記録します。
1. print文デバッグの限界を感じた
最初の頃、変数の中身を確認したいときは、とにかくprint()をコードのあちこちに埋め込んでいました。
print("user: \(user)")
print("isLoading: \(isLoading)")これで動いているうちは良かったのですが、原因を特定できないままprintだけがどんどん増えていき、しかもデバッグが終わった後に消し忘れて本番コードに残ってしまうことが何度もありました。コンソールも大量のログで埋まってしまい、肝心の情報がどこにあるのか探すだけで時間を浪費していました。
2. ブレークポイントで「その場で止めて見る」を覚えた
ブレークポイントの存在は知っていたものの、「行番号の左をクリックして止めるだけのもの」という理解で止まっていました。実際に使ってみると、止めた瞬間の変数の状態をその場で全部見られることに気づき、printを埋め込む手間がほぼ不要になりました。
func calculateTotal(items: [Item]) -> Int {
var total = 0
for item in items {
total += item.price // ← ここにブレークポイントを置く
}
return total
}止まった行でitemやtotalにカーソルを合わせると値がポップアップで表示され、forループが1回まわるごとにどう変化していくかを目で追えるようになりました。printで1行ずつ確認していた作業が、その場で完結するようになったのは大きな変化でした。
3. 条件付きブレークポイントで「特定の値のときだけ止める」
配列をループする処理で、100件中1件だけ異常な値が混ざっているケースを調べていたときのことです。毎回止めてContinueを連打するのは非効率だと感じ、ブレークポイントを右クリックして「Edit Breakpoint」から条件を設定できることを知りました。
Condition: item.price < 0こう設定しておくと、条件に一致したときだけ処理が止まるようになり、怪しいデータが混ざっているタイミングをピンポイントで特定できました。「とりあえず全部止めて目視で探す」から「怪しい条件を先に絞り込んでおく」に発想を変えられたのが、この機能を知った一番の収穫でした。
4. デバッグコンソールのpoコマンドを知らずに損していた
ブレークポイントで止めた後、デバッグエリア下部にコンソールがあることは知っていたのですが、しばらく使い方を知らずに放置していました。ある日po（print object）コマンドで、止めた時点の任意の式を評価できると知り、使い方が一変しました。
(lldb) po user.name
(lldb) po items.filter { $0.price < 0 }止めた瞬間のオブジェクトのプロパティを個別に確認できるだけでなく、その場でフィルタ処理のような式を書いて試すこともできると分かり、「ブレークポイントで止めて終わり」ではなく「止めた状態でその場調査する」という使い方ができるようになりました。
まとめ
- print文デバッグは手軽だが、埋め込みすぎるとログが読みにくくなり消し忘れのリスクもある
- ブレークポイントで止めれば、その場で変数の状態をまとめて確認できる
- 条件付きブレークポイントを使うと、特定の値のときだけ止めて効率的に原因を絞り込める
- デバッグコンソールの
poコマンドで、止めた時点の式をその場で評価できる
「print文を消し忘れる」というごく初歩的な悩みから始まった今回の学び直しでしたが、ブレークポイントを本格的に使い始めてから、バグ調査にかかる時間が体感でかなり短くなりました。
次は、SwiftUIのアニメーション実装でハマったポイントをまとめます。
本記事は生成AI（Claude）を活用して執筆・編集しています。内容は実体験に基づき、執筆者本人が確認・監修しています。
コメント