2016年總結 - Java程式員

標籤：comm   大量   通道   資料庫連接池   訪問   mil   min   是什麼   關鍵點   

一 . 技術積累

(1)代碼規範

1.1.1、通常的模組分布：一般如果你要實現一個web應用，你從後台將資料展示到前端頁面，在一個比較大的公司，你少不了跟其他項目有交集（你調用他的介面，他依賴你的介面），這樣下來，整個公司有很多個模組，怎麼做到很好的聯絡。回到剛剛的模組分布，你的一個web應用，應當需要分成三個模組：core模組、service模組、web模組。web模組就是展示到頁面，後台代碼而言主要就controller層了，其他邏輯基本都放在core了，service模組就是一些介面類和參數dto等等，介面的實作類別在core模組。這樣下來，web模組只需要依賴service模組，同樣的其他系統依賴你的介面也僅僅是依賴service模組，然後利用遠程調用方式消費你的介面服務。

1.1.2、代碼層級結構：針對後台服務項目，一般分為對外介面層、service層、Dao層。Dao層就是與資料庫交接的介面層，service層主要調用Dao或者外部系統的介面，複雜的邏輯基本都放在service層；一些方法需要提供給其他模組調用的時候，就封裝在對外介面層，只有對外介面層是暴露。這裡說的只是層級結構，還有與層級結構無關的，也是需要歸類的，比如對外部系統介面方法封裝的我們放在一個目錄下面，一些常量和工具類等我們放在common目錄下面。當然還有其他考慮，盡量讓整個模組有層次感，代碼才不會太亂，更好的維護。

1.1.3、總結上面兩點：可能不少猿友覺得上面囉嗦又不像代碼規範，其實這兩點也是代碼規範的一部分，主要引導大家往結構清晰好維護的思維方向走，多思考吧。

1.1.4、對於一些需要非同步處理的，不要直接new一個thread，應當使用線程池。使用線程池的時候應當對線程數量大小合理設定，一般最大不超過50個，當然還需要考慮你的IO和CPU，怎麼分析網上搜搜吧。

1.1.5、容器類變數，如果變化比較大且頻繁，盡量定義的時候設定初始容量大小，減少擴容帶來的消耗。

1.1.6、分支判斷if…else的時候，最常符合的條件處理放在前面。

1.1.7、對象比較的時候常量放前面，養成好習慣，減少null 指標的出現。

1.1.8、減少synchronized中等待處理的代碼，能放在外面就盡量放在外面。

 

1.1.9、下面到資料庫了，我覺得還是在這裡說了好點，一般查詢比較慢，很有可能是沒有建索引或者索引沒用到，多去檢查一下。

1.1.10、兩個大表的關聯查詢，可以使用二次訪問資料庫替代，先查出A表的資料，利用關聯欄位再查B表的。不要一味想著一條sql搞定最好。

1.1.11、堅決避免，查全表資料或者數量大的資料，返回list載入到記憶體中，一不小心查了100w資料，又查得比較頻繁，記憶體的爆了。有這種風險的改成分頁查詢。

1.1.12、不要select *，按需取列。

1.1.13、多考慮避免事務裡面有長這串連或者長事務，如果大量種情況出現佔用資料連線，會影響效能。一些無必要的邏輯可以放到事務外執行。

1.1.14、對欄位的加減乘除處理放到sql，嚴格避免先get處理，然後運算在set到資料庫裡面，並發情況非常容易導致失真。

1.1.15、方法裡面代碼不要太長，注意封裝，命名語義化，代碼整潔。常掛嘴邊的，沒放心上，一如既往的給自己埋坑，舉個博主的例子，最近把我們組長不寫代碼，一到程式碼檢閱我就害怕，檢視到有問題的代碼，畢業生吧就說這代碼以前就是這樣寫的，問題最終肯定都落我身上，現在感覺代碼是自己的孩子，只能有空自己偷偷的最佳化一下，怕出問題還得非常仔細。

 

(2) 關於資料庫連接池。

可能一些猿友都少去注意吧。先來看看一些參數，這裡只羅列了博主比較關注的，更多的可以自行查看一下配置。

initialSize ： 預設值是 0, 串連池建立串連的初始串連數目。
minIdle : 預設是 0, 串連數中最小空閑串連數。
maxIdle : 預設是 8 ，串連池中最大空閑串連數。
maxActive : 預設值是 8, 串連池中同時可以指派的最大活躍串連數。
maxWait : 預設值是無限大，當串連池中串連已經用完了，等待建立一個新串連的最大毫秒數 ( 在拋異常之前 )。

validationQuery : 一條 sql 語句，用來驗證資料庫連接是否正常。這條語句必須是一個查詢模式，並至少返回一條資料。一般用“ select 1 ”。

minEvictableIdleTimeMilis : 預設值是 1000 * 60 * 30(30 分鐘 ) 單位也是毫秒，串連池中串連可閒置時間。

