リターンのない複雑なポイント。あなたはそれを何と呼びますか？

ソフトウェア開発者としての私の主な仕事の1つは、複雑さを管理することです。

ただし、一部のプロジェクトでは、複雑さのレベルが非常に高くなり、ある種の「リターンなし」ポイントに達する瞬間があります。この瞬間を過ぎると、すべてを最初から書き直す必要がある場合よりも短い時間でプロジェクトを許容できるレベルの複雑さに戻すことはできません。

この特定の瞬間にはプログラマーの方言で名前がありますか（ゴルウィンのトロールの法則に似たもの）？

-編集-

はっきりしない場合は申し訳ありません。この「瞬間」には正式な名前があるとは思いませんし、重大な指標でもありません。私はxkcdの「バルマーピーク」の精神で何かを考えていました。

複雑さよりも保守性の問題です。

この現象は「技術的負債」と呼ばれ、危機的なレベルに達すると、プロジェクトは破産に向かっています。

それはあなたが意図したものですか？

「過剰な複雑さのポイント」は、英語では次のように呼ばれます。

なんてこった、このクラップスとは。

問題は、これは実際に単純なものに適用できるが、同じ反応をするような恐ろしい方法で実装されていることです。

したがって、非常に恐ろしいものから非常に複雑なものを区別することは困難です。

ただし、実際にすべてのソフトウェアで発生する傾向があるのは、次のようなプロセスです。

ステップ1：優れた仕様を作成し、優れた設計を行い、優れたものを実装します。みんな幸せ。

ステップ1の終わりに、開発者は自分のデザインの素晴らしい優雅さに自分自身を祝福し、「他の人が将来物を追加するための素晴らしい遺産があります。それは素晴らしいことであり、世界はより良い場所。"

ステップ2：いくつかの変更が加えられ、物事が追加され、新しい機能が含まれます。ステップ1のアーキテクチャと構造により、これは非常に簡単なプロセスになりました。[しかし、おっと、 "cruft factor"が少し増えただけです。]

ステップ2の終わりに、開発者は自分のデザインの素晴らしい優雅さに自分自身を祝福し、幸せな考えを捨てます。「ステップ1でこれらのすべてを許可したことはとても賢いことです。これはとてもうまくいきました。将来的に他の人が物事を追加するために、ここは素晴らしいものであり、世界はより良い場所になるでしょう。」

ステップ3：より多くの変更が行われ、より多くのものが追加され、より多くの新しい機能が追加され、多くのものが変更され、ユーザーのフィードバックが実際に聞かれています。

ステップ3の終わりに、開発者は自分の設計の素晴らしい優雅さに自分自身を祝福し、「このアーキテクチャは非常に多くの変更を簡単に取り入れることができるのでかなりいいと思います。しかし、私は少し不幸です。 XとYとZについてです。それらはもう少しクリーンアップできますが、!!!!!!ああ!!!ステップ1でこれらすべてを許可したことはとても賢いです。これはとてもうまくいきました。将来的に物事を追加する他の人たちは、素晴らしいことであり、世界はより良い場所になるでしょう。」

ステップ4：ステップ3と同じ

ステップ4の終わりに、開発者は次のように考えます。「非常に良かったものは、維持するためにいものになっています。本当に重大な変更が必要です。これに取り組むのはあまり好きではありません。リファクタリングが必要です。私は彼にそれが6週間を必要とし、これの終わりにユーザーが見ることは何もないと言うとき...と言いますが、私はこれを行うことでさらに5年間のおいしい将来の修正範囲を得ます....うーん..ビールを飲みにパブに行く時間。」

ステップ5：多数の変更を行う必要があります。

そして、ステップ5の間に、開発者は互いに「このコードはダメです。誰がこれを書いたのですか。彼らは撃たれるべきです。恐ろしいです。私たちはそれを書き直さなければなりません。」

ステップ5は致命的です。これは、重要な要素が非常に悪くなっているため、コードにさらにいくつかの変更を加えることはできず、いくつかの大きな変更が必要です。

ステップ5の問題は、それを捨ててやり直したいという欲求です。これが致命的である理由は「Netscape Factor」です。グーグルイット。企業はこの時点で死にます。なぜなら、再び始めることは、事実ではなく約50％の仮定、知識ではなく150％の熱意、謙虚ではなく200％のrog慢から始まることを意味するからです（「あの男たちはとても愚かだった！」そして、あなたはたくさんの新しいバグを導入します。

