Google SRE Book と Go
これを読んでわかったが Google は人間を信頼性の低いパーツだと思っている。
悪い意味ではない。
人間は動作が不安定で簡単には変えが効かずコストが高いので大切に扱いつつ、できるだけ人間の手が必要ない自律したシステムを作ることでうまく巨大なシステムを運用しようとしている。
大切に扱っているという部分が面白く、たとえば障害対応は持ち回り制にしましょうとか、24時間対応できるようにタイムゾーンを分けて複数のチームで障害対応を担当しましょうとか、障害対応中であっても引き継ぎして帰れるように状況は共有しながら対応しましょうとか、障害報告書には誰かを責めるような書き方をしないようにしましょうとか、当たり前っぽいけど合理的でシステムを運用したことがあれば自分もこんな環境が欲しかったと思わせるような内容が書いてある。
システム運用には「手動・自動・自律」というフェイズがあるとしており、手動は完全に人間が運用するもので、自動はスクリプトなどにより作業を自動化したもの、自律はシステム自身が状況を監視して適切な運用をするようにしたものだ。
巨大なシステムを手動で運用するのは無理がある。手動や自動だとシステムの大きさに合わせて人を増やす必要があるが人はそう簡単に増やせるものではない。信頼性を上げるためだけではなくシステムを大きくするためにも人の手を離れた自律した状態にするということは必要になるのだそうだ。
Google は人間の弱さを認めてそれをいかに克服するか、あるいはいかにコントロールするかということをやっている。
その観点から Go について見ると面白い。
Go は仕様の小さい言語だ。
クラスは無いし継承もない。例外もないしジェネリクスもない。
この機能があると便利だなと思うことは実際あるが、この機能がないと絶対実装できないと思うことはあまり無い。
むしろある処理を実装するのに一つの方法しか用意していないという状態は、書くのにも迷わないし誰が書いても同じようになり読みやすいのでストレスが小さくなる。
複数人で開発をしていてもやっとするのは微妙に不適切な実装をされたときだ。
一応それでも動くけれどもそれただ最近おぼえたであろうその機能を使いたいだけなんじゃないの？もっと単純に実装できんじゃないの？みたいなときは指摘しづらいし指摘しても微妙な空気になったりすることがあるのであまり嬉しくない。
言語仕様が小さいとそもそもそういうブレが少なくなるので嬉しい部分がある。
また、言語仕様が複雑だとその言語で作られたソフトウェアも複雑になりやすい。
もちろんそれは実装する人次第ではあるけれど、おれはいいけどおまえは使いこなせないからこの複雑な機能使うなとかは普通は言えない。
コーディング規約で縛って機能を制限するとかもできると思うが、それならそもそも仕様が単純な言語を使ったほうが簡単だと思う。
例外とか使っていていつも使いこなせている気になれなくてこれでいいのかなーとか不安な気持ちだったし、継承とか他の開発者が適当に使っていてつらい気持ちになったことが何度もある。
いろいろな機能がある方が書きやすいのは当然だが、Go は「どうせ複雑なものは人間には扱いきれないでしょ」っていうことで人間がコードを書きやすくなることよりも機能を絞ってソフトウェアの信頼性を上げることを選んでいるのだと思うし、自分もそれに心地よさを感じているところをみると自分で思っているよりも大したことないんだとわかって謙虚な気持ちになったりした。
