coding-style - 何年にもわたってスパゲッティコードを回避する方法はありますか?

Question

私はいくつかのプログラミングの仕事をしてきました。それぞれに 20 ～ 50 人の開発者が参加し、プロジェクトは 3 ～ 5 年続きます。

毎回同じです。優秀なプログラマーもいれば、平均的なプログラマーもいます。全員が CS の学位を取得しており、全員がデザインパターンを読んでいます。意図は良いものです。人々は良いコードを書こうと懸命に努力していますが、それでも数年後にはコードがスパゲッティになってしまいます。モジュール A の変更により、突然モジュール B が機能しなくなります。コードには、それを書いた人以外には誰も理解できない部分が常にあります。インフラストラクチャを変更することは不可能であり、下位互換性の問題により、優れた機能を導入できません。半分の時間は、すべてをゼロから書き直したいだけです。

そして、私よりも経験豊富な人は、これを普通のこととして扱います。それは...ですか？そうでなければなりませんか？これを回避するにはどうすればよいですか、それとも現実として受け入れる必要がありますか?

編集: 皆さん、ここでの回答の量と質に感銘を受けました. このサイトとそのコミュニティロック！

score 30 · Accepted Answer

スパゲッティコードを防ぐ唯一の方法は、絶え間ない単体テストと組み合わせた冷酷な勤勉さです。それでも、それは応急処置にすぎません。注意を払うのをやめるとすぐにパスタが登場します。

スパゲッティコードが導入されたのは、誰かがその日怠けていたからということがよくあります。彼らはそれを行うためのより良い方法があることを知っていますが、時間がありません. そうなったとき、やるべきことはただひとつ。

彼らに電話して、それを変更するように依頼してください

通常、コードレビュー中により良い方法を指摘するだけで、人々のやる気を引き出すことができます。彼らがチェックインして、私が強く感じたら、自分でリファクタリングします。

私は時折、少し風変わりなように見えますか? きっとそうです。率直に言って、私は気にしません。私はそれについて馬鹿ではなく、可能な限り最善の社会的方法でこれに取り組みます. ただし、悪いコードをチェックインできるようにしておくと、将来のある時点でデバッグする必要があることがほぼ確実になります。私は今、少し高射砲を取り、正しいコードを入れたいと思います.

また、単体テストの文化もスパゲッティコードの防止に役立つと感じています。コードを適切にファクタリングしたスパゲッティコードを単体テストするのは、はるかに困難です。時間が経つにつれて、これにより、人々はコードをある程度因数分解したままにしておく必要があります。

score 12 · Accepted Answer

20 人から 50 人の開発者がおそらく問題です。これはかなり高く、すべてをチェックするには多くの管理とリソースが必要です。

プロジェクトをより小さな再利用可能なセグメントに分割することを検討します。コアシステムから特定のレイヤーを抽象化します。

score 11 · Accepted Answer

コードの異なる領域間に「ファイアウォール」を作成します。これを行うには、コードのさまざまな領域またはレイヤーを定義し、各レイヤーが応答する単一の API (Java では通常、これはインターフェイスで行われます) を定義します。API が使用する最小限のインターフェースまたはクラスが存在する必要がありますが、それらはそれらのレイヤーの内部について何も「認識」していません。たとえば、GUI はデータの保存方法を認識したり気にしたりしてはならず、データベースはデータがエンドユーザーにどのように表示されるかを認識したり気にしたりしてはなりません。

これらの API は石でキャストする必要はありません。ファイアウォールを汚染していないことを確認する限り、必要に応じて追加できるはずです。

score 7 · Accepted Answer

私はあなたが言うときが要点だと思います

すべてを最初から書き直したいだけ

ただそれを受け入れてください。
できるだけ多くの単体テストを使用してから、リファクタリングを一般的な方法にしましょう。
自動化された単体テストにより、変更によってリグレッションが発生しないことが保証されます。古いコードのリファクタリングに一定の割合の時間を費やすことで (つまり、新しい機能が少なくなります!)、既存のコードベースが古くなったり、少なくともそれほど速くなったりすることはありません。

