程式軟體的版本釋出也會導致內卷化？ - GeePawHill

banq發表於2021-05-10

由中央高智慧部門協調和控制軟體的大批次釋出經常會失敗，其原因是由於數學NP問題以及人類之間的弱相互影響。
大多數公司以某種命令和控制方法開始軟體版本釋出，這是一種中央智慧組織推動和控制工作流程，批次大小為N的釋出策略是問題所在。
 
首先是數學上行不通，像很多問題一樣，我們可以使用N（在我們的案例中為故事總數，依賴項數量，受影響的模組數量，“合併衝突”的數量之和）作為這個問題的輸入數量的粗略指標。隨著N的增加，大多數問題都變得更難解決。
我們可以使用採用N的某種表示式來表達他們要付出多少努力。如果該表示式是多項式，則稱為P問題。如果不是，則稱為NP問題。
這個問題就變成了計算機中複雜性的問題：NP Complete問題（NP完全問題），就是說即使N的增加很少，也會使難度增加到驚人的大。
直覺是，可靠地交付批次大小為N的發行版的問題是NP complete（完全問題），這是一種軟體的包裝，是確切的。
人與機器始終以小N來解決NP完全問題的特定情況。關鍵：並不是每次例項都是不可解決的。確切地說，N的微小增加會迅速導致此類問題“在宇宙熱死之前無法可靠地解決”。
“可靠地”這個詞很重要。您會看到，在解決NP完全問題時，可以透過生成候選解決方案並進行嘗試來實現。如果問題有解決方案，那麼您可能會在第一次嘗試時就找到它。
 
這使我想到了第二個令人著迷的方面：團隊可以花很長時間*經歷*這個問題的NP完全問題，而沒有意識到它。在這場比賽中，我們成功了一段時間，也許十分之一。但是我們失敗了十分之九。但是我們更容易記住成功：“我們*幾乎*做到了！”
幾個小小的發行問題並不難解決，但是我們花了幾個小時瘋狂地奔波，急於捆綁新發現的遺漏的API端點，重建我們的應用程式，然後重新部署它。或者，在糟糕的日子裡，我們沮喪地流著淚回去。
我們每個回合都會遇到一個或兩個問題？他們每次都是不同的小問題：例如忘記了此連結、沒有開啟功能標誌、不知道該功能依賴於我們刪除的欄位，每次碰到的問題都是小的狗屎，但是不同的狗屎。
我們沒有在問題中看到模式，因為它不是模式，而是元模式：由於組合函式丟擲了太多細節供我們考慮，因此出現了問題。我們的N開始啟動使我們的問題無法可靠地解決。
 
第三個令人著迷的方面：軟體釋出還經常運轉順利。這些偶然的勝利徹底使水變得渾濁，因為它們確實只是組合運氣。但是他們使我們相信，*每次*都有可能幸運。
可以肯定的是，人們可以採取措施改善自己的運氣。在遊戲中，這稱為作弊。在電腦科學中，這確實是非常聰明。但是你不能消除運氣。它內建於我們解決NP完整問題的性質中。
 

內卷化
因此，當我們失敗時，我們會做兩件事：

  • 1）指責我們缺乏努力和意志，
  • 2）增加更多規則，門檻和檢查。

“我們只是沒有盡力而為。” “我們需要將其新增到我們要檢查的事物列表中。”我們提高了釋出活動的嚴肅性，確保每個人都知道真正嘗試，花時間，認真思考，避免犯下愚蠢錯誤的重要性。我們變得，我在這裡不是在開玩笑，非常*憂鬱*，皺著眉頭，若有所思地點頭。
我們只有少數幾個人，我們要求他們協調所有這些工作，並每次都堅持工作，直到釋出完成為止。我們獎勵他們，但我們也要求他們在高壓力下長時間工作，要求他們英勇。我們升級了流程。有新的簽收。有清單。透過通用的自動化程式碼質量系統有強制性通行證。有一個正式的滾動時間表，每個人都簽署了每個任務。
奇怪的是，儘管這些調整旨在幫助我們控制N個批次，但它們往往具有使N變大的實際效果，因為現在它會將這些額外的過程元素合併到問題中。
提高嚴肅性和賭注以後，也加劇了緊張局勢。我們越來越發展到以責備為中心（內卷化）。我們更加了解所謂的“長杆”政治，沒有人願意成為帳篷中的長杆。我們生氣了。
 
所有這一切都在發生，因為我們的N已經增長到足以破壞我們的演算法的程度。我們已經達到了一個問題的新的複雜層面，該問題太大了以至於無法解決。
我們已經隱式或顯式地假設：1批10個的大小與10批每批大小1個是完全相同，甚至更少，但是NP完整性說那是不對的。批次大小為10的組合殺手會殺死我們。
 

釋出關鍵技術
釋出關鍵技術包括：

  • 1）pull & swarm：程式設計師拉取一個版本的原始碼，以該原始碼為中心，作為一個整體進行“交付”。我們使用整體程式設計，或成對，甚至只是坐在一起。一次一個故事，一路走過去。
  • 2）測試驅動的開發：在編寫程式碼之前進行測試比在編寫程式碼之後進行測試更快，更便宜。但事實是，它只有在測試程式碼編寫完成後才更“有效”。這是我們自以為是的基本一線安全網。
  • 3）基於主幹的開發：我們不使用複雜的源分支策略來驅動N。相反，我們從主幹拉取程式碼，推向主幹，從主幹測試，從主幹交付。
  • 4）注重路徑的故事和程式碼設計：我們對故事和程式碼的設計不僅要著眼於最終的工作，還必須著重於它們可以被髮布，而又仍然小到可以容納它們的路徑，這將涉及根本的風格變化。
  • 5）穩定且值得信賴的自動化：希望該過程的每個環節都能實現自動化。自動化需要堅如磐石，甚至比應用程式本身更堅固。必須對其進行維護並將其擴充套件到我們的最高水平。

這五種技術中的每一種都需要學習和實踐，並且不能透過一道命令聖旨來立即開啟其中的任何一種。我和其他人中的一些人已經撰寫了廣泛的文章，並提出了各種方法來邁出小步。
 

總結
隨著N的增長，問題變得更加困難，以至於我們的所有進展都將停滯不前。這不是意志的失敗，也不是規則的不足，而是簡單的組合數學問題。
中央智慧部門可以將某個NP完整問題的大批次釋出釋出到某個N，但不能超出此範圍。否則它將會失敗，更加頻繁失敗。對於成長中的組織而言，看到這一點並採取相應的措施是一項嚴峻的挑戰。



 

相關文章