良いプログラムの基準
第2章いきますか。 第2章が。 プラグいいプログラムとは何か。
これなんか、今でもみんな、いいプログラムって何だろうっていうのは、結構喋ること多いですよね。
これはでも本当にマシンパワーとか、いろんなものの進化によって、いい悪いが変わってきますもんね。
この当時でいけば、もしかしたらデバッグしやすさとか、実行するまでに何が起きるかが想像つくことの方が価値が高いけど、
今の我々においては、全然PHPユニットのテスト回しまくればいいんじゃねみたいな、そうすれば挙動がわかるみたいなことができたりするんで、
全然前提が置かれてる環境が違えば、良いっていう評価基準も変わってくるなっていうのは思います。
あと、もっと端的なところで言うと、メモリが8KBしかないときのいいプログラムとかいいアルゴリズムと、今の状況だと全然違いますからね。
メモリを節約するために頑張ってイールドで書きましたって言ったときに、いやイールドの挙動知らないんだけどっていう人が多すぎると、
これ何をやってるんですかってなって、これを読解する方が難しいです。結果、認知コストが高いですみたいになってしまったりすると、やっぱりそれはそれで良くなかったりするから。
そうですね。認知的負荷みたいなものが結構最近のチームワーク重視みたいなプログラミング環境だと重視されるんじゃないかなみたいな。
思えば違いますね。
そうですよね。だからチーム全員がアレイカウントバリューズとかっていう関数を息を吸うように認識してれば使えばいいし、
そうじゃなかったらフィルターとカウントとかやったり、普通にループで数減ればみたいなことかもしれないし。
この本の中でいいプログラムみたいなことで取り上げてるのが面白いのが、まず仕様を見出すプログラムですみたいな話が出てきたりとか、
あとスケジュール間に合うかどうかとかね。効率性か、脳機に遅れたプログラマは価値がなくなる場合も多いみたいな話があって、そこは前提じゃないんかいみたいな気持ちになりながら。
コンパイラーの効率
要求を満たさなければ何でも書けるって言ってる人ですからね。
あと適応性っていうキーワードも出てきたりとか、あと効率みたいなところ。効率がいいプログラムみたいな話っていうのは、原来においても基本的にはやっぱり効率がいい方を選びたいよねっていう話はやっぱりありますよね。
おだしょー 効率はこれはどっちの効率ですかね。生産効率なのか、システムパフォーマンス的な。
おだしょー ここではシステムパフォーマンスかなと思いましたね。 コンピューターの実行時間って言ってるか。
おだしょー 現代でいうとNプラス1みたいなのがあったら、ちょっと処理が遅いよねみたいな。いくいこの処理は早いんだろうけど、期待してる処理の実行時間は長いから、やっぱ良くないよねとか。
あとバッチとか書いてると、時間の上限がある種ない、レスポンスタイムが500ミリセックを切るようにとかっていう話とはちょっと変わってくるんで、ちょっと時間長くてもいいかなとかってやり始めると、だんだん対象の件数が増えていったときに、あれこれ1日超えますねみたいなことが起きて、後で痛い目を見るみたいなこととかは、現代においても多分あるはずなんで。
おだしょー でもね、楽に処理詰め込みすぎて、なんかめちゃくちゃ短いクエリがデータベースに乱発してるぞみたいな。さっきのNプラス1の話とかに近いかもしれないし。自社のデータベースならいいけど、外部サービスにすごいDOSみたいなことしてるねーとか、やたらしんどいみたいな。
おだしょー ありますねありますね。なんかプッシュ通知の送信とかってリアルタイムでやりたいよねって思うけど、AppleとかGoogleとかのサーバーの捌けるスキルって本当すごいんだなとか思ったりとかね。
おだしょー そうなんか、一個メッセージ入れれば後はAWAさんとかAppleさんとかGoogleさんがばらまいてくれるんやって思ったら、逆にそのプッシュ通知で起動されすぎて、うちのAPIサーバーが起こたないみたいな。
おだしょー はい、ありますね。アプリが起動した瞬間に大量のリクエストがやってきて、お、なんか負荷がめっちゃ上がったんだけど、なんだなんだって言ったら、自業自得だったみたいなとかね。よくありますね。
おだしょー 面白いですよね。 回り回って自分のとこにめぐってくるっていう。
おだしょー 面白いですよね。その人間っていう生身の枠体を挟んで完全に分離されてるサブシステムのはずなのに、そこら辺もトータルでデザインしないと、やっぱりソフトウェアとかサービス作りって難しくなるよねっていうのは非常に面白い。
おだしょー いやって、リアルイスコンはなるべくやりたくないっていう、ありますからね。
ありますね。リアルイスコンやるとすぐ、とりあえず今日は全部を満たさなくても問題を捉え方を変えて、なんか捌けたらOKにしようよとか。
スコアが上がることではなく騒げて、後にじゃあこれはクーポン配ってごめんなさいしましょうよとか。なんか別の方向に逃げたくなるみたいな気持ちになるんだよ、ああいうのを見ると。
あとあれかな、この第2章だと僕結構、なるほど面白いなって思ったのが、ちょっとメモ入れ忘れてたんですけど、26ページに書いてある一節で、ソース言語のわずかな違いがコンパイラーの効率に驚くほどの影響を与えることがあるって書いてあって。
コンパイラーの話云々っていうよりかはその次が面白かったですよね。一般的にコンパイラーの作者が言語仕様の10%を実装しないことに決めた場合、コンパイラーは50%早くなる可能性がある。
ところがどの10%を選ぶかはマシンによってもまたコンパイル技法によっても異なるため、言語設計者は単純にどのサブセットを実装するのがより効率的だ、などということはできない。
って書いてあって。なんかこの8人とかじゃないんですけど、20%切ったら80%以上効率が上がるとか楽になるみたいな話とか。
逆にそこまでカバリッジを上げようとするとやたらつらいとかって話は。パフォーマンスって意味での効率もそうだし、生産とか開発実装って意味での効率もそうだし、なんかここはなかなか面白いなっていう気がしましたね。
50年前も同じこと言ってるんだなって気持ちになりますね。結局ソフトウェア開発やってると、なんか大体のケースはこれでいいんだけど、そのエッジケースのために結局開発頑張るみたいな。
設計の重要性
なんか今日もプロスタイプで大体動くみたいな、ユーザーの一般的な用途の部分は動くように作るっていうのは1日2日でできるんだけど、これちゃんと作ろうとしたらあとどれぐらいかかるかなって見積もにしたら2週間ぐらいかなみたいな話になって。
みたいな気持ちになりながら、なんかもうほぼできてるように見えるんだけどなーみたいな気持ちになりながら、でもあれやこれや考えたりとか、もうちょっと長期的に使われると、ライフサイクル考えるとデータが消えてる場合があるよねとか、そういうようなこと考慮し始めると、やっぱり実装コストがどんと跳ね上がるよねみたいなことをちょっと思ったりしましたね。
だから今も結局この10%を実装しないって決めれたらもっと早くできるんだけど、それは許されないんで頑張って作りますみたいなことはやってるなって思いましたね。
なんかねー難しい、そこですよね難しいの。やっぱりトレードオフをどう捌き切るかみたいな話だと思うんで。
こういう勇気を持ってユーザーに不便だなって思ってもらってもいいじゃんって言えるとか、なんか別な手段によるリカバリを用意するとか、それは多分運用でカバーみたいな話だと思うんですけど、そういうようなこととかに割り切れると楽になったりするんですけど。
運用が大変になったら元も子もないので、そうなるとやっぱりちょっと手厚くHKSは対応しときましょうみたいなことの方を考えた方がなんだかんだトータルで得だったりするなっていうことが多いですね。
あとはちょっとこの2章を読んでて、これを読んでて良いプログラムっていうところと連想して、良いっていう反対は悪いだと思うんで、悪い方が良いっていう話があるじゃないですか。
なんかあれをちょっと想起したりもして、この悪い方が良いってやつはどう説明するといいのかなっていうのはあるんですけど、ちょっとティーワダさんの資料にその辺が書いてあって、こうまとめてるみたいなあったらちょっと引用すると、
悪い方が良いってやつは設計の正しさ、美しさと実装の単純さが対立する。両立できないときは実装の単純さを選択した方が、たとえそれが漏れのある抽象になったとしても現実の問題解決し、実装の単純さによって開発参加のハードルが下がり、協力的な強さを獲得できるっていう風にティーワダさん予約してくれたりしてるんだけども。
この書かれた当時は多分コンピューター資源がないとかで、設計の美しさとか正しさと単純さみたいなところのソレドフっていうものがあんまり目立たなかったのかもしれないけど、現代においていいプログラムでいったときの良さみたいな解釈の仕方の中には設計の正しさとか美しさ、本当はこうなってると使い勝手はすごくいいんだけど、
それを複雑さをここに押し込めようとすると難しくなり、結果実装が単純にならないから、後でそれをメンテする人がしんどくなったりとか、オープンソースのものを開発するために外から入ってきた人が最初にまずこれは特別な仕様があってみたいな、理解をするのがとても難しくてハードルが高くなってしまうみたいな、
いう部分とかがあるっていう話はやっぱりこの当時ではなくて、現代においてはこういうような話っていうのもあったりするよなっていうのをちょっと連想したりしましたね。
まあだから一貫性、コンピューターリソースに関しては本当に恵まれてますからね、50年前に比べると。50年前と比べるとめっちゃ恵まれてるはずなのに、じゃあ何でもできるじゃんっていうと、できないと。
で、それなんでできないんだっけって考えると、やっぱり変更を加えようとした時に人間が壊すからな気がするんだよね。
そうですね。
ワース・イズ・ベターみたいな話聞くと、僕結構想起するのが変更が何か発生した時にちゃんと壊れる方がいいよねっていうような気はしていて、
フェイルファーストのような、それそうじゃないような感じの話なんですけど、要するに無理やり再利用できちゃうモジュールよりかは、
プログラミングの変更可能性
いやちょっとそんな要件の変更は想定してないので使わないでくださいって自分から語ってくれるコードの方が嬉しいんですよね。
使えないから、つまり元々想定されてた用途から外れてるのか、じゃあリファクター仕様ってなるかもしれないし、
ここに共通性を見出して注釈するって考え方自体が誤ってるんだなっていう風な学びになるかもしれないし、
なんかそんな感じで何でもかんでもできちゃう高機能よりかはすぐに壊れるよねっていう方が、何もしてないのに壊れるのは嫌なんですけど、
何かしようとしてるんだな俺今っていうのを教えてくれるやつは素敵だなっていう気がしてますね。
型による表明とかもそれに近いっちゃ近いんですけど。
結局シンプルVSイージーの話になったりとかしていくんだろうなとか、結局継続的にメンテされるとか長期的に生き残るためには、
LinuxのUnixのコマンドみたいに席目が小さいとか、それを組み合わせていろんな表現豊かなものができるとか、
そっちの方向に行った方がいいよねみたいな話がよくされるし、現代にも言ってもそうだよねっていう風に結構思ったりしますよね。
この本でいうと変更可能性みたい、変更が起こる可能性っていう意味でも、変更がしやすいっていう意味でも、
ダブルミーニングの変更可能性みたいな話で言うと、まとめです。第2章のまとめ28ページに、
良いプログラムとは何かの重要な要因をいくつか挙げてみようっていう感じで過剰書きというか、4つ書かれてるんですけど、
状況が変わった時にプログラムを変更することは可能か、変更にどれくらいコストがかかるかっていうふうに書かれてて、
なんかここ結構面白い問いだなーっていう気はしてて、僕の今の話だと変更が起きない方があまり信用できないなっていう気はしてるんですよね。
変更しないでそのままずっと使えます、ちゃんとオープンクローズドにして不要な変更が起きないようにしようは同意なんですけど、
今言ったら何でも使える、何でも受け付けて何でも吐き出せるみたいな関数作っちゃうと、確かに変更はされないですけど、
無理やりな共通化が起きちゃうなとか、変な採用による欠乏が起きちゃうなっていう意味で、変更のコストは低いけどすごい危うくないみたいな気はしていて、
だからこの変更にどれくらいコストがかかるかって聞かれたときに、コストがかからない方がいいプログラムだっていうとなかなか違うなっていう感じがして、
でもそれって今、無意識に僕らが思ってるプログラミングっていつでも修正してデプロイしてリリースできるみたいな話があるから、困ったらいつでも変更しちゃおうぜっていうマインドセットが今の時代と、
この50年前、一文字修正するだけでパンチカードとかやるために何人も関わって一晩待たなきゃいけないってターンラウンドって言ってましたけど、待ち時間がめちゃくちゃ発生するっていう世界観だと様子が違いそうだなと思って、ちょっと面白いなって思いました。
そうですね、あと今の近所さんの話聞きながら、状況が変わったときに変更できることと、それが継続してメンテできるとか、そのタイミングでは変更できるかもしれないけど、その後もさらに続けて変更できるかどうかっていうのはまだちょっとあるよねと思って、
イフ分1個増やせばすぐこれは対応できるんだけど、それをやった結果、その後もう1個追加しようとしたらもう1個イフ分が増えてとかってやっていくと、長期的には変更コストがどんどん増大していくんで、ちゃんとここはオープンクロスになるようにちょっと早めに抽象化して切り出しておきましょうかねとか、インターフェースによるちゃんと制約をつけておきましょうねとか、
DIC振る舞い変えられるようになるといいよねとか、そういうようなことを考えないと、現代においてはとてもとても辛いよねって思ったりするんで、ここでいう変更可能性みたいな、どれくらい簡単に変更できるかみたいなコストが安いかっていうのは、長期的にちゃんとそうできるかみたいな風に捉えておかないと、
こんなイフ分足したら終わりますっていう話になっちゃうんで、そう捉えるとちょっと危ういなっていう風に思ったりしましたね。
プログラミングの研究方法
この見極めも難しいんですよね。ここはイフ分で押し切れるんだみたいな判断がなくはないので、逆にここはゴミ箱みたいにイフ分が集まる場所ですっていう風に見えていればね、いいんですけど。
だからこそやっぱり良いプログラムって何なんだろうかって考えた時にやっぱり難しいんですよね。一概にこういう評価軸でこれを満たしてたらOKっていうことが言えないっていうのが難しいなって思いますね。
そうなってくるとやっぱりスケジュールの話とかってすごい関わってくるなと思ってて、要するに半年で使い捨てされるプログラムにおける良いコード、良いプログラムと、
これはバージョン2、バージョン3っていう風にずっと長年使い続けていくんですってなった場合に、やっぱりその時間軸的な見方によって良い悪いって変わってくると思うので、スケジュールって聞くとやっぱりリリースするまでとかプロジェクトがいつ終わるかみたいな話を強く想起しますけど、
なんかそれ以外のところでもすごい時間軸的な価値観っていうのが関わってくるなってちょっと思いますよね。
そうですね。なんか本当に書き捨てのGoogle Apps Scriptとプロジェクトで使うコードは全然違うし。
意外と生き延びるでおなじみのGoogle Apps Script。
気づいたらあれ便利だったんだけど、メンテできる人があれ退職しちゃって、みたいなことは往々にしてあったりしますね。
でも第2章がそんな感じ。一応第1部はあと1個だし、全部触れていきますか。
触れていきますか。
第3章、プログラミングをどのように研究するかですね。
うーん、
どういう風に研究するんやというのは、
いまいち社は現代においてこれが繋がっている部分はどうかなとかって考えたけどちょっとあんまり、「うん、うん。」みたいなことを思って、
なんかやっぱりちょっと今の中に近いんじゃないかなーみたことを思ったりしましたね。
そもそもここで言ってる研究って何ぞやみたいな話が必要ですかね。
そうですね。
品質を可視化しよう、定量化しようとか、生産性を比較しようみたいな、
ああいうソフトウェア工学って言われるような分野にタッチするような意味での研究ですかね、ここで言ってるのは。
そうですね。
ソフトウェア工学ってこの時代ないのかな。
いつできたんですか、あの分野。
これいつできたのかね、ちょっと分かんないですね。
パッとは。
パッと分かんないですね。
あれでもソフトウェア機器。
でも70年、69年とか70年くらいなんで。
でも1961年って書いてあるな。
NASAに関連したプロジェクトが進展していく中で、ソフトウェア工学って言葉が生まれたってことなのかな。
それになんでそんなこと言い出したかっていうと、第3章の扉、扉じゃないか、1ページ目で、
なんか、なんて言ってたっけな。
プログラミング、ちゃんと研究。
プログラミングというコードは複雑すぎて研究できないのだろう、的なことが書いてあって。
でもソフトウェア工学って研究してないと思ったんですよね。
でも違うか、正しがきがあるのか。
プログラミングが人間の行動の位置形態っていう切り口観点からプログラミングが研究された例はほとんどないって書いてあるのか。
人間の行動として見ようとした時にあまりにも複雑な生産活動すぎる。
だからそもそも研究しようと思われてないんじゃないか的な立場ですね。
だから多分アウトプットとして出てきたコード自体を研究対象とすることはできるけど、
そこでどういうふうに考えてそれを書いてるのかとか、
なんでミスが起きてしまうのかとかみたいな部分っていうところは、
人間側のほうのアプローチが足りてないんじゃないっていうのが疑問っていうか提言っていう感じですかね。
課題意識ですね。
だから工学的なアプローチっていうよりかは社会科学者がやってるようなアプローチで見ていこうぜっていうようなことをこの章で言っていて、
例えば内省をしてみようとか観察をしてみようとか、実験をしてみようとか的なことが書いてある。
そうですね。
社会学好きですよね今。
でもやっぱそっち側に行かないとわかんないなって思ったんですかね。
そうね。プログラミングの調子が良い日悪い日みたいな話もこの本でしたよね、出てたの。
ありましたね。
調子が良い悪いは医学的な感じで科学としてアプローチできるかもしれないけど、
どっちかっていうと社会科学とか産業心理学とかそっち側っぽいよねっていう気はしますもんね。
そうですね。
この辺で面白かったのが、観察するのはいいが気をつけないといけないよっていうので放送効果ってやつがあって、
見られてると人はちゃんとしようとするから、ちゃんとしたデータが取れないよみたいな話とかいうのも気をつけましょうねみたいなのがあって、
それの延長線上で観察しようと思って、ワインバーグがレビュー会に参加したらみんなすごくいいレビューがなされて、
なんかこのレビューすごい機能してるじゃんみたいになって、結果ワインバーグの答申台の写真を毎回そのレビューの場に用意すると、
その後もうまくいきましたみたいな話が出てたりはして。
これ面白かったですね。
あのコンサルタントが見に来たぞって言うと、みんな真面目にレビューとか会議するから、あれなんか話に聞いてたのとちょっと違う気がしますよね。
っていうワインバーグが思ってよくよく観察というか調査してみると、あ、俺がひたからだったんだ、じゃあ俺の答申台のパネルあればよくないんで。
フィードバックの重要性
だからあれですかね、今の我々で言うとTバダさんがレビュー会に参加したら、たぶんちゃんとテストも書かれるしさみたいな感じになって、うまく機能するみたいなそんな感じですかね。
そうですね。
どうなんですかね、生産的な会議とか意味のある身のあるレビューができたよねっていう体験を想起させるトリガーに答申台パネルがなったみたいな話なんですかね。
そうだから今で言うとリモートとかの会社だと一人Tバダさんのバーチャル背景としてTバダさんとか置いて、って参加するだけで。
アバターをTバダさんにくれば。
確かに。
効果あればかな。
まあでも、実際に一回Tバダさん来てくれた時のミーティングの経験があった後だとうまくいくんですかね、まあそれが当たったらきっと。
なんかそれはありそうですよね、思い出すためのものとして。
じゃないと何が正しかったんだっけ良かったんだっけみたいな経験がないままやってるといつも通りになりそうですね。
あそこにいるTバダさんのことですかってなっちゃう。
そうですね。
あそこから近づいてくるTバダさんのことですか。
いつものことになり見に入って次の行動が何もされないっていう。
なんかこの辺の研究って最近あるのかなーみたいなことをちょっと考えたりもしたんですけど、
なんかやっぱ自分が知ってる例はそのアウトブットの生化物に対するアプローチみたいなやっぱり工学的なアプローチみたいなところがやっぱ知ってるものがあるなーって感じで、
どちらかというと多分チームワークとかそういう系の研究とかの方が近そうだなーって思ったりとかもちょっとしたりしましたね、現代だと。
何でしたっけ、フォーキーズの元ネタになってたやつ。
リンとデボームスの科学のチームというかプロジェクトか。
プロジェクトアリストテレス。
行き過ぎだな。ドーラ?
ドーラ、はい、ドーラ。
なんかあそこら辺は本当に工学的な感じですよね。社会学なんだろうけど。
ドーラとかやっぱりどういうケーパビリティを備えてるかっていう話を見てたって感じですよね。
これでもあれですね、今話してて思ったけどこのワインバーグが、この本というか第3章で言ってるのは、
プログラミングをどのように研究するかっていうのは、何を研究してるんですかねっていうと、プログラミングとそれに関わる人間なんですけど、
何をゴールとしてるというか、どういう基準で比較して良い悪いっていうのを言おうとしてたんだっけって書いてありましたっけ。
そこはいまいち自分はわかんなかったな。
まあでもプログラミング、生産活動とか、そこに関わってもチームないし人間の能力を上げるために何か分析したり研究しましょうって思った時にはこういう話をしっかり意識しておく必要があるよねっていう感じなのかな。
そうですね。振り返ってた方とかでもやっぱり研究のコストが高いとかいう話も、価値は重要であるがコストが高いよねとかいう話も出てたりするし、
現代において人間の方のアプローチもするけど、仕組み化みたいなところの方がより強くあるような気はしていて、そっち側を研究した方が効果が高いっていうところで現代においてもあんまりこういう行動科学的な分野のアプローチよりも
ミスをしない、そもそもミスをしないような仕組みを作った方がいいよねみたいな、ここに行っちゃったんだろうなという気がしますね。人間変えるより仕組みを変えた方が楽ですからね
楽ですし、仕組みを変えるだけでやっぱり保存効果を得られるんで。照明をちょっと明るくしてみましょうだけでいけるはず。照明を消すでも良いし。
そうそうそうそう。なんかやってると変更すると人間が普通に慣れてて上手くいってしまうみたいなことの方がやっぱ効果が高いんですよね。
あとそっか、第三章振り返って言うと最後の方に入れてる文化っていうものが非常に大事だよねっていうところにこのプログラミングの心理学書いた後にワインバーグ自身がすごい深く気づいたというか
単純に深めていって、ソフトウェア文化を作るシリーズとか書いたりしたよっていう風なことが書いてあって
ワインバーグ好きの人は若くはないかもしれないけど、昔のちょっと前の時代のワインバーグの進化しきる前というか、探るためにちょっと面白い本かもしれないですね。
プログラミングの心理学と文化
そうですね。
そんな文学部みたいな読み方するの?っていう感じだったけど。
この作家を初期から初期中期後期を全部読んで、どういう平成を辿ったかみたいな。
第2部いきますか。
いきますか。
