如果你有一把錘子，那麼所有東西看上去都像釘子--我們是否應該冷靜
很意外自己會寫這麼一篇文章，絕對是臨時起意。算作是看最近在讀的《暗時間》一書而對於很多事情的有感而發的其中一發吧。從開始讀這本書，很多自己之前形成的系統一點的觀點就和作者相同。
關於冷靜，這次想說比較多的幾個方面。
程式設計師有很多錘子。豐富的語言、框架、設計模式、過程方法論等。
1. 上學期深受UML折磨。這學期又有系統分析與設計（SAD）。
於是乎看到一段話，深表贊同：有人希望拿UML去統一使用者和軟體設計者。殊不知UML有多麼難以理解（大讚），而UML設計者卻認為UML可以描述一切。就是這個道理，要理解你的程式碼還要去讀懂《設計模式》，這要求也太高了吧。
程式碼設計時去遵守設計模式，問題是，開發這種事情不是你一個人乾的，你讓別人怎麼去讀懂你的程式碼。不說如此，就算是被人呼叫你的程式碼。你告訴他：使用起來得配置這個或者那個，各種注意，還有時去用工廠方法建立XXX。。。我就是要功能而已，你給我個函式介面，最好還可以不傳引數，我呼叫就直接成功多好。效率、功能、易用性還一樣不少。至於想實現的框架、Pattern等，在自己程式碼中搞定。
自己確實試過UML後面那些設計模式，後來覺得--好無聊，寫起來複雜不說，別人也不懂。可能只有能顯示自己知道的東西多那麼一點。但是看來，知道這些東西也不是什麼炫酷的事。另外我始終不理解，軟體開發設計無非就是--設計介面--呼叫響應函式。特別是以現有的豐富的“所見即所得”的可拖拽設計介面的開發環境如此豐富的情況下。快速設計出介面，然後大家分幾個函式去寫。這樣迅速、結合起來也足夠清晰。不過也可能是因為我沒有見過那種極大的專案開發的緣故。或許以後我能懂。不過就課上老師自己描述的做過的大型專案而言，無非如此。
另外如果為了程式碼複用，這個理由更荒謬。
著名的《Head First Design Pattern》在書靠近結尾的地方也鄭重提醒：
不要覺得不用設計模式就不夠好不夠強大，以儘可能簡單地方式完成任務才是王道。
2. 語言之爭。越熟悉一門語言，那麼就會越容易走到死衚衕。
比如迭代器這個概念。可能C++、Java、Python程式設計師都會認為這是一個極其出色的概念。但是“更簡單的迭代方案是無需定義多餘的迭代器類和繼承體系（書中語）”。對此我沒有更直觀的感覺，只能說，確實太多的人視自己最愛的語言為聖經。最直觀的的就是Java和C++隨處可見的對罵。然而語言最大的優勢就在於特長。或者說，只是工具。
由TopLanguage對Bjarne的訪談中的問題：
1） 學習C++的第一原則是什麼？
答：關注基本的概念和技術，而非特定的語言特性，尤其不是C++中細枝末節的語言細節。
2） 使用C++的第一原則是什麼？
答：將你的設計理念直接對映為C++中的類或模板。
我對於第一條的解讀就是，關注一個語言的細枝末節，不如去寫彙編去。《Python學習手冊（第四版）》是我學習Python的第一本書。當時自己看了600頁出頭，然後實在看不下去了，那是真的有種要吐的感覺。全書在講述任何一個知識點的時候，都過於冗餘，或者說，過分地關注語言的細枝末節的東西。後來的很多程式碼真的是很難讀懂，因為糅合了過多的Python特性。當忍無可忍時，我跑去看另一本書了。Python的設計最吸引人的地方在於，程式碼的簡單易懂，實現起來易上手。但是那本書確實對不起“學習”的“手冊”之名。我用這本書學到了不少知識，但是我真的不覺得它適合語言的初學習。
學習投入的精力是有限的，一旦掌握了基本的概念，要用到細節的時候，細節就自然到位。讀書也一樣，特別是對於初讀，追求細緻會走到一個迷茫和苦惱的誤區。這個道理我直到最近才明曉。也是最近才能慢慢地讓自己不再為“讀書”二字所累，而是單純地追求知識。
所以以後看到偽碼寫的演算法，我是不是應該高興一下？
而對於第二條，STL的實現與發展就是最好的解讀。
3） 歷史的作用
最近上的課是《計算機網路》。再結合自己以前的學習經驗，發現學習歷史對於學習的重要性。
當對於一個方向的歷史瞭解之後，再學習起來是很輕鬆的。舉個例子，我們在將網路傳輸層協議的時候，就是沿著傳輸層協議歷史發展的道路一步一步設計下來的。這樣，理解與學習都快速、清晰、同時還印象深刻。很多其它的學習也一樣。我們不學資料庫實現。但是瞭解SQL的歷史，知道SQL89和後來的SQL92，那麼對於資料庫的理解與學習同樣會有幫助（就好像怎樣的SQL語言更通用、什麼情況下用什麼樣的SQL實現等）。
更何況思維。歷史的發展就是思維的產生與成熟的過程，這自然更符合人的學習習慣。當然，這也是為什麼大家對於我們現在學習數學的方法那麼厭惡的原因：一上來就把公式擺在那裡，就好像它是天生的一樣，然後我們去用就好了。最明顯的就是“一致收斂”，當時我學的時候，就想說這TM是什麼玩意
4） 培養計劃
原本想說教育，但是未免過於寬泛了。
上學期學Java。雖然大一下的時候就接觸了C++的面向物件。但是我相信對於大學之前沒有接觸過這個行業的人來講，知道Java後，才開始對於面向物件有了那麼一點概念。然後就被趕鴨子上架學了UML，這學期又是SAD。反倒是程式設計本身變得越來越不重要。語言相關的課程從考試變考察，學分也更低了。再加上可也繁重的培養計劃，自由學習的時間無比地少，更何況對於我這種人來講。在我看來，UML和SAD這樣的東西，拿到大三更合適。在我們實訓回來之後，有大一大二的學習以及後續對於面向物件和系統設計和工程開發的理解與學習，再學這些就是水到渠成了。
另外就是，國內的SE開的真是顯得急功近利。說白了，底子也不厚，學習也盲目。計算機，不管以後是哪個方向，基本功好才是真的好。這也是為什麼材料專業愛要學物理的、軟體專業那麼多學數學的做的好。
教育不是流水線作坊。軟體工程說到底還是計算機。技術>成績
所以，程式設計師有很多錘子。