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

30 年內軟體技術的不變與變化 (轉)[@more@]

30 年內技術的不變與變化

.9 （所有版權保留）

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

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

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

　　一、變化不大的

　　1. x86 的指令集

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

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

　　2. 操作 - 啟動過程

　　系統加電覆位、自檢、引導、管理、程式管理、硬體中斷處理、作業系統其它部分引導、 引導等這一套流程應該不會有大的變化。

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

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

　　4. 作業系統 - 程式（執行緒）及其排程

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

　　5. 作業系統 - 系統 API

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

　　6. - 語言

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

　　7. 瀏覽的與格式 - HTTP、HTML、script

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

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

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

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

　　9. 網路協議 - 族

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

　　10. 的 - Windows

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

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

　　11. 微軟的Windows -

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

　　12. 組織與 IBM 的 - Shell、XWindow

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

　　13. 語法與思想

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

　　14. 演算法

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

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

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

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

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

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

　　3. 開發管理模式

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

　　4. 開發技術的應用需求

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