個人對中國編程技術的感慨

前些天, 我和公司的一位同事在聊天, 談到了技術上的東東.
他是做LINUX內核方面的, 而我是做WINDOWS服務器方面的. 

他問: 你工作多長了?

我回: 4年多.

他說: 那麼短.

我說: 還短嗎? 覺得挺長的.

沉默了一會.

我問: LINUX下, epoll是怎樣用的? 怎樣實現採用多線程的方式的?

他回: 採用線程池啊

我說: WINDOWS下, IOCP說是跟epoll差不多, IOCP直接跟外部的線程進行綁定的, 有消息處理的時候, 線程就會在函數中返回.

他說: epoll跟線程沒關係的, 它只是一個select模型的進階版本, 什麼東西都是自己判斷自己寫的.

我說: 那你的意思是指所有SOCKET對應的accpet, close, recv, send都是自己檢測了?

他回: 是的. 

我說: 那你認爲怎樣寫一個服務器會是比較高效率的.

他回: 視實際需要情況.

我說: 服務器其實只做三件事: 接收數據, 處理數據, 回覆數據. 沒有實際需要也照樣的, 採用服務器羣組也好, 不採用也好, 只要每個服務器都是高效的, 自然組建起羣組來說也不會太低效率, 除非羣組架構出問題.

他回: 你這樣問也很難回答到你的問題啊.

我說: 那麼採用流水線的方式的話, LINUX下怎樣實現一個線程寫, 一個線程讀, 而且較高效率的一個列表. 

他回: 你這樣問我也回答不出你的問題, 具體怎樣寫, 是不是採用列表, 都是視實際需求而定的...(後面一大堆理由)

我說: 什麼實際需求不需求的, 現在就是要求這樣的一個功能而已.

他回: 你說出具體需求我就會設計, 不說出具體需求我就不會設計了.

我無語.......

非常明顯的. 他沒寫過服務器. 然而更讓我得知一點: LINUX內核的編寫, 只是掛個名. 有什麼可能內核的編寫不需要考慮線程的安全和抽象, 有什麼可能內核的編寫不需要考慮各種高效的數據處理模型.

像原子鎖, 異步讀寫, 併發讀寫, 這類網上評論N多的線程安全模型, 居然還需要實際需求才能夠設計. 

然而, 這些不是我最感慨的地方. 最讓我感慨的地方是: 中國, 實在太多所謂的資深技術人員連什麼叫功能, 什麼叫業務都不能夠明確劃分, 總是喜歡把什麼東西都混在一起. 弄得功能和業務緊密偶合起來. 而最可悲的是: 懂得的人總是要做善後工作.而最痛苦的是: 因爲這個工齡的問題, 有技術得到的工資, 還是比沒技術的人低...

我已經工作過四家公司, 有兩家公司, 是存在架構的, 但架構較差, 都存在一個單元有幾萬行代碼. 有一家公司, 是完全沒架構的, 每個業務單元都存在幾千行代碼. 而現在這家, 業務較爲單一, 只是業務邏輯較爲複雜, 功能最初有劃分, 現在的就把業務不多不少都偶合在功能裏面了. 

中國, 現在還是處於那種只要做得到, 不要做得好, 只要可以用, 就不會創造新的階段, 所以才導致中小型軟件公司不論發展多少年, 還是中小型. 唉, 中國, 什麼時候纔會可以領着世界走在軟件技術的前端...