《高效能程序員的修煉》讀書筆記

《高效能程序員的修煉 》 EffectiveProgramming More Than Writing Codehtml

   2013年  做者: Jeff Atwood  問答網站stack overflow創始人git

   軟件開發遠不僅是寫代碼那麼簡單------程序員

 

軟件開發過程當中的人文因素。github

作個全面發展的程序員,全面一精。擡頭看路,低頭作事。面試

第一章 你想成爲一個程序員

一、生命中最困難的,是想清楚你真正想要作的事情,而不是學上一堆假設未來會有用的東西。正則表達式

二、若是你想成爲一個程序員,你只需追隨你快樂的感受,而且愛上代碼。不要爲了學編程而學編程。(編程能夠是興趣、或者解決問題(例如成爲程序員是想改變我所玩電腦遊戲的規則)、或者問題引領着本身去學編程)編程

三、程序員的八種境界:數組

      面試問題引出,「你對本身將來5年的職業規劃是怎樣的?」安全

     做爲一個程序員,最完美的職業生涯應該是什麼樣的?服務器

(不朽、成功(比爾蓋茨)、知名、勝任、普通、業餘、低調、爛程序員)。

四、傑出的程序員關鍵要把想法表達清楚,清晰的註釋和技術文檔。

五、每一個人都應該大量的寫做,無論是撰寫博客、寫書、回覆問題、寫電子郵件,這種書面溝通有助於理清咱們的思路。動手吧,開始寫起來。

六、固然只會寫代碼還不夠,若是想從優秀髮展到卓越,你必須培養起有效溝通的能力:與你的同事溝通,與你的老闆溝通,與用戶溝通,最終於全世界溝通。

第二章 把一堆爛事搞定的藝術

一、學海無邊!每一天,你必定要一塊兒牀就熱情澎湃。不然,你就只是在打工。

二、讓興趣自由地引領咱們去任何地方。(沒有人是爲了掙錢纔來參與Stack OverFlow的,初衷是想作一些很酷的東西來讓互聯網變得更好。)

三、做爲一名軟件開發人員,你該如何磨快你的鋸子(編程之外的活動)?

四、不要只顧着埋頭寫代碼,要討論、反思和學習。能夠閱讀優秀的編程博客,例如:HackerNews

五、癡迷是通向成功的一個最明顯的風向標。

六、只要有可能,請遠離干擾,而且避免同時作多個項目。程序員在切換認爲時,必然會在時間、質量以及深度思考能力各方面都受到損害。

第三章 高效編程之原則

一、第一條法則:永遠都是你的錯

在怨天尤人以前,咱們應該先自我檢討、努力把自身的問題解決了。

二、大道至簡:你永遠都有簡化的空間

 

  • 做爲一個軟件開發者,你就是本身最大的敵人。你越早認識到這點,你的境況就會越好。
  • 編碼的本質——做爲程序員,咱們的任務是要意識到,咱們所作的每一個決定都是一個折中。
  • 代碼評價的維度(代碼簡潔度、功能的完整度、執行速度、編碼所花費的時間、健壯性、靈活性),從簡潔開始,而後依據測試的結果按須要提高其餘的維度。
  • 最好的代碼就是徹底沒有代碼(所謂「大道至簡」)。若是你熱愛編程——而且愛得情真意切——那你就應該惜墨如金。

 

三、避免寫註釋

 

  • 代碼其實已經告訴我程序是怎樣工做的了,我須要註釋告訴個人是:程序爲何這樣工做。你應該老是專一於編寫代碼,而忘了還有註釋這種東西的存在。這會迫使你不遺餘力使用最簡單、最直白、最能進行自我說明的方式把代碼寫出來。(不斷重寫、重構,直至百般無奈才加註釋)
  • 初級開發者依靠註釋來說故事,而實際上他們應該依靠代碼自己。若是你以爲你的代碼在沒有註釋的狀況下顯得過於複雜,很難被人理解,那隻能說明你的代碼寫的太糟糕了。重寫你的代碼吧,直到它不須要任何註釋。若是通過努力,你仍以爲註釋是必要的,那你就務必加上註釋。

 

