ReadWrite Japan 第160回

出来る開発者の酷いコードとのつきあいかた

ただの一行も酷いコードを書いたことがないというのは可能性としてあり得なくないはないが、実際にはとても考えにくいことだ。現実には、貴方自身も他の開発者と同じくセキュリティ欠陥を作ってしまったりUIの配置ミスなどをやってしまうことだろう。何もあなたがだめな開発者だからというわけではなく、人間である以上仕

ReadWrite Japan

2015年8月31日 15:00

大混乱を前提に考える

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

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

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

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

以上はインフラの向上のために良い手段だが、コードの方はどうだろうか？

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

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

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

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

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

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

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

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

例えば家にさらにスペースが必要になったとする。そこで二階部分をつくろうと思うのだが、そもそも家が端からその様にできていない。設計からして無理であり、そもそも家の荷重を支えている壁がどれなのかを貴方自身分かっていない。出来る事といえば出来るだけの当て推量で二階を作り上げ、実際に上がってみて崩れないことを祈ることくらいだ。インフラの重要な部分を担っている多くの古いソフトウェアシステムはこんな事を繰り返している。その時は動くかも知れないがレイヤーを重ねる毎に脆弱性も追加される。まるで地震が多い所で無計画にスラムが作られていくようなものだ。

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

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

関連記事：

Matt Asay
[原文]

※本記事はReadWrite Japanからの転載です。転載元はこちらをご覧ください。