程式設計師學什麼樣的知識才能賺錢[2]

另外，現代的作業系統，都是多工作業系統，多工開發是個難點，這個多工計算其實就是平行計算了，必須對程序，子程序，執行緒有很清楚的認識，對於時間片有清醒的認識，對於鎖的使用，鎖的作用域，去鎖優化要很熟悉。但是，也很可惜，目前市面上的書籍，講語言的就講語言，講作業系統的就講作業系統，對於這個多工開發這塊，同時需要結合語言和作業系統兩方面知識的，幾乎沒有，需要自己摸索。

嗯，還有一個很重要的問題，C語言的基本庫相對薄弱，很多近年發展的高階語言，對於雜湊，List,佇列，棧，樹等常見資料結構都提供標準庫函式，或者庫模組來支援，但C一般是沒有的，偏偏實際應用開發還經常用到，得自己找開源，或者程式設計師自己寫，這也會耽誤程式設計師很大一部分精力。

這裡就出現了C語言一個不好不壞的'特性，或者說既好也壞，C語言沒提供這些工具，程式設計師自己寫，很麻煩，但是，由於是自己寫的，自己掌握所有底層程式碼，因此，優化變得很容易，一個佇列，我隨手加個隊尾指標做加速因子，可以規避大量的遞迴操作，效率提升百倍甚至千倍以上，這在C裡面就是加幾行程式碼而已，但是對於Java等語言，由於底層庫是廠商提供，甚至根本就不是本語言開發的（很多高階語言底層庫其實是C和C++寫的）,程式設計師一般沒有修改能力，有時候，遇到效能瓶頸，大家就只有幹看著，沒有任何辦法。因此，同樣的應用，C語言可能一臺服務器就夠，但是Java語言呢，可能需要3~5臺，就是因為這些語言做的太完善，而太完善的東西，一般不好做優化，效能就不及經過專項優化的C程式碼。

就是因為這個原因，在很多嵌入式等小終端場合，由於CPU計算能力有限，需要使用C來做優化，而不能使用Java等高階指令碼語言，否則程式跑不過烏龜。

另外，現代的資料應用，出於優化起見，一般趨於功能細分的設計模型。比如一個數據庫應用，儲存模組專門負責高速出庫和入庫，中間甚至新增cache機制作專業的優化，而業務模組則強調設計一套嵌入式指令碼語言做二次開發，保持最大的業務開發靈活性。其實Java,PHP,很多都是這種模型，MySQL底層模組實現高速儲存，上層則使用apache和PHP、Java等語言，靈活二次開發具體應用。

但是，C由於一般都是編譯執行，不是解釋執行，一般很難做到這麼大的靈活度，不能使用者僅僅加個欄位，就跑過去把整個伺服器重新改寫編譯一遍，這樣維護成本太高了。因此，C程式設計師的解決方案，一般是自己實現底層的高速資料應用，再自己寫個指令碼語言的直譯器，提供給使用者做二次開發。