【專欄】錘子和釘子（1）

（一）

有這么一句古老的箴言：

如果你手里有一把錘子，所有東西看上去都像釘子。

其實這句話已經是老調中的老調重彈了，我們程序員有很多錘子：OO、設計模式、語言（C, C++, Java, Python, Ruby, etc.）、各種各樣的架構tricks&workarounds，以及一堆軟件過程方法論（Agile, XP, Scrum, etc.）、等等。 幾則故事：

1. 阿朱的（《走出軟件作坊》）：

我過去領導過架構組。架構組的人在2002年的時候，瘋狂迷上了UML和設計模式，人手一本《COM本質論》和《設計模式》。我手下有一個新手，就處處是類，處處是抽象，處處是封裝，處處是分離，盡量使代碼高內聚低耦合。但是這樣的的代碼太麻煩，他花費了大量的時間，他看自己的代碼賞心悅目，別人看他的代碼云里霧里，不閱讀懂《設計模式》就按照常規理解業務的思路去閱讀他的代碼根本閱讀不懂，不知道他為什么這樣寫代碼，怪異的很。本來，這位想達到可維護性，可閱讀性，卻真正的失去了可維護性、可閱讀性。這和我前幾天看我的朋友周愛民寫的《大道至簡》中寫到：有人希望拿UML去統一用戶和軟件設計者。殊不知UML有多難理解，而UML設計者卻認為UML可以描述一切。就這個道理，要理解你的代碼還要去讀懂《設計模式》，這要求太高了吧。

所幸這位新手自己都每次寫的累，慢慢的也就懶了，覺得確實需要分離的時候就分離，覺得沒什么必要的就懶得做了。用他自嘲的話說就是：被磨平了。其實，依我看，他現在這個代碼狀態才是剛剛好，即照顧了設計擴展，又照顧了實用。真正的純OO，純設計模式，可能只存在于教學和科學，而不在于我們的商業軟件開發。我們作為商業開發，強調的是叫座的基礎上叫好，所以折中方案是必須的，客戶和我們自己兩相宜就OK，是否符合正宗，就不在我們的商業開發管理范疇了。

這位新手還寫了大量的注釋。在每個源代碼文件頭都寫上幾月幾號，XX創建的，這個原代碼文件主要是干什么的，還畫蛇添足的寫上版權所有，公司名稱。好像這個代碼要開源，或者可能會被其他公司竊取了好表明公司版權。甚至每個函數都寫了注釋，每個參數是什么意思，每個參數可能出現的值代表什么意思，都寫的一清二楚。久而久之，也懶的維護了。代碼改動了，參數擴展了，參數狀態值有了變化，注釋說明卻沒有跟著改動，讓后來看代碼的人老誤解，還不如不寫這些注釋。

我告訴他：做事不能走極端。要么全寫注釋，要么不寫注釋，都是不對的。我只在我認為要小心的地方，或者我自己都覺得很難理解懂的地方我才寫注釋。否則，我自己都可能會過段時間理解錯了。如果某段代碼我看看就能看懂，我就不寫注釋了。咱們做企業管理軟件，深入技術又沒有，只要代碼能把復雜的業務處理描述的邏輯思路清晰就OK。雖然說理解能力不同，我能快速理解了的未必有新手能夠理解，但是你看看我的代碼你就明白了。（摘自 《走出軟件作坊：代碼那些事兒》）

再來一段：

有一部分所謂的架構師，技術超深厚，框架堪比Spring之類，但自己一個人悶頭寫框架不斷優化，力竭使用最先進的技術思想，希望把最豪華的設計模式融進去，希望把OSGi融進去，希望把AOP融進去，全無視那些想利用框架減輕自己工作量提高自己工作效率的應用功能開發同事。這是在用公司工資玩技術呢，還是在滿足個人技術幻想呢，還是在實驗呢？到底在干嗎？價值在哪里？

還有的人不會推廣自己的框架。不善言辭，就幻想著技術總監能夠通過行政命令讓大家必須用框架，能不自己寫代碼就不自己寫代碼，能交給框架做的就交給框架做。但技術總監號召完了，大家仍然我行我素，各自開發為政，讓框架開發者很孤單。

還有的人也不會推廣自己的框架，沉迷在自己的理想世界。好不容易技術總監召集大家讓大家來聽聽框架如何應用，但自說自話，滿口自己最得意的詞匯，聽得業務功能開發人云山霧罩。大家問些問題，如這樣的業務開發難題，框架怎么解決？于是，框架開發員就和業務開發員爭論了起來?？蚣荛_發員覺得這根本就不能答應客戶這種變態的需求，而業務開發員說這就是現狀?？蚣荛_發員說你可以這樣這樣，業務開發員說這樣太麻煩，框架開發員立刻還口這還麻煩？于是雙方各執一詞，框架也沒推廣成功。

