ソース編「DIV病」とは、何事もやり過ぎると危険であることの代名詞である|#エンジニアあるある システム開発現場・実録IT用語辞典

【ソース編】「DIV病」とは、何事もやり過ぎると危険であることの代名詞である

お疲れさまです。プログラムを書く時にはいつも「ソースの行数は極力短く」と「処理速度は極力速く」の2つの意識を持つようにしています。が、書いている途中でいつも「処理速度を上げようとするとソースの行数が長くなる」とか、その逆の状況に出くわして、どっちを優先すべきとか、無駄に長時間悩んだりします。

システム開発では常にバランス感覚が求められます。あまり処理速度だけ追求し過ぎたり、行数だけ意識し過ぎたりしたソースは、読みづらかったり、パフォーマンスが悪かったりします。

2つの相反する命題を前に、ちょうど良いさじ加減で書かれたソースは、ほかの人から「読みやすい」とか「キレイ」とか言ってもらえますが、どちらかに偏り過ぎると「病的」と言われてしまったりもします。

今回はそんなシステム開発現場にはびこる「病」や「やっちゃった系」のソースに関する用語をご紹介します。

#エンジニアあるある 実録IT用語辞典【ソース編】INDEX

「DIV病」とは

HTMLを書いていると、いつの間にかソースがDIVだらけになってしまう病気。

DIVのブロックが、1つずつ整然と並んでいるだけなら良いが、複数のDIVの中にDIVが入れ子になって存在していると、どのDIVがどこで閉じられたのかさっぱり分からなくなって困るもの。

似たような病気として、昔はTABLE病というものが流行っていた。デザイナーが紙に書いたイメージを厳密に再現するために、細かくTABLEを入れ子構造にして、読んでみてもどういった構成になっているのかさっぱり理解できない複雑なタグを組み上げることになってしまう病気である。最近はTABLE病の勢いは衰えつつあり、DIV病のほうが優勢な気がするが、まだまだ十分に見かけることがある代物なので注意しておきたいもの。

複雑なレイアウトを実現させようとすると、どうしてもDIVやTABLEを多様することになってしまうことはあるかもしれないが、何事もやり過ぎると危険なので、双方を交えて可読性を上げたり、無理せずレイアウトをもう少し簡易にしたりすることで、解読の難易度が高過ぎるとか修正する時にどう手を付けていいかまったく分からないといった声が出るようなHTMLを生み出さないことが、切に望まれている。

「定数病」とは

ソース上に出てくるすべての数字や固定文字列を、定数として扱いたくなる病気。重度の症状になると、ダブルコーテーションで括られた文字列が関数内にいるだけで許せない気持ちになるらしい。実に恐ろしい病である。

定数というと、例えばDBのレコードの「論理削除」や「休止中」といったステータスをプログラム側で扱うために、コードを定数として保持しておくような使用方法をよく見かける。これをしておくと、当初「論理削除」のステータスは「1」に設定する予定だったのが、途中で「9」に変わるといった変更が生じても、定数だけを変えればプログラム側は対応できるようになる。途中でコードを変えるなという苦情は置いておいて。

上記のような例で使用する分には定数は便利なものだが、使い方を誤ると、
public static final char ASTERISK = '*';
public static final int ONE = 1;
のような、まるで英語の勉強のために書かれたかのような記述が生まれてしまうことがある。
※上記の例文はJavaを使用しています。ほかの言語をホームランゲージにしている方は、適宜読み替えてお楽しみください。

また、明らかにその場所で1回しか使わないであろう記述に対してもすべて定数を使っていくうちに、数千の定数が乱立して物凄く追い掛けづらいコードになったりすることもある。

「スパゲッティコード」とは

言葉だけ聞くとちょっとおいしそうだが、実際に遭遇すると非常にまずい事態に陥りがちなもの。

