高效編程之原則

前言：清明時節雨紛紛，路上行人慾斷魂。借問酒家何處有？牧童遙指杏花村。對於清明節，想必杜牧這首詩確定會讓你呼之既出。今天是清明放假的最後一天，打掃完家裏的衛生，我就必需要抓緊美好的時光來記錄下《高效能程序員的修煉》一書第三章「高效編程之原則」的讀書札記。

永遠都是你的錯誤

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

      這個原則永遠都必須去遵照，不少時候，包括我，在遇到一個編程問題的時候，老是「不由自主」的埋怨到：「這TM都誰寫的代碼啊？」、「這確定是你的問題，你好好看看」、「jar包是舊的，先換個jar包再說」、「明明代碼沒有錯，怎麼回事」。這些想法容易讓咱們失去理智，忽略自身的問題，而將錯誤歸咎於他人，而這些都將影響到咱們解決問題的效率。

       在報告的錯誤中，有95%是由程序員形成的，2%是有操做系統形成的，2%是其餘軟件形成的，1%是由硬件形成的。

      OK，在出現問題的時候不要再逃避責任了，無論代碼是否是由你編寫，只要是你須要負責的，你就必須把責任扛下來。從本身寫的代碼找起，直到你找到確鑿的錯誤。我相信，你確定會有這樣的感受： 當你找出一個他人的問題時，你會無比知足，由於你在這方面超越了他；當你找出一個自身的問題時，你會很是竊喜，由於終於省得被別人嗤笑。

大道至簡

if(s==String.empty) if(s=="")

看完上面的代碼，你想用哪種？對於這兩種代碼，沒必要爭吵，我我的認爲我會使用第二行代碼，由於它更加簡潔和直白，我喜歡純粹和簡約。

     代碼不是什麼好東西。代碼會隨着時間的推移而漸漸腐爛，代碼須要週期性的維護。

     顯然，我認爲代碼是好東西，可是代碼的確會隨着時間推移而腐爛，這其中的緣由不是代碼很差，而是隨着時間，你的能力獲得了提升，這個時候，回首往日依稀歲月，你會發現你原來的代碼的確很爛，那麼就修剪他們吧，讓他們更加的純粹。所謂更好，也就是更簡，仔細看看我家的洗衣機，我真心以爲它太過複雜，面板上那麼多功能都是廢棄的，我甚至都懶得去用他們，真正的產品，不能爲了顯示本身的功能有多強大，而是讓咱們消費者做爲真正的受用羣體。

避免寫註釋

     你應該專一於編寫代碼，而忘了註釋這種東西。

     顯然，避免寫註釋是個好想法，由於高手的代碼自己就孕育着註釋，他們不會寫無聊的註釋來解釋這段代碼的功效。然而只有代碼沒有註釋是一種漸變的過程，就如同咱們看過的古裝武俠小說，小嘍囉都是在尋找各類各樣的祕籍，高手會只鑽研一門技藝，如九陰白骨爪，而最強的高手，每每都是掃地大爺，隨着年齡和覺悟的增加，咱們會最終實踐這條原則。

      很不幸，我所處的階段還不容許我任何註釋都不寫，我也尚未達到重構個人代碼直到它不須要任何註釋。對於這個方面，咱們不須要太過糾結，畢竟能力所限，主要咱們的註釋和代碼交相輝映就perfect了。由於註釋能夠幫助咱們記憶，而且理清複雜的思緒。

學會讀源代碼

      不關文檔上怎麼說，源代碼纔是最終的實現，是你所能找到的最新的、最準確的、最好的文檔。

      在讀源代碼這方面，個人能力和意識還很是欠缺，也是亟待增強的。從意識形態上，我還處於一個階段就是：「源代碼太過複雜，讀讀文檔就能解決問題了」。這個想法在不少時候，讓我陷入困局，我花費了大量的時間去找度娘，在茫茫大海中尋找着我想要的答案，而最終的都讓我失望而歸。

      而在我冷靜下來，嘗試去翻閱源碼的時候，結合自身的開發邏輯，很快就能定位到問題的真正所在。下面是書中我認爲很是好的論斷，我以爲我須要照搬過來：

       有些時候，文檔是不完整的，甚至是錯誤的，而源代碼歷來不會說謊。對於有經驗的程序員來講，看源碼遠比看文檔要快些。

    我鼓勵開發人員在源碼中暢遊，起初，他們很懼怕。「那個項目太大啦，我永遠沒法把問題找出來！」、「我沒那麼聰明，看不懂那些代碼」，如今，他們都感謝我強迫他們在別人的代碼裏潛水。

    若是一個軟件在個人機器上運行，那麼它就是個人軟件，我必須負責到底。

     那麼無論怎樣，強迫本身鑽進源碼中吧！

