キャリアVol.393

デキる開発者は「酷いコード」とどう付き合っているのか?

■ 記事提供:『ReadWrite Japan』

本記事は、ワールドトップ20ブログの一つにも選ばれている米のテクノロジーブログメディア『ReadWrite』の公式日本版、ReadWrite Japan(リードライト ジャパン)から転載したものです。同サイトと弊誌の相互コンテンツ掲載契約の一環となります。

デキる開発者は「酷いコード」とどう付き合っているのか?

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

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

開発者たちは皆、何かしらの弱点を抱えているものだ。だから、最高の開発者たちは自分たちが作るコードやインフラで最悪の事態を想像し、それに備えている。

以下が彼らが行っていることだ。

大混乱を前提に考える

数年前、NetflixがChaos Monkeyおよび、クラウドベースの管理ツール、Simian Armyの一部をオープンソース化した。かいつまんで言うと、Chaos MonkeyはAWSインフラで幅広く動いているインスタンスをランダムで終了するものだ。

これは、起こり得る最悪のシナリオをつくり上げることで、それに備える1つの方法だ。

Netflixのコリー・ベネットとアリエル・ツェイトリンは、リリースの時にブログで次のように書いている。

障害は発生するものであり、思っても見なかった最悪のタイミングで起こることは避け様がないことだ。もしあなたのアプリがインスタンスの障害に対処できない場合、夜中の三時に呼び出されて問題が起こっていることが分かり、会社で徹夜明けのコーヒーを飲む羽目になっていいのだろうか?

予想もしない形の障害をシミュレートすることで、Netflixのインフラは回復力を得ている。上手く行っているパターンではなく、ダメなパターンを想定することでだ。

その結果、我々は障害に悩まされることなく、ネットTVを観ることができている。

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

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

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

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

このことはつまり、「プログラマーは少なくともよくあるミス、一般的なプログラマーが起こしがちなミスについて十分な知識を持っている必要がある」という意味になるだろう。

つまり、あなた神レベルのプログラマーであるためには、ソフトウエアに無茶苦茶なことをやらせて積極的にエラーを掘り起こせる、神レベルのテスターである必要もあるということだ。

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

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

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

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

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

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

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

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

文/Matt Asay原文

この記事が気に入ったらいいね!しよう

エンジニアtypeの最新情報をお届けします

RELATED POSTS関連記事

JOB BOARD編集部おすすめ求人

この記事に関連する求人・キャリア特集


記事検索

サイトマップ



日本マイクロソフト株式会社 【マイクロソフトサポートエンジニア】トップ…

日本マイクロソフト株式会社【ポジションマッチ登録】 オープンポジション

株式会社富士通エフサス【ポジションマッチ登録】 オープンポジション

i Nations株式会社 【ITエンジニア】未経験からエンジニアへ!◆有給休暇取…

株式会社TAP プログラマ/完全自社開発/システム開発/5年連続110%成長…

ザ・パック株式会社【東証一部上場企業】 【生産技術エンジニア】未経験…

キリンビール株式会社 生産設備エンジニア/建築系・機械系・電気系エン…

DKSHジャパン株式会社 【サービスエンジニア】世界No.1シェアを有する…

ソニーエンジニアリング株式会社 [機械設計] ~ソニー製品の機械設計/機構…

株式会社東京ウエルズ 製造エンジニア*実務未経験OK*賞与9ヶ月分(過去…

「全てがコードで定義される世界の先頭を走りたい」DMM新CT...

メルカリがトップクラスのエンジニアを投入して「人事評価システ...

SIerって本当にヤバいの? ひろゆきが語る、業界ごと沈まな...

「新規プロダクト開発」成功の明暗を分ける6つのこだわり【及川...

「自律型ロボットで“物流”に魔法をかける」立命館大発ベンチャ...