ポイント: スパゲッティコードは、構造が不十分なコードであり、メンテナンスを複雑にし、プロジェクトの失敗を引き起こす可能性があります。通常、プロジェクトの範囲が不明確であったり、ベストプラクティスを無視したりすることから生じます。スパゲッティコードを防ぐために、開発者はアーキテクチャを優先し、定期的にユニットテストを実施し、軽量なフレームワークを活用する必要があります。
- スパゲッティコードは、プロジェクトのメンテナンスを妨げます。
- それは、計画不足やコーディングプラクティスの欠如から生じます。
- 回避戦略には、勤勉なアーキテクチャとユニットテストが含まれます。
スパゲッティコードは愛情を持って呼ばれる用語ではありません。それは、あなたの技術インフラが失敗する原因となる可能性があるコードの一種を説明する言葉です。スパゲッティコードに関する警告にもかかわらず、多くの企業はスパゲッティコーディングを構成するプロセスやエラーのセットに関する問題に直面しています。これはさまざまな理由で発生しますが、専門家の多くは、全体的なインフラにとって有害であると信じています。この記事では、スパゲッティコードの概念と、それがあなたの組織にとって何を意味するのかについて説明します。
スパゲッティコードとは？
スパゲッティコードは、プロジェクトの作業範囲が不明確であること、経験と計画の欠如、プログラミングスタイルルールにプロジェクトを適合させる能力の欠如、そして他の一見小さなエラーが蓄積してコードが時間とともにスムーズでなくなることによって引き起こされる、情報技術用語の悪口です。通常、スパゲッティコードは、複数の開発者が数ヶ月または数年にわたってプロジェクトに取り組み続け、既存のプログラミングインフラを最適化することなくコードとソフトウェアの範囲を追加および変更する場合に発生します。これにより、GOTOステートメントをプログラミング構文よりも好む、計画されていない、複雑なコーディング構造が生じ、長期的には維持できないプログラムになります。企業にとって、プロジェクトに何年もの作業（およびお金）がかけられた後にプログラムが維持できなくなることは、ITマネージャーや他のリソースにとってコストがかかります。さらに、プログラマーはインフラをコーディングするのに数時間を費やし、何かが壊れた場合にそれを特定するために数年の作業を見直さなければならないことにフラストレーションを感じます。スパゲッティコードは、開発者やITマネージャーにとって厄介なものであり、リソースを管理しなければならない企業にとっては、完全に避けるべきものです。
スパゲッティコードの歴史
「スパゲッティコード」という用語を初めて使った人物やその時期は明確ではありませんが、1970年代後半には構造が欠如した絡まったコードを説明するために使用されていました。80年代には、少なくとも一度ホワイトペーパーで、この用語がコードと修正のモデルを説明するために使用され、ウォーターフォールプログラミングの発展につながりました。しかし、その時代の大多数の書籍は、それを効果的にスケールするために必要な構造が欠如した乱雑なコードの巣として言及しています。1981年のコーディング風刺は、IBMの創設者たちがスパゲッティコードを好んでいたに違いないというアイデアを提起しました。リチャード・ハミングの著書The Art of Doing Science and Engineering: Learning to Learnでは、次のように述べています。「エラーを修正する際に、いくつかの省略された指示を挿入したい場合は、直前の指示を取り消して、空のスペースに転送しました。そこに、あなたが今書いた指示を置き、挿入したい指示を追加し、その後、メインプログラムに戻るための転送を行いました。「そのため、プログラムはすぐに制御が奇妙な場所にジャンプするシーケンスになりました。ほとんどの場合、修正にエラーがあった場合、同じトリックを再度使用し、別の利用可能なスペースを使用しました。その結果、プログラムのストレージを通る制御パスはすぐにスパゲッティ缶のような外観になりました。なぜ単に指示の流れに挿入しなかったのか？それを行うと、すべてのプログラムを見直し、移動された指示を参照していたすべてのアドレスを変更しなければならなくなります！それ以外は何でも！」
どのようにしてインフラに存在することになるのか？
スパゲッティプログラミングは清潔でも構造化されておらず、企業がまとめた範囲やモデルに反します。それでは、どのようにしてそこに存在するのでしょうか？スパゲッティコードは、特定の条件が満たされると発生します：
- プログラマーがプログラミング構文を使用してアーキテクチャを洗練することに気を配らず、代わりに容易なアプローチや十分に考えられたアプローチに頼ったり、計画なしでプロジェクトに飛び込んでコーディングを開始したりした場合。
- 開発のベストプラクティスや最も効率的なコーディング言語は時とともに変化するため、プログラミングが進化すると、既存のシステムはそれらを清潔で構造化された状態に保つために最適化されるべきです。これが失敗すると、スパゲッティコードのエコシステムが生まれます。
- スパゲッティコードは、プロジェクトを開始して数時間後に発生することもありますが、企業ビジネスでは、異なるプログラマーがプロジェクトの手を変える場合に長期間にわたって発生することがよくあります。
- スパゲッティコードは、経験が不足している人が、プログラムアーキテクチャの構造的完全性を確保するよりも、GOTOコマンドのようなより単純な技術を使用する場合に発生します。
一般的に、スパゲッティコードは、企業がプロジェクトの寿命にわたって信頼できるアーキテクチャを計画するのに失敗した結果として自然に発生します。
スパゲッティコード：それを避ける方法
効率の悪いスパゲッティコードの絡まりを避けるために、プログラマーは：
- 勤勉であること：まず第一に、勤勉さと細部への注意が重要です。開発者は、プロジェクトの最良のアーキテクチャを作成することに鋭く集中し、アーキテクチャを急いではいけません。
- ユニットテストを頻繁に行うこと：定期的なユニットテストを実施することで、スパゲッティコードが発生する可能性を減らすことができます。
- プログラマーをダブルチェックすること：追加の目があれば助けになります。スパゲッティコードに遭遇した場合は、すぐに対処し、変更を求めてください。
- 軽量フレームワークを使用すること：2020年には、実装できる数多くのスリムで軽量なフレームワークがあります。フレームワークをスリムに保つことで、より簡素なソリューションを目指すことができます。
- レイヤーを実装すること：実際には、レイヤーは、プログラム全体ではなく、単一のレイヤーに対処することでスパゲッティコードの修正をより容易にします。
関連するコードタイプ
さらなる学習のためにレビューできる関連するコードタイプがいくつかあります：
- ラビオリコード：これは、クラス内では理解しやすいが、プロジェクト全体の文脈では理解しにくいオブジェクト指向コードのエラーを指す用語です。
- ラザニアコード：これは、スパゲッティコードを避けるためにレイヤーを使用した際に、レイヤーが互いに依存しすぎているために、単一のレイヤーの中断がプロジェクト全体に影響を与える問題です。
- ピザコード：コードアーキテクチャが平坦すぎる場合、それはピザコードと呼ばれます。
これらの投稿は私自身の意見であり、必ずしもBMCの立場、戦略、または意見を代表するものではありません。