開発部JKです

スパゲッティコード

長く運用されているシステムや、販売から時間が経っているパッケージソフトが

抱えがちな問題がスパゲッティコード。

改修や機能追加をし続けた結果、何をしているのか容易にわからない

可読性の悪いプログラムのことを指します。

法改正に対応し続けているパッケージの保守をしたことがありますが

導入先会社向けのカスタマイズと法改正対応の修正が入り組んでいて

どこに追加改修したら一番よいかの判断に苦しんだものです。

先ほど改修し続けた結果…と書きましたが、フルスクラッチで

１から開発したとしてもスパゲッティコードになる場合もあります。

その要因の１つとしてプログラムには、より最適な解はあっても

正解は１つではないというのがあります。

これはあることを説明する文章を色んな人に書かせた場合と同じで、

非常に簡潔にまとめる人もいれば、やたら冗長に書く人もいて、

途中で何のことを説明したいのか発散した書き方をする人もいます。

最終的な結果が同じなら、途中に無駄や冗長さや潜在的な問題があったとしても

とりあえず読めればOK！になり、難読文章≒スパゲッティコードの完成となります。

これを防ぐ術として、開発の世界ではコーディング規約（ルールブック的なの）を

設けるというのが昔から一般的に言われていることで、エディタでも一部の規約を

チェックすることができたりします。

今までで一番厳しかった現場では１処理100行以内、クラス全体でも1000行以内、

なんてのもありました。

まぁ大きなプロジェクト以外ではあまりお見掛けしないですけどね。。。

そして生まれるデッドコード💀

スパゲッティコードは様々な人が様々なタイミングで改修を加えることでより難読化していきますが、

その中で生まれるのが無駄な処理、デッドコードです。

極端な例で「現在は１９５０年より昔である場合、○○する」という条件文があった場合、

今後何年たっても、そのあとに書かれた処理は実行されることはありません。

ただ、「現在は１９５０年より昔か？」という判定は今後もずっと行われます。

デッドコードの中でも上記のようなコードは「到達不能コード」と言われるそうです。

システム的には非常に短い時間で処理されるため、通常は問題になりませんが

一定規模のアクセスを超えると、パフォーマンス影響が出始めると言われてます。

厳しい現場では到達不能コードがないことをテストケースで

証明できることがリリースの条件だったりもします。

まぁ、今のマシンスペックだと問題ないのかもしれませんが、

何をしてるのかわからないまま残されている処理は無駄ですから

精査して無くしていきたいですけどね。。。

どうですか？私の文章、読みづらいでしょう？そういうことです。

文：開発部JK