スパゲッティコードに関するスパゲッティの記事

Michael O. Church Article Translation- スパゲッティコードとは？



エピソートが元の意味を失う最も簡単な方法は、過度に広範になり、単に「好きではない」以上の意味を持ち始めることです。 私たちは「スパゲッティコード」という用語について話します。人々はしばしば「悪いコード」の概念の同義語として使用します。 問題は、すべての悪いコードがスパゲッティコードではないということです。 スパゲッティコードは特に危険で特定の種類の悪いコードであり、その特定の悪さはソフトウェアの開発方法にあります。 なんで？ 個人がスパゲッティコードを自分で書くことはめったにないからです。 むしろ、開発の特定のスタイルは、時間とともにより一般的になります。 これを理解するには、「スパゲッティコード」の概念が定義された初期コンテキスト、つまりgoto演算子のひどい（そしてほとんどが古風な）使用を考慮する必要があります。



goto演算子は、プログラムのフローを制御するためのシンプルで強力なメカニズムです。つまり、コード内の別のポイントに移動します。 これは、ソースコードがループや関数などのより新しい構造を使用して記述されている場合でも、制御を転送するためにコンパイルされたアセンブラプログラムが実際に行うことです。 gotoを使用すると、誰でも必要なスレッド制御を実装できます。 現時点では、 gotoが最新のプログラムのソースコードとして不適切であることにも異議を唱えるのは困難です。 この規則には例外がありますが、非常に小さいものです。 最近の言語にはこの演算子さえありません。



goto演算子は、プログラムの制御が1つの場所から別の場所にジャンプできる場合、コードの特定のセクションを実行するときにプログラムがどのような状態にあるかを確実に判断することができないため、コードを読みにくくします。 Gotoベースのプログラムは、コード内のポイントがコードの他の部分へのワームホールになる可能性があるため、コンポーネント部分に簡単に分解できません。 その結果、このようなコードは「すべてがどこにでもあります」に変わり、コードの別の部分を理解するためにも、この混乱をすべて理解する必要があり、後に大きなプログラムでは不可能になります。 これはスパゲッティのボウルと簡単に比較できます。1つのパスタを抽出する場合でも、パスタの大きなボールをナビゲートする必要があります。 プレートを見て、どのパスタがどのパスタと混同されているかを理解することはできません。代わりに、もつれ全体を苦労して解き明かす必要があります。



スパゲッティコードは、「すべてがどこにでも」あり、（a）機能の特定の部分が実装されている場所、（b）オブジェクトがインスタンス化され、発生する方法、および（c）修正のためのクリティカルセクションを決定する方法などの質問に答えるコードです。 いくつかの簡単な質問に名前を付けるだけで、プログラム全体を理解する必要があるコードを既に見たいと思います。 つまり、最も単純な質問に答えられるようにするには、ソースコードの継続的な診断が必要です。 これは、各パスタを最初から最後までたどる規律を持っていない人にとっては謎のままであるコードです。 これはスパゲッティコードです。



スパゲッティコードを危険にしているのは、他の種類の不正なコードとは異なり、これがソフトウェアエントロピーの一般的な副産物になっていることです。 コードが適切なモジュール構造を持っているが、一部のモジュールの品質が低い場合、問題のあるコードを修正します。 悪い、誤った、または遅いコードは、インターフェイスを変更せずに修正できます。 正直なところ、多くの問題を解決するために設計された巨大なコードの塊よりも、小さな独立した関数でエラーを見つける方がはるかに簡単です。 スパゲッティコードは悪です。（a）不正なコードの非常に一般的な亜種である、（b）機能を変更せずに修正することはほとんど不可能であり、プログラムの動作の古いモデルに依存している人がいるとクラッシュする可能性があり、（d）理由のために、後で説明しますが、このようなコードの出現は、通常のコード検証プロセスでは防止できません。