向橡皮鴨求助

      當你看到這個標題的時候，你確定會好奇或者驚詫，向橡皮鴨求助個毛線啊。做者對於這個標題有一個故事，我就不須要贅述了，你固然能夠買書本身看看，這本書太棒了。

      在向別人求助的時候，首先把問題拋給本身，看看本身是否有解決之道。向別人提問題的時候，書寫的方式要儘量站在解決問題者的角度，也許等你把問題寫完的時候，你就豁然開朗了。向橡皮鴨求助，是一種態度，那就是徹底投入地向一個沒有生命體的物體問一個詳盡的問題。

• 用足夠多的細節來描述發生的情況。
• 告訴咱們你爲何須要知道答案。
• 說一說你爲了這個問題都作過什麼研究，你不能什麼都不作就跑出來要答案。
• 想要從別人那裏得到答案，就必需要捨得付出，什麼都不是無償的，別人若是要回答你的問題就要花費必定的時間。

     我忽然有一個想法就是，諸如京東的購物評價，若是真的作的好的話，就不該該容許出現毫無價值的評價「很不錯。。。。。。。」、「還好了。。。。。。。。。。。」這種只是爲了獲取20個京豆的評論都必需要去除，評論是爲了幫助下一個消費者的。

1. 我碰到一個問題
2. 我決定把這個問題提到CSDN
3. 我很笨拙的寫下個人問題
4. 我意識到這個問題根本說不通
5. 我從新思考我該如何提出問題
6. 我意識到我正在一個徹底錯誤的方向上解決這個問題
7. 我從頭再來，發現很快解決了問題

OK，若是你也曾發生做者所說的這種情形，我想，就這樣去作吧，也許你本身就解決了本身的問題。

創新以人爲本

         「哎，我這個想法不錯，我以爲真是一個別人都想不到的創意，你以爲怎麼樣，是否是很想讚美我啊？」 我無不自豪的向同伴炫耀道，同伴不假思索的回答道，或許是帶有一絲嘲笑： 「哎呀，不錯啊，不過好像一文不值啊」。

        瞭解蘋果歷史的人都知道，圖形化界面並非蘋果率先提出的，而是一家叫作「施樂」的公司提出的，而喬布斯「偷竊」了這個創意，使其成爲蘋果電腦的表明做，然後來，微軟顯然一樣剽竊了這個創意。爲何蘋果和微軟會成功，施樂會失敗。真正的緣由不在誰剽竊了誰的創意，而是誰更願意把想法付諸於實踐，只有付諸於實踐的創意才具備價值。

        若是你把一個好的創意給一個普通的團隊，他們會把它搞砸，若是你把一個普通的創意給一個號的團隊，他們會加以改善。

       因此說，不要太在乎你的創意有沒有被剽竊，而是關注於執行，若是你的想法本身沒法去執行，那麼就會失去其價值。因此我要告誡本身，若是我有一個好的想法，我必需要和個人團隊一塊兒，把他實現，不然毫無價值。

你的團隊經過了電梯測試嗎

       電梯測試，就是所謂的在電梯的升降過程當中，你如何向同處於一個電梯以內的客戶推銷你的產品，你能在短期內得到成功，仍是一無所得。

       不少時候，我問同伴，你在幹嗎，回答最多的是，在寫代碼啊。和程序員溝通就是會很累，他不會告訴你他在實現一個讓服務器時間和客戶端時間同步的功能，除非你打破砂鍋問到底。

       這個原則無非就是告訴咱們程序員，咱們不只僅是在敲代碼，咱們要明確咱們在創造一個什麼樣的價值體系。不少時候，爸媽問我，「 編程都作些什麼啊？」我回答：「 反正說了你也不懂。」如今我意識到，個人回答也許就會改一改：「編程作的有：咱們可讓手機接通電話，能經過咱們編寫的代碼讓你聽到我在說話，同時讓你聽到我在說話」。

性能致勝

         網站載入和顯示的速度越慢，使用它的人就越少。

        看看CSDN的評論機制吧，你好不容易寫了一大串的文字來做爲對別人文章的評論，然而等你火燒眉毛的點了確認後，god來了，按鈕會 灰掉持續很長一段時間，而且久久看不到你是否已經評論有效，我常常都是從新打開一個網頁，在上面刷新看看個人評論是否有效，而後再關閉前一個提交中的網頁。求求CSDN，好好的優化一下吧。

       做者提到一個觀點是「善待匿名用戶和註冊用戶」，我以爲這個觀點足夠的好，不管是匿名用戶仍是留有其名的用戶，咱們必需要可以爲他們都創造很好的體驗效果。個人客戶老是有一個我沒法忍受的觀點，老是讓我把舊的代碼、性能差的交易平臺代碼給一些他認爲爛的交易所用，我這個時候，老是會有一股無名業火，我以爲這種作法，太過狹隘。

       性能好，才能抓住客戶的心理，進而帶動更大的潛在用戶，而不是用劣質的代碼敷衍那些咱們看不起的客戶。