前段時間，我和一個好朋友的一次談話中，聽到這樣一句話：
——程式設計師的數量會不斷增長——因為程式碼量不斷增長，並且不斷需要越來越多的開發人員來支援。
— 但程式碼已經過時，其中一些不再受支援。 甚至有可能存在某種平衡。
幾天後想起它們，我想知道隨著時間的推移，維護程式碼是否需要越來越多的資源，最終會導致新功能的開發陷入癱瘓，還是需要無限增加程式設計師的數量？ 數學分析和微分方程有助於定性評估支持金額對發展的依賴性並找到問題的答案。
問題一。 能支持「吃掉」所有開發資源嗎？
考慮一個程式設計師團隊，其中參與者的數量是恆定的。 他們的工作時間比例 
(）用於開發新程式碼，剩餘時間 去支持。 在模型的假設範圍內，我們假設第一類活動旨在增加程式碼量，第二類活動旨在更改程式碼量（修正錯誤）並且不會對程式碼量產生重大影響。
讓我們表示 截至該時間點所寫的全部程式碼量 。 假設編寫程式碼的速度成正比 ，我們得到：
很自然地假設維護程式碼的勞動成本與其數量成正比：
或
從那裡
我們得到一個可以輕易積分的微分方程式。 如果在初始時刻代碼量為零，則
在 功能 和 。 這意味著隨著時間的推移，新功能的開發逐漸減少到零，並轉移所有支援資源。
不過，如果在這段時間裡 程式碼變得過時並且不再受支持，然後是一次需要支援的程式碼量 已經相等 然後
а 是帶有延遲變元的微分方程的解 [1]：
這種方程式的解是透過指定值唯一決定的 “在時間開始之前” 。 由於程式碼在初始時刻之前尚未編寫，因此在我們的例子中 在 .
讓我們來看幾個例子。 我們將以年為單位來衡量時間，以數千行來衡量程式碼量。 那麼對於 十數量級的值是可以接受的，我們取50和100。也就是說，開發團隊一年內將分別編寫五十和十萬行程式碼。 為了 可接受的值可能是： , , 。 這意味著開發團隊可以支援一年內編寫的程式碼量，無論是四分之一、一半還是全職。 作為代碼的平均生命週期，我們將設定以下值：1年、2年和4年。 對方程式進行數值求解，我們得到了函數行為的範例 對於某些參數組合 .
函數的行為 隨著程式碼的老化，它已經改變了。 功能不再單調，而是隨著時間的推移波動“平靜下來”，並有趨向 到某個恆定值。 圖表顯示：更多 , и ，也就是說，程式碼老化越慢，新程式碼的開發速度越快，程式碼品質越低，留給新功能開發的資源就越少。 人們希望至少舉出一個例子，其中 「依偎」接近零。 但這需要選擇非常差的開發品質指標和不會長期老化的程式碼。 即使在左下圖中，也為新功能保留了大量資源。 因此，第一個問題的正確答案是這樣的：理論上──是的，這是可能的； 實際上——幾乎沒有。
無法回答的問題：
- 是不是真的 趨於某種極限 對全部 ？ 如果不適合所有人，那麼適合哪些人？
- 如果存在極限，它的值如何取決於 ?
問題二。 程式碼維護會導致程式設計師數量無限增長嗎？
讓我們表示 參與開發新程式碼的程式設計師數量。 如上， — 到某個時間點為止所寫的程式碼量 。 然後
讓程式碼支援保持忙碌 程式設計師. 考慮到代碼老化，
從那裡
如果 ，然後
因此，第二個問題的答案是否定的：如果新程式碼的開發人員數量有限，那麼在程式碼老化的情況下，支援並不能導致程式設計師數量的無限增加。
結論
所考慮的模型是「軟」數學模型[2]。 它們很簡單。 儘管如此，模擬結果對參數值的依賴性符合實際系統的預期，這有利於模型的充分性和足夠的精度來獲得高品質的估計。
參考文獻
1. Elsgolts L.E.，Norkin S.B. 帶有偏差參數的微分方程理論簡介。 莫斯科。 《科學》出版社。 1971年。
2.阿諾德六世“硬”和“軟”數學模型。 莫斯科。 MCNMO 出版社。 2004年。
來源： www.habr.com