LoginSignup
40

More than 5 years have passed since last update.

printデバッグについて

Last updated at Posted at 2017-05-27

初心者が多用するデバッグ法というと、printデバッグです。誰に教わることもなく、自然と自己発見して使い続けるケースが多い気がしています。

プログラマーの三大美徳には怠惰という文言があります。ただ、この怠惰というのは繰り返し作業をやめるために、アクティブな行動を伴うので、別なポジティブなラベリングがされるべきだし、個人的にはちょっと違和感があります。低きに流れて部分最適化されてしまうprintデバッグこそ愛すべき怠惰な気がしています。

UI/UXというと、すごい意識高い感じだけど、じつは意識の低さが大事だと思っていて、低きに流れた先が最短ルートで目的というのが大事なんじゃないかと。何かを探すときはまずスタートボタン(Windows95)。困ったらホームボタン(iOS)。OSごとのUIガイドラインに従うのも、そのユーザーにとってすでに常識となっている使い方に対応することで、ユーザーに新しい学習を強いることなく使えるようにしてあげると。意識低い重要。

で、こういうことをツイートしたわけです。

いろいろ反応があったので、まとめておきます。

いまのところ雑なprintデバッグでこれに近いのはChrome/SafariのDevTool。出力すると、出力した場所の情報も出てきます。オブジェクトとか配列は構造化されていてクリックして中を覗いたりできます。もう1つ思い出したのはWerkzeugのデバッグ機能ですね。ウェブサーバー内でエラーが発生すると、スタックトレースがブラウザ上に表示されて、それぞれのスタックの中の変数とかを覗いたり、それぞれのスタックの名前空間でスクリプトを実行できるやつ。

なるほど、binding.pryやJSのdebuggerステートメントとデバッグ出力を兼ねると僕が妄想してたやつに近そうです。リプライ要求付きコンソール出力命令というのはいいですね。

そうですね。出力する情報を増やすというのは手っ取り早く効率があがりそうです。

C言語とかだとマクロでいろいろやったりはありますよね。そういえばバグベアードというのもありました。

このあたりは別の手法が必要ですね。Goだと、静的チェックではなくて動的にクリティカルセクションを探し出すraceチェック機能がありますしね。

妄想をアウトプットするといろいろ反応があって楽しいですね。

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
40