score 7 · Accepted Answer

コードレビュー、コーディング標準、および企業ポリシー。

以下は当店に当てはまります - どんなお店か分からないので、走行距離は違うかもしれません。Team Foundation Server への移行中、私たちはコードの品質を維持することに重点を置きました。少なくとも、可能な限り品質を維持することを支援しました。追加するものの例:

コードレビューワークフロー - プロセスの一部としてコードレビューを実施します。コードがレビューされていない場合にチェックインが行われないようにするポリシーが含まれています。
TeamReview - 完全な "IDE 内" エクスペリエンスを提供することで、コードレビューの負担を軽減します。
チェックインポリシー (全般) - コードの流れを制御するために利用できる多くの便利な機能。チェックインの前にパブリックメソッドとプロテクトメソッドが文書化されていることを確認することや、対応するワークアイテムがなければチェックインできないことを確認することなどです。

先ほど言ったように、別のプラットフォームを使用している場合は、利用できるツールとできることが異なる可能性があります。ただし、可能な限り役立つツールを除外しないでください。それを使用して、ワークフローとその中で移動するアイテムを改善、制御、および監査できる場合は、少なくとも検討する価値があります。

プロセスの変更にはプッシュバックが伴うことを忘れないでください。私たちがこれを容易にするのに役立ったのは、古いバージョン管理/欠陥追跡システムから移行するためのトレーニングにポリシーを組み込むことです。

score 3 · Accepted Answer

多くの人が、カプセル化と優れた設計の基本原則に従っていないようです。

あなたが説明した問題を回避するには、物事を分離し、他の部分に依存しないようにすることが不可欠です。より高いレベルのデザイナーまたはアーキテクトが必要になる場合があります。これは、人々がいくつかの厳格なプロセスと変更管理を正当化している典型的なシナリオです。（私はそれを主張していません）

依存関係や相互関係を避け、パブリックインターフェイスのみを定義して使用する必要があります。もちろん、これは単純化しすぎですが、クラスの複雑さ、パブリックメソッド、コードのリバースエンジニアリングから構築された UML ダイアグラムなど、コードに関するいくつかの指標から多くのことを学ぶことができるでしょう。

score 3 · Accepted Answer

依存性注入を本格的に使用することで得られる疎結合は、非常に役立つ技術的機能だと思います。アプリケーションの断片をバラバラにすると、「興味深い」再利用によるスパゲッティが発生する可能性が低くなります。

代わりに、過度の断片化に向かっている可能性がありますが、それは別の問題であり、グローバルな構造上の問題ではありません.

score 3 · Accepted Answer

少なくとも 2 組の目がそれを見るまで、コードをコミットさせないでください。

score 3 · Accepted Answer

ソフトウェア業界の最大の問題は、プログラミングコードの品質が主観的な問題と見なされていることです。明確に定義された指標がなければ、きちんと整頓されていて、慣例に従うだけでは、品質が許容できることを保証するには不十分です。

これを変えようとする試みはありますが、十分な関心や受け入れを得ることはまずありません。これは主に、長い間確立されてきたプログラマーの文化が、エンジニアリングに似たものから遠ざかろうとすることに懸命に取り組んでいるためです。プログラミングの「純粋な芸術」哲学とは、20 人から 50 人の開発者全員が独自の方法でコードに苦労することを意味します。「大きな泥の玉」になります。

これを避けるには、すべてのコーダーを同じ「ページ」に配置するか、正規化されたコードを規則の一部にするか、開発チームが小規模 (1 ～ 3 人) であり、あなたが大カフナである場合の仕事を追跡します。いつか大規模なチームがより良いものを構築する方法を見つけるかもしれませんが、それまでは、10 点中 6 点に近づくことができれば、最高のチームでさえ非常に幸運です。私たちの業界がやるべきこと...

ポール。

score 2 · Accepted Answer

私はそれが正常だとは思わない。それが数年間そこにあったとき、これと戦うのは本当に難しい.

それを回避する唯一の方法は、態度を変えることです。

