Help us understand the problem. What is going on with this article?

「スパゲッティコード」を書かないために意識すること

More than 3 years have passed since last update.

はじめに

この記事は、(実際に動いている)スパゲッティコードを見てきた私自身のふりかえりです。

  • なぜ「スパゲッティ」になるのか?
  • そうならないためにはどうすればよいのか?

私なりのベストプラクティスを集めたものです。

熟練者の方からすれば「あたりまえ」なこと、異論などあると思いますが、少なくとも、私はこれらを意識することで(多分)そこそこなコードが書けているので、投稿することにしました。

前提として、私のバックグラウンドはC#とRubyです。
そのため、これらの言語に寄っているかもしれません。
その辺りはご容赦ください。m(_ _)m

一番大事なこと

他の人が読んで、コードを作った人の意図がわかること。

「スパゲッティコード」と呼ばれるコードは、確かに論理的整合性が取れていなくて、見辛いということもあるのですが、本質的には「何書いてるのかわからない」「何をしたいのかわからない」からそう呼ばれるのだと思います。

そのため、「スパゲッティコードでない」と言うために一番大事なことは、
書いた人がきちんと意図を読み手に伝えるコードを書いているのか?
ということです。

それでは、読み手に意図を伝えるためのエッセンスを見ていくことにします。

目次

  • 基本はSimpleであること(KISSの法則)
  • DRYであることの重要性
  • if,whileは本当に必要か?
  • 名は体を表す
  • オブジェクト指向原則って知ってますか?
  • テスト容易性はきれいなコードにつながっている
  • デザインパターンシンドローム
  • ログは安くすます

Simpleであること

最も難しいことはプログラムを「単純」に保つことです。

なぜ難しいか?

その理由は、「単純」の定義自体が難しいからです。

「プログラムを単純に保て!」と言われても、作るべき要件や機能が増えるほど、その難度は増します。

:

この一つの答えは、設計指針を決めることです。
こんな方針で設計するんだ!」をまず最初に決めることです。

なぜなら、スパゲッティコードの一番の理由は、「何書いてるかわからない」ことだからです。
設計指針があれば、第3者が見た時に「設計指針に従っているか?」が判断材料になります。

設計指針がプログラム全体から見えることがすなわち「単純」であることです。

参考
KISSの法則(単純なんだよ!バカっ!)

DRYであることの重要性

いわずもがな。
冗長なコードは止めましょう。

保守開発の現場では、どうしても「既存のコードを触りたくない」という気持ちもわかります。
ただ、もしその保守開発が長く続くのであれば、既存のコードを触ることも検討したほうがよいです。

余談ですが、私が経験したプロジェクトはこんなスパイラルに陥っていました。
冗長なコードを書く=影響範囲が見にくくなる=確認に時間がかかる=生産性が低下する=冗長な...

DRY

if, whileは本当に必要か?

プログラムの基本構造は 「順次」、「分岐」、「反復」です。
今も昔も変わっていません。

スパゲッティコードとして良く見られるのは、「巨大なクラス」「複雑な条件分岐」、「無駄に多い反復」です。

こうなる理由は、コーディングのバリエーションを知らないことにあります。
オブジェクト指向言語のいいところは、クラス構造をうまく考えることによって、
構造面から単純な解決策を模索できるところ
です。
複雑な問題も、順次構造とクラスの組み合わせで解決させられないかを模索することが、見やすいコードを書くためのポイントです。

名は体を表す

変数名を考えるときこそ集中しましょう。
ロジックを考えるのと同じくらい難しい作業ですが、根詰めてやりましょう。
文章を書くときの言葉選びと同じで、あいまい表現になっていないかを何回も確認すべきです。

余談ですが、
temp や i や k などは使うな!
私もよく言われましたが、これは本質ではありません。
ロジック上「あいまいさ」がなければ、temp や i や k だって使っていいんです。

以下の書籍がオススメです。
リーダブルコード

オブジェクト指向原則って知ってますか?

設計に迷ったとき、思いついた解決策に飛びつくことはよくあることです。
そのとき、目の前の問題だけに目が行き、全体のクラス構造から逸脱したことに気づかないことで、
スパゲッティへの火種ができてしまいます。

こんなときふりかえるべきは、デザインパターンではなく原則に立ち返ることです。
オブジェクト指向の法則集

これらの原則から逸脱するとき、明確な理由があるか。
逸脱するなら、説明が必要ということです。

「テスト容易性」はきれいなコードにつながっている

テストがしやすいということは、そのクラスが単純であるということができます。
グローバル変数やDBへの依存性が高いために、テストコードを書くのに壮大な準備作業が要るなら、
それは、クラス構造を見直したほうがよいです。

オブジェクト指向の再定義(1)-EoT テスト容易性

デザインパターンシンドローム

アンチパターンにはまると、可読性を損ないます。
でも「使わなきゃ」と考えている人は結構多いです。

デザインパターンには、柔軟性を得られる適切な「シーン」があり、デメリットもあることを理解してないことが原因です。

一番いい例がSingletonパターンの使い方。
オブジェクトをアプリケーション内で1つに留めることができますが、その実装はstaticなグローバル
オブジェクトとして実装されます。
安易に多用することは、グローバル変数を増やしているのと同じ行為であることを認識すべきです。

ログは安くすます

「ログを出すのに4行の行数が必要」、「コード上にログの組み立て箇所が数100箇所もある」
ログを出すだけでコードが長くなり、本当に表現したいロジックが埋もれてしまいます。
ログ出力はなるべく1行で書けるように工夫します。

これはログだけに限った話ではなく、大事なことは重要なロジックを表に出すように意識することです。


以上、私が設計、実装で意識している1+8か条です。

必ずしもこれに従え、というわけではないですが、少しでも判断の助けになれば幸いです。

haruharuharuby
2016年からフリーランサー。 Alexa Champion AlexaとAWSとRubyとRubyOnRailsが大好き。 前職(〜2015年)は、.net(C#)デベロッパ 兼 社内のインフラエンジニア。 綺麗なコードと新しいことはなんでも好き。
https://hugtech.io
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away