《高效程序员的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个习惯》-末篇