「スパゲッティコード」の概念を「悪いコード」のより広い概念から分離することが重要だと思うのは、コードを悪くするものの多くが主観的すぎるためです。 コラボレーションソフトウェア （または不在）での多くの矛盾と無礼は、主に男性が未熟な創造性（またはその認識、およびコードに関して、偏った認識であることが多い）をtendency笑する傾向の結果です。彼の無能なアイデアで私たちを悩ませることをやめません。 この行動モデルの問題は、それが役に立たず、人がやろうとしていることで人を良くすることはめったにないということです。 視覚的なコンポーネントに基づいて良いプログラマーと悪いプログラマーを定義する嫌な人も多いので、「良いコード」の定義は「私が書いたように見えるコード」に帰着します。 スパゲッティコードの問題は、「悪いコード」という大規模ではあるが主観的な問題よりも、スコープ内でより適切に定義されていると感じています。 「スペースまたはタブ」の問題についてコンセンサスを得ることは決してありませんが、スパゲッティコードは理解できず、役に立たないことに全員が同意します。 さらに、スパゲッティコードは最も一般的で破壊的な種類の不正なコードであるため、このサブタイプに関する理由と注意事項のほとんどは、不正なコードの他のカテゴリに拡張できます。



人々は通常、「嫌なコード」を意味する「悪いコード」の概念を使用しますが、コードの一部が悪いとうんざりしていると考える理由を判断し、それを修正する可能な方法を見つけることができる場合、これはほとんどのスパゲッティコードからはるかに優れています。 スパゲッティのコードは理解できず、多くの場合非常に正確ではありません。 特定のコードを嫌う理由がわかっている場合 、このコードはすでにスパゲッティコードよりも品質が高くなっています。



スパゲッティコードの原因は何ですか？ しばらくの間、 goto演算子がスパゲッティコードの主な理由でしたが、重要性がなくなったため、人気が失われ、まだ忘れられています。 現在、その理由は完全に異なっています。つまり、オブジェクト指向プログラミングの現代の牛システムです。 ここでは、継承が特別な役割を果たします。その結果、抽象化を考え抜くことはありません。特定のクラスのパラメーター化特性の使用、単一のユースケースの意味、または不要なパラメーターの追加です。 私は、OOPが現在実践されている形式ではスパゲッティコードであるという主張は否定できない観点ではないことを認めます。 かつてのように、 goto演算子を使用することの有害性は否定できません。



比較ソフトウェアの最大の問題の1つ（アプローチ、手法、言語、またはプラットフォームの比較）は、ほとんどの比較が単純な例に焦点を合わせていることです。 20行のコードでは、これらの行が意図的な平均意図で書かれていない限り、不吉なものを明らかにすることはできません。 gotoを使用して記述された20行のプログラムは一般に許容され、それを使用せずに記述されたプログラムよりも単純な場合があります。 20行では、明示的な制御転送を伴うステップバイステップの命令のセットは、プログラムを表す非常に自然な方法です。 一度に読むことができる静的プログラム（たとえば、変更されずにメンテナンスされることのないプラトニックなフォーム）の場合、この構造は問題ありません。 しかし、 gotoを使用したプログラムの2万行では、すでに理解できないほどになっています。 2万行で、 gotoプログラムは非常に多くのハッキング、拡張、および最適化に役立ち、物事を構築するという当初のビジョンが失われます。 また、プログラムは「どこからでも」コードの任意の部分に表示できるということは、コードを安全に変更するには、「どこからでも」これらの数の信頼できる知識が必要であることを意味します。 すべてがどこにでもあります。 これは、コードを理解するのを難しくするだけでなく、予期しない結果のためにコードを変更するたびにコードが悪化する可能性が高いことも意味します。 時間の経過とともに、ソフトウェアは「生物学的」になります。 この用語は、すべてのコンポーネントが独立しているビヘイビアモデルを開発することを意味しますが、一部のモジュールには隠された接続がある場合があります。