四、學會讀源代碼(源代碼示例源程序)

 

  • Git clone一條命令,能把遠程的源代碼複製到本機。Git(分佈式版本控制系統)是一個在開源社區裏普遍應用的源代碼管理工具,github網站給用戶提供git服務
  • 咱們須要接觸到源代碼,咱們必須閱讀別人的代碼,由於只有理解了那些代碼後,咱們才能把本身的事情作好。

 

五、你的團隊能經過電梯測試嗎?

 

  • 團隊裏的每一個人都應該經過有陌生人主持的「電梯測試」:在60秒以內,清晰的解釋他們在作什麼,以及爲何人們會在乎他們正在作的事。
  • 軟件開發者認爲他們的工做就是編寫代碼。其實否則,應該是解決客戶的問題,要有全局的觀點。

 

項目遠景模型能夠有助於電梯測試即:

爲了(目標客戶)

他們(關於需求或者機會的說明)

這個(產品名稱)是(產品類型)

它的(關鍵優點、吸引人的購買理由)

不像(主要競爭對手的替代產品)

咱們的產品(主要的差別化的特性說明)

 

  • 建立一個項目遠景聲明能夠幫助團隊持續專一於產品的關鍵方面,哪怕細節一直在快速變化也不怕;不然,團隊很容易就會被短時間(2-4周)開發迭代中的問題纏住,從而失去對整個項目遠景的控制。
  • 即便在一個提供信息技術服務的組織裏,每一個項目都應當作是一個創造「產品」的過程。面向產品的思惟方式能帶來豐厚的回報。
  • 重要3點:用簡單可行的方法來解釋咱們的產品是什麼;把潛在客戶願意購買這個產品的緣由解釋的一清二楚;與貨架上因此其餘的產品相比具備獨一無二的辨識度。

 

六、性能致勝

你的網站越快,就會有越多的人來用它。對於速度的需求,3點建議

 

  • 虔誠地遵循雅虎的指導原則                                                                                                                                   雅虎網站的加速優化實踐                                                                                                                                     記住,80%~90%的終端用戶響應時間都花在下載頁面的全部組件上:圖片、樣式表、腳本、動畫。     CDN(內容分發網絡)
  • 善待匿名用戶和註冊用戶(而且爲他們進行優化)                                                                                               不管你是否登錄,網站的內容永遠是可見的。
  • 使性能成爲一種(公開的)驕傲。                                                                                                                        對於網站的性能,有一個基本的宇宙法則是沒法被繞過的:你永遠不可能在服務器完成渲染以前發出一個網頁。做爲一名開發者,你要始終把每一個頁面的性能指標放在你的正前方。在開放的互聯網世界裏競爭,最後只會剩下兩種網站:要麼很快,要麼已經死去。

 

第四章 招聘程序員須得其法

一、爲何程序員不會編程

(立足基本,動手編程)

二、怎樣招聘程序員

(一、在什麼狀況下你會使用哈希表而不用數組?

用數組時發現有太多下標沒用到的時候,比方說要求你寫一個函數,根據輸入的日期,輸出那天的節日名稱。

你就要考慮怎樣存儲一年中各節日的日期信息了,最簡單的能夠用char *DayName[365];

但一年中多數是非節日的日常日,這個數組中其中真正有用的元素只佔少數,此時就能夠……

二、「爲何程序員開玩笑說10月31號跟12月25號是同一天?」

譯者注:10月31號用英語表示爲Oct. 31,是萬聖節(也叫「鬼節」);12月25號用英語表示爲Dec. 25,是聖誕節。Oct.原本是October(10月)的意思,

而程序員能夠把它解釋成Octal(八進制);Dec.原本是December(12月)的意思,而程序員能夠把它解釋成爲Decimal(十進制)。

因而,八進制的31等於3 x 8 + 1,結果等於十進制的25,也就是Oct. 31 = Dec. 25。)

