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