プロジェクトを大きくするものは何ですか？
好奇心から、中小規模のプロジェクトと大規模プロジェクトの違いは何ですか？コードの行数または複雑さによって測定されますか、それとも何ですか？
物々交換システムを構築していて、これまでのところ、ログイン/登録用のコードが約1000行あります。 LOCはたくさんありますが、これは私の最初のプロジェクトですがそれほど複雑ではないので、私はそれを大きなプロジェクトとは見なしません。それはどのように測定されますか？
複雑。
複雑さが増すほど、プロジェクトのすべてを学ぶことが難しくなります。
大まかに私が物事を一致させる方法-これは多かれ少なかれ恣意的であることを覚えておいてください。複雑さ、コードのソース行、機能の数/ビジネス価値など、他の要素を組み合わせたプロジェクトの「サイズ」。非常に小さい製品は、大きな価値などをもたらす可能性があります。
2m + slocは大規模から巨大なプロジェクトです。これらは一般に非常に複雑であるため、システム全体で「流暢」な人はほとんどいません。むしろ責任は、コードの構造に沿ってモジュール化される傾向があります。これらのプロジェクトは非常に大きなビジネス価値をもたらすことが多く、ミッションクリティカルな場合があります。また、技術的な負債やその他のレガシーの懸念の重荷の下にあることもあります。
100k-2m slocは中規模プロジェクトです。これは私の中立の立場です。このプロジェクトは専門家の知識を必要とするほど複雑であり、ある程度の技術的負債が発生している可能性があります。また、ある程度のビジネス価値ももたらします。
10k-100kは小さなプロジェクトですが、専門家の検討が必要となるほど複雑ではないほど小さくはありません。オープンソースの場合は、信頼できる人にコミットをレビューしてもらうことを検討してください。
10k sloc未満のものは実際には小さなものです。それがまったく価値を提供できないという意味ではなく、多くの非常に興味深いプロジェクトには非常に小さな痕跡があります（例：Camping、ソースが〜2） kb（！））。一般に、専門家ではない人は、ドメインについてあまり知らなくても、価値の懸念を引き起こし、バグを修正し、機能を追加できます。
プロジェクトのサイズは、保守性の程度によって測定されます。
いくつかの方法で推定できる複雑さ：
- 予算。予算が$ 10,000,000以上のプロジェクトは、たとえば$ 10,000未満のプロジェクトとはかなり異なります。これには、プロジェクトを実施するために発生した人件費、ソフトウェア、ハードウェア、およびその他のコストが含まれます。
- プロジェクトを完了するための作業時間。 100万時間か何かかかりますか？これは、1週間もかからないプロジェクトと比較して、プロジェクトによっては何年もかかる可能性があり、他のプロジェクトと比較して大きなものだったという、時系列的な要因と見なすこともできます。誰かがスタッフを2倍にしてプロジェクトに取り組んでいると考えるかもしれないように、人の時間は誤解を招く可能性があることに注意してください。
- プロジェクトが構築しているものを使用しているハードウェア、他のシステム、および人々の量。何かが101システムに結びついている場合、それが独立していて他に何も結び付けていない場合よりも複雑になる可能性があります。
要件はこれを測定する素晴らしい方法のように聞こえるかもしれませんが、プロジェクトがウォーターフォールではない方法論を想定して行われるときに、より多くの要件が見つかることがあります。
プロジェクトのサイズはおそらく、システムの要件の数によって最もよく測定され、要件をさらに減らすことはできません。
もちろん、より多くの要件ほとんどはより複雑であることを意味しますが、常にそうであるとは限りません。
私は、プロジェクト全体を単一の全体像として見ることがどれほど難しいかによって、プロジェクトのサイズを測定します。たとえば、私が取り組んでいる機械学習の問題の探索/プロトタイピングコードベースがあります。わずか5000行のコードですが、巨大なプロジェクトのように感じられます。予測できない方法で相互作用する設定オプションはたくさんあります。コードベースのどこかに存在することがわかっているほぼすべての設計パターンを見つけて、そのすべての複雑さを管理できます。物事は進化によって大きく成長し、必要な頻度でリファクタリングされないため、デザインはしばしば最適とは言えません。このコードベースで動作するのは私だけですが、物事の相互作用に驚かされることがよくあります。
一方、私の趣味のプロジェクトの1つは約3〜4倍のコードがありますが、基本的には互いに直交する数学関数のライブラリーであるため、はるかに小さく感じられます。物事は複雑な方法で相互作用することはなく、各機能を個別に理解するのはかなり良いことです。全体像が少ないので、全体像が見やすいです。
任意の答え：プロジェクトは、イベントソーシングとSOAを最初から使用してどのくらいの規模で達成したいと思っていますか。または、システムの作成者がEvanの本「DDD：Tacklingソフトウェアの中心にある複雑さ」;）
複雑さと範囲
複雑さと範囲は、プロジェクトの実際の大きさを決定するものだと思います。ただし、プロジェクトのサイズにも影響を与える可能性のある無形資産がいくつかあります。
必要条件
私が直面した最大の失敗は、要件の欠如でした。私の特定の状況では、営業マネージャーが要件を決定していました。彼の焦点は販売でした...販売を得なければなりません。私たちが似たようなものを構築したので、顧客が求めていることは彼の心の中でそれほど複雑ではないように見えました。あいまいな要件は、低価格の仕事と過大な期待につながります。
CCMUの欠如
CCMUは、私が "Coo Ca Moo"（クリア完全相互理解）と呼んでいるものです。顧客と一緒にCCMUを用意する必要があります。
CCMUが不十分な小さなプロジェクトの場合、プロジェクトを2、3、4回以上実行する必要があります。したがって、単純な20時間の作業は、ストレスがたまったスタッフと非常に不満な顧客を伴う60時間のプロジェクトに変わります。
スコープクリープ
これはあなたが思っているよりも頻繁に起こります。既にA、B、Cを実行しているので、DやFを追加するのもそれほど難しくないはずだとお客様が判断しました。この動作がチェックされていない場合は、小規模プロジェクトを中規模プロジェクトに変えることもできます。そして、セールスマネージャーがどのようにジョブを販売したかに応じて、これらのスコープクリープの期待は顧客に "FREE"のように見えるかもしれません。
奇妙なことですが、これらの回答の多くを読んでいると、プロジェクトのサイズの見方が大きく異なります。多分それは私が大企業で働いていることですが、私はプロジェクトのサイズをそのクライアントへの可視性/望ましさのスケールのより多くのものとして見る傾向があります（あなたの仕事の領域に応じて、これらは同僚や実際の支払い顧客になることができます）。
複雑さは正しい答えですが、それをどのように推定するのですか？
要因は次のとおりです。
- 拡張ポイント数
- モジュールレイヤー数（関数、クラス、クラスシステム、ライブラリ、共有ライブラリ、アプリケーション、ネットワークアプリケーションなど）
- 依存関係の数（プラットフォームを含む）
- 相互依存カウントを備えています。
- 必要な非コードリソース（グラフィックス/アート、駆動スクリプト（レベルデザインスクリプトなど）、およびアプリケーションのバージョンを完了するために必要なその他のリソースを含む）。
それらが多いほど、プロジェクトは複雑になります。
LOCisは多くの測定で不正確であることで悪名高いが、正確な測定方法がないものを測定しようとしていると思う。おそらく、代替案は 循環的複雑度 かもしれません。
結局のところ、プロジェクトの「大きさ」を数値化するのは難しいと思います。犬が大きいかどうかをどのように判断するかを尋ねるようなものです。それを測定する方法（質量、体積など）が複数あるだけでなく、個人的にはあまり役に立たないと思います。現実は、私の基準はおそらく「暗い路地で見た場合、この犬から逃げる可能性はどれくらいあるだろう」のようなものになるでしょう。
そして、記録のために、私は一般に1k行のコードが多くなるとは考えません。それはかなりの量のコードですが、グランドスキームではそれではありません。もちろん、それは言語に依存すると思います。たとえば、1k行のコードは、Pyhonのような言語よりもCのような言語のほうがmuch少ないコードです。