スパゲッティコードによる可読性低下

スパゲッティコードとはその名の通りスパゲッティのようだと
揶揄されるほど絡み合ったコードのことをいいます。

エンジニア同士の雑談では、特定の人しかわからないコードがあるという話はよく聞きます。

ほかの人がそのプログラムを理解できないとは、
スパゲッティ化しており可読性が失われているかもしれません。

この記事でいいたいこと

• 悪い再利用性は可読性低下につながる
• 複数の機能が同じメソッドにあれば分離することを検討する

スパゲッティを起こす原因の一つはグローバル変数

グローバル変数はスコープ管理されていないため
どこからでも呼び出されるという特徴をもちます。

どんなところでも利用ができる＝どこにでも絡みつきます。

「priveteメソッドだからスコープ内のことだけ考えていればよい」
と油断しているときにグローバル変数でてきて
考慮しなければならない領域が一気に広がります。

そのグローバル変数がまた別のところで使用されていて、
書き変えられていると一気に複雑になります。

これがロジックが絡まる原因の一つです。

Web界隈だとjavascriptで発生しがちですね。

ただ、最近の言語やフレームワークを使用していると
あまりグローバル変数を使うという選択肢自体が
減ってきたかなと感じています。

グローバル変数でスパゲッティを起こしているコードを
あまり見る機会は少なくなってきたかもしれません。

再利用性を上げたつもりでスパゲッティ化

再利用性を重視した結果がスパゲッティになることもあります。

この再利用性はうまく使えているプログラムであれば保守性や可読性を
高めますが中途半端に再利用してしまうと逆効果をもたらします。

類似コードをまとめて再利用性を高めたつもりが逆にスパゲッティになっていたり。

良く見るのはデータを登録するときと変更するときで
同じメソッドを使用している場合です。

例えば「商品」データで考えてみると
登録するときと変更するときどちらも「商品名」を扱います。

小さいプログラムでは「商品名」を更新するとき
同じメソッドで処理することがあります。

たまに引数でフラグが追加されているメソッドを見たことはありませんか？

void update(bool createFlag , .etc)

「createFlag」のように登録と変更を引数で場合分けする実装です。

「登録」は登録のときだけ処理され、
「変更」は登録の時には実行されない、If文と考えてください。
「共通」となっている部分が登録と変更で実行されます。

とくに共通の部分に大量の単純コードがある場合では
引数にフラグをとって各処理にIf文入れるだけで楽だし、
修正や生産コストも少ないんです。

新しいメソッドを作るとテストも大変です。

サービスやアプリを世に出すなど、価値の提供を目的としている場合
時間もかけずに成果のでる修正方法や開発は悪ではありません。

しかし大きいプログラムになってくるとどうでしょう。

そのラクさの影で可読性は簡単に落ちます。

この状態がスパゲッティ化の第一歩です。

メソッドを分割してみると可読性があがり再利用性の視点を変わる

改めて考えてみます。
登録と変更は本当に同じでしょうか。

受け取るデータは似ているのですが、チェックする方法も違えば
データを登録するクエリも違います。

さっくり分けてしまうほうがシンプルです。

コードを読み進めているとき文脈が「登録」もしくは「変更」にフォーカスされ読みやすくなります。

むしろ「共通処理」を別のメソッドにするという案もでてくるでしょう。

再利用性が可読性を低下させるとき、それは再利用性自体が低下しているサインかもしれません。

まとめ

• 悪い再利用性は可読性低下につながる
• 複数の機能が同じメソッドにあれば分離することを検討する

同じようなコードがでてくると、まとめたい衝動にかられます。

しかし、メソッドの目的が異なっていると、
いざ再利用するときに内容が複雑になっていて
注意しながら呼び出すということになります。

私が見てきた経験にはなりますが、

再利用性は共通化できる機能ではなく
共通化できるコード量で判断している場合は危ないです。

いつの間にか大皿のスパゲッティになってしまうかもしれません。