プロジェクトを大きくするものは何ですか？[閉まっている]

好奇心から、小、中、大のプロジェクトの違いは何ですか？コードの行数または複雑さで測定されますか？

物々交換システムを構築しており、これまでのところ、ログイン/登録用のコードは約1000行あります。たくさんのLOCがありますが、これは大きなプロジェクトだとは思いません。これはそれほど複雑ではないからです。どのように測定されますか？

複雑。

複雑になるほど、プロジェクトのすべてを学ぶのが難しくなります。

おおまかに言うと、これは多かれ少なかれarbitrary意的であることに留意してください。複雑さ、コードのソース行、機能/ビジネス価値などのような他の要因の複合におけるプロジェクトの「サイズ」。非常に小さな製品でも、大量の価値などを提供できます。

• 2m以上のslocは、大規模から巨大なプロジェクトです。これらは一般に非常に複雑であるため、システム全体に「流fluent」な人はほとんどいません。むしろ、責任はコードの構造に沿ってモジュール化される傾向があります。これらのプロジェクトは、非常に大きなビジネス価値をもたらすことが多く、ミッションクリティカルな場合があります。また、技術的な負債やその他の遺産の懸念が重くのしかかることもあります。

• 100k-2m slocは中規模のプロジェクトです。これが私の中間です。プロジェクトは、ある程度の専門知識を必要とするほど複雑であり、ある程度の技術的負債が生じている可能性があります。また、ある程度のビジネス価値も提供する可能性があります。

• 10k-100kは小さなプロジェクトですが、専門家の検討が必要になるほど複雑ではないほど小さくありません。オープンソースの場合は、信頼できる人にコミットをレビューしてもらうことを検討してください。

• 10k sloc未満のものは本当に小さなものです。それはまったく価値を提供できないという意味ではなく、多くの非常に興味深いプロジェクトには非常に小さな痕跡があります（たとえば、ソースが〜2 kb（！）であるCamping）。一般的に、専門家でない人は、ドメインに関する知識をあまり必要とせずに、価値の懸念（バグの修正と機能の追加）を推進できます。

プロジェクトのサイズは、保守不能の程度によって測定されます。

いくつかの方法で推定される複雑さ：

1. 予算。予算が$ 10,000,000 +のプロジェクトは、たとえば$ 10,000未満のプロジェクトとはおそらくまったく異なります。これには、人件費、ソフトウェア、ハードウェア、およびプロジェクトの実施で発生したその他の費用が含まれます。
2. プロジェクトを完了するための作業時間。百万時間かかるのでしょうか？これは、1週間もかからない他のプロジェクトと比較して大きなプロジェクトであると言うプロジェクトもあります。スタッフを2倍にすることで誰かが考えるかもしれないので、人の時間は誤解を招く可能性があることに注意してください。
3. プロジェクトの構築物を使用しているハードウェア、他のシステム、および人々の量。101のシステムに何かが結びついている場合、それが単独で他のものに結び付けられていない場合よりも複雑になる可能性があります。

要件はこれを測定する良い方法のように聞こえるかもしれませんが、私が信じる非ウォーターフォール方法論を想定してプロジェクトが行われると、より多くの要件が見つかることがよくあります。

プロジェクトのサイズは、おそらくシステムが持つ要件の数によって最もよく測定され、要件をさらに減らすことはできません。

もちろん、より多くの要件はより多くの複雑さを意味しますが、常にそうとは限りません。

プロジェクト全体を単一の全体像として見ることがどれだけ難しいかによって、プロジェクトのサイズを測定します。たとえば、私が取り組んでいる機械学習の問題のための探索/プロトタイプコードベースがあります。コードはたったの5k行ですが、巨大なプロジェクトのように感じます。予測不可能な方法で相互作用する設定オプションがたくさんあります。その複雑さをすべて管理するために、コードベースのどこかで人間に知られているほぼすべての設計パターンを見つけることができます。設計は進化によって大きく成長し、必要な頻度でリファクタリングされないため、多くの場合、設計は最適ではありません。このコードベースで動作するのは私だけですが、物事がどのように相互作用するかにしばしば驚かされます。

