Vol.382

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

  • Facebookシェアボタンシェア0
  • このエントリーをはてなブックマークに追加ブックマーク0

■ 記事提供:『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の最新情報をお届けします
  • Facebookシェアボタンシェア0
  • このエントリーをはてなブックマークに追加ブックマーク0

RELATED POSTS関連記事

JOB BOARD編集部おすすめ求人

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

  
 @type新規登録キャンペーン
記事検索


アマゾン ウェブ サービス ジャパン株式会社 クラウドサポートエンジニ…

アマゾン ウェブ サービス ジャパン株式会社 クラウドサポートコンサルタン…

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

株式会社ドワンゴ【ポジションマッチ登録】 オープンポジション

日本アイ・ビー・エム株式会社 IoTエンジニア/コンサルタント■IoT技術で…

株式会社トラスト・テック【東証一部上場】 テスト・実験エンジニア(自…

株式会社スタッフサービス エンジニアリング事業本部(リクルートグルー…

株式会社 新興技術研究所 機械設計/CAD知識を活かせる/実務未経験歓迎/海…

株式会社 新興技術研究所 電気制御技術スタッフ/実務未経験歓迎/年間休…

株式会社トラスト・テック【東証一部上場】 CADオペレーター/未経験者歓…

英文メールでよく見る「略語」の意味は? 海外エンジニアに聞い...

データアナリストになる方法~コンサル型かエンジニア型か?ビッ...

「クオリティー最優先」 CygamesのCTOが説く“ヒット...

大手ゲーム開発会社から、「VRに触れる」デバイスのベンチャー...

Xcodeの使い方~Swiftからはじめるアプリ開発の基礎【...

>>過去のエンジニアtypeのページはこちら