三、如何作好面試刷選

   面試軟件開發工程師時須要問的5個基本問題,它不能保證你會找到最棒的人,但能阻止至關一部分的人矇混過關。

 

  • 編程。寫一段簡單的代碼
  • 面向對象的設計。OO的概念---
  • 腳本編程和正則表達式。Eg,描述一下如何在50000個HTML網頁裏把電話號碼都找出來。
  • 數據結構。 經常使用的數據結構的基本瞭解
  • 位與字節。位 字節 二進制數字

 

四、工做經驗年數之神話

尋找並僱傭聰明、富有熱情、有幹勁、自學能力強的工程師。有些公司都癡

迷於僱傭經驗和技術徹底匹配的人,結果形成不少才華橫溢的軟件工程師都被拒之門外。他們彷佛已經忘了,軟件開發者最擅長的就是學習。工做經驗年數與編程技能之間是沒有必然聯繫的。

第五章 促使團隊緊密協做

一、如何避免被本身的團隊「槍殺」的一個總結:

 

  • 保持謙虛;(宣佈你的發現以前,請確保你的觀察結果是正確的)
  • 提出建設性的批評時要當心;(最好非正式的建議或巧妙引導)
  • 要想贏得信譽和尊敬,最好的辦法就是努力工做而且取得實實在在的成績;
  • 百說不如一干;
  • 沒有一個通用的建議能夠適合於全部的狀況。
  • 最有效的一種領導技術就是以身做則。。

 

二、結對編程與代碼評審

結對編程:讓兩個開發者在同一臺機器上工做。一個負責編寫代碼,一個負責閱讀、覈對,每隔必定時間交換角色。(代碼被很快地完成,並且不須要返工。當代碼確實須要改動的時候,則有不止一我的熟悉代碼)

三、會議是浪費工做時間的最佳去處

爲何要開會,就我而言,我採用如下幾個原則,以確保個人會議是真正有用的:

 

  • 會議毫不應該超過一個小時,不然應該判以死刑;
  • 每一個會議都應該有一個清晰的目標聲明;(開會要達到聲明目標?)
  • 開會以前預先作好功課;
  • 把會議變成可選的;
  • 在會議結束時歸納一下待辦事項。

 

努力使咱們必需要開的爲數很少的會議開得更有效率。讓咱們快速幹活,少說廢話,抓住工做的重點。

四、處理壞蘋果

 

  • 一個有問題的團隊成員,也就是一個典型的「壞蘋果」—團隊的毒藥。
  • 你沒必要和團隊中的每一個人都成爲好朋友。
  • 若是你的團隊主管或者經理沒有處理項目中的「壞蘋果」,那他就是玩忽職守。
  • 團隊的績效能夠從團隊裏最差的那位成員身上準確地預測出來。

 

五、關於遠程辦公

 

  • 編程的世界是真正全球化的!
  • 遠程開發表明着將來

 

第六章 蝙蝠洞:程序員的高效工做場所

一、程序員的《權利法案》

「程序員應有的權利你都要去爭取!並且記住:你可讓公司作出改變,要否則就換一家公司。」(在我大中華也能夠這麼屌麼O(∩_∩)O~)

      基礎條件

 

  • 每一個程序員都應該有兩臺顯示器
  • 每一個程序員都應該有一臺快速的電腦(向高配置看齊吧~)
  • 每一個程序員都應該本身選擇鼠標和鍵盤
  • 每一個程序員都應該有一把溫馨的椅子
  • 每一個程序員都應該能快速接入互聯網。任何東西只要能「偷」來,好的程序員是歷來不會本身寫的。互聯網是有史以來「偷」東西的最佳去處。
  • 每一個程序員都應該有安靜的工做環境

 

二、電腦工做站的人體工程學

我醒着的每一刻幾乎都是在電腦前度過的。我就是那種所謂的「技術宅男」。

購買一張優質的桌子和一把優質的椅子會是你做爲一名軟件開發者所能作的最好投資之一,它們對你每一天工做的快樂度有着最直接的影響。


第七章 設計時要把用戶放在心上

一、作好細節

程序是全部微笑細節的集合。

2、用戶界面表明了軟件。—重要性