最善の方法は、リファクタリングすることです。少しずつ変更します。アーキテクチャが少し疲れてきたら、修正します。追加、拡張、改善。徐々に。途中の各ステップで、テスト、テスト、さらにテストを行います。このような漸進的な変更は、10年後、現在および元のコードが祖父のxのようになることを意味します（「10個の新しいヘッドと3個の新しいハンドルがありましたが、それでも祖父のaです」）。つまり、共通点はあまりありません。しかし、古いものから新しいものに徐々に慎重に移行しました。これにより、リスクが軽減され、顧客にとっては、腹立たしい要因が減少します。

この瞬間を認識するのは難しく、適切なプロセスで回避できることに同意します。しかし、質問はそれを何と呼ぶか​​についてでした。実際の経済学では、「収益の減少」という概念があります。プロセス内の1つのリソースへの入力を増やすと、ユニットあたりの全体的な利益が減少するポイントです。これは確かにコーディングに当てはまり、抽象化、再利用などの優れたものでさえ、利益を減らすようなポイントを持っています。一般的なプログラミング固有の用語は「オーバーエンジニアリング」です。これを行う傾向がある人にとって、私はジョエルの用語「建築宇宙飛行士」が好きです。

新しいツールを備えた新しいチームは、それを見つけるためだけに、より安価で、より高速に、より信頼性の高いコードを実行できるという誤った印象の下で、あまりにも頻繁に良いコードが破棄されます。

• 複雑さは非文書化要件にあります
• 新しいツールは、約束されたフラッシュWebサイトよりも使いにくい
• 新しいチームは思っていたほど「ホット」ではありません

おそらくあなたが説明した時間は、いくつかのコードベースで到着します（私はそう思っていました）。私は、古いコードがプロジェクトを終わらせたり、コードを書き直してプロジェクトを保存したりするケースを個人的に経験したことがありません。

このケースでは、特定の問題のあるモジュールまたは設計を特定するためにメトリックが使用され、それらが選別されて置き換えられた場合は含めません。

この理論的な「瞬間」の本当の問題は、事実の後にしか認識されないということです。同僚がサイコパスでない限り、コードベースへのすべてのコミットは、そのコードベースの改善であるという信念で行われます。その「瞬間」に合格したことがわかる次の混乱を振り返るだけです。

しかし、私はそれに名前を付けることができるのが好きです。「紳士」と言うことができます。仲間の開発者をあなたの周りに引き寄せてください。「私たちは保守性のヘレスポントを越えました。

名前があるかどうかはわかりませんが、名前がなければ「メルトダウンポイント」と呼ぶことをお勧めします。

これはあまり興味深い質問ではありません。

確かに簡単です。

非常に些細なことなので、私たちは多くの対処方法を進化させてきました。

1. ウォーターフォールの方法論。多くの人が要件と設計ドキュメントの確認に多くの時間を費やして、複雑さが管理されていることを確認します。

2. アジャイル手法。誰かの問題を解決し、ソフトウェアをリリースするためにすぐに適用できるものについて議論する時間が少なくなります。誰もが何かをリリースすることに集中しているため、複雑さが管理されます。

誰もが「複雑さ」と格闘するのは、方法論に従わず、時間を適切に管理できないためです。

• ウォーターフォール方法論の詳細な監督なし。要件、アーキテクチャ、高レベルの設計、または詳細な設計レビューで中間作業成果物をレビューする必要はありません。

• アジャイル手法では、スプリントの期限や適切なユースケースの優先事項はありません。ユーザーに何かをできるだけ早くリリースすることに焦点を合わせていません。

目標を設定することにより、複雑さを制限する必要があります。

複雑さと格闘するということは、目標が設定されていないか、適切に報われていないことを意味します。

「ターニングポイント」はありません。複雑さの管理がなんらかの問題である場合、組織的に何かがすでに間違っています。

（大きな）プロジェクトとコードの複雑さを増大させるリスクを視覚化および監視する方法があります。それらが適度に適用される場合、戻りのないポイントの新しい名前は必要ありません。（openHPIに関連するMOOCがあります：https ://open.hpi.de/courses/softwareanalytics2015/ ）

構造的な複雑さは、大規模なチームのソフトウェア設計だけでなく、一般的な設計上の問題です。視覚化は、構造の複雑さの管理における最初のステップです。行列と有向グラフもこの目的に使用できます。

構造の複雑さを軽減する方法は、http：//www.buch.de/shop/home/suche/？fq = 3540878890です。

• モジュール化
• フィードバックループの回避
• 三角測量

さらに、公理的設計の概念があります。https：\ en.wikipedia.org \ wiki \ Axiomatic_design \この概念により、不必要な複雑さによる信頼性の問題を回避できます。

したがって、多数のメソッドが利用可能です。プロジェクトは十分に大きくなるので、最終的には常にそれらについて考える決定についてです。