锤子和钉子
編者按:各行各業(yè)都有自己的工具,這些“工具”不僅僅是機械實物,更是處理問題的方式和思維的方法。也許是因為太熟悉自己的“工具”,我們總會用這把“黃金大錘”去敲擊生活中遇到的一切“釘子”。以至于很多時候,明明有簡單有效的解決方法,我們卻視而不見,非要用自己的“錘子”將問題復雜化。
?
作者:劉未鵬
?
(一)
有這么一句古老的箴言:
如果你手里有一把錘子,所有東西看上去都像釘子。
?
其實這句話已經(jīng)是老調(diào)中的老調(diào)重彈了,我們程序員有很多錘子:OO、設(shè)計模式、語言(C,C++,Java,Python,Ruby,etc.)、各種各樣的架構(gòu)tricks&workarounds,以及一堆軟件過程方法論(Agile,XP,Scrum,etc.)等等。
?
幾則故事:
?
1. 阿朱的(《走出軟件作坊》):
?
我過去領(lǐng)導過架構(gòu)組。架構(gòu)組的人在2002年的時候,瘋狂迷上了UML和設(shè)計模式,人手一本《COM本質(zhì)論》和《設(shè)計模式》。我手下有一個新手,就處處是類,處處是抽象,處處是封裝,處處是分離,盡量使代碼高內(nèi)聚低耦合。但是這樣的的代碼太麻煩,他花費了大量的時間,他看自己的代碼賞心悅目,別人看他的代碼云里霧里,不閱讀懂《設(shè)計模式》就按照常規(guī)理解業(yè)務(wù)的思路去閱讀他的代碼根本閱讀不懂,不知道他為什么這樣寫代碼,怪異的很。本來,這位想達到可維護性,可閱讀性,卻真正的失去了可維護性、可閱讀性。這和我前幾天看我的朋友周愛民寫的《大道至簡》中寫到:有人希望拿UML去統(tǒng)一用戶和軟件設(shè)計者。殊不知UML有多難理解,而UML設(shè)計者卻認為UML可以描述一切。就這個道理,要理解你的代碼還要去讀懂《設(shè)計模式》,這要求太高了吧。
?
所幸這位新手自己都每次寫的累,慢慢的也就懶了,覺得確實需要分離的時候就分離,覺得沒什么必要的就懶得做了。用他自嘲的話說就是:被磨平了。其實,依我看,他現(xiàn)在這個代碼狀態(tài)才是剛剛好,即照顧了設(shè)計擴展,又照顧了實用。真正的純OO,純設(shè)計模式,可能只存在于教學和科學,而不在于我們的商業(yè)軟件開發(fā)。我們作為商業(yè)開發(fā),強調(diào)的是叫座的基礎(chǔ)上叫好,所以折中方案是必須的,客戶和我們自己兩相宜就OK,是否符合正宗,就不在我們的商業(yè)開發(fā)管理范疇了。
?
這位新手還寫了大量的注釋。在每個源代碼文件頭都寫上幾月幾號,XX創(chuàng)建的,這個原代碼文件主要是干什么的,還畫蛇添足的寫上版權(quán)所有,公司名稱。好像這個代碼要開源,或者可能會被其他公司竊取了好表明公司版權(quán)。甚至每個函數(shù)都寫了注釋,每個參數(shù)是什么意思,每個參數(shù)可能出現(xiàn)的值代表什么意思,都寫的一清二楚。久而久之,也懶的維護了。代碼改動了,參數(shù)擴展了,參數(shù)狀態(tài)值有了變化,注釋說明卻沒有跟著改動,讓后來看代碼的人老誤解,還不如不寫這些注釋。
?
我告訴他:做事不能走極端。要么全寫注釋,要么不寫注釋,都是不對的。我只在我認為要小心的地方,或者我自己都覺得很難理解懂的地方我才寫注釋。否則,我自己都可能會過段時間理解錯了。如果某段代碼我看看就能看懂,我就不寫注釋了。咱們做企業(yè)管理軟件,深入技術(shù)又沒有,只要代碼能把復雜的業(yè)務(wù)處理描述的邏輯思路清晰就OK。雖然說理解能力不同,我能快速理解了的未必有新手能夠理解,但是你看看我的代碼你就明白了。(摘自 《走出軟件作坊:代碼那些事兒》)
?
再來一段:
?
有一部分所謂的架構(gòu)師,技術(shù)超深厚,框架堪比Spring之類,但自己一個人悶頭寫框架不斷優(yōu)化,力竭使用最先進的技術(shù)思想,希望把最豪華的設(shè)計模式融進去,希望把OSGi融進去,希望把AOP融進去,全無視那些想利用框架減輕自己工作量提高自己工作效率的應(yīng)用功能開發(fā)同事。這是在用公司工資玩技術(shù)呢,還是在滿足個人技術(shù)幻想呢,還是在實驗呢?到底在干嗎?價值在哪里?
?
還有的人不會推廣自己的框架。不善言辭,就幻想著技術(shù)總監(jiān)能夠通過行政命令讓大家必須用框架,能不自己寫代碼就不自己寫代碼,能交給框架做的就交給框架做。但技術(shù)總監(jiān)號召完了,大家仍然我行我素,各自開發(fā)為政,讓框架開發(fā)者很孤單。
?
還有的人也不會推廣自己的框架,沉迷在自己的理想世界。好不容易技術(shù)總監(jiān)召集大家讓大家來聽聽框架如何應(yīng)用,但自說自話,滿口自己最得意的詞匯,聽得業(yè)務(wù)功能開發(fā)人云山霧罩。大家問些問題,如這樣的業(yè)務(wù)開發(fā)難題,框架怎么解決?于是,框架開發(fā)員就和業(yè)務(wù)開發(fā)員爭論了起來。框架開發(fā)員覺得這根本就不能答應(yīng)客戶這種變態(tài)的需求,而業(yè)務(wù)開發(fā)員說這就是現(xiàn)狀。框架開發(fā)員說你可以這樣這樣,業(yè)務(wù)開發(fā)員說這樣太麻煩,框架開發(fā)員立刻還口這還麻煩?于是雙方各執(zhí)一詞,框架也沒推廣成功。
?
我手底下有個框架開發(fā)員。他的技術(shù)渴望很強烈,為了技術(shù)難題攻克,可以不吃不睡。并且技術(shù)敏感度很強,學習也快。所以當時我感覺他是個程序員的料,就把他拉到我的手下。
?
但是有個問題,他寫出的框架代碼,在平時開發(fā)業(yè)務(wù)功能的時候挺麻煩。大家可能需要的是一把鐵鍬,但是他卻給大家N根不同長度不同粗細不同材質(zhì)的木棍,N個不同形狀不同用途的鐵鍬頭。大家會有N種組合。不僅導致他寫代碼老超任務(wù)期,而且也讓使用人感覺沒多大幫助。使用起來復雜,而且還得配置這個配置哪個,需要注意的地方太多。業(yè)務(wù)開發(fā)組的同事就不愿意用,還不如把代碼自己直接寫死了得了。超期還會影響業(yè)務(wù)功能開發(fā)組的使用。本來人家是為了想加快自己的工作效率。你答應(yīng)好這個星期給業(yè)務(wù)開發(fā)組提供一個功能,但你沒有拿出來。就耽誤人家進度。你多次拿不出來,人家業(yè)務(wù)開發(fā)組還不如自己開發(fā)一個呢,求人不如求己。
?
我最后警告他:如果你認為自己技術(shù)夠牛,那么你必須證明你能很快做出來。如果你認為自己技術(shù)夠牛,最好能牛到,只提供一個函數(shù)就解決了他們的問題。別這個代理類,那個聚合類,這個唯一實例類。最好連參數(shù)也沒有,大家調(diào)用一下寫一句代碼就OK。甚至你做的好,大家都不用調(diào)用你的代碼,你可以包含在基礎(chǔ)框架中,你自己去判斷什么時候什么應(yīng)用需要執(zhí)行這個動作。如果你認為自己技術(shù)夠牛,那么在業(yè)務(wù)功能需求發(fā)生變化的時候,你能夠保證接口不變的情況下還能適合變化,這才你夠牛。別讓業(yè)務(wù)開發(fā)組的人跟著你也得改他們自己的代碼,那樣的設(shè)計就很爛了。
?
小伙聽了我的話。進度保證,代碼接口簡潔。(摘自《走出軟件作坊:走鋼索的人》)
?
2. 坊間流傳的大家耳熟能詳?shù)男」适?#xff1a;
?
話說聯(lián)合利華新?lián)Q了一批自動香皂包裝機以后,經(jīng)常出現(xiàn)香皂盒子是空的沒有香皂的情況,而在裝配線一頭用人工檢查因為效率問題不太可能而且不保險。這不,一個由自動化,機械,機電一體化等專業(yè)的博士組成的Solution隊伍來解決這個問題,沒多久他們在裝配線的頭上開發(fā)了全自動的X光透射檢查線,透射檢查所有的裝配線盡頭等待裝箱的香皂盒,如果有空的就用機械臂取走。
?
不巧,中國一鄉(xiāng)鎮(zhèn)企業(yè)生產(chǎn)香皂也遇到類似問題,老板吩咐線上小工務(wù)必想出對策解決之,小工拿了一個電風扇放在裝配線的頭上,對著最后的成品吹之,空盒子被吹走,問題解決之。(摘自TopLanguage上的討論)
?
因此,
?
心中有錘,就容易為其奴役:在遇到問題的時候不是具體問題具體分析,而是屁股決定腦袋,不管三七二十一先上黃金大錘再說,而且往往還頗有成就感,卻將自己真正原本要解決的問題拋在腦后了。始終莫要忘記提醒自己,“問題是什么?”
?
但毫無疑問,沒有錘子是萬萬不行的,沒有誰會傻到徒手釘釘。重點是選擇合適你的工具。這又要求在學習工具的時候始終別忘記它的適用范圍。
?
正確的態(tài)度應(yīng)該是:
?
手中有錘,心中無錘。
?
容我具體解釋一下這句話:任何工具都有其適用范疇和前提。然而,我們在學習工具的時候由于投入很多的時間,往往在情緒上面對工具產(chǎn)生了太強的感情,我們既投入了時間,當然內(nèi)心希望能夠用上這些工具,所以就容易忘掉其適用前提,欣欣然地不管三七二十一就把黃金大錘亮出來,以顯示自己的厲害。但如果我們換一個態(tài)度,僅僅將它看作我們工具箱中的又一件工具,就可以客觀地評估它,視具體情況而使用了——始終別忘記自己要解決的問題是什么。Why永遠在How之前。
?
(二)
?
與上面對應(yīng)的還有另一句話(實際上這是我杜撰的):
?
如果你想釘一個釘子,所有東西看上去都像是錘子。
?
用大白話來說就是:如果你心中專注于你想要解決的問題,那么你所看到的東西就會呈現(xiàn)出以往你沒有看到的一面。
?
例子:
?
1. 阿基米德洗了一輩子的澡,然而,只有那一次,當他想要解決皇冠密度問題的時候,想到可以利用排水體積來測量不規(guī)則物體體積。
?
2. 如果你也喜歡看《Monk》,就會體會到把問題裝在心中,甚至把自己變成問題,問題即自己的作用——當 Monk的潛意識里面始終在尋思How,Why,Who did it這幾個問題時,周遭環(huán)境中的一切信息都會顯出另一番面目,一個平常情況下根本不會注意到的細節(jié)也能成為破案的關(guān)鍵,看似不相干的信息也能帶來出乎意料的啟發(fā)
3. BentObjects
?
如果你也像我一樣,習慣于經(jīng)常把疑問裝在大腦中醞釀好幾天,你肯定會有eureka的體驗。
或者,如果你喜歡在一段時間之內(nèi)關(guān)注某個主題,你在閱讀書籍資料的時候就會帶著問題的眼鏡,看到平常看不到的東西,作出與平常不一樣的思考。
?
把自己變成釘子,這就是eureka的奧秘。
?
作者:劉未鵬
?
(一)
有這么一句古老的箴言:
如果你手里有一把錘子,所有東西看上去都像釘子。
?
其實這句話已經(jīng)是老調(diào)中的老調(diào)重彈了,我們程序員有很多錘子:OO、設(shè)計模式、語言(C,C++,Java,Python,Ruby,etc.)、各種各樣的架構(gòu)tricks&workarounds,以及一堆軟件過程方法論(Agile,XP,Scrum,etc.)等等。
?
幾則故事:
?
1. 阿朱的(《走出軟件作坊》):
?
我過去領(lǐng)導過架構(gòu)組。架構(gòu)組的人在2002年的時候,瘋狂迷上了UML和設(shè)計模式,人手一本《COM本質(zhì)論》和《設(shè)計模式》。我手下有一個新手,就處處是類,處處是抽象,處處是封裝,處處是分離,盡量使代碼高內(nèi)聚低耦合。但是這樣的的代碼太麻煩,他花費了大量的時間,他看自己的代碼賞心悅目,別人看他的代碼云里霧里,不閱讀懂《設(shè)計模式》就按照常規(guī)理解業(yè)務(wù)的思路去閱讀他的代碼根本閱讀不懂,不知道他為什么這樣寫代碼,怪異的很。本來,這位想達到可維護性,可閱讀性,卻真正的失去了可維護性、可閱讀性。這和我前幾天看我的朋友周愛民寫的《大道至簡》中寫到:有人希望拿UML去統(tǒng)一用戶和軟件設(shè)計者。殊不知UML有多難理解,而UML設(shè)計者卻認為UML可以描述一切。就這個道理,要理解你的代碼還要去讀懂《設(shè)計模式》,這要求太高了吧。
?
所幸這位新手自己都每次寫的累,慢慢的也就懶了,覺得確實需要分離的時候就分離,覺得沒什么必要的就懶得做了。用他自嘲的話說就是:被磨平了。其實,依我看,他現(xiàn)在這個代碼狀態(tài)才是剛剛好,即照顧了設(shè)計擴展,又照顧了實用。真正的純OO,純設(shè)計模式,可能只存在于教學和科學,而不在于我們的商業(yè)軟件開發(fā)。我們作為商業(yè)開發(fā),強調(diào)的是叫座的基礎(chǔ)上叫好,所以折中方案是必須的,客戶和我們自己兩相宜就OK,是否符合正宗,就不在我們的商業(yè)開發(fā)管理范疇了。
?
這位新手還寫了大量的注釋。在每個源代碼文件頭都寫上幾月幾號,XX創(chuàng)建的,這個原代碼文件主要是干什么的,還畫蛇添足的寫上版權(quán)所有,公司名稱。好像這個代碼要開源,或者可能會被其他公司竊取了好表明公司版權(quán)。甚至每個函數(shù)都寫了注釋,每個參數(shù)是什么意思,每個參數(shù)可能出現(xiàn)的值代表什么意思,都寫的一清二楚。久而久之,也懶的維護了。代碼改動了,參數(shù)擴展了,參數(shù)狀態(tài)值有了變化,注釋說明卻沒有跟著改動,讓后來看代碼的人老誤解,還不如不寫這些注釋。
?
我告訴他:做事不能走極端。要么全寫注釋,要么不寫注釋,都是不對的。我只在我認為要小心的地方,或者我自己都覺得很難理解懂的地方我才寫注釋。否則,我自己都可能會過段時間理解錯了。如果某段代碼我看看就能看懂,我就不寫注釋了。咱們做企業(yè)管理軟件,深入技術(shù)又沒有,只要代碼能把復雜的業(yè)務(wù)處理描述的邏輯思路清晰就OK。雖然說理解能力不同,我能快速理解了的未必有新手能夠理解,但是你看看我的代碼你就明白了。(摘自 《走出軟件作坊:代碼那些事兒》)
?
再來一段:
?
有一部分所謂的架構(gòu)師,技術(shù)超深厚,框架堪比Spring之類,但自己一個人悶頭寫框架不斷優(yōu)化,力竭使用最先進的技術(shù)思想,希望把最豪華的設(shè)計模式融進去,希望把OSGi融進去,希望把AOP融進去,全無視那些想利用框架減輕自己工作量提高自己工作效率的應(yīng)用功能開發(fā)同事。這是在用公司工資玩技術(shù)呢,還是在滿足個人技術(shù)幻想呢,還是在實驗呢?到底在干嗎?價值在哪里?
?
還有的人不會推廣自己的框架。不善言辭,就幻想著技術(shù)總監(jiān)能夠通過行政命令讓大家必須用框架,能不自己寫代碼就不自己寫代碼,能交給框架做的就交給框架做。但技術(shù)總監(jiān)號召完了,大家仍然我行我素,各自開發(fā)為政,讓框架開發(fā)者很孤單。
?
還有的人也不會推廣自己的框架,沉迷在自己的理想世界。好不容易技術(shù)總監(jiān)召集大家讓大家來聽聽框架如何應(yīng)用,但自說自話,滿口自己最得意的詞匯,聽得業(yè)務(wù)功能開發(fā)人云山霧罩。大家問些問題,如這樣的業(yè)務(wù)開發(fā)難題,框架怎么解決?于是,框架開發(fā)員就和業(yè)務(wù)開發(fā)員爭論了起來。框架開發(fā)員覺得這根本就不能答應(yīng)客戶這種變態(tài)的需求,而業(yè)務(wù)開發(fā)員說這就是現(xiàn)狀。框架開發(fā)員說你可以這樣這樣,業(yè)務(wù)開發(fā)員說這樣太麻煩,框架開發(fā)員立刻還口這還麻煩?于是雙方各執(zhí)一詞,框架也沒推廣成功。
?
我手底下有個框架開發(fā)員。他的技術(shù)渴望很強烈,為了技術(shù)難題攻克,可以不吃不睡。并且技術(shù)敏感度很強,學習也快。所以當時我感覺他是個程序員的料,就把他拉到我的手下。
?
但是有個問題,他寫出的框架代碼,在平時開發(fā)業(yè)務(wù)功能的時候挺麻煩。大家可能需要的是一把鐵鍬,但是他卻給大家N根不同長度不同粗細不同材質(zhì)的木棍,N個不同形狀不同用途的鐵鍬頭。大家會有N種組合。不僅導致他寫代碼老超任務(wù)期,而且也讓使用人感覺沒多大幫助。使用起來復雜,而且還得配置這個配置哪個,需要注意的地方太多。業(yè)務(wù)開發(fā)組的同事就不愿意用,還不如把代碼自己直接寫死了得了。超期還會影響業(yè)務(wù)功能開發(fā)組的使用。本來人家是為了想加快自己的工作效率。你答應(yīng)好這個星期給業(yè)務(wù)開發(fā)組提供一個功能,但你沒有拿出來。就耽誤人家進度。你多次拿不出來,人家業(yè)務(wù)開發(fā)組還不如自己開發(fā)一個呢,求人不如求己。
?
我最后警告他:如果你認為自己技術(shù)夠牛,那么你必須證明你能很快做出來。如果你認為自己技術(shù)夠牛,最好能牛到,只提供一個函數(shù)就解決了他們的問題。別這個代理類,那個聚合類,這個唯一實例類。最好連參數(shù)也沒有,大家調(diào)用一下寫一句代碼就OK。甚至你做的好,大家都不用調(diào)用你的代碼,你可以包含在基礎(chǔ)框架中,你自己去判斷什么時候什么應(yīng)用需要執(zhí)行這個動作。如果你認為自己技術(shù)夠牛,那么在業(yè)務(wù)功能需求發(fā)生變化的時候,你能夠保證接口不變的情況下還能適合變化,這才你夠牛。別讓業(yè)務(wù)開發(fā)組的人跟著你也得改他們自己的代碼,那樣的設(shè)計就很爛了。
?
小伙聽了我的話。進度保證,代碼接口簡潔。(摘自《走出軟件作坊:走鋼索的人》)
?
2. 坊間流傳的大家耳熟能詳?shù)男」适?#xff1a;
?
話說聯(lián)合利華新?lián)Q了一批自動香皂包裝機以后,經(jīng)常出現(xiàn)香皂盒子是空的沒有香皂的情況,而在裝配線一頭用人工檢查因為效率問題不太可能而且不保險。這不,一個由自動化,機械,機電一體化等專業(yè)的博士組成的Solution隊伍來解決這個問題,沒多久他們在裝配線的頭上開發(fā)了全自動的X光透射檢查線,透射檢查所有的裝配線盡頭等待裝箱的香皂盒,如果有空的就用機械臂取走。
?
不巧,中國一鄉(xiāng)鎮(zhèn)企業(yè)生產(chǎn)香皂也遇到類似問題,老板吩咐線上小工務(wù)必想出對策解決之,小工拿了一個電風扇放在裝配線的頭上,對著最后的成品吹之,空盒子被吹走,問題解決之。(摘自TopLanguage上的討論)
?
因此,
?
心中有錘,就容易為其奴役:在遇到問題的時候不是具體問題具體分析,而是屁股決定腦袋,不管三七二十一先上黃金大錘再說,而且往往還頗有成就感,卻將自己真正原本要解決的問題拋在腦后了。始終莫要忘記提醒自己,“問題是什么?”
?
但毫無疑問,沒有錘子是萬萬不行的,沒有誰會傻到徒手釘釘。重點是選擇合適你的工具。這又要求在學習工具的時候始終別忘記它的適用范圍。
?
正確的態(tài)度應(yīng)該是:
?
手中有錘,心中無錘。
?
容我具體解釋一下這句話:任何工具都有其適用范疇和前提。然而,我們在學習工具的時候由于投入很多的時間,往往在情緒上面對工具產(chǎn)生了太強的感情,我們既投入了時間,當然內(nèi)心希望能夠用上這些工具,所以就容易忘掉其適用前提,欣欣然地不管三七二十一就把黃金大錘亮出來,以顯示自己的厲害。但如果我們換一個態(tài)度,僅僅將它看作我們工具箱中的又一件工具,就可以客觀地評估它,視具體情況而使用了——始終別忘記自己要解決的問題是什么。Why永遠在How之前。
?
(二)
?
與上面對應(yīng)的還有另一句話(實際上這是我杜撰的):
?
如果你想釘一個釘子,所有東西看上去都像是錘子。
?
用大白話來說就是:如果你心中專注于你想要解決的問題,那么你所看到的東西就會呈現(xiàn)出以往你沒有看到的一面。
?
例子:
?
1. 阿基米德洗了一輩子的澡,然而,只有那一次,當他想要解決皇冠密度問題的時候,想到可以利用排水體積來測量不規(guī)則物體體積。
?
2. 如果你也喜歡看《Monk》,就會體會到把問題裝在心中,甚至把自己變成問題,問題即自己的作用——當 Monk的潛意識里面始終在尋思How,Why,Who did it這幾個問題時,周遭環(huán)境中的一切信息都會顯出另一番面目,一個平常情況下根本不會注意到的細節(jié)也能成為破案的關(guān)鍵,看似不相干的信息也能帶來出乎意料的啟發(fā)
3. BentObjects
?
如果你也像我一樣,習慣于經(jīng)常把疑問裝在大腦中醞釀好幾天,你肯定會有eureka的體驗。
或者,如果你喜歡在一段時間之內(nèi)關(guān)注某個主題,你在閱讀書籍資料的時候就會帶著問題的眼鏡,看到平常看不到的東西,作出與平常不一樣的思考。
?
把自己變成釘子,這就是eureka的奧秘。
總結(jié)
- 上一篇: 翼灵物联工作室第一次考试总结
- 下一篇: fork炸弹c语言能否运行,Fork炸弹