一個碼農的項目小結(血淚史)

很長一段時間沒對本身作個總結了，說實話，在過往的一年中，感受比本身2年學的東西都多。也許，這也算是痛並快樂着吧！

 

1.嚴謹應該是一種能力，或是習慣，而不僅是認識！

剛開年時，寫了一個微信邀請卡項目，項目不大，也就開發了一天左右，2 天就上線了（要配合其它項目），可是不知道是否是由於剛開年的緣由，這個項目上線後的一天了，報警日誌一直在爆發，開始的時候覺得是 微信 accessToken 的問題，可是最後發現，不是token 的問題，是我代碼邏輯的問題，原本應該return 掉的代碼，我竟然給它作了複製操做，致使重複獲取了token，實在不該該呀！出這個問題也就算了，畢竟影響不是太大，可是我有個用戶類型，竟然忘記作了處理，致使上線了，那麼你必定想問了，爲啥你測試環境ok呢，由於我測試的微信號那個用戶類型走的是另外一個代碼分支，暈，本身夠粗心的！因此呢，在此項目以後，沒當我在項目添加了新的 邏輯分支，都要自覺去review 這些分支，保證代碼準確，功能完整！嚴謹應該是一種能力，或是習慣，而不僅是認識！

 

2.作好代碼的標記 【todo，check，review，fixme】

在我使用的idea 或者 phpstrom 中，都有個todo功能tab，說實話，這東西很棒，可讓咱們不漏下功能！我通常是這樣子作的，打開設置，搜索todo，像這樣子

 

這樣子，我就設置好了，咱們開看看效果

 

 怎麼樣，這樣子是否是對本身的工做安排更加清晰了！

 

3.java nullpointerexception 異常不要慌，找到該對象，解決問題

我以前遇到 error 級別的錯誤時，多少會比較慌亂，不知道如何處理，好比這個問題，咱們只要找到該對象產生的地方，作處理就行了！

 

4.新項目上線，注意和運維（dba）同窗進行溝通，保證帳號信息正確

這樣子的狀況，只出如今新項目首次上線的狀況，以前我也這樣子坑過咱們的運維，後面咱們溝通後，上線前對一下數據庫的配置，發現不再會由於配置問題，而影響上線了

 

5.設置微信相關配置的時候，須要注意http 和 https 協議

上週呢，測試小姐姐說她的qc 環境沒法進行微信支付，我說不可能啊，我打開了微站，發現一切ok呀！我當時就用charles 去抓包了，查了好久，估摸有一個小時吧，忽然看到，她的支付頁咋是 http://... 的呢？我一會兒就明白了，我在微信支付配置的是 https:// 。後來問她要連接，好傢伙，她的連接是這樣子的  ce.aba.com/index.html 。。。我一會兒就明白了，這樣子的連接點進去的話，使用的協議就是 http:// 難怪報錯了。因此呢，和微信相關的配置，這倆個協議必定要區分好！否則就很尷尬了！

 

6.要注重項目配置文件的管理 

不得不說，配置文件在有些項目中就是一個痛點，一不留神，可能就坑了隊友。我想說的是，配置文件必定要規範，開發環境，測試環境，線上環境要區分好，一者便於管理，一者便於閱讀。

共用的配置文件須要進行抽離，不要出現太多的冗餘！

還有就是，一些只是存儲 文本 的配置文件，儘可能用jsonStr 進行保存，這樣子結構清晰明瞭，方便修改！

一個好的配置文件內容，能夠像這樣子：

 

 7.注意 項目包的命名、類的命名

 一段代碼寫的好很差，其實命名也是個反映！好的命名，能夠看其名，而知其意。在我遇到的開發中，通常會對 Vo 添加 後綴，如UserVo；對接口類 則是 以 I開頭，如 IUserService; 用 Impl 表示接口實現類，如 UserServiceImpl; 而dao呢則都帶上 Dao... 等等，諸如此類吧，這樣子命名必定程度上算比較規範了，像阿里這些企業，還有一些嚴格的開發規範呢！

 

8.儘量的寫單元測試，無單元測試，不編程

不知道不少人是如何看待單元測試的，但我認爲，無單元測試，不編程。

我如今也是以這樣子的標準在要求着本身，真的很好用。不少問題，在開發階段就可以發現，這簡直就是一種福利嘛！

java 在這一塊作的很好，基本引入個jar包就差很少了，php 就麻煩些了，如phpunit，對一些框架的集成不太友好。以前試過把 yii2 和 phpunit進行集成，發現好多問題，太過於雞肋了！

對應單元測試，仍是但願都寫一下吧，並不會浪費多少時間，與其出了bug去尋尋覓覓，到不如把bug扼殺與搖籃中！

 

9.若是須要進行圖片合成，建議把底圖換成.jpg 格式

我的一直有作圖片的合成功能，這期間發現了一個規律，一樣尺寸的圖片，jpg 比 png 節約空間。千萬很差小看這些節省的空間，蚊子再小也是肉。並且用jpg 的目的不是爲了節約空間，而是爲了提高用戶體驗！咱們以前的圖片，在合成後，通常會上傳到微信服務器，或者說存儲到阿里雲，若是圖片小一些的話，速度必然就有很大提高了！

 

10.若是須要進行圖片合成，建議使用 平方字體

這個沒啥好說的吧，一來咱們的設計同窗不少都是用 平方來進行設計的，二來呢就是平方看起來更友好寫，此外，最好是對字體進行鋸齒消除！（可參考下 http://www.cnblogs.com/zeopean/p/7906470.html ）

 

11.mysql 存儲emoji時，儘可能使用 utf8mb4 編碼

有時候會遇到微信暱稱保存不了的狀況，發現是mysql 編碼的問題，這樣子作能夠處理下；若是不行，最好是把 emoji 過濾掉

 

12.必須對緩存鍵值進行規範及管理

這個點，很容易被忽略，說說本身在項目中的使用吧！我在定義緩存key的時候，會保證這個緩存key的惟一性，若是緩存key過長，我還會對其進行md5編碼。至於惟一性，最好是和數據查詢條件關聯起來，這樣子基本不會有太多問題了！

 

13.不一樣數據庫的sql 文件必須區分開

以前由於這個問題，坑了咱們的運維同窗倆次，實在很很差意思！然後呢，我便與他約定，若是我給到的部署內容，sql 沒有寫明數據庫的，直接打回。（人啊，有時候就是得狠點！）

 

14.對技術實現的預演不到位

一些需求呢，給出來多是有些想固然的，因此呢，就須要咱們作好技術預演，這一環節若是作的很差，可能讓項目有所延期（這樣子就不太nice啦！）

 

15.作好系統的報警

一個好的系統，不單要代碼寫的好，並且報警機制也很重要。拿咱們如今的系統爲例，當出現 500 錯誤時，郵件，短信都會有提醒，這樣子及時的報警，雖然有點吵，可是卻也保證着系統的穩定。

 

 

 

好了，先寫到這裏，有機會再總結一篇！！！