<bdo id="ayg0w"><samp id="ayg0w"></samp></bdo>
  • <code id="ayg0w"><samp id="ayg0w"></samp></code>
  • <code id="ayg0w"></code>
    <bdo id="ayg0w"></bdo>
  • <code id="ayg0w"></code>
    聯系我們

    博客

    工程師博客

    答案往往在“對面”

    程序改善靈感的發掘方法

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

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

    開發課題是數據遷移工具

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

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

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

    處理時間變長的原因

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

    (1)舊系統的數據規格不規則,而且存在多種數據模式

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

    (2)需遷移的數據龐大

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

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

    嘗試逆向思維

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

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

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

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

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

    答案往往在“對面”

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

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

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

    TEXT BY
    渡邊 聰
    解決方案開發部 解決方案推進課 課長代理

    [主要產品開發業績]
    直流穩定電源PAT-T系列,電子負載裝置PLZ-4W系列
    系統模擬試驗用軟件(電網模擬器)
    航空電子設備試驗用軟件
    程序編寫,控制軟件 Wavy系列

    聯系我們
    亚洲成a人片在线观看的电影
    <bdo id="ayg0w"><samp id="ayg0w"></samp></bdo>
  • <code id="ayg0w"><samp id="ayg0w"></samp></code>
  • <code id="ayg0w"></code>
    <bdo id="ayg0w"></bdo>
  • <code id="ayg0w"></code>