00:06
こんにちは、readline.fmです。 readline.fmは、つんどくが趣味の2人が、何かの本を読んだ感想を雑談するポッドチャストです。
ハッシュタグは、ハッシュ、readline.fmです。 AMC2にもreadline.fmのコミュニティがありますので、そちらでも感想やワイワイお待ちしております。
ホスト役は、げんえいさんときんじょうです。 それではげんえいさん、よろしくお願いします。 げんえいさんよろしくお願いします。
はい、ということで、今日はどんな本でしょうか。 はい、今回はソフトウェア設計のトレードオフと誤りという本を読んだ感想を喋っていきます。
なんか技術書を技術書した技術書、まあそんな形容してないんですけど、いつぶりぐらい?デマルコ以来?
デマルコのあれですよね、構造化分析とかぐらいから以来って感じですかね。割とソフトウェア開発のプロセスだったり、組織だったりとか、人だったりっていうところにフォーカスを当てた本が多いから、あんまり読んで
こなかったですね、こういう技術書は。
そうですよね、あんまりやってないよな。ということで珍しいですね、技術書を読むんですね、我々も。
我々としては多分本来的にはこっちを読む方が多そうな気がしますけどね。普通にいくとなんかもっと技術書読んでてもおかしくなさそうだなと思ったけど、思ったより読んでないですね。
取り上げなくても読むからなはあるんだよな。
そうですね、1個はそれもあるし、ソースコードばっかり出てくるような本だとちょっと喋りにくいよねみたいなとかあるから、そうするとやっぱり組織とか人とかプロセスとか。
せいぜい設計の話とかになりますよね。まさに設計の本ですけどとは思う。
この本は読もうとしたきっかけとか買ったきっかけとかなんか話しますか?
買ったきっかけは何も覚えてなくて、ずっと家に眠っていて。
誰かが面白かったよみたいなこと言ってて、読みたいなそれ買ってあるから読みたいなと思って、ずっとつんどくタワーの上に乗っかってたんですけど、なかなか読む機会がなくて。
で、近所さんと次何読むって喋ってて。ソフトウェア設計のトレードオフとはやまりどうすかねみたいな話をして、いいねそれにしようみたいな感じになったっていう背景ですね。
これが出たのが、僕もあんまり買ったきっかけ覚えてないんですけど、でもあれだ、翻訳社の渋河さんフォローしてるから、それで知った可能性高いなっていう気はしてるんですけど。
03:07
アマゾンの履歴見たら2023年4月26日に購入日ってなってて、これ発売が2023年の5月なんで、明らかに情報が出回る前というか、新刊出ますで買ってる気がするな。
現帳を持ってるとかじゃなければ。
購入履歴は出てこないな。俺どこで買ったんだろう。どこで買ったかわかんないけど、家にある本みたいになってきたな。
それが怖くてアマゾンに集約してるからな。
きっと多分オライリーのブースとかで10%オフだからって言って買ったとかありそうだなって思ってます。
なるほど。
リアル物販で買ってる可能性がありそう。
二人ともあまり買った時とか読もうと思ったきっかけっていうのがそんなにユニークなものがないっていう。
そこにあったってことは興味があるってことだから読むかって。
本の全体に全体通して読んできてどうだったかって喋ってみますか。
そうですね。そもそもどんな本かっていうと、読んでみて改めてタイトルの通りだなって感じがしましたけど。
ソフトウェア設計のトレードオフと謝りっていう署名で、これ一章一章がこういう設計判断手法選択とそれに対してこういうやり方もあるよねっていうのを結構対比して語ってるっていうのが多かったですね。
13章だてで一章一章を個別の独立したトピックを扱ってるっていう感じかな。
一章だけイントロダクションなんでちょっと立ち位置違いますけど、あとは完全にオムニバスっぽい本ですね。
そうですね。だからどっから読んでも困らない本ではありますね。
書いてる人もあれですよね。多分一章ごとに違う気がする。なんかそんなこと書いてなかったっけな。一人で書いてるのかな。
一応名前が二人載ってるんで。
二人で書いてるのか。
のどっちかが書いているはず。で、翻訳はもう翻訳者すごいずらっと並んでいて、各章多分それぞれ違う人が訳しているっていうのは誰がどこを訳してるかは後ろについていたので、結構な人数で翻訳をしていたはず。
12人で書いているって感じかな。翻訳をしている。
一人一章ぐらいか。
みたいな感じだったようですね。
06:02
そうですね。2章をやっている人がちょろっといるぐらいだな。
そうですね。なのでそうやっても困らないぐらいには結構話題が全然違う。
全然違うっていうほど離れてないものもあった気がするけど、基本的には違う話題が扱われているっていう感じではありましたね。
基本的にはね、さっき言ったAとBどっちであるとこういうトレードオフがあるから考えたいよねって話なんですけど、扱ってるレイヤーも結構違っちゃ違いましたもんね。
本当にコーディングレベルみたいな話から、いわゆるアーキテクチャーみたいな分散システムでみたいな話とかっていう幅広さというか、いろんなところを扱ってる感じでしたね。
あんまりこういう本って今までなかったなーって気がして、設計という意味ではこういうふうに設計するといいよみたいな本はあるんだけども、トレードオフという観点でどういうところに読む曲かっていうのはそんなに多
くないから面白い切り口だなと思いましたね。
何かアーキテクチャーとかの本だと、当然そこら辺の話好きな人はトレードオフにめちゃくちゃ興味あるからかもしれないんですけど、まるまるアーキテクチャーの話してでこういうプロコがあって、で次の章で別のアーキ
テクチャーの話してそっちはそっちでこういうプロコがあるよねみたいな書き方よくしてると思いますけど、
何かそういう感じじゃなかったですね。このトピックに対してこういうパターンとこういうパターンがあってみたいな感じだったから、確かに言われてみたら珍しいかもなーっていう気が今になって感じました。
自分もこう振り返ってて、でもそういえばこういう本ってあんまないなーとか、こういうアーキテクチャーがあってっていうのでそのアーキテクチャーを紹介していって、このアーキテクチャーにはこういうメリットデメリ
ットプロコがあるよっていうのはソフトウェアアーキテクチャーの基礎とかが多分代表例ですけど、ああいうのとかは確かにあったなーと思いながら。
でもそのトピックレベルではやっぱりなかなかないですよね。だからまあ結構面白いなーと思うから、これは結構みんなで読むと、いや俺はこっちがより大事かなって思うみたいな話とかが盛り上がりそうな本でいいなー
って思いますね。
そうですね、チームの読書会とか向いてそうだなーっていうか、うちのチームではこういう方向にしたいよねっていう目線合わせの呼び水というか叩き台みたいなのに使えそうだなーっていう気がすごいしましたね。
09:05
一人で読むよりは一章ずつ毎週読んできてみんなでディスカッションした方が絶対に楽しい本ですね、これは。
そうですね、そうですね。
たぶんそこで先輩社員とかその若手とかが、先輩社員が昔こういう設計をしてな、こういう痛い目にあったんだよみたいな話をいっぱい聞いて、ああこういうことに気をつけないといけないんだなって言って、同じ失敗を
して、あああの時言ってたのこれのことだったんかみたいなのを体験してもらいたいなっていうところまで見えた読書会でしたね。
読書会でしたねっていうか、読書会存在してないんですけどね。
存在してないんだけど、なんか頭の中にはそういう読書会が存在してましたね。
あとあれだな、一定の経験年数積むとどっちがいいっていうか、要はバランスなんだけどみたいな逃げ切らないことしか言わなくなりそう。
そうそう、なんかもう絶対こっちしかないでしょとか絶対言わないっていう感じになるから、まあその時の局面に応じてまあ決めるかなみたいなことしか言えなくなっちゃうからな。
実際そうなんだよな、答えないっていうか答えが変動しますからね、今の答えを出したとて。
そうですね、幅広いトピックを扱っててさっき言ったように13章立てっていうのもあって、本のボリューム的にはそこそこありますね。
持ち歩くのが大変でした。
僕は引きこもって読んでました。
150ページくらいあるんでまあ結構大変だけど、最初から最後まで読み通す必要もないんじゃないので、気になったとこだけつまみ食いして読むでも全然OKって感じですね。
あとは他の本でここらへんは読んだことあるしなーみたいなの結構サラサラとレベル感的にもサラサラと読んじゃっていいかなっていう気はしたかな。
ちゃんと読む前は割ともうちょい、ハイネンジなんて言葉ないか、経験レースもうちょい長めの人向け、リードエンジニアとかそこらへんの人向けの本かなって思ってたんですけど、全然もっと手前の段階でむしろ読むべき
本だなっていう気はして。
ソフトウェアアーキテクチャの基礎とかそこらへんのレベル感かなって勝手に思ってたんですけど、ページ数とタイトルから勝手に思ってたってだけなんですけど。
実際中読んでみるとすごいわかりやすいのが第1章じゃない?第2章か。なんか高度の重複は必ずしも悪ではない。高度の重複VS高度の柔軟性みたいな話で、どこをドライにするのとか。
12:08
ドライだと思って変に共通化しすぎてないっていうトレードオフあるよねみたいな話とかっていうところから始まったりしてるので、仕事に慣れてちゃんと高度をかけるようになってきたし、設計とかそろそろ勉強したい
んだよなーぐらいの人でも、ちょっとチャレンジして読んでみてもいいかもなーっていう気がするし。
さっき言ってた本当にチームの読書会とかにはおあつらい向けの本だと思うので、なんか僕が最初に抱いてたよりかはハードル低く、なんか幅広く手に取ってもらえると良さそうだなーっていう感じがしましたね。
なんか締めの感想みたいになっちゃいましたけどまだ。
まだ始まってもない。
始まってもない。
一応本書についてのところで、どういう人がターゲットとしてますかっていうところで、トレードオフやパターンを理解したい全ての開発者に向けて書かれましたよって言ってて、全てって書かれた瞬間にそれは何も言って
ないのではって気持ちにはなったんですけど、
一応本書はキャリアをスタートさせたばかりのソフトエンジニアにとっても非常に価値のある低レイヤーのトピックから始まりますっていう風にあって、後ろに行くにつれて上級者にとって有益な行動のトピックに進んで
いきますっていう風に書いてるんで、前から順番に読んでいくとよく遭遇するものから始まり、後ろに行くにつれてそういう経験ないなーみたいなものとかに触れていくみたいな構成にはなってますね。
あれなんですよね、本書について低レイヤーのトピックからって書いてあって、目次見ると分散システムにおける一貫性とアトミック性みたいなこと書いてあるから、なるほどレベル高そうって思ったんですけど、
そういう低レイヤーじゃないんだよなーっていう感じ。
そうそうそう。 よかったよかった。そんなところですかね、本編を全部やっていくと長いなって話をさっきしてて、いくつかの章を取り上げながら読む感じで今回はいいかっていう進め方について事前に相談
をしたんですが、
どんな章があるかだけ最初にさらっておくぐらいはやっておきますか。 13章読み上げるの疲れそうだな。1章がイントロダクションで2章がさっき言ったコードの重複は必ずしまくではないで、
3章が例外vs他のエラーハンドリングパターンですね。4章が柔軟性と複雑性のバランス、5章が早すぎる最適化vsホットパスの最適化、6章がAPIの分かりやすさvsメンテナンスコストで、
15:05
7章が日付と時間のデータを効率よく扱う、ここら辺からAvsBっていうショータイトルじゃなくなってますけど、8章がデータローカリティとメモリーの活用で、てかあれだろうな多分7章から2人目が書いてる気が
するな。
確かにここからなんかちょっと違うって感じですね。
コードのメンテナンスコスト、13章本編の後に付録Aっていうのがあって、これが日本語版限定なんでしたっけ。
そうですね多分渋川さんが書いてるおまけ、おまけと言うとあれかもしれないけど、日本語だけに多分入ってるやつって感じですね。
っていう感じの小構成になってて、でわりかしサンプルコードとか含めてJavaかな、Javaを題材にしてることが多いですかね。
まあとはいえ、全然Javaだからできる話っていう感じではなくて、DIの話するときにJavaのDIライブラリーっていうのが例字として出てくるよとか、そういう感じだったんで、別に言語問わず読めるって感じ
ですね。
そうですね。
てかサンプルコード出てくる章がそんなにないしな。
まあそんなにこう難しいことは書いてないはずだから。
してないしてない。
読めや分かれ。
という感じで。
はい。
じゃあ入っていきますか。
入っていきますか。
じゃあ最初は。
まず3章の例外vs他のエラーハンドリングパターンっていうところからいきますか。
これはね、本で言うと何が書いてありますか。
まあJavaの本なんで本当に例外文化ですよね。
そうですね。例外処理をするときの扱い方を書いていて、サードパーティーのライブラリーからの例外だったりとか、マルチスレッドとか非同期処理みたいなときにどうやって例外を扱うかとか。
あと関数型プログラミングとオブジェクト思考における例外の違いみたいなところがトピックスとして扱ってますよっていうのが3章の一番最初に書いてますね。
そうですね。3章そうだな。
18:03
検査例外どうするみたいな話が出てきたりとか、Javaほどしっかり検査例外とそれ以外を分けてなくても実質的にそういう感じの機能を備えている言語とかっていうのもあるよねっていうちらっと紹介みたいなのもあ
ったりとか。
言語機能としてなかったとしても考え方としてどう扱うかっていう話だったりとか。
PHPからくるとちょっと検査例外、そうかみたいな。
検査例外もないし、マルチスレッドもないから、一直線な処理しかしてないからそんなに。
なんか読んでて、なるほど、考えること多いなと思いながら読んでましたね。
PHPってなんて単純なんだって思いながら読んでましたけど。
PHP分かりやすいな。
そうなんですよ、PHP分かりやすいんですよ。分かりやすいけど、それがために例えばマルチスレッドがなかったりするからセルフホストできないというか、自分でサーバーになれないとかそういう問題があったりとか
しますけどね。
なんかこの章を読んでの感想とかあります?
なんかこの章を読んでて、まず最初に思ったのが金城さんが、そういえば昔スライドにこの辺の例外とかエラーの話とか、その継承釣りの話とか書いてたよなっていうのをパッとまず思い出しましたね。
これあれですよ、2021ぐらいの、あ、違うか、ペチパー会議か。あ、でも2021のペチパー会議っすね。
これあれなんですよ、なんかPHP、エラーとエラーとエラーエクセプションとエクセプションとっていうのがあって、
で、チャッチスローアブルみたいなことを書かれるたびに、もしくはバックスラッシュルートのエクセプションみたいなのが書かれるたびに、いや待ってくれ、気をつけてくれっていうのを説明することが多かったんで、
もう何度も何度も文章を書き直すのがやだ、当時せせええとかもなかったんで、いちいち手書きでやるしかなかったんで、めんどくさいから説明資料欲しいと思ってプロポーザル投げたやつですね。
なるほどなるほど。 たぶんちょうど転職した年度で例外とエラーとエラーがあってのっていうのを繰り返しやってたんで、最ポータブルな形にまとめようっていう時代ですね。
21:02
社内説明ドリブンプロポーザル。
この辺やっぱ例外っていうものを使うときに、じゃあどこまでをキャッチしてますかとか、いやそもそもキャッチするんじゃないよみたいな話とかやっぱありますよねって思いながら、
ポケモンキャッチ、全部エクセプションをキャッチして潰しちゃうとか握り潰しちゃうみたいなのとか、あとなんかキャッチしてるけどスローEXしか書いてなくてこれ一体何なんだみたいなのとかたまにあったりします
けど。
IDに怒られる回答。
この辺の話をパッと知ってるか知らないかとか、じゃあどうやって、ちょっとこの本から外れちゃうかもしれないけど、例外ってものがそもそも何であるんだっけとか、例えばGoには例外ないよねとか、例外がない言
語ってどうやって扱ってたんだっけってことまで含めて例外の話をいろいろ考えるのに結構面白いなって思いながらまず読んで、
読んでましたね。
どっちをですか、この本?
本の方ですね。あとはエラー発生時のリソースのクローズとか、確かにこの辺とかね、うっかり忘れそうだよねみたいなやつとかを、そういえばそうだよねとか思い出しながら読んでましたね。
なんかまあ、わりとTHPで言うとリソースを開いてる変数がなくなった時点でわりと、なんかガベコレと一緒にいい感じにしてくれることが多いっちゃ多いんで、
そんなにしょっちゅう終わらなそうな体感はありつつ、だからこそ気づかないで地雷踏んでたりとかもあるよなっていう気もしたりとか。
別の言語に行って、うっかりファイルを掴んだまんま死んでそのままになっちゃったりとかすると、とかね、あったりもするだろうし。
あとPythonとかだと、ファイナリーが絶対通るよねみたいな書き方ができたりとか、あとCシャープとかだとスコープで囲ってそのスコープ抜けたら絶対これをやるみたいな書き方ができたりとか。
なんか結構言語によってそのリソースを扱い方とかをこうやって書くといいぞみたいなのがいろいろあったりとかして、そうなんだよなみたいな。
その辺のことってなんかPHP書いてるとあんま覚えてねえなーってちょっと思いながら読んでましたね。
アイソンのファイナリーってなんかPHPのファイナリーと違うんですか?
えっとね、Pythonのファイナリーってかウィズックみたいなのがあって。
24:03
はいはいはい、ありますね。
あれとかってPHPにはないなと思いながら。
ないですね。
ウィズを使ってると最後閉じてくれるんですよね、確か。
そうなんだよな、PHPは大前提1リクエスト1プロセスっていうすごい牧歌的な世界だから。
なんかシェルターの中に住んでますっていう感じの作られた平和の中で生息できるんで。
そうそうそう。
たまにね、シェルターに穴が開いてうわーみたいな。
うわーそうそうそうそう。
なりますけど。
ウィズ、ゴーだとデファーとかあったりしますね。
そうデファーね、デファー欲しいんですよね。
わかる、めっちゃわかる。
なんかデストラクターで似たような処理ができた気分に、いややっぱ慣れねえかーっていうのを何回か繰り返してるんだよな。
そう、1回ゴーを書くとね、デファーってやつ便利じゃんって気持ちになっちゃうから。
そう、デファーってやつ便利じゃんってなる。
だからそれ1回覚えちゃうとね、いやなんでPHPにこれがないんだろうっていう気持ちはやっぱりありますね。
そうですね、いろんな言語学んでみるとか比べてみる面白さの一つがそのエラーハンドリングとかは結構文化の違いが出るからちょっと楽しいですよね。
そうそう、そうなんすよね。ゴーに行くとなんかこうエクセプションを投げたいと思っても投げられないみたいな感じになって、
じゃあ毎回このオートリッジでやるんですかって、なんかどうやらパニックってやつがありますねみたいな。
なるほどこれかーっつってやった瞬間に全てが死ぬみたいな。
怒られるんですよね。
そう、そうなんだよな、その辺のメンタルもんでもな、結構PHPと世界からいくと全然ほんと違うから。
あとはね、濃度とかもまあそうじゃないですか、やっぱり結構1個死ぬと全部丸ごと死ぬから辛いみたいなこともあったりするし。
そうなんすよね、PHPはなんか自己責任の範疇でしか死なないから、もうそれで本当に考えること少ない。
本当にそう、まあもちろんねそのなんかスウォールがやってきたりとかそのフランケがやってきたりとかで、
多分またちょっとそうはいかんぞみたいな部分とかもあるにはあるかもしれないけど、
まあ多くは多分PHP、PMかアパッチで動いてると思うんで、あんまりそこまで考えることはないですよね。
フランケンってグローバル変数あるんでしたっけ、
PHPが言ってるグローバルじゃないグローバル変数じゃなくて、本当の真のグローバル変数あるんでしたっけ。
27:01
いやーちょっとねフランケンをね使ったことがないからわかんないんだよな、そんなへん。
フランケンちゃんとやったことないんだよな、なんかエンジンXのコンテナ建てるのめんどくさいからフランケンでいいやみたいな使い方をしがち。
しがちというか楽に言うとめちゃくちゃそれで簡単に動くから、ビルトイーサーバーよりは100倍マシかなって思う。
他の言語はね大体みんなそういう気持ちなんですよっていう感じですよね、エンジンXがソフト入れなくたって動くんだからみたいな。
でもレッドマイン建てるときにユニコーン使ったからな。
懐かしいな。
フランケンPHPだとあれか、ワーカーモードみたいなモードによってそのリクエスト、ワーカーでリクエストっていう単位があるのかよくわかんないけど、ちゃんと状態を残せるやつがあるっぽいですね。
なるほどな。
リクエストが開始されるタイミングで初期化するっていうのもあるらしいです。
わかんないです、これAIなんで嘘ついてるかもしんない。
でも本当その辺のこと気使わなくていいっていうのが、いかにPHPは楽な方になっているのか、そしてなぜこのパフォーマンスが出るのかなぞっていうところも含めすごい言語だなって思いますね。
早いっすよね、早いんだよな。
現実的な時間で動いてるからな。
そういうようなところがありながら、そこで他のエラーハンドリングパターンみたいなところでそのマルチスレッドの話が今さっきいろいろ出てきましたけど、この本の中でもマルチスレッドにおける例外の話が出てきたり
とか、あとPromise API使った非同期処理の例外とか出てきて、
確かにな、この辺ってPHP書いてると本当にやんないなって気持ちになりましたね。
やんないですね、そこと関連して気軽に例外を投げるか我慢するかちゃんと考えようねみたいな話になってましたよね。
早めに失敗させる、こけさせる方がいいっていう、派閥というか、それがハマる時もあるし、それが必ずしもいつでもそうじゃないからよしよしあるよねっていう話になって。
そこら辺のトレードオフっていう話で、確かになるほどって思って、どこに書いてあったっけ、61って書いた気するなさっき。
30:05
でもそんなページに付箋貼ってないから多分そうだな。
50ページですね。Dread It Crushのアプローチは、みたいなことが書いてあって、要するに例外的な状態が起きたらすぐにスローエクセプションみたいなことして通知しましょうよっていう。
致命的な失敗は回復しない方が望ましいっていう考え方もありますよねっていう話を聞いた上で、マルチスレッド環境とか、自分のスレッドの中で何か例外的な失敗状態が発生しましたってなった時に、
大元まで丸ごと殺しちゃうとやばいっしょっていう話があるから、本当にそのDread It Crushを徹底的にやっていいんだっけみたいな話になったりとか。
そこの続きで書かれてるのが、アクターモデルみたいな一個一個がちっちゃいスコープで、ちっちゃいタスクが強調しながら全体のシステム作り上げてますっていう時には、そのちっちゃい単位では全然これを押しちゃって
もいいじゃんみたいな。
全体ごとクラッシュはしないけど、明確に自分自身は失敗しましたっていうのを周りの人に伝えられるから、それはそれでいいよねみたいな話もあったりして、うん、なるほどって思って読んでましたね。
そうですね、だから、今PHPの話をした時とか、我々の前提としてはウェブのシステムというものを考えた時と、もしかしたらデスクトップアプリとかiPhoneアプリとかAndroidアプリとか、
そういうものによっても例外っていうものをアプリごと丸ごとキルしていいのか、バックグラウンドプロセスで動いてたものが失敗したら、ただ単に画面に通信エラーになりましたって出してあげるレベルでいいのかとか、
そういうこととかも含め考えるとすごいトレードオフというか、どうやってエラーハンドリングするかっていうのはかなり状況によって色々選ばないといけないというか、いう風になるから
いやー大変ですね。
そうですよね、なんかエディターでファイル開こうとしたら他のアプリが編集中でしたよっていう時に、うわー例外だーって言って大急ごとクラッシュさせられたらたまたまじゃないですもんね。
これはもうある種の飛行をついた不具合。
確かに。なんか攻撃されてると思った方がいい。
そう、ブルースクリーンが出せたらすごい、それはすごいですねみたいなレベルですけど。
確かに。あーでもそうっすね、昔のパソコンというか昔のインターネットだとあのブラクラ踏んで丸ごと操作効かなくなるみたいなのは。
33:06
うん、ありましたね。
あれはなんかブラザーが頑張りすぎないで落ちてくれればちくしょうみたいなやつでしたもんね。
そうですね。
いや俺落ちてねえし、自分まだやれますって言って、親ごと丸ごと持っていくみたいな。
うん。だからブラウザとかもやっぱり、ある種こうね、もはやOSと近いレベルという言われ方を、クロームとかクロームOSとかありますけど、
だからタブが別のタブに干渉しちゃうとまあ辛いからそこって隔離をすげー頑張ったりするんだけども、
大元のブラウザのクロームのところが死んでしまったら全部死ぬわけなので、
そうならないようにじゃあどうやって隔離するかとか、どうやってハンドリングするかとかって、きっと裏っかわではいろんなことがされてるんだなとかって思うと、
いやー結構エラーハンドリング奥が深いですね。
なんかいろんなアプリケーション作ってみて経験、自分でしてみないとわかんないですよね。
わかんないですね。
いや本当PHPやって、C言語、C言語昔学生の時に触って、NullPointerExceptionを踏んだりとか、いろんなクラッシュを踏みながら、
でPHPの世界に来ると、そもそもなんか最初に見たコードはExceptionがなかったんで、Return Falseって書いてるので、
これC言語で見たやつやんとか思いながら、でもそもそもそうやってやんないのかとかいうのをコーディングを支える技術って本を読んで、
Exceptionって結構異体だなと思いながら読んで、でGoいったらそもそもまだExceptionがないしとか、
でiOSとAndroidを触った時はまたなんか考え方も違うしとか、本当にいろんなものやっておくと全然こっちはこうなんだなとか、
言語レベルもそうだし、OSレベルの話もそうだし、やっぱり考え方全然違うんだなーっていうのをよくよく見ますね本当に。
いやー、なんかそうですね、プログラミングってある意味そのエラーを失敗的な状況にどう対処するかが肝心だと思うので、
そう考えるとその言語レベルの設計思想というか、壁みたいなものが当然出ますよねって今思ったな。
そうなんですよね、だからそこなんていうか、あれじゃないですか、よくあるニッパ中法則でも大体のケースっていうのはあっという間に作り終わって、
大体やってることってこうレースコンディションだったり、エラーハンドリングのためのことをやってたりとか、
そのハイタの制御どうしますかとか、同時書き込み、じゃあオーバーブッキングしたらどうしますかとか、なんか大体そういうことばっかやってますよね。
36:04
それがなければだいぶ世界平和になりますからね。
世界が平和になるみたいな文章がこの本にもあった気がする。
平和な世界だったら問題ないんですがみたいな。
マジでそれだったらバイブコーディングでいろんなものをもっと作って安心って感じになりますからね。
でも現実はね、まとめてプロセスが死ぬと辛いし、テーブルの開いたロッカー、デッドロッカーが必ず起きるし、全ては大変ですみたいな世界です。
そこでお金頂いてるからな。利害をハンドリングすることによってお賃金もらってるんで。
そうですね。そこがある種の専門性と、どこまでそういうところが考えられるかが専門性っていうところに紐づいてるっちゃ紐づいてるってことですからね。
でも参照そんなところかな。サードパーティーライブラリの例外とかね。
どこまでやるかって話になってくる。
そうですね。そこの例外を握りつぶすってことはしたくないけど、何か時と場合によって握りつぶして回避みたいなのがあったりとかするし。
使ってるユースケースのミスマッチだったりするとどうしても気にしないといけないことが多かったりするんだろうなって気持ちになったりとかね。
当然例外をまたいだときに例外翻訳しなさいみたいなのはやるべきなんでしょうけど。
そうですね。
やらない理由がないからやったほうがいいんですけど、結構真面目にそこ取り組もうとするとやらない理由が意外とあって単純にトライタッチばっかの行動になってきて非常に見通しが悪いみたいな。
アンノーンエクセプションみたいなのにしたいけど、でもアンノーンなのは俺がこのレイヤーにいるからわからないだけであってみたいな話。
何がわからなかったのか含めて伝えるんだっけどうだっけみたいなね、ありますね。
ありますね。
言語化がめんどくさい、あと普通にやれるしやるんですけど、汎用的な説明をするとなんか頑張れってなっちゃうから、めんどくさい。
エラーで死んでもらうのが楽。
そうPHPね、それができるんでね。
ただ一方でPHPじゃない世界に行ったときにはいろいろ気にしないといけないってなっちゃう。
39:00
ロングライブのプロセスがマジでないからな。
そうですね。
バッチとかがやり始めたら全然別なんですけど、長くて0.3秒ぐらいのプロセスしか使ってないわけじゃないですか。
ウェーブだけやってると。
0.3秒で長すぎますからね。
そうなんですよ、そうなんですよ。0.3秒はもう本当に支持したいラインとかっていう世界ですからね。
そう考えるとOSとかとは全く違う世界。
そうそうそう。
この辺はみんなが失敗した例外ハンドリングについてしゃべるとめっちゃ楽しさがあるんだろうなと思いながら読んでましたね。
次のどっか別のショー行きますか。
はい。