一方、私の趣味のプロジェクトの1つは約3〜4倍のコードを持っていますが、基本的には互いにほぼ直交する数学関数のライブラリであるため、かなり小さく感じます。物事は複雑な方法で相互作用することはなく、各機能を分離して理解することは非常に重要です。見るべきものがあまりないので、それが存在するほど大きな全体像を見るのは簡単です。

任意の回答：最初からイベントソーシングとSOAを使用してどの程度プロジェクトを完了させたかったのか、プロジェクトがどれだけ大きいか。または、システムの作者がエヴァンの本「DDD：Tackling Complexity in the Heart of Software」を読んだこと;

互換性と範囲

複雑さと範囲私は、プロジェクトの実際の大きさを決定するのはそれだと信じています。ただし、プロジェクトのサイズに影響を与える可能性のある無形資産もいくつかあります。

必要条件

私が直面した最大の失敗は、要件の欠如でした。私の特定の状況では、営業マネージャーが要件を決定していました。彼の焦点は販売にありました...販売を得なければなりません。私たちが似たようなものを作ったので、彼の心では、顧客が求めていたことはそれほど複雑ではないようでした。あいまいな要件は、低価格のジョブと過剰なコミットメントにつながります。

CCMUの欠如

CCMUは、私が「Coo Ca Moo」（完全な相互理解をクリア）と呼ぶものです。顧客とCCMUが必要です。

CCMUが貧弱な小規模プロジェクトの場合、プロジェクトを2,3,4回以上実行することができます。したがって、単純な20時間のジョブは、ストレスの多いスタッフと非常に不満のある顧客を抱える60時間のプロジェクトに変わります。

スコープクリープ

これはあなたが思っているよりも頻繁に起こります。顧客は、A、B、Cをすでに実行しているため、DまたはFを追加することはそれほど難しくないはずだと判断します。また、セールスマネージャーがどのようにジョブを販売したかによって、これらのスコープクリープの期待は顧客にとって「無料」に見える場合があります。

その奇妙な、これらの答えの多くを読んで、私はプロジェクトのサイズを非常に異なって見ています。大企業で働いているのかもしれませんが、プロジェクトのサイズは、クライアントに対する可視性/望ましさのスケールと見なす傾向があります（作業領域によっては、同僚や実際の支払いをする顧客になります）。

複雑さは正解ですが、どのように推定するのですか？

要因は次のとおりです。

1. 拡張ポイント数
2. モジュールのレイヤー数（関数、クラス、クラスシステム、ライブラリ、共有ライブラリ、アプリケーション、ネットワークアプリケーションなど）
3. 依存関係の数（含まれるプラットフォーム）
4. 機能相互依存カウント。
5. 必要な非コードリソース（グラフィック/アート、駆動スクリプト（レベルデザインスクリプトなど）、およびアプリケーションのバージョンを完了するために必要なその他のリソースを含む）。

それらが多ければ多いほど、プロジェクトはより複雑になります。

LOC は多くの測定で不正確であることで有名ですが、実際には正確な測定方法がないものを測定しようとしていると思います。おそらく、代替手段は循環的複雑さかもしれません。

最終的には、プロジェクトの「大きさ」を定量化するのは難しいと思います。犬が大きいかどうかをどのように判断するかを尋ねるようなものです。それを測定する方法（質量、体積など）が複数あるだけでなく、個人的にはあまり有用ではありません。現実には、私の基準は「暗い路地で見た場合、この犬からどれだけ逃げる可能性が高い」というようなものになるでしょう。

そして、記録のために、私は一般的に1k行のコードを多くとは思わないでしょう。これは、コードのかなり大きな塊だろうが、それはないだろうという物事の壮大な計画でずっと。もちろん、言語に依存すると思います。たとえば、1k行のコードは、Cyのような言語のコードは、Pyhonのような言語のコードよりもはるかに少ないです。