程序員學什麼樣的知識才能賺錢[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程序員的解決方案，一般是自己實現底層的高速數據應用，再自己寫個腳本語言的解釋器，提供給用戶做二次開發。