MTI1MTAxMjM0OTgwOTc0NTYy_0
Pocket

ただの一行も酷いコードを書いたことがないというのは可能性としてあり得なくはないが、実際にはとても考えにくいことだ。

現実には、あなた自身も他の開発者と同じくセキュリティ欠陥を作ってしまったりUIの配置ミスなどをやってしまうことだろう。なにもあなたがダメな開発者だからというわけではなく、人間である以上しかたがないことなのだ。

開発者たちはみな人として仕方のない弱点を抱えていることから、「最高の開発者」と呼ばれる人々は自分が作るコードやインフラで起こりうる最悪の事態を想像し、それに備えている。以下、最高の開発者たちがおこなっていることだ。

 

大混乱を前提に考える

数年前、Netflixが「Chaos Monkey」およびクラウドベースの管理ツール「Simian Army」の一部をオープンソース化した。かいつまんで言うと、Chaos Monkeyは、AWSインフラで幅広く動いているインスタンスをランダムで終了するものである。これは起こりうる最悪のシナリオをつくり上げることでそれに備える1つの方法だ。

Netflixのコリー・ベネット氏とアリエル・ツェイトリン氏は、リリースの際にブログで次のように書いている。「障害は発生するものであり、思ってもみなかった最悪のタイミングで起こることは避けようがないことだ。もしあなたのアプリがインスタンスの障害に対処できない場合、夜中の3時に呼び出されて問題が起こっていることがわかり、会社で徹夜明けのコーヒーを飲む羽目になっていいのだろうか?」

予想もしない形の障害をシミュレートすることで、Netflixのインフラは回復力を得ている。上手くいっているパターンではなく、「ダメなパターンを想定する」ことでだ。その結果、我々は障害に悩まされることなくネットTVを観ることができている。

 

最高のプログラマによるテストとは

先ほどの話はインフラ向上のためにはいい手段だが、コードの方はどうだろうか?

ある有名なプログラマー、ジェフ・アトウッド氏が述べていることは上記とさほど変わらない。「Do terrible things to your code」で彼は次のように書いている。

私はあらゆる職業プログラマにとっての重要なターニングポイントとは、最大の敵は自分自身だと考え受けいれ、これこそがこのリスクと向き合う唯一の方法だと気付けるかどうかだと考えている。あたかも自分自身が最悪の敵であるように、UIやコードを無茶苦茶にしてみたりすることだ。

これは、「プログラマは少なくともよくあるミス、一般的なプログラマが起こしがちなミスについて十分な知識を持っている必要がある」という意味になるだろう。つまり、あなたが“神レベル”のプログラマであるためには、ソフトウェアに無茶苦茶なことをやらせて積極的にエラーを掘り起こせる、“神レベル”のテスターである必要もあるということだ。

これにアンドレ・メデイロス氏は、プログラマ自身だけでなくデバッグも同様の姿勢をとるべきだと付け加える。

「バグを起こさないためにも、コードはプログラマの誰が見てもわかるように書かれなければならない。バグの修正の際は自分のコードについてきちんと理解しなければならない。高い精度で自分のコードを理解するために、仮定を並べ上げて検証する。 必要であればデバッグ用のツールを作るべきだ。」

 

コードに積み上がっていくスラム

他から多くのコードを引き継いでいるというのも、我々が抱えている最大の問題の1つだ。特に社内ソフトなどはレガシーコードの上に成り立っており、多大なマイナス要因となっている。

ゼネップ・トゥフェクシ氏は以下のように述べている。

たとえば、家にさらにスペースが必要になったとする。そこで2階部分をつくろうと思うのだが、そもそも家のつくりが2階立てに耐えうるものではない。設計からして無理であり、そもそも家の荷重を支えている壁がどのようなものなのかをあなた自身がわかっていない。できることといえば、できるだけの当て推量で2階を作り上げ、実際に上がってみて崩れないことを祈ることくらいだ。

インフラの重要な部分を担っている多くの古いソフトウェアシステムは、こんなことを繰り返している。そのときは動くかも知れないが、レイヤーを重ねるたびに脆弱性も追加される。まるで地震が多いところで無計画にスラムが作られていくようなものだ。

こういった過去の負債が撤去できるわけでもない限り、問題に対して我々ができることもあまりないのは明らかだ。

しかし、あくまで可能性だが、コードに対して「無茶をしてやろう」という取り組みが、過去の負債を取り除くことの重要性を明らかにする可能性はあるかもしれない。

Pocket