一年到頭了，作為本命年的我，今年發生了太多的事情，但是不幸的是，都是好事兒，有點太過得意洋洋了，不過，不管一年順抑或不順，都是需要總結的，畢竟，總結，才能讓人成長，首先，想注意的事情就是開發注意事項。

    特別想說一件事情，公司每個功能上線之前都要測試，在測試環境測試，並且也會在正式環境測試（非公開版），把上線的問題降到最低，發生過這麼幾件事情，有好幾次，我開發的時候沒有看到問題，測試測試的時候也沒有問題，但是在正式環境測試的時候，我們的頭兒一眼就看到問題，很神奇的一件事情，感覺他好像就長了一雙挑bug的眼，的確，我們的頭兒是一個有十幾年工作經驗的人，不得不佩服他的眼力勁兒，但是，的確眼力勁兒是常年積累下來的，也許也是一次次的出的問題才會意識到這個地方需要格外注意，但是，既然是特別需要注意的地方，那麼在他們心裡，肯定有一個總結，就是每次上線前要注意什麼，只是歲月積累變成了一種潛意識，那麼，如果是對於我們這群“涉世未深”的菜鳥，該怎麼注意呢？只能是學習經驗並總結，把它們歲月沉澱的潛意識，總結出來，強制變成自己的意識。

    好了，廢話少說，書歸正傳：

    第一：查詢的時候注意上下界，這是個經常犯的錯誤，但是屢犯不爽，經常出現這種在哪裡跌倒就還在那裡繼續跌倒的情況，這是第一條，已經拒絕在犯。

    第二：欄位為空情況，很多時候我們以為這個欄位不可能為空，或者正常資料不會為空，但是要知道，所以的bug都是處在非正常的資料中，把系統搞出問題的資料也肯定不是正常資料。

    第三：插入資料庫欄位為空情況，一般情況下資料庫欄位是不能為空的，既然資料庫這樣設計，那麼插入是欄位就不能為空，因為這個問題，已經讓我在線上出國問題，感覺很慘是不是，所以，每個物件都要記得設定預設欄位。否則，這很有可能因為你這裡的改動，影響到其他功能。

    第四：字型樣式問題，很多時候，開發的人比較注意功能的完整性反而很容易忽視的就是樣式問題，所以反而更容易在這個上面栽跟頭，雖然一般情況下會有前端來把關，但是我們也會經常遇到一些需求對前端要求比較低，不需要前端介入，所以這個時候，就需要注意一些樣式問題了，尤其是字型樣式更容易被忽略。

    第五：多打日誌，這個習慣好像到目前還沒有很好的適應，但是這也是我下一階段要十分注意的地方，無論是對異常日誌的處理，還是console的日誌輸出，每次開發都急於完成，日誌就程式設計一個可有可無的東西，而每次都是出了問題才想起來日誌的重要性，但是這個時候在寫日誌就已經晚了，因為無法把出的問題記錄下來。這是一個加星的注意事項。

    第六：寫程式碼的風格，平時寫程式碼沒有加空格的習慣，每次頭兒給review程式碼的時候都會因為這個問題提醒我一下，或者他在看我程式碼的時候就會順手把看的部分加上空格，當然，我們不會因為少加空格就出bug，但是會因為不好的程式碼而影響發現bug。

    這是一般情況下，不論什麼專案都要注意的問題，當然還有一種問題，發生在特定的場合，這種問題，跟程式設計習慣、思維習慣就有很大的關係了，當然，還跟程式設計素質有很大的關係。

    首先，說一件事情，寫程式碼複製貼上是一種很常見的事情，但是我們究竟應該怎麼複製貼上呢？以前，總是以功能能夠執行為主，其實，除了能夠執行，還要注意程式碼中有沒有多餘的程式碼，這些程式碼能不能夠影響效能。我是一個比較懶的人，但是也因為這樣的懶，犯了不少錯誤，舉個例子，又一次我只需要查詢一個金額，但是查詢的語句跟之前查詢一個物件的完全一樣，只是這次我只取裡面 的金額，於是我想都沒想，直接拷過來程式碼用，然後判斷一下查處的物件是不是為空，之後直接從物件裡去金額，這個問題測試的時候是沒有問題的，但是上線之後出問題了，問題的原因是金額為null，因為我只判斷了物件不能為null，忘記判斷物件裡的金額，之後頭兒看了下我的程式碼，說了句“從你程式碼裡看出你思路不太清楚啊”，當時聽了很難受，首先是因為上線之後出的問題，一般這樣的問題會對公司有影響，還有一個原因：這個問題是我犯懶了，如果我當時改動一下之前的程式碼，只獲取金額，以後的問題就沒有這麼多了，當我把程式碼拷過來改動時，就意味著，我很有可能因為少改一些地方而報錯，或者是因為依照程式碼的思路走下去，去修補之前的程式碼符合現在的需求，而不是從現在的需求出發，去構造一種真正的符合現狀的程式碼。所以，貼上複製沒有問題，但是絕對不能通過修修補補來應付現在的需求。

    其次，眼界，眼界這個東西很難說清楚，但是總是隱隱感覺這是一個可以培養的東西，在做這個功能的時候，你的目光能看到多遠，舉個例子，產品有這樣一個需求，一個數據，要麼是一天，要麼是若干個月，這就要求一個欄位裡面要麼存一天，要麼存幾個月，當時我只是反覆跟產品確認：天數只會出現一天情況，其他的都是以月為單位的嗎？十分確定之後，欄位設定的是0代表一天，其他的比如1代表一個月，2代表兩個月，後來跟頭兒說這件事兒，他的解決方案是這樣的：1~100表示天，100以上，比如101，表示1個月，102表示兩個月，這樣即使以後出現15天的情況，也很好擴充套件。的確，我在做的時候雖然感覺這樣的需求有點怪異（最後這個需求統一改成以天為單位，後話不說），但是我做的只是反覆確認需求不會變動，但是，萬一呢，雖然我們的需求一直跟著產品經理的要求做，但是沒有人保證這個事是一定的，所以，我們何不往前做一步呢，這步並不難，難的是想不到。很多時候我都太著急，太過急於求成，忘記了，最省事兒的方法，是省將來的事兒，而不是立刻完成當下的事兒，做事兒之前先動的是腦，而不是手。

   還有，完成功能的前提下，多關注一下程式碼的效率，包括執行的效率和別人閱讀的效率，邊上有一個大牛，總愛聽他說到“這個功能的設計的特別優雅”，不知道該怎麼定義優雅，至少我從沒有覺得我寫的程式碼優雅，甚至連看都不想看，包括有時候事兒少的時候也會說看看自己的程式碼，哪裡需要優化，但是，哎，漸漸的做多了，發現，不是因為不想重構，不想改進，而是自己跟寫程式碼時的自己是出於一個level的，解決這個的辦法不是看自己的程式碼，而是看別人的程式碼，當然看別人的程式碼不容易，找一個自己比較熟的功能，並且是一個比較厲害的人寫的程式碼去看（功能熟容易看懂），你會發現你們寫的差距，然後只有這個時候，才能激發你去優化你的程式碼的潛力，你也才會自慚形穢的去偷偷修改程式碼（因為是在不好意思讓別人發現這塊程式碼是你寫的%>_<%，只能偷偷修改）。

   最後還想說，讓自己進步最快的辦法是虛心，程式設計師有一個通病，就是高傲，不願意承認自己有問題，當然這不是隻有程式設計師才有的問題，各行各業的都有，只是因為程式設計師的工作性質，別人總要提出各種各樣的bug，所以不得不高傲，但是我認為進步，還是需要虛心，虛心接受別人的意見，時刻反省一下自己，才會去從不同角度考慮問題，比你厲害的人不必說，有太多的發光點需要你去學習，但是其他人，包括產品包括測試，他們的意見與想法，都是需要思考的，只有把不同意見聽進去的人，才會去思考去判斷，才會成長。

   這篇總結從年前寫到年後，就先到這兒吧，再繼續下去就變成裹腳布了，未完待續、、、、、。。。。