? 說明：非常抱歉，這周參加了太多的會議。原來寫作也是需要心情的，當沒有心情的時候，你都懶得動筆。 歐陽明來到云南的最主要的目的，是為了應對昆明客戶要求的評標。就是客戶邀請了幾家資質還可以的公司，分別演示和講解各自的系統，然后再進行評選。而這一次他們就是要進行講標。歐陽明沒有講過標，這次也不是他講，是當地的分支經理親自上陣。分支經理名字中也有一個“琨”，因此人稱琨哥，另外還有一個響當當的名號：“西南王”。是公司西南幾個省市的市場負責人。 西南王不是蓋的。至少講標方面，歐陽明一行人都得好好學習。 講標的前一天晚上，大家都還在進行緊張調試，做系統驗證。大家的思路很明確，按照講標的順序，把系統完整演示一遍。過程中不允許出現任何錯誤。這個方法他們取名叫“主流程覆蓋法”，后來一直持續使用下來。這個方法的最大好處，在于真正結合業務在進行驗證，而不是單純的功能驗證，所以目標導向很強。但即使這樣，系統也還是一直在報錯。 “這個系統的框架太差了，必須進行改進！”歐陽明在旁邊給冀揚他們打氣，慢慢就聊開了。 “不如重寫一個得了！”冀揚也基本同意他的想法，但更愿意自己寫，而不是改寫。 “嗯，重寫一個是必然的，因為這個產品目前是拓展客戶，還屬于需求收集階段。需求穩定后，必然會進行大版本升級的。” “那什么時候才可以升級呢？” “這個還得有點時間，目前關鍵是解決系統的穩定性問題。” “那得從那里著手呢？” “目前，影響穩定性的主要有兩個方面：第一個是模塊之間存在不必要的耦合，導致數據一致性常常存在問題。” “嗯，是的。” “第二個問題是，數據量大的時候的軟件性能問題。常常出現大工程，系統就歇菜了。” “嗯，要解決這兩個問題也很麻煩啊。” “是的，不過整體思路還是很明確的。耦合的思路就是解耦，用接口的方式，將模塊獨立出來，不允許模塊對模塊的直接引用。” “這個還好說，那性能呢？” “嗯，表面上說，性能問題很復雜，因為形成原因多種多樣。不過針對咱們的系統，性能往往來源于大數據量的導入（到SQLServer）和服務端的數據獲取。” “那又怎么樣？”冀揚繼續問道。 “就是說，我們第一解決好導入數據的模型，然后適時優化數據獲取的SQL即可。”歐陽明這樣解釋到。 討論還沒有完，但是時間已經很晚了。為了更好的應對明天的講標，大家都要好好休息。因此在最后一次流程正常走完之后，下班的命令被歐陽明下達了。 第二天，他們的講標順利嗎？