最近在網上讀到 leezy_2000 的一篇文章《編程本質》，讀後頗有感觸。其中有些觀點我非常贊同，但也有一些不同看法。既然討論區難以盡述，加上自己早有許多想法想表達，索性寫下這篇文章，希望能與 leezy_2000 以及各位程序員朋友共同探討。
leezy_2000 將程序設計歸納為四大要素：問題、概念、邏輯和技巧，並以此對應分析、抽象、概要設計、實現四個步驟。從開發流程來看，這確實切中肯綮。
作者將程序本質歸結為「概念和邏輯」，我卻難以苟同。我更傾向於 cPPTrIEr 的觀點：「編程的本質是問題模型到編程語言的映射」。但這樣描述似乎將程序員簡化為翻譯員，抹殺了創造性。我認為編程本質應是：以編程語言的思想描述、解決現實問題，即 Thinking in Programming Language。
leezy_2000 的描述非常經典：「語言是邏輯的載體和描述工具，框架是對邏輯和概念的一種封裝」。使用不同語言解決同一問題，其邏輯往往截然不同。以 Prolog 為例，這門語言極為特殊，却能輕鬆解決離散數學問題；若由 Prolog 程序員和 C++ 程序員分別解決，邏輯必然大相徑庭。大師曾說：「語言磨砺了我們的思維方式，也決定了我們的思考範圍」，正說明每種語言都內含獨特的描述問題思想與方法。
光讀 Bruce Eckel 的《Thinking in Java/C++》系列只能學到皮毛。必須實踐，寫上幾千、幾萬行代碼。只有在水裡才能學會游泳。好書只能縮短學習過程，不能替代實踐。從未寫過面向對象代碼的人無法真正理解 UML；初學 C++ 或 Java 者僅讀《Design Pattern》也無法掌握設計模式。
計算機是一門實踐的學科。討論本質固然重要，缺了實踐就會淪為形而上學。微軟高級副總裁 Rick Rashid 仍堅持每年編寫 50,000 行代碼，以保持對前沿技術的敏感。反觀身邊有些小官（項目經理）以編程為恥，實在令人汗顏！
設計是工程概念，結果是一組文檔，製造團隊據此構建產品。源代碼是滿足此要求的唯一軟件設計文檔。根據源代碼構建產品成本極低，計算機自動完成，無需工人。流行觀點以為畫 UML 才是設計，編碼不算，這是本末倒置。UML 只是輔助設計文檔，真正的設計文檔是源代碼。因此，我們都是軟件設計師，在設計軟件而非構建軟件（觀點出自 Jack Reeves《源代碼就是設計》）。
設計軟件不能憑空進行，總要以某種編程語言為載體。與語言無關的設計只能算概要設計；詳細設計必須與特定語言相關。
以上只是一家之言，希望能給初學程序設計的朋友一些幫助。