goto演算子は、プログラミング言語の構築として行われませんでした。これは、その使用で作成されたプログラムの継続的な診断に関連する多くの問題を引き起こしたためです。 プロシージャ、関数、明確に定義されたデータ構造など、それほど強力ではないが、より専門性の低い構造がより好まれました。 人々がグローバルなフロー制御（エラー処理）を必要とする唯一のケースでは、例外が開発されました。 gotoを使用して作成されたプログラムの極端な普遍性と抽象化から、特定の問題を解決するための部分（手順など）の具体性と特異性への移行でした。 非構造プログラミングでは、多くのことを行うすばらしいプログラムを作成できます。すべての好みに新しい機能を追加し、必要に応じて物事のコースを変更します。 ある種の「問題」を解決すべきではありません（退屈です...）が、組み込みのインタープリターを使用したメタフレームワークになる可能性があります。 構造的プログラミングは、人々がプログラムを単一の問題に対処する特定の部分に分割し、可能であればこれらの部分を再利用できるようにすることを奨励します。 この原則は、Unixシステム（1つのこととそれをうまくやる）と関数型プログラミング（正確な数学的セマンティクスの定義を容易にし、グローバルな状態を回避する）の哲学の基礎となっています。



goto演算子についてもう1つ言いたいのは、言語レベルのプリミティブとしてはほとんど必要ないということです。 whileループ-ループの外側で宣言され、switch-caseコンストラクトで使用されるカウンター変数を使用して、同じ効果を得ることができます。増加（ステップ）、ループを継続、またはゼロ（ goto ）。 必要に応じて、このような1つのサイクルとして機能する1つの巨大なプログラムに拡張できますが、そのようなコードは決して作成されません。 これがほとんど行われないという事実は、 gotoの使用がほとんど必要ないという事実を示しています。 したがって、構造的プログラミングは狂気を指しており、非ローカルフローを強く制御しようとすると、狂気に陥ります。



しかし、 gotoを放棄することは非常に議論の余地のある問題であり、構造プログラミングのこれらのアイデアはすべてナンセンスに見えました。 異議申し立ては次のように聞こえました。gotoステートメントがはるかに強力な場合に、なぜ関数とプロシージャを使用するのでしょうか。



同様に、オブジェクトがより強力な場合、なぜ参照透過関数と不変レコードを使用するのですか？ オブジェクトは最終的にrunまたはcallまたはapplyメソッドを持つことができるため、関数になることができます。 また、静的フィールドまたは定数フィールドを持ち、レコードにすることもできます。 しかし同時に、さらに多くのことができます。誰かがそのような決定をした場合、オブジェクトは初期化子とファイナライザーを持ち、再帰と50のメソッドを開くことができます。 それで、この無意味な構造プログラミングの大騒ぎは何ですか？これは、フィールドが決して変わらず、クラスに初期化マジックが含まれていないレコードなど、はるかに強力ではない構造体からプログラムを作成することを意味しますか？