1つの変数が複数の用途で使い回されているせいで、1箇所に手を入れると全体に影響が出るとか、継承に継承を重ねに重ねて実装されている為に、いくら追い掛けてもロジックの全体が把握できない迷宮が構築されてしまっているなどの、複雑に入り組んだコードを指す言葉である。

スパゲッティコードの発生する代表的な原因は、単純なエンジニアの技術不足である場合が多い。それ以外には、以下の2つが挙げられる。
1つは既存のコードに改修を入れる際に「後先なんて考える余裕なんてない。最短工数と最小のリスクで改修……」という発想から小手先の改修をさまざまな人の手で繰り返すことによって、手が付けられないくらいの複雑な構成の出来上がりという緩やかな流れで発生する。

もう1つは、日々勉強中のエンジニアが、ちょっと凝った作りに挑戦しようと思い未体験の実装方法に挑戦したけど、途中で破綻してしまい、作った本人すら理解できない凄いものが出来上がってしまった、という形で発生する。

日々見かけるソースの中には、もしかしたらこれ、わざと難読化してない? とか、「俺のソースは誰にも触らせない」という意思でも込められてるんじゃないだろうかと疑いたくなるような、無事に動いているのが不思議なくらいの芸術的スパゲッティコードと出くわすことがある。
そんなソースを見かけた際は、極力触れずにそっとしておき、改修案件なども極力回避することが推奨されている。

「コピペ展開ソース」とは

既存のロジックと酷似しているけど、若干ルールが違うコードを書かなければいけない時に使用される。技術書ではよく「使うべきでない」とか「無作法」と言われている割には、現場では最もよく見かける実装手法である。

よく使われるだけあって、この手法にはそれ相応のメリットはある。

まず、既存のコードに手を出さずに展開できる為、修正後に発生するテスト必要範囲が狭く済む。
また、この実装方法はスキルや注意力がなくても実現可能である為、安心して任せられるエンジニアがいなかったり、終電続きで働き続けてもう考えるのも疲れたよ…… という精神状態になっていたり、納品まであと1週間という時期に機能追加を依頼されたなどの極限状態、大量の障害票とその対応に追われるうちに自分が書くコードが信じられないという自己不信状態に陥った時などは、この方法を選択するのも仕方ないかもしれない。

逆にデメリットとして、コピペした元のソースにバグがあった際に、そこから展開したソースすべてを修正しなければならなくなる。ロジックを共通化したり、テンプレートパターンを使って流れをまとめたりした場合に比べて、ステップ数自体が非常に多くなるので、ソースすべてを把握するのが難しくなる。その為、保守性や拡張性には欠ける。大量にコピペ展開されたソースを見てみるとエンジニアの心が萎えるなどが挙げられる。

「ソース上の誤字」とは

変数名を付ける際に英語の綴りを間違ってしまったり、コメントを書く際に妙な漢字変換をしてしまったりすることで発生するもの。

特に英語のスペルミスなどは、気を付けて2つ3つソースを読めば必ず1つは見つかるくらい登場頻度の高いものである。

人の書いたソースの中に誤字を見つけた時はちょっと楽しい気持ちになることもあるが、ほかの人から自分のソースに対して「この変数名、スペル間違ってない?」と指摘されると、ちょっと気恥ずかしい気持ちになったりするので、できるだけミスはしないように気を付けたいもの。

すでにリリースが終わり運用されているソースの中にスペルミスを見つけた場合などは、ミスを修正したことが原因でデグレが発生しましたという怖い事態を発生させる可能性もあるので、なかなか手が出せなかったりするもの。

でも、見つけたタイミングで勇気を出して直しておかないと、その誤字はシステムの中で末代まで残り続けてしまう可能性もある。

「10年前のソース」とは

せっかく作ったシステムが3カ月後には陳腐化し、1年後にはまったく使われない代物になっていてもおかしくない、ドッグイヤーという言葉がしっくりくる業界では、そんなに多くは見当たらないような気がする……、のはたぶん錯覚。

