やめようスパゲティコード

2019年5月27日

ノウハウ

皆さんこんにちは、末ちゃんです。

今日はTwitterにたまたま流れてきた某ツイートで、

スパゲティコード書く奴らは成果がすぐでるせいでプログラム分からない人から評価されるのが許せない。そのコードを引き継いだときに真っ当なエンジニアが作業に時間がかかって駄目なエンジニア評価うけるのも許せない（原文あやふや、出所忘れた・・・）

みたいなものをみて、ちょっとこの件についてブログにしてみようと思いました。

自分もスパゲティコードを量産している害悪コーダーなので、戒めを兼ねて書きます。

スパゲティコードとは

スパゲティコードとは、プログラムのソースコードが書いた人以外にとって解読できないようなコードのことを言います。
語源は皿に盛ってあるスパゲティのように、複雑に絡み合ってることからだそうです。

スパゲティコードの強み

悪い評価を受けるスパゲティコードにもメリットがあります。

それは、開発スピードが速いということです。

通常コードを書くプロセスというものは以下のようなもののはずです。

要件・仕様をまとめる
使用する技術等のあたりをつける
試しに書いてみる
テストをする
リファクタリングをする
テストをする
完成

しかしスパゲティコードが生み出されるときはおおよそ以下のようなときと思います。

要件・仕様をまとめる・・・？（まとめても後出しで根幹をなす仕様の変更がくる）
使用する技術は、行き当たりばったりで決める
試しに書いてみる
完成
仕様変更がきたから、とりあえず書き直す
完成

このような書き方をすれば当然、コーディングは早くなります。

故に、経営者やクライアント、並びにディレクター等から評価を受けます。
コストを極力抑えることができるからです。

スパゲティコードは害悪

しかしスパゲティコードは上記のメリットすら霞むデメリットがあります。

他人によるコードの解析に時間がかかる
未来の自分自身によるコードの解析に時間がかかる
修正時の影響範囲が大きくなる
バグが発生しやすくなり、更にそのバグをみつけづらくなる
そもそも解析すら不能になる

一度書いたコードを引き続き直していかなければいけない企業案件では、これらの問題は説明するまでもなく致命的です。
これが問題と認識できない、それでも早ければいいとお考えの方がいたらどうぞ自分でコードを書いてみてください。
「それでも仕事だから淡々とやる。」のはもちろんですが、それでよしとするのはただの怠慢です。

技術不足

また、スパゲティコードは技術不足によりも引き起こされます。
コードを書くときのベストプラクティスを知らなかったり、ウェブサイトからコピペするだけのコーダーはこの問題を引き起こしやすいです。

チームに一人経験豊富なコーダーを組み込み、細々アドバイスを貰うようにしたり、コードレビューをしてもらうことで大きく改善するはずです。

スパゲティコードを書かないために

さて、そんなスパゲティコードを書かないためにどんなことができるでしょうか。

KISSの原則

KISSの原則、これを守るようにすればそれだけで良いんじゃないかなと思います。

KISSの原則とは Keep it simple stupid. のことで、物事はシンプルにしておけということです。

Wikipedia: KISSの原則

設計におけるKISSの原則

ウェブサイトはソフトウェアを制作する際にとてもよくあることが、後からの仕様追加です。

これはクライアントが自分の要求を理解していないがためによく起こりがちな事であり、かつディレクション時にクライアントの要求を正確に汲み取れなかったときにも起こります。

このため後からの機能追加が連発し、やがて本来の目的すら霞んできてしまうようになります。
そしてその迷走が、コードに対して大きく反映されます。

そもそもコードに対してのみではなく、そんな仕事の進め方は駄目ですよね。見積の意味がありません。

コーディングにおけるKISSの原則

コーディングする際にもKISSの原則が当てはまります。
これはすごい簡単な話です。ひとつのスコープに複数の機能を設けなければいいだけのことです。

たとえば受け取ったデータとしきい値を比較して、メッセージを表示させてエラーを返すというプログラムを書く場合を想定してみましょう。

var n = 100;

if ( n > 80 ) {
  console.log('超えています');
  var error = true;
}

if (error) {
  console.log('値がしきい値を超えています');
}

これはスパゲティコードの第一歩ですね。

もちろんただこれだけの処理で終わるのであればそれで良いでしょう。

const valueIsError = checkValue(100, 80, 'above');
if (valueIsError) errorHandler();

↓ 判定処理等は別ファイルに格納

const checkValue = (val, threshold, direction) => {
  let error = false;

  if (direction === 'above' && val > threshold) {
    error = true;
  } else if (direction === 'below' && val < threshold) {
    error = true;
  }

  return error;
}

const errorHandler = () => {
  console.log('値がしきい値を超えています');
};

この書き方なら、例えこの処理が100回あったとしても、かなりすっきりします。
また、判定処理自体に手を加える必要があった際も、1箇所のコードの修正で終わりますし、判定処理に単体テストをかけられるためバグも起きにくくなります。

前者の方法で書いたときに、あのコードが100個あったら修正対象箇所は100箇所に及びます。