如果問乙個程式設計師：**為什麼會變爛？他可能會找出無數種理由：
1、**本來就爛，我只是加了一點東西；
2、時間壓得太緊，根本沒有時間把**優化，功能實現出來就不錯了；
3、系統已經上線了，不敢隨便去改以前的**，不出問題還好，改出問題了誰負責；
……但是，這都是從外部找原因推卸責任，程式設計師應該從自身尋找原因。其實，**變爛，罪魁禍首就是程式設計師自己。
很多時候，**一步步變爛，就是因為程式設計師自己沒有良好的意識，沒有及時地重構，剛開始的**還是挺好的，後來需求一步步變更，就開始不斷地往裡面加分支，慢慢就變爛了。所以建立強烈的重構意識才是最重要的，頭腦裡要建立這樣的意識：一旦**變爛了，就去重構，要寫出高質量同時又優美易讀的**。
重構的技能每個人都可以學得會，但建立首先這樣的意識才是更重要的。
至於寫出好**卻不被上級知道和認可，也有相應的措施：推行**質量視覺化。在公司或部門內部，通過sonar等系統實時地公布各專案組和成員的**總體質量，使所有人都能看到，這樣就能讓領導看到**的改善，也促使更多的人建立寫出好的**的意識。
不要在乙個方法或乙個類中堆砌太多的**，不管是方法還是類，都應該短小。過長的類或方法都是壞味道，它們會導致以下種種不快：
1、 **難以理解，難以維護。比如乙個方法中包含10個邏輯，這時程式設計師要修改其中乙個邏輯，那麼他不得不把這10個邏輯全部理解了才能動手修改，而且一大堆無關**堆砌在一起，導致程式設計師修改**時很容易出錯。而如果分成了10個小方法，那麼程式設計師就可以直接聚焦於要修改的那1個小方法就行了，修改也很容易。
2、 **難以重用，導致重複**。乙個大方法中有一部分**，在另乙個地方有同樣的處理，但是由於這部分**身處這個大方法的泥潭中，所以無法重用，那麼就只能拷貝乙份了，這樣就導致了重複**，而重複**的危害是不言而喻的。
……另外，不管是方法還是類，都應該遵循「單一職責原則」，否則不同的職責雜糅在一起，同樣導致以上的種種不快。所以，這句話很重要：函式的第一原則是短小，第二原則是短小，第三原則還是短小。
**是給機器去執行的，但更是給人看的，要寫出機器能執行的**很容易，但要寫出人易讀懂的**則更重要。建立這樣的意識之後，往往就能寫出非常整潔優美的**。
要怎樣寫出人易讀懂的**呢？
首先，還是上一條所說的，要簡潔短小，職責要單一，邏輯要清晰的區分開。不要把一大堆**堆砌在一起，更不要把不同職責的**堆砌在一起，那樣都必然導致可讀性下降。
然後，不要寫過於長的複雜表示式，那樣非常難以理解。可以把表示式進行分解，可以用解釋變數（只起到解釋的作用，就是為了讓**更加易讀）。
還有，比如乙個方法中包含10個重要的步驟，人要讀懂它很難。那麼可以把這個10個步驟提取到10個小方法中，然後給每個小方法起乙個有意義的名字，讓人顧名思義一目了然，然後在原方法中依次呼叫這10個方法，程式設計師一看便知道這個方法幹了什麼。
提到有意義的名字，需要強調的是，在**中，不管是類、方法還是變數，乙個好的名字都非常重要，起乙個有意義的名字，讓人一看就知道它是幹什麼的，比多少注釋都有效。
有時為了達到**整潔的目的，甚至可以犧牲一點點「效能」。這一點尤其令我印象深刻，故單獨列出來作為第四個方面。
這裡加了引號，是因為這裡所說的「效能「，其實只是程式設計師的臆測。而這種臆測經常經常發生。
比如乙個迴圈當中幹了兩件完全不相關的事情，使得不同職責的**雜糅在一起，影響了易讀性又不利於重用。其實應該分兩次做，即使做了兩次迴圈也沒有關係，除非有實際的測試資料證明，這樣做確實影響了程式的效能。但是其實大部分情況下，這並不會對效能造成影響。
應該時刻記住大師們的教誨：
由此可見，寫出人易讀懂的整潔的**是多麼重要。
以上幾種意識的無論怎麼強調都不為過的重要性,我也將牢固建立這些意識,寫**的時候時刻從這些意識出發,不斷地持續地重構,只寫乾淨整潔的**。
關於學習的幾點感悟
2019 05 18 這週的主要時間都集中在寫乙個視覺化的貪吃蛇搜尋演算法，除了視覺化部分利用了別人已有的 後續的完全都是自己寫的，並且現在通過整理 已經達到了一定程度的抽象。這裡來記錄幾點自己的感悟，並且結合自己以往學習的內容，想想後面的學習過程，可能內容比較冗雜，但中心都是圍繞後續的學習方法上。...
關於購買電腦的幾點感悟
本人購機經驗還算豐富，經歷了奔三到多核這樣乙個過程。從本科一開始就幫人配電腦，經我手的機器不下百台 都稱得上專業 js了，可惜我比較傻，都沒有給自己留利潤 這裡有一點購機感悟與大家分享，主要是產品選購上的。中國人有個毛病 隨大溜。原理很簡單 不可能大家都吃虧吧？真的吃了虧，至少也是大家都吃虧啊，所以...
TDD重構感悟
tdd和重構練功房打卡總共兩周時間，從第一關的fizzbuzz到十三關的英文單詞遊戲，每一關都有其訓練指標和意義，一路打卡下來，體驗和感悟都很深，作為一名程式設計師，這種訓練場景還是非常有必要的，從開發的流程和編碼的思路上都有很好的指導意義，下面是我對tdd和重構的一些理解。tdd是測試驅動開發 t...