スパゲッティコードとは、他人には読み取りにくいソースコードを意味します。本記事では、スパゲッティコードの概要や発生する原因、デメリット、対策について、エンジニアや管理者が押さえておきたい内容を解説しています。
本記事では、スパゲッティコードについて知っておきたい内容を基本情報から具体例までまとめて紹介します。
スパゲッティコードとは？
ソースコードは、正確で無駄がなく、保守性・拡張性の高いものが理想的です。逆に、無駄な記述が多く、複雑に入り組んだソースコードはスパゲッティコードと呼ばれ、理解しにくく扱いづらいことから敬遠されます。
なぜスパゲッティコードが生まれるのか
スパゲッティコードとは、ソースコードのロジックがあいまいで、構造が乱雑なさまを、長く絡まったスパゲッティにたとえた俗語です。「スパゲッティプログラム」または「スパゲッティ」とも呼ばれ、他人には読み取りにくいソースコードを意味します。
コードの実行順を線でたどったときに、複雑に入り組んでいたり、あちこちにジャンプしてしまっていたりするソースコードがスパゲッティコードに該当します。このようなコードは記述したプログラマー以外が理解できず、解析に時間がかかります。
コードの変更や機能追加が何度も繰り返されると徐々に長く複雑になるため、意識しないとスパゲッティコードになりやすくなるため注意が必要です。また、スパゲッティコードを拡張していくと、さらに複雑化する恐れがあります。
スパゲッティコードの特徴
スパゲッティコードの特徴は「誰が見てもわかりにくい」ことです。そうなってしまう原因としては、ソースコードが機能ごとに分離されていない（モジュール化されていない）、互いの依存関係が強く密結合状態になっている、処理が複雑、似た処理を繰り返している、コーディング規約に沿っていない、などが考えられます。
また、コードの組み方だけでなく、開発途上の書きかけなど、動作に無関係なコードが残されている状態でも処理内容を理解するのに時間がかかり、把握が困難になります。
スパゲッティコードのデメリット
エンジニアからスパゲッティコードが敬遠されるのは、「保守性の低下」や「損害発生リスク」があるためです。
スパゲッティコードが残されたプログラムがトラブルを起こすと、原因特定や修正に多大な手間がかかるため、保守性に問題があります。
たとえば大規模なプログラムでグローバル変数を多用すると、あとからコードを読み解きにくくなります。何らかの問題で関数を変更する場合にも、その関数だけでなく同じグローバル変数を使っているすべての関数を確認する必要があるため、解決までに時間と手間を要するでしょう。
さらに、内容を全て確認しきれないまま変数の値を変更してしまうと、たとえ問題点の修正ができたとしても、異なる場所で問題が生じる可能性があります。さらなる問題発生に気づかないまま稼働させれば、突然のシステム停止や誤作動といった大きな問題へと発展するリスクが生じます。
たとえスパゲッティコードを理解できる人がいても、チーム全体への悪影響は避けられません。担当者の不在時に問題が発生した場合、他のメンバーが修正にあたることになり、また他者が対応できない、もしくは対応を間違えると前述した損害発生の可能が高い場合、担当者を呼び戻す手間と時間がかかります。このように作業が属人化し、担当者の退職や配置転換に対応できない状況では、チームやプロジェクトの信頼性が低下します。
スパゲッティコードが起こる原因とは？
スパゲッティコードが起こる原因としては、「納期が短い・人手不足」「経験・スキル不足」などが挙げられます。
まず考えられるのは、納期に間に合わせるため、または人手不足などの理由から、エンジニアが場当たり的な対応をしてしまうことです。トラブルや仕様変更、機能追加などに際して、とりあえずの問題解決を優先して必要最小限の変更・追加のみに留める状況とは、根本的な修正を後回しにすることでもあります。後回しにした修正を行わず、技術的負債をため込むことで次第にプログラムがスパゲッティコードと化していきます。
また、単に技術者の経験・スキル不足により良いコードが書けず、可読性が低くなってしまうことがあります。結果として同じ動作をするコードでも、エンジニアによって書き方が異なります。
可読性や保守性の考えられたコードを書けるようになるためには経験やスキル、知識が必要です。能力の低いエンジニアが書いたプログラムは、残念ながらスパゲッティコードとなる可能性があります。
スパゲッティコードの具体例
スパゲッティコードになりやすい代表例が、自由な位置にジャンプできるgoto文です。規模が大きなプログラムでgoto文を多用すると、あちこちにジャンプしてしまい、本人以外は構造が把握できない複雑なコードになってしまいます。
また複雑な条件分岐がある条件文や、複数の機能が入った関数もあとから理解しにくいスパゲッティコードになりやすい例です。
モジュール化されていないコードは、分割されずに長くなり可読性が低くなります。類似した処理を繰り返しやすく無駄が多いうえ、修正する際にはすべてを書き換える必要があり、直し忘れのリスクがあります。
他にも、繰り返し制御文・サブルーチンなどで処理をまとめていない、変数名・関数名があいまいで目的がわからない、クラス構造の見直し不足、前述したグローバル変数の多用や根本的な解決を伴わない修正などがスパゲッティコードにありがちな例として挙げられます。
スパゲッティコードを起こさないための4つの対策
スパゲッティコードを生み出さないためには、「良いコードを書く」ことに尽きます。そのために有効な対策を4つ紹介します。
正確に設計する
理解しやすいソースコードを書くためには、前工程の内部設計を正確に行い、決められた設計方針・コーディング規則に沿ってコーディングするのが有効です。
プログラムの基礎的な仕組みの定義は、経験・スキルの豊富なエンジニアが担当しましょう。また設計工程を支援するツールの導入もおすすめです。
現場のマネジメントを見直す
エンジニアが場当たり的なコーディングを行ってしまう背景には、マネジメントがうまくいっていないことがあります。
仕事内容・納期に対しての人員やそれぞれのスキルに応じた仕事の割り振りを適切に行い、エンジニアが余裕をもって仕事ができる環境であれば、短絡的な修正だけでなく、プログラムの品質を重視した改善に取り組むことができます。
現場の管理者が問題の把握と対策を行い、マネジメント業務やマニュアルの見直し・改善を進めていくことが、結果的にスパゲッティコードの予防につながります。
コード記載後はレビューで確認する
エンジニアがコーディングを行った後、本人とは別のエンジニアが内容を精査して感想を伝える作業がコードレビューです。品質を一定に保つために重要な工程で、効率が悪い書き方や脆弱な箇所など、本人が見落としがちな箇所を発見できます。
レビューによってプログラムの可読性・保守性を高めることはもちろん、新人にノウハウを伝え、学習する機会を与えるという点においても有用です。
コーディングはKISSの法則を厳守する
コーディングを行う際には、KISSの法則を守ることが重要です。KISSとは「Keep It Simple Stupid」の頭字語で、コードをシンプルで簡潔にするという方針です。
たとえば、ひとつのスコープにもたせる機能はひとつにするといった方針がこれにあたります。
シンプルなコードは、動作処理とコードの該当部分の関係が理解しやすく、解読が容易です。読み取りやすいコードは他のエンジニアでも迷わず追加や修正に取り掛かることができ、シンプルな状態を維持できるでしょう。
まとめ
可読性の低いソースコードであるスパゲッティコードは、保守性の低下や損害発生のリスクなど、多数のデメリットがあります。対策としては正確な内部設計やマネジメントの見直し、簡潔なコーディングを行うことが有効です。
