30 年內軟體技術的不變與變化

軟體技術及相關問題的變化是發明創新、公司產品運作、社會市場需求消費、人才資金迴圈、政策法律等等整體運行中的一個小部分，其發展過程將受諸多因素的影響，但其自身也是有一定規律的。作為行業中具體幹活的人，面對這個技術日新月異的行業，琢磨一下行業未來 30 年的某些事情。

　　30 年後的事情不用考慮了，就算想清楚也沒用了。

　　30 年內的軟體技術及相關問題分為變化不大的和變化可能比較大的。變化不大的學會了用熟了會終身收益，變化大的要及時把握參與深度。

　　一、變化不大的

　　1. Intel x86 的指令集

　　原因很簡單，如果這些指令集發生重大變化，那這行業開發、積累的軟體都不能運行了，變化成本太高。

　　即使從32位發展到64位、128位，指令集的相容是可以預見的。

　　2. 作業系統 - 啟動過程

　　系統加電複位、硬體自檢、作業系統引導、記憶體管理、進程管理、硬體中斷處理、作業系統其它部分引導、使用者 Shell 引導等這一套流程應該不會有大的變化。

　　3. 作業系統 - 記憶體管理

　　i386 的三層記憶體管理員模式現在還看不出有多大的變化趨勢。作業系統的記憶體管理員模式、API也不會有大變化。

　　4. 作業系統 - 進程（線程）及其調度

　　只要作業系統內程式的運行是通過時鐘中斷或其它軟硬體中斷進行調度，那麼進程是作業系統調度的基本單位。如從某一天開始“獨立的二進位組件”成為作業系統的基本調度單位，那可能更多的是進程式控制制塊的變化。“獨立的二進位組件”的載入本身很可能就是進程。

　　5. 作業系統 - 檔案系統 API

　　檔案系統可能會不斷變化，但檔案系統的 API 應該不會有多大變化。

　　6. 資料庫 - SQL 語言

　　關聯式資料庫的理論與產品技術已經非常成熟，對維護到現在已經儲存的大量資料而言，SQL 語言是很難被替換的，XML 可能將會與 SQL 合作而不是替換。即使對象資料庫理論及產品成熟了，SQL 肯定將被相容。

　　7. 網路瀏覽的協議與格式 - HTTP、HTML、Javascript

　　就算大家對 HTML 再不滿意，其修改、進步的步伐也不會很快，太多的資訊內容儲存成這種格式了，變化的成本太高。

　　HTTP 是與 HTML 相伴的，變化不會太大。Javascript 更是如此。

　　8. 電子郵件的協議與格式 - POP3、SMTP、MIME

　　POP3、SMTP、MIME 也已成大規模，變化的成本很高。

　　9. 網路通訊協定 - TCP/IP 族

　　IPv4 到 IPv6 是可以看到的，但 TCP/IP 的基本結構及 API 應該不會有多大變化。變化的成本太高。

　　10. 微軟的Windows - Windows

　　除非連續發生重大經營失誤，否則微軟是不會簡單倒下去的，關於這個主要不是技術的問題，不多說。簡單認為 Windows 會存在很長的時間。

　　Windows（產品） 中的 Windows（視窗技術）是精華，已經很成熟，其相關的 API，包括 GDI、訊息機制、Common Controls等不會有太大變化。就算以後以組件的形式出現，那也只是 API 的另外一種形式。

　　11. 微軟的Windows - DirectX

　　只要老百姓還在用 Windows，那麼 DirectX 作為遊戲的開發平台會長期的保持下去。

　　12. 開源組織與 IBM 的 Linux - Shell、XWindow

　　開源組織現在看不出任何的前景衰落，IBM 已經發展了百年，他們聯合推動的 Linux 再活 30 年應該沒問題。其基本的 Shell 與 XWindow 結構不會有太大變化。

　　13. OOP 文法與思想

　　程式設計語言是編寫邏輯、調用 API、解決問題的工具。其中的 OOP 文法現在方興未艾，引導了編譯器、虛擬機器、API 都向其轉變。若干年後，即使程式設計語言又發展革命了，OOP 很可能將作為其基礎。

　　14. 演算法

　　可以說是數學的一部分，包括純數學演算法與應用商務邏輯或應用演算法。解決問題的演算法的生命力是永遠的，獨立於系統、程式設計語言。即使我們研究不出來新演算法，但掌握某些演算法是應該的，這是掌握基本軟體開發知識後的長遠競爭力之所在。

　　二、變化比較大且影響比較大的

　　1. 產品外觀、使用者操作介面與互動方式

　　產品外觀、介面與互動方式的變化永無止境。像微軟這樣的公司在這方面投入巨大精力。實際上這是給老百姓看的，不是給開發人員的，但在很大程度上會影響開發人員的產品外觀設計、介面設計及互動設計。

　　2. 程式設計語言、編譯器及其支援庫、虛擬機器

　　具體的程式設計語言與編譯工具的選擇使用是程式員、開發部門自己的內部事務，一般與系統API、產品市場需求、開發結果等無關。影響程式設計語言與編譯工具的選擇使用的因素非常多，變化性很大。就算一個程式設計語言或其相關的編譯工具的生命週期很長，但也很難保證被一個Team Dev長期固定使用。過度沉迷進而局限於某個編譯工具的風險很大，但不鑽研到一定深度很難做出來好東西。

　　3. 開發管理員模式

　　不同的產品、項目，不同的應用平台，不同的編程式語言，需要針對性的開發管理員模式。即使使用相同的 OOP 文法的程式設計語言，針對不同的產品或編譯工具其開發管理也是不同的。開發管理其實是組織開發人員利用程式設計語言寫出結果的過程，當然應該不斷地進行調整。有一些粗線條的管理理論只能進行指導，真正的實踐是另一回事兒。

　　4. 開發技術的應用需求

　　隨著軟體應用平台廠商、開發工具廠商的不斷的產品升級、市場推廣活動，以及社會消費熱點不斷的變化，市場客戶對開發技術的需求不斷地進行調整。