現場の端っこのほうでひっそりと動いているプログラムに目を向けると、想像していた以上にレガシーなソースが中身を誰も把握していないような状態で放置されていたりすることがけっこうあるもの。

10年も前のソースになると、現在ではアンチパターンとされているようなコードが詰まっていたり、逆に当時のコードにしか見られないようなトリッキーな書き方が見られたりして、読んでいると発想の転換になったり歴史の勉強をしているような気がして、割と参考になるもの。

「ガラパゴス現象」とは

日本の携帯電話市場に対して(主に皮肉や揶揄、叱咤などの意味を込めて)使われることがある言葉。

ガラパゴス諸島は赤道直下の太平洋に浮かぶ、どこの大陸ともつながっていない島で、熱帯なのにペンギンがいるなど、ほかの土地では見られないユニークな進化を遂げた生物が多く生息している。

その様子が、世界で使用されている携帯のプラットフォームとはちょっと違った進化を遂げているとか、日本国内では使われているけど国際的には残念なくらい競争力がないといった特徴を持つ国産携帯市場に似ているということで、最近よく使われている時事用語である。

ガラパゴス現象と呼べるような状況は、携帯だけでなく、一般的なソフトウエア開発でも散見されるような気がする。

例えば、ある程度の規模の企業になると、メーカー独自の聞いたこともないようなDBMSとか、独自仕様の運用実績がほとんどないフレームワークとか、世間ではアンチパターンと言われているような記述が義務付けられているようなコードを読みづらくするコーディング規約などが根付いていたりして、新しく入ってきたエンジニアを戸惑わせたりすることがある。それらもガラパゴス現象と呼んでみたい気がする。

#エンジニアあるある 実録IT用語辞典 【注目のキーワード】

あわせて読みたい

注意!!

この連載記事には必ずしも正しいとは限らない内容が含まれています。この記事を信じたことによって発生した障害に対して、筆者及び株式会社マイナビは一切の責任を負いません。ご容赦ください。

※この記事は2007/11/23〜2009/08/28に連載された内容を再構成しています

著者プロフィール:MW(えむだぶりゅー)

Java、PHP、C、C++、Perl、Python、Ruby、Oracle、MySQL、PostgreSQL関連の業務経験がある、典型的な広く浅い役に立たない系のウェブ(時々クライアント)アプリのエンジニア。 週に1日休みがあれば、ほか6日間は終電帰りでも全然へーきな体力と、バグが出ても笑って誤魔化す責任感の無さを武器に、今日も修羅場った開発現場の風景を横目で見ながら、適当に仕事をこなす日々を送る。
著書「それほど間違ってないプログラマ用語辞典」(発行:毎日コミュニケーションズ)

併せて読みたい記事
賛成! あたらしい生き方。マイナビ転職

豊富な転職・求人情報と転職ノウハウであなたの転職活動を支援する【マイナビ転職】。マイナビ転職は正社員の求人を中心に“日本最大級”常時 約8,000件以上の全国各地の豊富な求人情報をご紹介する転職・求人サイトです。毎週火・金更新であなたの希望の職種や勤務地、業種などの条件から検索することができます。職務経歴書や転職希望条件を匿名で登録するとあなたに興味を持った企業からスカウトされるサービスや、転職活動に役立つ職務経歴書サンプルや転職Q&A、会員登録をすると専門アドバイザーによる履歴書の添削、面接攻略など充実した転職支援サービスを利用できる転職サイトです。

「知っトク」メール

基本のノウハウだけでなく、市場動向も踏まえた「今、知っておきたい」転職情報を読めるメールマガジンです。毎週月曜日配信です。

新着求人メール

新着求人の中から、あなたの希望条件に合った求人やお勧め情報をお届けします。
毎週2回、更新日(火曜日・金曜日)に配信です。

キーワードから記事を探す

検索フォーム

人気コンテンツランキング
転職成功ガイド