#好久沒來,以此文章清清雜草吧!
眼下比較常用的軟體知識歸類法是以關鍵字為導向的,但感覺這種分類法挺誤人子弟的。
比如:
· 程式設計語言與程式設計
· 軟體工程及軟體方法學
· 軟體專案管理
· 軟體需求
· UML
· 建模
· 極限編程
· 軟體方法/軟體工程
· 物件導向
· 軟體品質、軟體測試及維護
· 軟體過程
· CMM(軟體能力成熟度等級模型)
· 設計模式
· ... ...
“設計模式”,“極限編程”和“物件導向”之所以成為不同的類別主要的原因應該是他們使用了不同的關鍵字,而並非兩者間本質上有什麼區別。
這麼分類的好處是,找書比較方便,壞處是對學習協助較小,有點誤人子弟。
因此,我們需要一種新的軟體知識歸類法:
軟體的直接知識可以被分為三大類:
①用於打造概念邊界並且最佳化概念間邏輯關係的知識。比如,物件導向分析和設計。
②用於實現概念和邏輯的通用領域知識。比如程式設計語言。
③用於解決指定領域問題的專業的領域知識。比形演算法。
在很多場合③並不是必須的,但①和②則是不可分割的,並不存在孰輕孰重的問題。沒有概念無法形成邏輯,沒有邏輯,概念的徹底定義更是無從談起。而沒有載體(比如程式設計語言或UML)概念和邏輯根本就無法表達。事實上程式設計語言的演化很大程度上是想把這種表達變的更容易。
而與軟體有關聯的間接知識則有4大類:
①需求開發和描述。比如規格說明的編寫。※1
②估算。比如功能點方法等。
③測試。比如驗收測試等。
④軟體工程和方法論。比如CMMI和敏捷。
※1 把需求開發算作軟體的直接知識也可以。
根據,上面的分類,我們可以重新製作一份分類的表單。
關於軟體的直接知識:
· 通用的領域知識
· 程式設計語言(C/C++,Java,C#,Python,Perl等)
· 架構和類庫(MFC,Boost,Struts,,Hibernate等)
· 平台(Windows API,POSIX,.Net Framework※2,Java API,C/C++ Runtime Library
· 電腦體繫結構(CPU指令,虛擬儲存等)
· 實用技巧(調試方法,代碼產生器等 )
· ... ...
※2 有的時候子類別間的界限並不是很容易界定,其中一個主要原因就是存在著像.Net Framework這樣涵蓋了過多內容的概念。
· 概念和邏輯建立和最佳化
· 物件導向分析和設計/結構化分析和設計
· 設計模式
· 重構
· 契約式編程
· UML ※3
· ... ...
※3 從形式上來看UML更近似於一種程式設計語言,但從其目的上來看也許歸在這裡是更合適的一種選擇。
· 專業領域知識
· 圖形映像演算法
· 網路通訊協定
· 人工智慧
· 數值/非數值類演算法
· ... ...
關於軟體的間接知識:
· 需求開發和描述
· ... ...
· 估算
· 估演算法。比如,COCOMO, FP等。
· 估算術。比如,使用計數等原始辦法。
· 測試
· 軟體工程和方法論
· 輕量型方法論。比如敏捷。
· 大方法論。比如CMMI
· 綜合分析。比如,《人月神話》,《人件》所做的工作。
在這份表單裡面,諸如管理相關的內容並未被列入,主要關注的是軟體開發以及和軟體開發直接關聯的領域。而管理等會在綜合能力歸類法一章做進一步的分析。
有了上述分類之後,我們可以回到一個非常古老的話題:
究竟應該如何學習程式設計?
根據軟體的本質,我們可以說,由於程式設計主要解決概念與邏輯的問題,而概念與邏輯問題與現實緊密相關,因此不存在一種記住某些定理,接下來有選擇的進行應用,最終就會產出好的產品(作品)這樣的因果。只能是學一點,實踐一點,總結一點這樣的不斷迴圈。
根據上面的分類,一種具體的可能的學習方法是:
Step1: 選擇一種通用的領域知識。
比如: C# + .Net Framework,Java
Step2:
在實踐過程中,逐步提高概念和邏輯建立和最佳化的能力
比如: 物件導向方法
Step3:
如果有機會:深入研究選定的專業領域知識,並且擴充自己的通用領域知識。
對大多數開發人員而言,直接接觸某些專業領域知識的機會比較少,更多的時候是集中於前兩個步驟,這個時候有一個誤區需要避免。
掌握的語言,平台和類庫越多越好這樣一種傾向,雖然有時候有其現實合理性,但從學習的角度看,卻是一種誤區。頻繁切換語言,平台和類庫的同時,往往就浪費了一些去思考軟體的本質問題的機會,最終對個人成長不利。
現實中有些企業中生存壓力過大,對有些事情是沒有選擇權利的,那也沒轍。
但考慮到公司和個人間本質上更傾向於價值交換(你幹活,我付錢)。你乾的事情蘊含的價值沒上來(比如說:新畢業生也能幹),那你想收入太高也不太可能,或者說可能了也危險。