キャリア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編集部おすすめ求人

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


記事検索

サイトマップ



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

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

株式会社アドバンスト・ネット 【初級エンジニア】IT未経験大歓迎★100%…

株式会社 フォーラムエンジニアリング 【社内SE】大手メーカーIT部門募集…

株式会社コロプラ【ポジションマッチ登録】 オープンポジション

株式会社 フォーラムエンジニアリング 【テストエンジニア】未経験歓迎◆…

キャル株式会社 機械・電気設計/未経験OK/残業月10h以内/年間休日125…

株式会社 フォーラムエンジニアリング 【設計開発】大手メーカーの最先…

株式会社 リープエムケイ ハードウェア設計/経験浅めOK/5G(次世代無線通…

伊藤忠マシンテクノス株式会社 サービスエンジニア【技術職】

【hey佐藤裕介】天才と呼ばれた男が、20代で経験した挫折か...

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

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

日本のエンジニアが”作業者扱い”から脱するために起こすべきア...

フリーランスエンジニアに聞く、最速で「時給5000円以上」人...

TAGS

「type転職エージェント」無料転職サポートのご案内 エンジニア転職フェア開催 IT&モノづくりエンジニアを求める優良企業が大集結!