(若是你的系統有一個糟糕的界面,你基本上一無全部了。哪怕系統內部使用了最高深的技術,那也於事無補。)

用戶界面須優先設計。寫代碼前,就要想清楚這個程序的用戶界面看起來是什麼樣子的。

紙上畫原型設計時一種永遠不會過期的方法。

三、分頁顯示該休矣

一旦你有幾千條信息,你要解決的不是分頁問題,而是搜索和過濾的問題。

咱們應該避免沒頭沒腦地生成一個包含有成千上萬個條目的列表,而後用「一刀切」的方法把他們分頁顯示出來。這樣就是把全部負擔扔給了用戶。這是不合理的。記住!咱們發明計算機是爲了讓人們的生活變得更輕鬆,而不是更難。

總之,你應該努力不扯上分頁這玩意,由於你應該讓用戶在幾個條目中就能找到他們須要的東西。這是高於一切的!

第八章 安全基礎:保護用戶數據

一、全部網絡通訊都應該加密碼

 

  • 鏈接免費、開放的wifi訪問各類網站時,他們頗有可能截取你用以標識身份的cookie。
  • 使用加密的https網絡通訊。
  • Https意味着沒人能在互聯網上監視你。
  • Https不可避免的會比普通http要慢一點。

 

二、防範字典式攻擊

 

  •  限制每一個用戶的登錄嘗試次數是安全領域的101.

 

三、每一個網站都採用不一樣的強類型密碼,採用相同的密碼很容易被盯上。

第九章 增強代碼測試,別讓它太差勁

一、與客戶同甘共苦

 

  • 把開發人員帶到客戶的「戰壕」裏去是相當重要的,由於開發人員交付代碼以後,客戶纔是真正與代碼休慼與共的人。代碼是開發人員寫的,但他們並不會像他們的客戶那樣常常性的去使用。若是你對你的用戶和客戶缺少最基本的認識,那你也不可能作出貼心的軟件來。

 

二、結交「混世魔猴」(搗蛋的東東)

 

  • 每件事發生的背後老是有緣由的,要想避免失敗,最好的辦法就是不斷的失敗。

 

三、代碼評審:說作就作

 

  •    同級之間的代碼評審是你爲提升代碼質量所能作的最大的貢獻。
  • (Peer Review同級評審—軟件交付給原做者之外的其餘人幫忙檢查缺陷、促進提高的一種活動。Karl書籍《軟件同級評審》)
  •   就我我的而言,在找到一位同事幫我檢查完代碼以前,我是不會認爲我已經完成了編碼的。數據證實,代碼評審是頗有功效的。。

 

四、加大測試力度

 

  •    若是你以爲用1~2個測試用例就夠了,你卻是輕鬆了,實際上你也離失敗不遠了。

 

五、我同情那些不寫單元測試的傻瓜

   你們對單元測試(模塊測試)的廣泛接受,已經成爲軟件開發領域在過去5~7年裏最大的進步之一。


 

                                    12. 它比不寫單元測試而直接寫代碼的效率更高


六、低保真的可用性測試

 

  •  你怎麼知道你的應用程序可以正常工做?
  • 即便經過了編譯,經過了全部的單元測試,成功部署到了一個正式的服務器或打包成了一個安裝程序,連最終集成測試都經過,這些都不能保證你的程序能夠正常工做。
  • 只有找真正的用戶來作可用性測試,才能知道。

 

七、比程序崩潰更糟糕的是什麼


 

軟件測試方法參考

第十章 建立並管理社區,同時從中受益

一、傾聽社區的聲音,但別被他們牽着鼻子走

二、別盲目遵從你的用戶


第十一章 揭露營銷伎倆,以及如何規避

一、網絡廣告該休矣

二、軟件訂價,咱們深諳其道嗎

 

  •  這麼多優秀的iphone應用程序,要麼是免費,要麼只賣區區幾塊錢。
  • 我很是贊同這樣的觀點:「軟件訂價就應該足夠低,低到大部分用戶看到價格的第一反應是‘爲何不買呢’的水平」。
  • 低價是一種銷售推進力,它能夠成倍地補償價格下降的部分。(低價,銷量多,總的銷售收入多)

 

