在軟件程序的處理性能中，速度是永恒的真理。換言之，速度是最重要的指标。如果是簡單，數據處理量小的程序，隻要設備安裝了時下主流CPU和足夠的RAM，在處理速度方面一般不會帶來麻煩。但是，如果程序需要處理海量數據，由于設備架構（基本設計和設計思路）不同，在處理時間上就會産生明顯差異。

若是經驗尚淺的軟件工程師，為了滿足規格條件就已焦頭爛額，可能完全無法顧及處理速度。這次為大家講述的是我入職半年後，首次獨立開發子系統的經驗。我是如何解決所遇到的障礙（改善處理時間）的呢？算不上什麼先進的經驗，僅供大家參考。

開發課題是數據遷移工具

交予我開發的子系統因為系統更新，需要将某個舊系統中的數據遷移至新系統用的子系統。現在已經很少這樣做了，具體内容是創建一個将SQL組合在一起的存儲過程（将多個處理位彙總在一起的程序），然後依次啟動批處理文件，在數據庫之間進行數據轉換和遷移處理。

最初，我自認為這是一個非常簡單的程序（新人非常容易犯的毛病…），但後來才發現，其實這并不單純是數據遷移的問題，如果在運用維護方面考慮到用戶體驗的話，處理時間是很大的瓶頸。

開始着手這項工作時，我考慮的比較簡單，認為隻要通過單純的規則便可實現遷移。但随着工作的進展，最終發現問題遠非想像的那般簡單，遇到了障礙──程序處理時間比較長。處理時間長不僅令用戶體驗差（用戶壓力），而且在調試過程中，如果出現某種問題，很難調整。

處理時間變長的原因

處理時間變長的原因主要可以歸結為如下兩點：

（1）舊系統的數據規格不規則，而且存在多種數據模式

在舊系統中，用戶可以自由地編輯格式和決定規則，任意創建數據。因此，為了能夠把所有用戶數據遷移到新系統之中，需要在所有數據庫表中嵌入轉換處理程序。
實際試運行後發現，産生了多層的條件分支，其處理時間超過了預期。另外，不僅僅是轉換處理時間的問題，導入之前舊系統中的數據規格也耗費了相當多的時間。

（2）需遷移的數據龐大

表有100多個，而且每個表的記錄數量高達幾百萬條。由于舊系統中的運用記錄數量龐大，隻單純的設定條件進行處理，處理時長會與記錄數量的增加成正比。調試是使用樣品記錄，通過少量數據實施的，并沒有太在意處理速度的問題，但首次進行聯機測試時，實耗時間半天以上，簡直讓我無言以對。

鑒于此情況，我曾考慮通過新系統端的數據庫設計調整解決該問題，但數據轉換規格已經有了約定，隻能采用改進表索引等方式，但仍然無法改善速度，作為入職經驗不滿一年的工程師，一時無法想到其他解決方案。

嘗試逆向思維

當時感覺在這種情況下已經束手無策了，但轉念又一想，既然已無計可施，何不轉變想法，嘗試一下其他的方法呢？于是開始挑戰表分割，表追加，也就是分散處理。

按常理來說，将處理進行分散或增加隻是單純的增加工作量，反而會更浪費時間。當時，我自己也認為雖然可以分散處理，但程序會增加，分散後還需組合在一起，通過表的分割處理和表的追加，效果可能并不太好。但實際嘗試後發現，處理時間居然減少了約10%。

冷靜地仔細思考後發現，舊系統的數據多達幾百萬條記錄，單純地訪問表就會花費很多處理時間。隻要事先将表分割，對訪問處理進行分散，便可有效地改變處理時間。
得出這一結論後，改善速度加快，完成了所有表的調整等工作。同時，在作業推進過程中，還發現了另一個改善點。

那就是，使用SQL可以組合和提取多個表，還可以對其進行多階段組合。最初，按照數據轉換，遷移的規則，單純編寫了SQL，所以制作了形成表組合隊列的存儲過程。

如此，該存儲過程看上去像是在訪問數據庫的表，但實際上是在訪問SQL的處理結果（查詢），即虛拟表，并非實際的表。因此，與相同的記錄數量相比，僅僅用SQL編寫的存儲過程的處理時間會大幅增加。着眼于這一點，通過進行表分割和設置過渡表，處理時間最終減少了約30％，總算完成了這項工作。

答案往往在“對面”

還是新人的時候，關注點隻在按規格編寫方面（符合規格要求，沒有必要進行調整），從未考慮過處理時間的問題，但通過這次經驗，我深刻地認識到站在各個不同角度研究問題的重要性。

我們很容易誤解，增加程序＝延長處理時間，但如果把目光轉移到處理分散等方面，也許結果會發生翻天覆地的變化。不僅SQL如此，我覺得其他程序語言也是相通的。在開發過程中遇到難以跨越的障礙時，先将自己的想法清零，通過逆向思維等方式，站在第三方視角冷靜思考是一種有效的手段。

進入最後階段時，我們會把視線集中到一個方向，自己一般意識不到。這種情況下，問題的答案往往在“對面”，而自己一個人是很難注意這一點的。即使能夠發現，可能也會花費相當長的時間。因此我認為，開發不應該由一個人進行，而應該從封裝之前的設計，評審階段開始，由組織（團隊）進行推進。這樣能快速發現問題，很大程度上也可以避免開發上的返工（＝提高開發速度）。我希望年輕的開發人員能夠認識到這一點。