timeBetweenEvictionRunsMilis : 預設值是 -1 ，每隔一段多少毫秒跑一次回收空閑線程的線程。

對於minEvictableIdleTimeMilis、timeBetweenEvictionRunsMilis這兩個參數，timeBetweenEvictionRunsMilis必須大於1且小於minEvictableIdleTimeMilis，建議是minEvictableIdleTimeMilis的五分之一或十分之一。

(3)  

對於前端的幾點建議。

1.7.1、一些圖片壓縮後再使用，效能方面提高不小吧（可以使用熊貓圖片壓縮）。雖然自己前端比較菜，但是估計也有不少猿友跟我一樣偶爾需要兼顧前端吧。

關於技術積累這一塊，之前羅列的提綱還挺多的，寫到後面感覺沒什麼精力了，有些三言兩語似乎說不清楚啊。

 

二、工作心得

（1）溝通協作第一：

工作中必然少不了團隊協作，積極主動去溝通的人做事總是更加靠譜。道理大家都懂。但是我們需要把想法問題，簡潔明確的表達給對方。另外總是以溝通的心態面對問題，而不是抱怨。如果覺得上級分配的任務難度太大了，你可以嘗試跟他溝通，擷取他有很好的建議或解決方案。

（2）謹慎記錄與排漏：

經常是開一兩個會，測試同時偶爾找你排查一下環境問題，一天下來其實寫代
碼的時間並不多。一些關鍵點，非常建議提前記錄下來，方便接回被打斷的思路，同時避免一些邏輯或功能點的遺漏。

（3）思路清晰與效率：

建議動手寫代碼之前，建議先理清思路，關鍵邏輯，需求細節，這樣後面寫代碼的時候效率比較高，而且品質也比較好。

（4）主動與多管閑事：

清楚自己的工作範圍，自己心裡有個界限，有些屬於別人工作範圍的事情，可以你提出的建議是好的，但是最好還是在合適的情境和時機提出。

（5）心態與工作狀態：

程式員，總會有被坑的時候，或者不順心的時候，盡量嘗試控制一下自己的心態。

（6）可持續發展觀看待技術與業務：

這點是我自己希望做到的。對於責任心而言，或者是說一個優秀的程式員。很多時候並不是完成產品提的需求就好了。多為它著想，代碼可維護性和擴充性高不高。一些功能點也可以提出自己的想法，不要總是被動的接受產品的需求，業務功能拓展性好的話，可以減少產品改動需求。

三、學習方向與職業發展

（1）先廣後深還是先深後廣：

個人性格而言，比較偏向於實用驅動，如果在實際使用情境有用到再去深入學習，這樣邊學邊用才能比較集中注意力。像一些同事，他們喜歡把一樣東西研究得很深。

（2）業務經驗也應當注重：

技術人員必然是技術優先，但是等你到了一定工作年限，其實業務經驗也是非常重要了,招進階工程師的時候對業務經驗也非常看重，是否有自己獨特的見解。相通道理大家都懂，但是平時有沒有這樣的意識，有沒有去做又是另外一方面了。平時也可以多學習業務方面的知識。

（3）相同的工作年限為什麼當過專案經理的人更吃香：

因為他們對業務理解更加深入，代碼品質問題落在他頭上，項目的人員協調與時間安排規劃，責任越大，思考的問題就越多，遇到的問題處理經驗就越豐富。把控能力也比較強。

（4）怎樣能進入學習狀態，並且堅持：

要想集中注意力學習技術，需要安靜的環境，需要耐得住寂寞，因此你需要沒有人打擾的環境，比如在一個集體居住環境，幾個朋友一起住，一般多數回想著去哪玩，朋友在玩遊戲，估計也是對你的一種誘惑吧。可以早點到辦公室學習或下班學習一段時間再回去。或者選擇自己一個人住。

（5）如何把握住學習的時機：

學習最能集中注意力的情況是有著比較強的好奇心和求知慾。所以一般一些技術分享或者老員工討論的問題，可能很多概念知識你都不懂，這時候你就可以去學習瞭解這些知識。或者你工作中遇到的問題，盡量刨根問底的去弄清楚是什麼原因導致的，不要一些老司機幫忙解決了就一了了之。或者是其他同事遇到的問題，你都可以去瞭解一下。

（6）你更適合走一條怎樣的職業道路：

剛畢業不久的猿友，一般都是會比較心浮氣躁的，對技術求知慾很強，特別是一些高大上的技術，什麼大資料、雲端運算、架構等等，有些偏向於技術研究，有些偏向於業務。大部分程式員可能都會選擇偏向於技術研究的，於是乎對偏向業務的不怎麼感冒，因此覺得天天做這些東西沒什麼意思。這時候，靜下來分析一下，你到底適合哪種方向。你能否靜下心來對技術研究很深入，能否耐得住寂寞。

 

2016年總結 - Java程式員