這樣一個軟件公司該怎麼辦

60多年前，我們公司一羣無知無畏充滿理想的程序員從俄羅斯那裏裏找了一個免費的開源軟件框架，進行了漢化以後，寫了幾行漏洞百出的代碼，產品居然上線運營了。系統試運行期間還算正常，但是隨着系統外圍接口的增加，系統固有的問題就暴露出來了。30年前，新CTO實在看不下去了，重構了部分代碼，改進了部分用戶體驗，但框架依舊是原來的舊框架。這幾年，新代碼和舊框架嚴重不兼容，產品瀕臨崩潰，用戶流失嚴重。關鍵是那個開源框架設計思路有問題，還沒哪個使用它的產品長期穩定運行過，後來連俄國人自己都拋棄不用了。

    其實這個軟件最初設計思路就是單線程設計，這有一個前提就是單線程必定是強壯和穩固的，但是這個前提只是存在於理論上，並沒有實例證明。因此當世界開始流行多核處理，並行處理，甚至已經有部分軟件實現了雲計算的時候，單線程設計的先天缺陷就暴露出來了，主要問題在於單線程佔有所有系統資源而且不受控制，甚至連原來系統的保留資源都被佔用了，線程的運行方向就變得不可控，系統魯棒性經受了嚴重的考驗。

    這一切在用戶界面上，就是隔三差五跳出應用程序錯誤。當用戶試圖開啓調試模式的時候，由於單線程控制了所有的輸入和輸出，象資源利用率、資源效率等指標都被屏蔽了或被修改了，但是系統還告知用戶“由於你的操作不當，系統資源暫不可用”，用戶還只能點“確定”按鈕，然後等待資源可用。

    相對而言，多線程的設計考慮到了多線程並行運行，或暫時某一線程優先、其他線程等候等情況，雖然存在線程之間切換成本，有時候也存在算法不當致使多線程搶奪資源的情況，但是多線程畢竟保證了系統的穩定性，用戶可以藉助不同的線程完成程序的運行，至少在用戶體驗上沒有本質差別，運算結果也能基本準確。

    雲計算則更爲領先，雲計算使用了更先進的虛擬技術，採用分佈式計算的方式來處理用戶請求，在短時間內作出響應。用戶可藉助某些通用組件和程序包，實現跨軟件聯合計算運行。但是目前，在虛擬技術的耦合度上還存在一些問題，比如某些虛擬技術一發動全身、存在安全組件等級下降等問題。

    當然了，單線程、多線程和雲計算互相併不兼容。單線程指責多線程技術在業界形成了壟斷；多線程則一直都在打壓雲計算的市場份額；雲計算呢，到現在還沒承認單線程資源分配方式的技術標準！

    但是從目前的用戶體驗來說，單線程已經到了幾乎難以爲繼的地步了。這時我們該怎麼辦呢？第一種方法是繼續修bug打補丁，補丁實在太多，工程師和現有的經費幾乎耗盡了，而且不知道打補丁還能幾年。第二種方法是換個框架重構代碼，但是這種重構會引起系統巨大的變動，也許是一個嶄新的系統，也許系統會崩潰。第三種方法是乾脆換掉這些程序員。但是程序員號稱他們對軟件開發作出了革命性的貢獻，只可以程序員控制用戶行爲，絕不允許用戶另行選擇。可是用戶居然發現這些程序員拿到了其他公司的Offer！

    大家說說，這個軟件公司該怎麼辦？