第十二章 輕重緩急,瞭然於心

一、程序員,你幸福嗎

「------最難的是,要搞明白你沒日沒夜地拼命工做究竟是爲了什麼。」

什麼是幸福的真諦呢?總結出8點

1.經歷賽過物質

東西會變舊、會變得平淡無奇,它還會磨損,很難拿來分享。可是經歷是獨特的,經歷永遠均可以拿出來與人分享,並且經常還會歷久彌新。只要有可能的話,把錢花在經歷上(好比帶全家去迪士尼樂園玩),而不要花在物質上(好比買一臺新電視機)。

2.助人爲樂

人類本質上是社會性的動物。想想,你能經過何種方式、只需花費本身一部分的錢就能幫到別人?勿以善小而不爲。

3.讓幸福細水長流

人是最能適應變化的。所以,最有效的花錢方式是常常買來一些小變化,而不是花大錢一會兒買來一個大驚喜,而後坐等着新鮮勁很快過去。若是可能的話,把一個大的購買計劃拆分紅多個小的,一點一點慢慢買進來,更好地享受整個過程。就拿幸福來講吧,頻率比強度更重要。你們須要改變一下觀念,記住:不少次小的、愉快的購買實際上比一次鉅額的購買更能有效地給你帶來幸福。

4.少買保險

額外的擔保或保險是在利用咱們「損失厭惡」的天性,利用咱們的一時衝動。由於人們的適應能力很強,當購買的東西出現故障時,其實他們並不會像原先想象的那樣懊惱不已。

並且,由於人們放棄了享受完整承諾帶來的情感利益,保險條款容易不生效或者慷慨的返還政策反而會引發更多的焦慮和不快。所以,避免購買保險,千萬別貪圖慷慨的返還政策。

5.爲未來埋單

即刻的喜悅可能會使你衝動買下你承受不起的東西,或者不是你真正想要的東西。衝動購買使你喪失了必要的思考空間,讓你難以作出合理的決定。

6.三思然後行

在進行一次重要的採購以前,考慮一下售後服務,同時也想一想一旦擁有這樣東西以後你到底哪些時間會用在它上面。試着設想未來典型的一天,一小時一小時地細細審視:這東西會如何影響你的生活?

7.當心比較購物的陷阱

「比較購物」轉移了咱們的注意力,使咱們過多地關注在這個商品區別於其餘商品的一些無足輕重的特性上,而忽略了去評估咱們真正有多喜歡這個東西。換句話說,花2美圓買到一塊便宜巧克力(不錯的買賣),跟這塊巧克力好很差吃其實沒什麼關係。不要爲了比較而比較,謹防掉入比較購物的陷阱。

試着去考量那些真正能給你帶來快樂或提高體驗的指標。

8.隨大流

不要高估你的能力,別覺得你能獨立預測你會有多喜歡某樣東西。從科學的角度來說,咱們在這方面極其不擅長!但若是某樣東西可靠地給其餘不少人帶來了幸福,那它極可能也會給你帶來幸福。在你作出購買決定以前,請認真考量一下別人的見解和用戶評論。

賺錢不容易。跟錢財相比,幸福更是來之不易!所以,當你花錢的時候,請記住上面的8點,這樣才能使你買到的幸福最大化。請記住:這是科學

附錄 程序員必讀之書

《代碼大全》Steve McConnell    

《人月神話》Frederick P.Brooks Jr (計算機也許會變,但人不會變)

《點石成金》Steve Krug

《快速軟件開發》Steve McConnell (講失敗的現實)

《Peopleware人件》Tom DeMarco (團隊領導須要好好讀此書)

《設計心理學》Donald A.Norman (魔鬼藏在細節之中)

《程序員修煉之道:從小工到專家》Andrew Hunt     

《精通正則表達式》Jerrrey E.F. Friedl

另外參考:StackOverFlow程序員推薦:每一個程序員都應該讀的30本書

相關文章
相關標籤/搜索