「DIV病」とは

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

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

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

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

「定数病」とは

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「ソース上の誤字」とは

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

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

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

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

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

「10年前のソース」とは

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

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

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

「ガラパゴス現象」とは

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

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

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

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

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