程式設計師看法上的幾個典型錯誤

　　今天我不談抱負理想，也不談具體的技術，我來談幾個看法上的典型錯誤。下面的這些問題都是我曾經遇到，或者是我的朋友們遇到過的問題，這些都是我個人的理解，希望對大家有幫助。

關於設計模式、設計原則

　　有人認為，熟悉了設計模式、設計原則，就學會了設計。其實，設計模式和設計原則，只是前人根據設計實踐做的總結和提煉，設計，歸根到底是要解決問題的，把具體問題的解決辦法，經過一定的抽象，變成程式設計師的語言。

　　我見過一些人，他們知識淵博、見識廣博，甚至理論可以給你闡述得冠冕堂皇，但是到了實際需要解決問題的時候，他們卻拿不出巧妙的、優雅的辦法，這是典型的象牙塔人。

　　另一方面，也有一些人看不起學習設計模式的人，他們覺得他們已經掌握了軟體設計的奧義，這些對他們來說是毫無意義的詞彙，對此大可以一笑置之。

　　有時候我們反而被設計模式或設計原則粗暴的掌握束縛了手腳，譬如我遇到這樣一件事情，某位努力的程式設計師，設計的程式碼用遍了組合（例如把User物件 放置到Administrator裡面），我好奇地問，有一些類和物件之間的關係很明顯符合繼承的特徵，為什麼不願意用它？他說，設計原則告訴我們，要多 用組合，少用繼承。我想，對這些優秀的模式、原則、方法論，如果不能透徹地掌握，不能根據實際場景合適地運用，是不是反而不如對其不瞭解來的好呢？

關於多種計算機語言的學習

　　有人覺得學習一種語言就可以了，學習那麼多語言沒有必要。事實上，多掌握一門合適的計算機語言不僅僅是多掌握一種謀生的工具，如果一種新的語言能夠很大程度上改變你對程式設計、對設計的看法，那麼興許它就值得你去學習。

　　譬如C語言，可以培養嚴謹的思維；譬如動態語言，它可以幫助程式設計師更好地做物件導向的coding；譬如函式式語言，它在工業生產、運算領域有著不可替代的作用。

　　當然話說回來，所謂術業有專攻，對於某一門計算機語言（包括該語言所需的執行時環境、其中的編譯或解釋的原理）深入的掌握，是很有必要的。

　　另外，我們時常看到諸多計算機語言孰優孰劣的爭論，計算機語言歸根到底是一種工具，工具是隨著時代發展升級和變更的，單純的優劣爭論沒有太大意義。

關於英語

　　中國人為什麼要學英語，程式設計師為什麼要學英語，當我把那些方法名、變數名全部取成拼音，一樣可以，誰下的這個破規定？

　　遺憾的是，諸多學習材料、論文、技術資料（尤其是一些剛出不久的技術），都是英語的；另一方面，國際標準、程式設計師交流的通用方式，都是英文的，我想肯定很難想象，那些有名的framework、lib的原始碼，如果用拼音來寫變數名會成什麼樣子。

　　所以，如果你的英語不好（至少讀寫不好），就不要給自己找太藉口，英語是一個掌握其他工具的工具，除非你堅信，中文很快就會在計算機界變成世界第一通用的語言。

關於演算法

　　演算法有多重要，這一件事的爭議一直都很大。

　　軟體歸根到底是用來解決問題的，提到演算法就不能不提到數學（這也是為什麼很多軟體領域的大師都具備相當的數學背景），對於解決問題，這裡可以簡單歸納成兩步：

　　（1）把實際的問題抽象成簡化的數學模型

　　（2）用演算法去解決這個數學問題

　　演算法，在這裡應該是一個廣義的概念（這裡的演算法並不僅僅指大學裡學習的狹義的具體演算法），演算法是解決上述數學問題的辦法。如果工作中你並未意識到它的存在，那只是說明，你抽象出的數學模型比較簡單，解決這個模型的辦法也很簡單，或者有現成的方式可以模仿，或者有現成的框架幫你完成了，以至於你不去關注它、在乎它。

　　如果你做的事情是充滿創新意義的，是別人從沒有做過的，這時候演算法興許就成了決定你成敗的因素。

　　在當前中國的環境下，視野廣闊和經歷豐富的人很好找，但是企業要招到具備上述兩點能力來解決問題的人，其實是非常困難的。

關於經驗

　　唯經驗論者的人有很多，他們認為，在軟體企業的職位、薪水、甚至決策能力，都取決於經驗，一個5年經驗的工程師，肯定比3年經驗的工程師能找到更好的飯碗：

　　“我是老員工，我工作5年了，憑什麼工作3年的他薪水比我高那麼多”

　　實際上，很多因素，包括領域積累（這是業務上的，例如網際網路領域、傳統軟體領域，這和所謂的純技術沒有直接關係）、視野、承受壓力的能力等等往往都 在很大程度上取決於“經驗”的積累，但是，這並不是絕對的。有句話叫做“事業一半是幹出來的，一半是總結出來的”，也確實有一些出色的程式設計師，他們善於總 結、善於觀察和積累，並且善於不斷地思考，這樣的程式設計師就是擁有更多優秀的經驗。

　　另一方面，程式設計師是要來解決問題的，經驗不能代替解決問題，有的人具備更優秀的解決問題的能力，他為什麼就不能得到更優厚的薪水？