前言：清明時節雨紛紛，路上行人欲斷魂。借問酒家何處有？牧童遙指杏花村。對於清明節，想必杜牧這首詩肯定會讓你呼之既出。今天是清明放假的最後一天，打掃完家裡的衛生，我就必須要抓緊美好的時光來記錄下《高效能程式設計師的修煉》一書第三章「高效程式設計之原則」的讀書札記。
在怨天尤人之前，我們應該做好自我反省，努力先把自身的問題解決了。
這個原則永遠都必須去遵守，很多時候，包括我，在遇到乙個程式設計問題的時候，總是「情不自禁」的埋怨到：「這tm都誰寫的**啊？」、「這肯定是你的問題，你好好看看」、「jar包是舊的，先換個jar包再說」、「明明**沒有錯，怎麼回事」。這些想法容易讓我們失去理智，忽略自身的問題，而將錯誤歸咎於他人，而這些都將影響到我們解決問題的效率。
在報告的錯誤中，有95%是由程式設計師造成的，2%是有作業系統造成的，2%是其他軟體造成的，1%是由硬體造成的。
ok，在出現問題的時候不要再逃避責任了，不管**是不是由你編寫，只要是你需要負責的，你就必須把責任扛下來。從自己寫的**找起，直到你找到確鑿的錯誤。我相信，你肯定會有這樣的感覺：當你找出乙個他人的問題時，你會無比滿足，因為你在這方面超越了他；當你找出乙個自身的問題時，你會非常竊喜，因為終於免得被別人嗤笑。
if(s==string.empty)
if(s=="")
看完上面的**，你想用哪一種？對於這兩種**，不必爭吵，我個人認為我會使用第二行**，因為它更加簡潔和直白，我喜歡純粹和簡約。
**不是什麼好東西。**會隨著時間的推移而漸漸腐爛，**需要週期性的維護。
顯然，我認為**是好東西，但是**的確會隨著時間推移而腐爛，這其中的原因不是**不好，而是隨著時間，你的能力得到了提高，這個時候，回首往日依稀歲月，你會發現你原來的**的確很爛，那麼就修剪他們吧，讓他們更加的純粹。所謂更好，也就是更簡，仔細看看我家的洗衣機，我真心覺得它太過複雜，面板上那麼多功能都是廢棄的，我甚至都懶得去用他們，真正的產品，不能為了顯示自己的功能有多強大，而是讓我們消費者作為真正的受用群體。
你應該專注於編寫**，而忘了注釋這種東西。
顯然，避免寫注釋是個好想法，因為高手的**本身就孕育著注釋，他們不會寫無聊的注釋來解釋這段**的功效。然而只有**沒有注釋是一種漸變的過程，就如同我們看過的古裝武俠**，小嘍囉都是在尋找各種各樣的秘籍，高手會只鑽研一門技藝，如九陰白骨爪，而最強的高手，往往都是掃地大爺，隨著年齡和覺悟的增長，我們會最終實踐這條原則。
很不幸，我所處的階段還不允許我任何注釋都不寫，我也還沒有達到重構我的**直到它不需要任何注釋。對於這個方面，我們不需要太過糾結，畢竟能力所限，主要我們的注釋和**交相輝映就perfect了。因為注釋可以幫助我們記憶，並且理清複雜的思緒。
不關文件上怎麼說，源**才是最終的實現，是你所能找到的最新的、最準確的、最好的文件。
在讀源**這方面，我的能力和意識還非常欠缺，也是亟待加強的。從意識形態上，我還處於乙個階段就是：「源**太過複雜，讀讀文件就能解決問題了」。這個想法在很多時候，讓我陷入困局，我花費了大量的時間去找度娘，在茫茫大海中尋找著我想要的答案，而最終的都讓我失望而歸。
而在我冷靜下來，嘗試去翻閱原始碼的時候，結合自身的開發邏輯，很快就能定位到問題的真正所在。下面是書中我認為非常好的論斷，我覺得我需要照搬過來：
有些時候，文件是不完整的，甚至是錯誤的，而源**從來不會說謊。對於有經驗的程式設計師來說，看原始碼遠比看文件要快些。
我鼓勵開發人員在原始碼中暢遊，起初，他們很害怕。「那個專案太大啦，我永遠無法把問題找出來！」、「我沒那麼聰明，看不懂那些**」，現在，他們都感謝我強迫他們在別人的**裡潛水。
如果乙個軟體在我的機器上執行，那麼它就是我的軟體，我必須負責到底。
那麼不管怎樣，強迫自己鑽進原始碼中吧！
當你看到這個標題的時候，你肯定會好奇或者驚詫，向橡皮鴨求助個毛線啊。作者對於這個標題有乙個故事，我就不需要贅述了，你當然可以買書自己看看，這本書太棒了。
在向別人求助的時候，首先把問題拋給自己，看看自己是否有解決之道。向別人提問題的時候，書寫的方式要盡可能站在解決問題者的角度，也許等你把問題寫完的時候，你就豁然開朗了。向橡皮鴨求助，是一種態度，那就是完全投入地向乙個沒有生命體的物體問乙個詳盡的問題。
我碰到乙個問題
我決定把這個問題提到csdn
我很笨拙的寫下我的問題
我意識到這個問題根本說不通
我重新思考我該如何提出問題
我意識到我正在乙個完全錯誤的方向上解決這個問題
我從頭再來，發現很快解決了問題
ok，如果你也曾發生作者所說的這種情形，我想，就這樣去做吧，也許你自己就解決了自己的問題。
「哎，我這個想法不錯，我覺得真是乙個別人都想不到的創意，你覺得怎麼樣，是不是很想讚美我啊？」
我無不自豪的向同伴炫耀道，同伴不假思索的回答道，或許是帶有一絲嘲笑：
「哎呀，不錯啊，不過好像一文不值啊」。
了解蘋果歷史的人都知道，圖形化介面並不是蘋果率先提出的，而是一家叫做「施樂」的公司提出的，而賈伯斯「偷竊」了這個創意，使其成為蘋果電腦的代表作，而後來，微軟顯然同樣剽竊了這個創意。為什麼蘋果和微軟會成功，施樂會失敗。真正的原因不在誰剽竊了誰的創意，而是誰更願意把想法付諸於實踐，只有付諸於實踐的創意才具有價值。
如果你把乙個好的創意給乙個普通的團隊，他們會把它搞砸，如果你把乙個普通的創意給乙個號的團隊，他們會加以改善。
所以說，不要太在意你的創意有沒有被剽竊，而是關注於執行，如果你的想法自己無法去執行，那麼就會失去其價值。所以我要告誡自己，如果我有乙個好的想法，我必須要和我的團隊一起，把他實現，否則毫無價值。
電梯測試，就是所謂的在電梯的公升降過程中，你如何向同處於乙個電梯之內的客戶推銷你的產品，你能在短時間內獲得成功，還是一無所獲。
很多時候，我問同伴，你在幹嘛，回答最多的是，在寫**啊。和程式設計師溝通就是會很累，他不會告訴你他在實現乙個讓伺服器時間和客戶端時間同步的功能，除非你打破砂鍋問到底。
這個原則無非就是告訴我們程式設計師，我們不僅僅是在敲**，我們要明確我們在創造乙個什麼樣的價值體系。很多時候，爸媽問我，「
程式設計都做些什麼啊？」我回答：「
反正說了你也不懂。」現在我意識到，我的回答也許就會改一改：「程式設計做的有：我們可以讓手機接通**，能通過我們編寫的**讓你聽到我在說話，同時讓你聽到我在說話」。
**載入和顯示的速度越慢，使用它的人就越少。
作者提到乙個觀點是「善待匿名使用者和註冊使用者」，我覺得這個觀點足夠的好，無論是匿名使用者還是留有其名的使用者，我們必須要能夠為他們都創造很好的體驗效果。我的客戶總是有乙個我無法忍受的觀點，總是讓我把舊的**、效能差的交易平台**給一些他認為爛的交易所用，我這個時候，總是會有一股無名業火，我覺得這種做法，太過狹隘。
效能好，才能抓住客戶的心理，進而帶動更大的潛在使用者，而不是用劣質的**敷衍那些我們看不起的客戶。
高效程式設計之 cProfile 效能分析
寫 經常會聽說一些名詞，比如 效能分析 調優。cprofile 是 python 調優的一種工具，它能夠統計在整個 執行過程中，每個函式呼叫的次數和消耗的時間。這個工具雖然很常用，但是沒必要花太多時間研究這個工具，簡單使用就能達到效果，所以我這裡只簡單記錄下核心用法。兩種使用方式 cprofile....
《C 高階程式設計》之 編寫高效的C 程式
第五部分 編寫高效的c 程式 本文基址 http blog.csdn.net cugxueyu archive 2007 12 07 1923564.aspx 一 效能和效率概述 編寫高效的程式，需要在設計層次上做考慮，並在實現層次上考慮細節。一定要在程式的生命週期已開始就考慮效能 編寫高效的c 程...
Oracle高效SQL語句原則
oracle高效sql語句原則 良好的sql語句風格易於發現問題 易於閱讀，移植性好。80 的效能問題是由不良sql語句引發的。1.盡可能對查詢條件的列建立索引 2.盡量不要在where條件中對查詢列使用函式，除非建立了相應的函式索引，如可用帶前導字元的like代替substr 3.任何在where...