答えは、力を持つことは必ずしも良いことではないということです。 プログラミング能力は、コードを書く人にとっては利点であり、後で読む人にとってはそうではありません。メンテナンス（たとえば、コードを理解する必要性）は約2,000行または6週間で始まり、プロジェクトに客観的に取り組む複数の開発者がいます。 実際のプロジェクトでは、誰もコードを書きません。 多くの場合、自分のコードと他の人のコードの両方を読む必要があります。 読めないコードは単に受け入れられないものであり、多くあるために許可されています。また、多くのソフトウェア会社が採用しているOOPの「ベストプラクティス」が原因です。 より「強力な」抽象化はより一般的であるため、特定性が低くなります。つまり、そのようなコードを読んだ人は、そのコードが何に使用されているかを判断するのが困難です。 しかし、コードを単独で書く人はしばしば非常に単純です-強力な抽象化には 18の可能な用途がありますが、実際にはそのうちの1つだけが関与しています。 この場合、特有の個人的なビジョンがありますが（通常は文書化されていません）、混乱を避けるのに役立ちます。 このビジョンに着手していない人がコードを変更し始めると、危険が生じます。 多くの場合、これらの変更はハッキングであり、残りの17の使用のうちの別の使用を明示的に暗示していません。 これは、原則として矛盾につながり、その結果、エラーが発生します。 残念ながら、これらのバグの修正を担当する人々は、コードの背後に隠されている初期ビジョンについての考えがさらに少なく、彼らの修正はさらに多くのハックを追加します。 修正が行われる場所もありますが、コードの全体的な品質は低下します。 これは、「スパゲッティ化」コードのプロセスです。 ただ座って自分でスパゲッティコードを書き始める人はいません。 これは、プロセスを徐々に「ストレッチ」することで起こり、ほとんどの場合、複数の開発者が責任を負います。 ソフトウェアでは、「急な勾配」は本当に現実的であり、落下は非常に突然の場合があります。



元々スパゲッティコードを防ぐために設計されたオブジェクト指向プログラミングは、（完全に理解されていない「デザインパターン」の使用により）最悪のソースの1つになりました。 「オブジェクト」はコードとデータを簡単に組み合わせることができますが、任意の数のインターフェイスを持ち、同時にクラスはプログラム全体でサブクラスを自由に生成できます。 オブジェクト指向プログラミングには大きな力があり、きちんと使用すれば非常に効果的です。 しかし、ほとんどのプログラマーはそれを処理できず、時間の経過とともにコードはスパゲッティに変わります。



スパゲッティコードの問題の1つは、コードが徐々に形成されることです。これにより、「スパゲッティ」につながるすべての変更が画像の外側で純粋に肯定的に見えるため、コード検証プロセスで識別することが困難になります。 プラスは、マネージャーまたはクライアントが「昨日」必要とした変更がコードに表示されることです。一方、これはすべて中程度の量の追加の困難のように見えます。 gotoの暗黒時代でさえ、誰も座って言っていませんでした：「コード内の1つのポイントを指す40個のgotoステートメントで完全に理解できないプログラムを作成します。」プログラムの開発は人から人へと徐々に移りました。 同じことがオブジェクト指向のスパゲッティにも当てはまります。 クリーンな初期設計から理解できないスパゲッティコードへの具体的な移行ポイントはありません。 これは時間の経過とともに発生し、人々がOOPのパワーを乱用してあいまいなハックをプッシュします。誰もが修正するプログラムの動作を理解し、より明確な（より強力ではないが）抽象化が使用される場合は不要です。 これはすべて、「スパゲッティ化」の責任はすべての人にあり、同時にではないことを意味します。個々の開発者は、コードを地獄に直接送ったのは自分の変更ではないと自信を持って言うことができます。 これが、（Unixシステムのミニマリスト哲学とは対照的に）大規模なソフトウェア製造業者が次の方針に従う傾向がある理由です：誰が本当に何かを責めるべきか誰も知らない。



追加のコードチェックは、スペースとタブの混合や長すぎる行など、明らかに悪いプラクティスを識別するのに役立ちます。 したがって、「悪いコード」の表面的な側面は、スパゲッティコードよりも面白くありません（「面白い」の定義を「邪魔」の同義語として使用）。 追加のコードチェックでそれらに対処する方法は既に知っています。 このコードを拒否するように継続的統合サーバーを構成することもできます。 明確な定義がないスパゲッティコードに関しては、不可能ではないにしても、それほど簡単ではありません。 プログラムコード全体の完全なチェックは、それを決定することを目的としていますが、そのようなチェックに必要な時間とリソースを投資しようとする企業はほとんどありません。長期（10年以上）では、重要なソフトウェアまたは重要なソフトウェアを開発するチームを除き、ほとんど無理だと思います。これは、無期限に高レベルの規律を提供します。



