拝読しました。お贈りいただき、ありがとうございました！
こちら、お贈りいただきました！
— a-know | Daisuke Inoue (@a_know) September 7, 2023
僕も、「プログラミングを楽しむきっかけとなれば」という思いで趣味サービスを運営してるところは大きいので(敢えてエラーを出したり(！)してる箇所もあったりする)、さらにそれを良いものにできないかどうか、心して拝読します！ @zaru さんありがとうございます！ pic.twitter.com/Cqvu5BJy7T
目次
●第1章 エラーはどうして怖いのか？ 1-1 エラーを読んでみよう 1-2 エラーを読まなくなってしまう理由 1-3 エラーに向き合う心構え ●第2章 エラーの上手な読みかた 2-1 エラーの構成要素を知ろう 2-2 エラーの種類を知ろう ●第3章 不具合の原因を効率的に見つけるには？ 3-1 デバッグとは？ 3-2 プリントデバッグをやってみよう 3-3 二分探索で効率的に探そう 3-4 最小限のコードでデバッグしてみよう 3-5 デバッグをすばやく進めるための考え方 ●第4章 ツールを活用してデバッグを楽にしよう 4-1 デバッガは強力なツール 4-2 ブレークポイントを使ってみよう 4-3 いろいろなステップ実行 4-4 条件つきブレークポイント 4-5 変数を監視してみよう ●第5章 どうしても解決できないときは？ 5-1 プログラマーのための情報収集テクニック 5-2 エラーが見つからないときは？ 5-3 不具合が再現できないときは？ 5-4 本番環境のエラー収集方法 ●第6章 デバッグしやすいコードを書こう 6-1 再代入は控えよう 6-2 スコープは可能な限り狭めよう 6-3 単一責任の原則を知ろう 6-4 純粋関数を利用しよう 6-5 型を意識してコードを書こう 6-6 デバッグを助けるテストコード
感想
読み終えて......というか、読みながら常に感じていたこととしては、すでに他の読者の方の多くも同様の感想を抱いているようだったのだけど、「自分がプログラミング初心者だったころに出会いたかった！」です。ｗ 社会人としてキャリアをスタートさせてから18年、「プログラミング」と呼べるようなことをし始めてから数えるともう20数年になりますが、今でこそ "なんとなく" 体得しているようなあれこれを、とても平易な表現で簡潔に、かつわかりやすく、まとめてくれている一冊だなと感じました。この本に書かれてあるようなことに反することをやったり、やろうとすると、「なんとなく、気持ち悪いな......」と（非常に感覚的で抽象的に）感じるようなことが、全て言語化されている、そんなかんじ。
改めて考えるとむしろ不思議なもので、エラーについて誰かにちゃんと教わったことって、確かにないんですよね。そういう意味では、これまでみんなが一定以上の時間を掛けて（浪費して）同じように轍を踏んできたことに対して、一石を投じる一冊とも言えるかもしれないですね。もし今後、僕がプログラミング初学者に触れ合う機会があって、その方に対して「あ、エラー読めてないな」と感じたときには、すっと差し出してあげたい。そんな本でした。
あと、 デバッグしやすいコードを書こう 、という、「エラーを受け取る側」にとどまらない記述がちゃんとあるあたりもすごく好感を持てました。本当にエラーの出し方が悪い場合もあるから注意しなきゃだし、自分がコードを書くときもその視点を持っておくことが肝要なんですよね。終始、初級者の方目線で書かれているだけでなく、この記述のような、初級者から脱却するために必要な観点のうちのひとつがきちんと書かれていることもまた、初級者の方に勧めたい理由になってるよなぁと思いました。「デバッガビリティ」「テスタビリティ」「オブザーバビリティ」......などなど、さまざまな X-bility のことを考慮できるコードを書ける、ということは、間違いなく熟練者としての必要条件のひとつになると思います。
そんな、良書であることは間違いない一冊だとは思うんですが、敢えて「これも書いてほしかった！」ということを挙げるとすると、それは「ググっても出てこなかったエラーをもしあなたが解決することができたら、ぜひそれをブログなどの形で書きましょう・インターネット上に書いて公開しましょう」ということでしょうか。......いやもちろん、「コードが動かないので帰れません！」というタイトルであるこの本のスコープからは外れていることは理解しています。。ｗ
「エラーはプログラマーの最大の味方」
本書に記述のあった「エラーはプログラマーの最大の味方」という言葉は、僕の一番好きなフレーズです。
ちょうど最近、こんな話が話題になったりもしましたが、エラーを受け取る側だけでなく、システム・サービスを作る側に回ると、ごく当たり前に "エラー" というものを扱うことになるはずなんですよね。例えば人間同士のやりとりで、「お昼食べに行かない？」「ん、あと5分待って」みたいな場合でも、プログラム上の表現としてはエラーになる、といったことは自然なことであったりするわけで。
ここでちょっとだけ昔話。僕のWebアプリケーションプログラミングのはじまりは GAE（Google App Engine）でした。特に初期のGAEは制限（クォータ）だらけで、それぞれの天井に触れたとき（各エラーを捕まえたとき）に「いかにそれをうまく捌いて、全体として問題ない動作にするか？」というのは、一種の思考パズルになっていた（苦しみながらも、楽しんでた）なーと思うんですよね。エラーをルール、制約と捉えると、またそれを克服する面白さが生まれるはずで、プログラミングというのは本質的にそういう楽しさを持っている行為だなぁと思っています。
だから・これを原体験として、......というと怒られちゃうかもなんですけど、拙作のWebサービス・Pixela でも、無料版の場合には一定の割合でリクエストをエラーにする、という仕様を入れてみたりもしています。
エラーは学びを得るチャンス、っていうのはほんとそうで、だからこそ敢えてつまづきポイントを入れてみているんですが（このサービスの性質上、プログラミング初心者の方の利用者がとても多いので）、たぶんこれはユーザーの方にはあまり伝わってはいないとも思う。。ｗ
なんだか取り留めのない感じになってしまいました。僕自身はここ数年は、プログラミング経験のない人にノーコード・ローコードなツールを紹介するという機会が結構あるんですが、この本に書いてあるような試行錯誤をした経験は、これからの世界でどんな仕事をするとしてもきっと役に立つよなぁ、と改めて思いました。
