程式江湖：第二十章 講标的前一晚上

說明：非常抱歉，這周參加了太多的會議。原來寫作也是需要心情的，當沒有心情的時候，你都懶得動筆。

歐陽明來到雲南的最主要的目的，是為了應對昆明客戶要求的評标。就是客戶邀請了幾家資質還可以的公司，分别示範和講解各自的系統，然後再進行評選。而這一次他們就是要進行講标。歐陽明沒有講過标，這次也不是他講，是當地的分支經理親自上陣。分支經理名字中也有一個“琨”，是以人稱琨哥，另外還有一個響當當的名号：“西南王”。是公司西南幾個省市的市場負責人。

西南王不是蓋的。至少講标方面，歐陽明一行人都得好好學習。

講标的前一天晚上，大家都還在進行緊張調試，做系統驗證。大家的思路很明确，按照講标的順序，把系統完整示範一遍。過程中不允許出現任何錯誤。這個方法他們取名叫“主流程覆寫法”，後來一直持續使用下來。這個方法的最大好處，在于真正結合業務在進行驗證，而不是單純的功能驗證，是以目标導向很強。但即使這樣，系統也還是一直在報錯。

“這個系統的架構太差了，必須進行改進！”歐陽明在旁邊給冀揚他們打氣，慢慢就聊開了。

“不如重寫一個得了！”冀揚也基本同意他的想法，但更願意自己寫，而不是改寫。

“嗯，重寫一個是必然的，因為這個産品目前是拓展客戶，還屬于需求收集階段。需求穩定後，必然會進行大版本更新的。”

“那什麼時候才可以更新呢？”

“這個還得有點時間，目前關鍵是解決系統的穩定性問題。”

“那得從那裡着手呢？”

“目前，影響穩定性的主要有兩個方面：第一個是子產品之間存在不必要的耦合，導緻資料一緻性常常存在問題。”

“嗯，是的。”

“第二個問題是，資料量大的時候的軟體性能問題。常常出現大工程，系統就歇菜了。”

“嗯，要解決這兩個問題也很麻煩啊。”

“是的，不過整體思路還是很明确的。耦合的思路就是解耦，用接口的方式，将子產品獨立出來，不允許子產品對子產品的直接引用。”

“這個還好說，那性能呢？”

“嗯，表面上說，性能問題很複雜，因為形成原因多種多樣。不過針對咱們的系統，性能往往來源于大資料量的導入（到SQLServer）和服務端的資料擷取。”

“那又怎麼樣？”冀揚繼續問道。