我手底下有個框架開發員。他的技術渴望很強烈，為了技術難題攻克，可以不吃不睡。并且技術敏感度很強，學習也快。所以當時我感覺他是個程序員的料，就把他拉到我的手下。

作者：劉未鵬 出版：電子工業出版社

但是有個問題，他寫出的框架代碼，在平時開發業務功能的時候挺麻煩。大家可能需要的是一把鐵鍬，但是他卻給大家N根不同長度不同粗細不同材質的木棍，N個不同形狀不同用途的鐵鍬頭。大家會有N種組合。不僅導致他寫代碼老超任務期，而且也讓使用人感覺沒多大幫助。使用起來復雜，而且還得配置這個配置哪個，需要注意的地方太多。業務開發組的同事就不愿意用，還不如把代碼自己直接寫死了得了。超期還會影響業務功能開發組的使用。本來人家是為了想加快自己的工作效率。你答應好這個星期給業務開發組提供一個功能，但你沒有拿出來。就耽誤人家進度。你多次拿不出來，人家業務開發組還不如自己開發一個呢，求人不如求己。

我最后警告他：如果你認為自己技術夠牛，那么你必須證明你能很快做出來。如果你認為自己技術夠牛，最好能牛到，只提供一個函數就解決了他們的問題。別這個代理類，那個聚合類，這個唯一實例類。最好連參數也沒有，大家調用一下寫一句代碼就OK。甚至你做的好，大家都不用調用你的代碼，你可以包含在基礎框架中，你自己去判斷什么時候什么應用需要執行這個動作。如果你認為自己技術夠牛，那么在業務功能需求發生變化的時候，你能夠保證接口不變的情況下還能適合變化，這才你夠牛。別讓業務開發組的人跟著你也得改他們自己的代碼，那樣的設計就很爛了。

小伙聽了我的話。進度保證，代碼接口簡潔。（摘自《走出軟件作坊：走鋼索的人》）

2. 坊間流傳的大家耳熟能詳的小故事：

話說聯合利華新換了一批自動香皂包裝機以后，經常出現香皂盒子是空的沒有香皂的情況，而在裝配線一頭用人工檢查因為效率問題不太可能而且不保險。這不，一個由自動化，機械，機電一體化等專業的博士組成的Solution隊伍來解決這個問題，沒多久他們在裝配線的頭上開發了全自動的X光透射檢查線，透射檢查所有的裝配線盡頭等待裝箱的香皂盒，如果有空的就用機械臂取走。 不巧，中國一鄉鎮企業生產香皂也遇到類似問題，老板吩咐線上小工務必想出對策決之，小工拿了一個電風扇放在裝配線的頭上，對著最后的成品吹之，空盒子被吹走，問題解決之。（摘自 TopLanguage 上的討論。）因此，

• 心中有錘，就容易為其奴役。在遇到問題的時候不是具體問題具體分析，而是屁股決定腦袋，不管三七二十一先上黃金大錘再說，而且往往還頗有成就感，卻將自己真正原本要解決的問題拋在腦后了。始終莫要忘記提醒自己，“問題是什么？”
• 但毫無疑問，沒有錘子是萬萬不行的，沒有誰會傻到徒手釘釘。重點是選擇合適你的工具。這又要求在學習工具的時候始終別忘記它的適用范圍。

正確的態度應該是：

手中有錘，心中無錘。

容我具體解釋一下這句話：任何工具都有其適用范疇和前提。然而，我們在學習工具的時候由于投入很多的時間，往往在情緒上面對工具產生了太強的感情，我們既投入了時間，當然內心希望能夠用上這些工具，所以就容易忘掉其適用前提，欣欣然地不管三七二十一就把黃金大錘亮出來，以顯示自己的厲害。但如果我們換一個態度，僅僅將它看作我們工具箱中的又一件工具，就可以客觀地評估它，視具體情況而使用了——始終別忘記自己要解決的問題是什么。Why 永遠在 How 之前。

（待續；此文的修訂版已收錄《暗時間》一書，由電子工業出版社2011年8月出版。作者于2009年7月獲得南京大學計算機系碩士學位，現在微軟亞洲研究院創新工程中心從事軟件研發工程師工作。）