答えは、私には思えますが、Big Codeは機能しないということです。大規模なプログラムでは動的タイピングがクラッシュし、別の方法では静的タイピングがクラッシュします。これはすべて、オブジェクト指向プログラミング、命令型プログラミング、および機能的プログラミング（スレッドに配置されたパラメーターの増加に現れます）にはそれほどではありませんが、目立った程度に当てはまります。 「gotoの問題「そうではありませんでした。その性質上、コードは非常に迅速にビッグコードになりました。しかし、残酷な現実は、ビッグコードは「銀の弾丸」ではないということです。大規模なプログラムは単純に理解不能になります。逆に、複雑さと大きなサイズは「望ましくない場合もあります」ではなく、常に危険です。 Steve Yeggのような人々はこれを長い間理解してきました。



それが、私がUnixシステムの哲学を本質的に正しいと考える理由です：プログラムは、規模が大きくなり、決して完全にならない不明瞭な湿ったものであってはなりません。プログラムは1つの問題を解決し、それをうまく行う必要があります。大きくてかさばる場合は、ライブラリとスクリプト、実行可能ファイルとデータの別々の部分に分解する必要があります。野心的なソフトウェアプロジェクトは、個別のプログラムのようなオールオアナッシングの構造を持つべきではありません。各プログラミングパラダイムやツールボックスは単純にそれを破壊するからです。代わりに、そのようなプロジェクトはシステムとして構造化されるべきであり、これに多くの注意が払われるべきです。これは、フォールトトレランス、部品の互換性、および通信プロトコルに注意を払う必要があることを意味します。もっと規律が必要ですランダムに成長する大きなプログラムを開発するのではなく、それだけの価値があります。よりクリーンで便利なコードの明らかな利点に加えて、人々は実際にこのコードを読んでおり、実際に何をするのかを知らずにハッキングを無意識に追加することはありません。これは、開発者が時間とともに改善し、長期的にはコードの品質が向上することを意味します。



皮肉なことに、OOPはもともとミニマリストのソフトウェア開発に似たものを奨励することを目的としていました。 OOPの最初のビジョンは、人々が座って巨大で複雑なオブジェクトを書くことを意味していませんでしたが、OOPを特に使用することを意味していました複雑さが避けられないとき。この分野での成功した使用例はデータベースです。人々は、トランザクションの整合性、耐久性、可用性、同時実行性、およびパフォーマンスの観点からリレーショナルデータベースを必要とするため、複雑さが不可欠​​です。データベースは信じられないほど複雑であり、高速化するための多大な金銭的インセンティブにもかかわらず、コンピューターの世界が価値ある実装を達成するのに何十年もかかったと自信を持って言えます。しかし同時に、データベースが複雑になる可能性がある場合（必要な場合）、その使用のためのインターフェースははるかに単純です（SQL）。データベースが使用する検索戦略を指定せず、単にSELECTを記述します（ユーザーが受け取りたいものを記述し、取得方法ではありません）、クエリオプティマイザーがこれを処理できるようにします。



Big Codeが嫌いなのは、データベースは一種の例外であることに注意してください。彼らの複雑さは十分に理解されている必要性であり、自分のキャリアを研究に専念する準備ができている人々がいます。しかし、人々は一般的なビジネスアプリケーションを理解するためにキャリアを交換すべきではありません。そして、彼らはしません。彼らはそれを拒否し、コードを他の手に転送することで、スパゲッティ化をスピードアップします。



