低階程式設計師和高階程式設計師的區別

　　低階程式設計師認為自己與高階程式設計師的區別, 主要是高階程式設計師任何功能都能編碼實現, 編碼速度快, 程式碼無 bug. 正如一慣的那樣, 低階程式設計師之所以低階, 正是因為他們勉強能看到(或者根本看不到)事物的表象而看不到本質. 所以, 低階程式設計師總結出的一切東西, 你都可以大膽的忽略.

　　所以, 我們來聽聽高階程式認為自己與低階程式設計師的區別是什麼. 高階程式設計師之所以高階, 在於他們認識到程式碼 bug 是不可避免的, 有千萬種理由可以導致 bug, 但他們可以在設計和邏輯上保證(追求)滴水不漏, 並用邏輯的百分之百準確性還減少程式碼 bug. 沒錯, 嚴謹的邏輯能力是高階程式設計師區別於低階程式設計師的最主要原因.

　　可以舉一個簡單常見例子: 網路購票終端的開發. 當然, 比低階程式設計師還低階的程式設計師做不出來. 我們先看看低階程式設計師是怎麼做:

order = Db::new_order();
ret = Network::place_order(order);
if(ret == TRUE){
    order.finish();
}else{
    order.cancel();
}

　　你看到的沒錯, 這段程式碼邏輯清晰, 一般 90% 的情況都能正常工作, 有的甚至能達到 99%, 在某些特定的時間段, 這樣的系統 100% 能正常工作(幾乎是完美的系統).

　　你可能發現了問題: 網路是不可靠的, 網路請求可能發出去了, 也可能沒發出去; 對方可能收到了, 也可能沒收到; 響應可能由對方發出去了, 也可能沒發出去; 你可能收到了響應, 也可能沒收到.

　　但是, 低階的程式設計師會這樣解釋: 我用的是 TCP 協議, "TCP 是一種可靠的傳輸協議", 哈! 可笑的照本宣科. 這種低階程式設計師, 不僅在於他們寫出了邏輯上不完備的系統, 而且還惡劣地引經據典來做錯誤的辯護. 但他們引用的經典是不合時宜的(不能支撐他們的結論).

　　正確的做法應該是假設上面的每一行程式碼都可能中斷執行, 然後進行相應的對策. 正如狹義上的網路協議其實是廣義上的互動協議, 我們可能把 TCP/IP 協議上的許多思想和機制應用到系統間的互動上來.

　　簡單來講, 可以加上就是重試(超時重傳)和對賬(請求確認). 所以, 邏輯上更準確的程式碼應該是這樣:

Process_0{
    order = Db::new_order();
}
Process_1{
    order = Db::find_new_order();
    ret = Network::query_order_result(order);
    if(ret == NOT_FOUND){
        ret = Network::place_order(order);
        if(ret == TRUE){
            order.finish();
        }else{
            order.cancel();
        }
    }
}

　　Process_0 和 Process_1 是相互獨立的處理邏輯.

• Process_0 即處理使用者互動, 接受訂單.
• Process_1 請求服務提供商進行對賬. 進行採購下單(補單), 更新訂單狀態.

　　上面的程式碼邏輯實現了重試(超時重傳), 對賬(請求確認). 但上面的程式碼在邏輯上還不是 100% 準確的, 例如, 如果對方系統誤報呢? 但其它的異常情況可以根據實際情況來忽略. 如果你發現這段程式碼還有重要的邏輯上缺陷, 歡迎告訴我.

　　記住, 低階程式設計師和高階程式設計師的區別在於邏輯和抽象.