《高效程序员的45个习惯》-之二
請您在閱讀本文之前,先了解《高效程序員的45個習(xí)慣》-之一。
每一期都會涉及15個話題,用3期來列出這45個習(xí)慣,每次不貪多,貪精,大家如果有空,一定要細(xì)細(xì)品味這15個習(xí)慣。
注意:每一個好的習(xí)慣,開頭都會相應(yīng)有一個唱反調(diào)的句子哦。
?
1 做事
“出了問題,第一重要的是確定元兇,找到那個人!一旦證實了是他的錯誤,就可以保證這樣的問題永遠(yuǎn)也不會再發(fā)生了。”
指責(zé)不會修復(fù)bug,把矛頭對準(zhǔn)問題的解決辦法,而不是人。這是真正有用處的正面效應(yīng)。
也許你不相信,但確實有些人常常不把解決問題放在最高優(yōu)先級上。也許你也沒有。先自我反省一下,當(dāng)有問題出現(xiàn)時,“第一”反應(yīng)究竟是什么?
一個重大的錯誤應(yīng)該被當(dāng)作是一次學(xué)習(xí)而不是指責(zé)他人的機(jī)會。
團(tuán)隊成員們在一起工作,應(yīng)互相幫助,而不是互相指責(zé)。
如果你沒有犯過任何錯誤,就說明你可能沒有努力去工作。
?
2 欲訴則不達(dá)
“你不需要真正地理解那塊代碼,它只要能夠工作就可以了。哦,它需要一個小小的調(diào)整。只要在結(jié)果中再加上幾行代碼,它就可以工作了。干吧!就把那幾行代碼加進(jìn)去,它應(yīng)該可以工作。”
拙劣的代碼工人會這樣不假思索地改完代碼,然后快速轉(zhuǎn)向下一個問題;而優(yōu)秀的程序員會挖掘更深一層,盡力去理解為什么這里需要加1,更重要的是,他會想明白會產(chǎn)生什么其他影響。
千里之堤,潰于蟻穴,大災(zāi)難是逐步演化而來的。一次又一次的快速修復(fù),每一次都不探究問題的根源,久而久之就形成了一個危險的沼澤地,最終會吞噬整個項目的生命。
如果有一位團(tuán)隊成員宣布,有一塊代碼其他人都很難看懂,這就意味著任何人(包括原作者)都很難維護(hù)它。請讓它變得簡單些。
?
3 對事不對人
“當(dāng)L先生在做一個新方案介紹時,下面有人會說‘這樣設(shè)計很蠢!都沒有考慮線程安全!’(這也暗示著L先生很蠢)。”
事實上,最適合并且最有效的表達(dá)方式應(yīng)該是“謝謝,L先生。但是我想知道,如果兩個用戶同時登錄會發(fā)生什么情況?”
盡力貢獻(xiàn)自己的好想法,如果你的想法沒有被采納也無需生氣;不要因為只是想體現(xiàn)自己的想法而對擬定的好思路畫蛇添足。
?
4 排除萬難,奮勇前進(jìn)
“老鼠們打算在貓的脖子上系一個鈴鐺,這樣貓巡邏靠近時,就能預(yù)先得到警報。每只老鼠都點(diǎn)頭,認(rèn)為這是一個絕妙的想法。這時一個年老的老鼠站出來說道’那么,誰愿意挺身而出去系鈴鐺呢?’毫無疑問,沒有一只老鼠站出來。當(dāng)然,這個絕妙的計劃也就這樣泡湯了。”
有時,絕妙的計劃會因為勇氣不足而最終失敗。盡管前方很危險,但你必須有勇氣向前沖鋒,做你認(rèn)為對的事情。
當(dāng)你勇敢地站出來時,如果受到了缺乏背景知識的抉擇者的抵制,你需要用他們能夠聽懂的話語表達(dá)。“更清晰的代碼”是無法打動生意人的。節(jié)約資金、獲得更好的投資回報,避免訴訟以及增加用戶利益,會讓論點(diǎn)更有說服力。
?
5 跟蹤變化
“軟件技術(shù)的變化如此之快,勢不可擋,這是它的本性。繼續(xù)用你熟悉的語言做你的老本行吧,你不可能跟上技術(shù)變化的腳步。”
如果只是掌握了工作中需要的技術(shù)并不夠。那樣的工作也許幾年之后就不再有了—它會被外包或者會過時,那么你就將會出局。
迭代和增量式的學(xué)習(xí);了解最新行情;參加本地的用戶組活動;參加研討會議;如饑似渴地閱讀。
?
6 對團(tuán)隊投資
“不要和別人分享你的知識—自己留著。你是因為這些知識才成為團(tuán)隊中的佼佼者,只要自己聰明就可以了,不用管其他失敗者。”
團(tuán)隊中的開發(fā)者們各有不同的能力、經(jīng)驗和技術(shù)。每個人都各有所長。不同才能和背景的人混在一起,是一個非常理想的學(xué)習(xí)環(huán)境。
一個學(xué)習(xí)型的團(tuán)隊才是較好的團(tuán)隊。
每周,要求團(tuán)隊中的一個人主持講座。他會給大家介紹一些概念,演示工具,或者做團(tuán)隊感興趣的任何一件事。你可以挑一本書,給大家說說其中一些特別內(nèi)容、項目或者實踐,無論什么主題都可以。
?
7 懂得丟棄
“那就是你一貫的工作方法,并且是有原因的。這個方法也很好地為你所用。開始你就掌握了這個方法,很明顯它是最好的方法。真的,從那以后就不要再改變了。”
打破舊習(xí)慣很難,更難的是自己還沒有意識到這個問題。丟棄的第一步,就是要意識到你還在使用過時的方法,這也是最難的部分。另一個難點(diǎn)就是要做到真正的丟棄舊習(xí)慣。 畢竟,汽車要比馬車車廂強(qiáng)多了。
不是完全忘記舊的習(xí)慣,而是只在使用適當(dāng)?shù)募夹g(shù)時才使用它。
?
8 打破砂鍋問到底
“接受別人給你的解釋,別人告訴你問題出在了什么地方,你就去看什么地方。不需要再浪費(fèi)時間去追根究底”
要不停的問“為什么”。不能只滿足于別人告訴你的表面現(xiàn)象,要不停的提問直到你明白問題的根源。
問“為什么”,但是要問到點(diǎn)子上。
當(dāng)你問“為什么”的時候,也許你會被反問:“為什么你問這個問題?”。在提問之前,想好你提問的理由,這會有助于你問出恰當(dāng)?shù)膯栴}。
?
9 把握開發(fā)節(jié)奏
“我們很長時間沒有進(jìn)行代碼復(fù)審,所以這周會復(fù)審所有的代碼。”
在許多不成功的項目中,基本上都是隨意安排工作計劃,沒有任何規(guī)律。那么樣的隨機(jī)安排很難處理。你根本不知道明天將會發(fā)生什么。
但是,敏捷項目會有一個節(jié)奏和循環(huán),讓開發(fā)變得更加輕松。Scrum約定了30天之內(nèi)不應(yīng)該發(fā)生需求變化,這樣可以確保團(tuán)隊有一個良性的開發(fā)節(jié)奏。(Scrum是一種迭代式增量軟件開發(fā)過程,通常用于敏捷軟件開發(fā)。包括了一系列實踐和預(yù)定義角色的過程骨架。)
站立會議最好每天在固定的時間和地點(diǎn)舉行,比如說上午10點(diǎn)左右。要養(yǎng)成這樣的習(xí)慣,在那時就準(zhǔn)備好一切參加站立會議。
?
10 讓客戶做決定
“開發(fā)者兼具創(chuàng)新和智慧,最了解應(yīng)用程序。因此,所有關(guān)鍵決定都應(yīng)該由開發(fā)者定奪。每次業(yè)務(wù)人員介入的時候,都會弄得一團(tuán)糟,他們無法理解我們做事的邏輯。”
在設(shè)計方面,做決定的時候必須有開發(fā)者參與。可是,在一個項目中,他們不應(yīng)該做所有的決定,特別是業(yè)務(wù)方面的決定。
記錄客戶做出的決定,并注明原因。好記性不如爛筆頭。
?
11 讓設(shè)計指導(dǎo)而不是操縱開發(fā)
“設(shè)計文檔應(yīng)該盡可能詳細(xì),這樣,低級的代碼工人只要敲入代碼就可以了。編寫代碼的時候,無論你發(fā)現(xiàn)什么,絕不能偏離了設(shè)計文檔。”
設(shè)計滿足實現(xiàn)即可,不必過于詳細(xì)。
即使之前已經(jīng)提交了設(shè)計文檔,也還會有一些意料之外的情況出現(xiàn)。時刻謹(jǐn)記,此階段提出的設(shè)計只是基于你目前對需求的理解而已。一旦開始了編碼,一切都會改變。設(shè)計及其代碼實現(xiàn)會不停地發(fā)展和變化。
設(shè)計可以分為兩層:戰(zhàn)略和戰(zhàn)術(shù)。前期的設(shè)計屬于戰(zhàn)略,通常只有在沒有深入理解需求的時候需要這樣的設(shè)計。更確切的說,它應(yīng)該只描述總體戰(zhàn)略,不應(yīng)深入到具體的細(xì)節(jié)。
?
12 合理地使用技術(shù)
“你開始了一個新的項目,在你面前有一長串關(guān)于新技術(shù)和應(yīng)用框架的列表。這些都是好東西,你真的需要使用列表中所有的技術(shù)。想一想,你的簡歷上將留下漂亮的一筆,用那些偉大的框架,你的新應(yīng)用將具有極高的技術(shù)含量。”
這個技術(shù)框架真能解決這個問題么?(如果需要,先做一個小的原型)
你將會被它拴住么?(一些技術(shù)是賊船,一旦你使用了它,就會被它套牢,再也不可能回頭了。我們需要考慮它是開放技術(shù)還是專利技術(shù))
維護(hù)成本是多少?(維護(hù)成本昂貴。我們聽說,有個項目的合同是支持一個規(guī)則引擎,引擎一年的維護(hù)費(fèi)用是5萬美元,但是,這個數(shù)據(jù)庫只有30條規(guī)則)
不需開發(fā)你能下載到的東西。
新技術(shù)就應(yīng)該像是新的工具,可以幫助你更好地工作,它自己不應(yīng)該成為你的工作。
?
13 保持可發(fā)布
“我們剛試用的時候發(fā)現(xiàn)了一個問題,你需要立即修復(fù)它,放下你手頭的工作,去修復(fù)那個剛發(fā)現(xiàn)的問題。不用告訴其他任何人—趕快讓它工作就行了。”
已提交的代碼應(yīng)該隨時可以行動。
在本地運(yùn)行測試;檢出最新的代碼;提交代碼。
?
14 提早集成,頻繁集成
“只要沒有到開發(fā)的末尾階段,就不要過早地浪費(fèi)時間去想如何集成你的代碼,至少也要等開發(fā)差不多的時候,才可以考慮它。”
敏捷的一個主要特點(diǎn)就是持續(xù)開發(fā),而不是三天打魚兩天曬網(wǎng)地工作。特別是在幾個人一起開發(fā)同一個功能時,更應(yīng)該頻繁地集成代碼。
絕不要做大爆炸似的集成。
代碼集成是主要的風(fēng)險來源。要想規(guī)避這個風(fēng)險,只有提早集成,持續(xù)而有規(guī)律地進(jìn)行集成。
?
15 提早實現(xiàn)自動化部署
“沒問題,可以手動安裝產(chǎn)品,尤其是給質(zhì)量保證人員安裝。”
系統(tǒng)能在你的機(jī)器上運(yùn)行,或者能在開發(fā)者和測試人員的機(jī)器上運(yùn)行,當(dāng)然很好,但是,它同時也需要能夠部署在用戶的機(jī)器上。
質(zhì)量保證人員應(yīng)該測試部署過程。
從第一天起就開始交付,一開始就實現(xiàn)自動化部署應(yīng)用。
如果維護(hù)安裝腳本變得很困難,那很可能是一個早期警告,預(yù)示著—很高的維護(hù)成本。
總結(jié)
以上是生活随笔為你收集整理的《高效程序员的45个习惯》-之二的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: POJ 3613 Cow Relays
- 下一篇: 《高效程序员的45个习惯》-末篇