なぜビッグコードなのか？落とし穴にもかかわらずなぜ存在するのですか？そして、なぜプログラマーは、自分の力と複雑さが本当に必要かどうかを尋ねることなく、OOPツールの使用を急ぐのですか？いくつかの理由があると思います。それらの1つは怠inessです。人々は、非常に具体的な抽象化や適用する必要のある状況を習得するのに時間を費やすよりも、1つの大きな汎用抽象化を研究することを好みます。 ArrayListが既にある場合、リンクされたリストと配列、またはツリーのようなこれらの不明瞭な構造のすべてを、なぜだれもが勉強するのでしょうか？オブジェクトが同じジョブ（およびそれ以上）を実行できる場合、プログラムがリンク透過関数をどのように使用するかを知っているのはなぜですか？コマンドラインの使い方を学ぶ理由、最新のIDEが、あなたの人生でこの気の毒なものを少なくとも一度は見られないように保護できるとしたら？ Javaがすでにチューリング完了しているのに、なぜ新しいプログラミング言語を学ぶのですか？大規模なコードは、次の位置の普及から発生します。現代のコンパイラが数十万行のコードを簡単に処理できるのに、なぜ大規模なプログラムをモジュールに分割するのですか？コンピューターがBig Codeに遭遇したときに気にしない場合、なぜ気にする必要がありますか？なぜこれを気にする必要があるのでしょうか？なぜこれを気にする必要があるのでしょうか？



それにも関わらず、ポイントに近づいた場合、私はこれはすべて少し欲のあるwith慢に他ならないと信じています。 Big Codeは、ソフトウェアプロジェクトが非常に人気があり成功するという信念から生まれたもので、人々はその複雑さに耐えます-独自のドメイン固有プログラミング言語（DSL）がCやSQLと同じくらい巨大になるようなアイデア。また、問題を解決済みとして認識する準備ができていないために表示され、作業の大部分がすでに完了していてもプログラムが完了しました。プログラミングとは何かという誤解からも生まれます。明確に定義された既存の問題を解決して邪魔にならないようにする代わりに、ミニマリストの方法論で設計されたプログラムが行うように、Big Codeを使用したプログラムは必要以上に多くを行います。このようなプロジェクトは、多くの場合、すべてを包括し、ソフトウェアのためにソフトウェアを作成することを含む不適切な「ビジョン」を伴います。企業環境の「ビジョン」はすぐに政治になる傾向があるため、これは混乱です。ビッグコードを使用したプログラムは、常にそれらを生成した環境を反映しています（コンウェイの法則）、そしてそれらは常に数学とコンピューターサイエンスの普遍的な言語というよりも、パロディーと特定のユーモアのコレクションのようなものです。



このプレイには別の問題があります。プログラマーとプログラムの関係が1対多ではなく多対1になった場合、労力を追跡し、「人員」を決定できるため、マネージャーは単にビッグコードを崇拝します。ミニマリストソフトウェアの方法論は優れていますが、複数のタスクに適切に時間を割り当てる能力にはプログラマーへの信頼が必要であり、ほとんどのティラノサウルスマネージャーはこれを行うことに不安を感じています。 Big Codeは実際には機能しませんが、管理者が技術的努力の配分を制御できるようになります。また、マネージャーがよく行うサイズと成功の混合も伴います（マネージャーへのインタビューでの質問「部下は何人いましたか？」で証明されています）。ビッグコードの結果である長期のスパゲッティ化は、そのようなマネージャーにとってめったに問題になりません。彼らはこれがどのように起こるのか見当がつかず、しばしばこれが問題になる前にプロジェクトを去ります。



まとめると、スパゲッティコードは悪いコードであると自信を持って言えますが、すべての悪いコードがスパゲッティコードであるとは限りません。Spaghettiコードは、多くの場合（常にではありませんが）コードが多数の手を通過した結果である産業用プログラミング製品であり、大規模なソフトウェア製品を開発する方法論の不可避な結果と、欠陥のある管理プロセスから生じたオブジェクト指向プログラミングbydloopの結果です。スパゲッティコードに対する解毒剤は、プログラムをコンパクトで効率的で、クリーンなソースコードで、そして最も重要なことに一貫性を保つための積極的かつ積極的なリファクタリングと努力です。



翻訳者から：この記事は非常に広範囲にわたるため、不正確またはエラーについてPMにお知らせいただければ幸いです。