「機敏な開発者がソフトウェアの設計に対して持つ態度は、外科医が無菌手術に対して持つ態度と同じです。無菌処置が手術を可能にします。それがなければ、感染のリスクが高すぎて耐えられないでしょう。アジャイル開発者は、自分たちの設計について同じように感じています。ごくわずかな腐敗を開始させるリスクは、許容するには高すぎます。」マーティン C. ロバート「C# におけるアジャイルの原則、パターン、実践」</p>

アドバイスを得るために、この本を参照することを強くお勧めします。それはすべての「デザインのにおい」、その存在理由、およびそれらを離れることの結果を挙げています。これにより、現在の状況が適切ではないことを経営陣に納得させることができます。

幸運を！

score 2 · Accepted Answer

ソフトウェア開発の慣行に厳密に従う必要があります。コードレビューと、更新がシステム内の他のものに影響を与えていることを常に確認する単体テストが必要です。20 ～ 50 人の開発者は多いですが、それは可能です。この環境であなたを救う唯一の方法は、適切なプロセスを実装することです。強制的なコーディング標準も重要です。

score 2 · Accepted Answer

リファクタリング

できるだけきれいなデザインを保つように努めてください。これは簡単なことではありませんが、努力する価値はあります。

score 1 · Accepted Answer

ShoreandWardenのTheArtof Agile Developmentは素晴らしい本であり、「既存のプロジェクトへのXPの適用」（第4章）に関するセクションがあります。あなたが一生懸命戦わない限り、プロジェクトは時間とともに悪化します。そのような技術的負債を克服することは困難であり、受け入れ可能なリリースを出荷することはますます困難になります。唯一の解決策は、新しい機能を提供する速度を減らし、時間を節約してテストカバレッジとリファクタリングを改善することです。

通常、プロジェクトにはテストカバレッジがあまりなく、コードを完全にビルドして実行する10分間の自動スクリプトを実行するオプションがありません。代わりに、ほとんどのコードはテストが難しいように構造化されています。その場合の最良のオプションは、テストを容易にするためにコードを抽象化する目的でリファクタリングを開始しながら、可能な場合は単純なテストカバレッジを追加することです。

チームはコードをクリーンでテスト可能なものにするために時間を費やす必要がありますが、クリーンアップが「終了」するまでの間、配信を停止することはおそらくできません。したがって、新しい機能を追加しながら、段階的に実行する必要があります。それは大丈夫です、最初に最悪の領域を選んでください、そしてすぐに明白な利益を期待しないでください。最終的にそこに着くので、それを維持してください。すべての大規模なプロジェクトが悪いと言う声に耳を傾けないでください。

つまり、毎週少し時間をかけて片付けを行い、来週のコードが今週よりも優れていることを確認してください。

score 1 · Accepted Answer

システムのさまざまな部分の欠陥とパフォーマンスを追跡することで、問題を特定できます。システムが変更されると、設計または記述が不十分な機能またはモジュールは、欠陥の割合が高くなります。「問題のある」モジュールが特定されると、モジュール (アプリケーションではなく) を書き直す決定を下すことができます。

score 1 · Accepted Answer

より多くのコードレビューと、おそらくコードの所有権。

ランダムなコードをハックするだけなら、自分が「所有している」コードほど気にする必要はありません。プロジェクトの 1 つのモジュールを維持するのがあなたの責任であるなら、あなたは輝きたいです。

コードレビューは、自分のコードを見せるときです。

score 1 · Accepted Answer

継続的なリファクタリング。特に設計レベルでは、リファクタリングを行う必要があります。壊れたコードやデザインを見つけたら、それを修正する準備をしてください。これは、多くの場合、それ自体が壊れていないものを修正する場合です。それを除いて... それは壊れていることを明らかにしていないだけです... まだ。

score 0 · Accepted Answer

単体テストの作成を開始します。これにより、コードを分離し、バグ修正のフォローアップエラーを回避できます。カバレッジが良ければ、未使用のコードも簡単に削除できます。

coding-style - 何年にもわたってスパゲッティ コードを回避する方法はありますか?

18 に答える 18

Related

Reference

coding-style - 何年にもわたってスパゲッティコードを回避する方法はありますか?