以前に書かれたコードを保守するには何人のプログラマーが必要ですか?

しばらく前、私と親友の間で次のような会話が交わされました。

— プログラマーの数は常に増加します。コードの量は増加しており、それをサポートするために常により多くの開発者が必要になるためです。
— しかし、コードは古くなり、一部はサポートされなくなりました。 ある種の均衡が存在する可能性さえあります。

数日後それらのことを思い出して、時間の経過とともにますます多くのリソースを必要とするコードの保守は、最終的に新しい機能の開発を麻痺させる可能性があるのではないか、それともプログラマーの数を際限なく増やす必要があるのではないかと疑問に思いました。 数学的分析と微分方程式は、開発に対する支援額の依存性を定性的に評価し、疑問に対する答えを見つけるのに役立ちました。

質問 XNUMX。 サポートはすべての開発リソースを「使い果たす」ことができますか?

参加者の数が一定であるプログラマーのチームを考えてみましょう。 労働時間のシェア () は新しいコードの開発に費やされ、残りの時間は 応援に行きます。 モデルの前提条件内では、最初のタイプのアクティビティはコードの量を増やすことが目的であり、XNUMX 番目のタイプのアクティビティはコードの量を変更する (エラーを修正する) ことが目的であり、コードの量に大きな影響を与えないと仮定します。

と表しましょう その時点までに書かれたコードの全量 。 コードを書く速度は比例すると仮定する 、 我々が得る：

コードを保守するための人件費はコードの量に比例すると考えるのが自然です。

または

そこから

簡単に積分できる微分方程式が得られます。 最初の時点でコードの量がゼロの場合、

に 機能 と 。 これは、新しい機能の開発が時間の経過とともに徐々に削減され、すべてのリソースがサポートに移管されることを意味します。

ただし、その時間内であれば、 コードが時代遅れになりサポートが終了すると、一度にサポートが必要なコードの量が増加します。 すでに等しい その後

а は遅延引数を使用した微分方程式の解です [1]:

このような方程式の解は、値を指定することによって一意に決定されます。 「時の始まりの前に」 。 最初の瞬間より前にはコードがまだ書かれていなかったため、この場合、 при .

いくつかの例を見てみましょう。 時間は年単位、コード量は数千行単位で測定します。 それから 数十のオーダーの値は許容されますが、ここでは 50 と 100 を採用します。つまり、開発チームは XNUMX 年でそれぞれ XNUMX 行と XNUMX 万行のコードを書くことになります。 のために 許容可能な値は次のとおりです。 , , 。 これは、開発チームが四半期、半分、またはフルタイムであっても、1 年に作成するコードの量をサポートできることを意味します。 コードの平均寿命として、2 年、4 年、XNUMX 年の値を設定します。 方程式を数値的に解くと、関数の動作の例が得られます。 一部のパラメータの組み合わせでは .

関数の動作 コードが古くなると、コードも変化します。 関数は単調ではなくなり、時間の経過とともに変動が「落ち着く」傾向があります。 ある一定の値に設定します。 グラフは次のことを示しています。 , и つまり、コードの老化が遅いほど、新しいコードの開発が速くなり、コードの品質が低下するため、新しい機能の開発に残されるリソースが少なくなります。 少なくとも XNUMX つの例を示したいという要望がありました。 ゼロに近い「寄り添う」。 しかし、これには、非常に劣悪な開発品質指標と長期間劣化しないコードを選択する必要がありました。 左下のグラフでも、新機能のためにかなりの量のリソースが残っています。 したがって、最初の質問に対する正しい答えは次のとおりです。理論的には、はい、可能です。 実際にはほとんどありません。

答えられなかった質問:

1. それは本当ですか である程度の限界に達する傾向がある みんなの ? 全員に当てはまらないとしたら、誰に当てはまりますか?
2. 制限が存在する場合、その値はどのように依存しますか ?

質問 XNUMX。 コードのメンテナンスにより、プログラマーの数が無制限に増加する可能性がありますか?

と表しましょう 新しいコードの開発に携わるプログラマーの数。 上記のように、 — ある時点までに書かれたコードの量 。 それから

コードサポートを常に忙しくしておく プログラマー。 コードの経年劣化を考慮すると、

そこから

もし その後

したがって、XNUMX 番目の質問に対する答えは否定的です。新しいコードの開発者の数が限られている場合、コードが古くなっている状況では、サポートによってプログラマの数を無制限に増やすことはできません。

まとめ

考慮されるモデルは「ソフト」数学モデルです [2]。 とてもシンプルです。 それにもかかわらず、シミュレーション結果のパラメーター値への依存性は実際のシステムで予想されるものに対応しており、これはモデルの適切性と高品質の推定値を取得するのに十分な精度を裏付けています。

参照

1. エルスゴルツ L.E.、ノーキン S.B. 逸脱した議論を伴う微分​​方程式の理論への入門。 モスクワ。 出版社は「サイエンス」。 1971年。
2. アーノルド V.I. 「ハード」および「ソフト」数学モデル。 モスクワ。 出版社はMCNMO。 2004年。

出所： habr.com