Java程序員

1、技術積累

（1）代碼規範

1.1.一、一般的模塊分佈：通常若是你要實現一個web應用，你從後臺將數據展現到前端頁面，在一個比較大的公司，你少不了跟其餘項目有交集（你調用他的接口，他依賴你的接口），這樣下來，整個公司有不少個模塊，怎麼作到很好的聯繫。回到剛剛的模塊分佈，你的一個web應用，應當須要分紅三個模塊：core模塊、service模塊、web模塊。web模塊就是展現到頁面，後臺代碼而言主要就controller層了，其餘邏輯基本都放在core了，service模塊就是一些接口類和參數dto等等，接口的實現類在core模塊。這樣下來，web模塊只須要依賴service模塊，一樣的其餘系統依賴你的接口也僅僅是依賴service模塊，而後利用遠程調用方式消費你的接口服務。

1.1.二、代碼層級結構：針對後臺服務項目，通常分爲對外接口層、service層、Dao層。Dao層就是與數據庫交接的接口層，service層主要調用Dao或者外部系統的接口，複雜的邏輯基本都放在service層；一些方法須要提供給其餘模塊調用的時候，就封裝在對外接口層，只有對外接口層是暴露。這裏說的只是層級結構，還有與層級結構無關的，也是須要歸類的，好比對外部系統接口方法封裝的咱們放在一個目錄下面，一些常量和工具類等咱們放在common目錄下面。固然還有其餘考慮，儘可能讓整個模塊有層次感，代碼纔不會太亂，更好的維護。

1.1.三、總結上面兩點：可能很多猿友以爲上面囉嗦又不像代碼規範，其實這兩點也是代碼規範的一部分，主要引導你們往結構清晰好維護的思惟方向走，多思考吧。

1.1.四、對於一些須要異步處理的，不要直接new一個thread，應當使用線程池。使用線程池的時候應當對線程數量大小合理設置，通常最大不超過50個，固然還須要考慮你的IO和CPU，怎麼分析網上搜搜吧。

1.1.五、容器類變量，若是變化比較大且頻繁，儘可能定義的時候設置初始容量大小，減小擴容帶來的消耗。

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

1.1.七、對象比較的時候常量放前面，養成好習慣，減小空指針的出現。

1.1.八、減小synchronized中等待處理的代碼，能放在外面就儘可能放在外面。

1.1.九、下面到數據庫了，我以爲仍是在這裏說了好點，通常查詢比較慢，頗有多是沒有建索引或者索引沒用到，多去檢查一下。

1.1.十、兩個大表的關聯查詢，可使用二次訪問數據庫替代，先查出A表的數據，利用關聯字段再查B表的。不要一味想着一條sql搞定最好。

1.1.十一、堅定避免，查全表數據或者數量大的數據，返回list加載到內存中，一不當心查了100w數據，又查得比較頻繁，內存的爆了。有這種風險的改爲分頁查詢。

1.1.十二、不要select *，按需取列。

1.1.1三、多考慮避免事務裏面有長鏈接或者長事務，若是大量這種狀況出現佔用數據鏈接，會影響性能。一些無必要的邏輯能夠放到事務外執行。

1.1.1四、對字段的加減乘除處理放到sql，嚴格避免先get處理，而後運算在set到數據庫裏面，併發狀況很是容易致使失真。

1.1.1五、方法裏面代碼不要太長，注意封裝，命名語義化，代碼整潔。常掛嘴邊的，沒放心上，一如既往的給本身埋坑，舉個博主的例子，那會剛畢業也是沒放心上，最近把咱們組長不寫代碼，一到代碼評審我就懼怕，檢視到有問題的代碼，畢業生吧就說這代碼之前就是這樣寫的，問題最終確定都落我身上，如今感受代碼是本身的孩子，只能有空本身偷偷的優化一下，怕出問題還得很是仔細。

（2）SQL規範與性能優化

1.2.一、先提早聲明，博主工做用到是MySQL，可能有些場景只針對MySQL。說到SQL優化，一些概念必需要理解，否則死記硬背一兩天就忘記了。特別是執行計劃的概念。

1.2.二、什麼是執行計劃：a.決定如何訪問表數據，是否經過索引，是否排序等。b.多表關聯是先訪問哪一個表。c.多表關聯時，使用哪一種鏈接方式，不過如今MySQL只有嵌套鏈接（嵌套循環，顧名思義就是將一個表爲出發點，將該表所有記錄逐條去遍歷另一張表的記錄）。

1.2.三、SQL執行順序：a.檢查語法是否正確。b.檢查表是否存在、權限是否知足等。c.根據統計信息(如data length,rows,index length、索引惟一度)，生成較優的執行計劃。d.根據執行計劃，進行數據檢索、過濾、合併、排序等操做。訪問數據時，內存中如存在表數據，則直接進行操做；不然，從磁帶讀取表數據，放入內存，再進行操做；如內存不足，則內存中較冷數據涮出內存，再從內存中讀取數據。

1.2.四、索引：查詢的時候若是使用上了索引，能夠提升效率，由於創建了索引後，能夠理解爲數據字典的結構存儲，所以根據條件查詢的時候更加高效。下面看一下MySQL經常使用的索引類型的概念。

a．普通索引：在建立普通索引時，不附加任何限制條件。這類索引能夠建立在任何數據類型中，其值是否惟一和非空由字段自己的完整性約束條件決定。創建索引之後，查詢時能夠經過索引進行查詢。例如，在student表的stu_id字段上創建一個普通索引。查詢記錄時，就能夠根據該索引進行查詢。

b．惟一性索引:使用UNIQUE參數能夠設置索引爲惟一性索引。在建立惟一性索引時，限制該索引的值必須是惟一的。例如，在student表的stu_name字段中建立惟一性索引，那麼stu_name字段的值就必需是惟一的。經過惟一性索引，能夠更快速地肯定某條記錄。主鍵就是一種特殊惟一性索引。

c．單列索引:在表中的單個字段上建立索引。單列索引只根據該字段進行索引。單列索引能夠是普通索引，也能夠是惟一性索引，還能夠是全文索引。只要保證該索引只對應一個字段 便可。

d．多列索引：多列索引是在表的多個字段上建立一個索引。該索引指向建立時對應的多個字段，能夠經過這幾個字段進行查詢。可是，只有查詢條件中使用了這些字段中第一個字段時，索引纔會被使用。例如，在表中的id、name和sex字段上創建一個多列索引，那麼，只有查詢條件使用了id字段時該索引纔會被使用。

e . 全文索引：使用FULLTEXT參數能夠設置索引爲全文索引。全文索引只能建立在CHAR、VARCHAR或TEXT類型的字段上。查詢數據量較大的字符串類型的字段時，使用全文索引能夠提升查詢速度。例如，student表的information字段是TEXT類型，該字段包含了不少的文字信息。在information字段上創建全文索引後，能夠提升查詢information字段的速度。MySQL數據庫從3.23.23版開始支持全文索引，但只有MyISAM存儲引擎支持全文檢索。在默認狀況下，全文索引的搜索執行方式不區分大小寫。但索引的列使用二進制排序後，能夠執行區分大小寫的全文索引。

還有空間索引，平時也比較少用。目前只有MyISAM存儲引擎支持空間檢索。目前博主也只接觸過InnoDB存儲引擎。

1.2.五、通常一張表索引不要超過5個，並且避免重複索引，並且也不是建了索引，根據索引字段條件查詢，索引就會起做用。

1.2.六、通常哪些場景會致使索引失效：a.使用like關鍵字匹配字符串第一個爲」%」的場景。b.條件中包含or、in、not in、<>關鍵字，默認不走索引的。c.訪問表上的數據行超出表總記錄數30%，變成全表掃描。d.查詢條件使用函數在索引列上，或者對索引列進行運算。e.多列索引中，第一個索引列使用範圍查詢，只能用到部份或沒法使用索引。f.多列索引中，第一個查詢條件不是最左索引列，上面多列索引概念中也有提到。確定還有更多的場景，可是博主如今能想到的場景就這些了。

1.2.七、不能同時使用兩個索引，一個過濾數據，一個用於排序（主鍵除外）。

1.2.八、DML語句若是使用索引，會致使lock全表；若是使用了非惟一索引，可能只是鎖住必定範圍。對此，建議更新/刪除數據儘可能用上索引，若是能夠最好用上主鍵或惟一索引，另外事務要及時提交。

1.2.九、最後一點，如何看執行計劃，分析SQL的性能。這個吧，三言兩語說不清楚，直接看其餘博主的博文吧

（3）關於事務的一些建議

若是沒有聽過事務這麼個概念，網上了解學習一下，先理解一下各個事務類型的含義吧：a.日誌記錄儘可能放在獨立事務裏面，避免後面的異常發生致使日誌丟失。b.上面已經幾回提到，儘早提交事務，避免事務過長，所以寫代碼的時候，一些能夠不放到事務的邏輯能夠移到外面，長事務看可否拆成兩個事務。

（4）關於數據庫鏈接池。

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

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的五分之一或十分之一。

（5）對於前端的幾點建議。

1.7.一、一些圖片壓縮後再使用，性能方面提升不小吧（可使用熊貓圖片壓縮）。雖然本身前端比較菜，可是估計也有很多猿友跟我同樣偶爾須要兼顧前端吧。畢竟剛畢業不久。

1.7.二、關於移動端頁面重構兼容不一樣屏幕大小的問題，建議doc的fontSize，實時獲取屏幕的寬度，而後除以320再乘以16，固然16能夠根據本身狀況去調。而後其餘一些單位儘可能用rem，這樣不管什麼大小的屏幕都等比例縮放。感受比@media效果好不少。

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

2、工做心得
（1）溝通協做第一：

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

（2）謹慎記錄與排漏：

感受如今挺常常是開一兩個會，測試同時偶爾找你排查一下環境問題，一天下來其實寫代

碼的時間並很少。一些關鍵點，很是建議提早記錄下來，方便接回被打斷的思路，同時避免一些邏輯或功能點的遺漏。

（3）思路清晰與效率：

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

（4）主動與多管閒事：

清楚本身的工做範圍，本身內心有個界限，有些屬於別人工做範圍的事情，能夠你提出的建議是好的，可是最好仍是在合適的場景和時機提出。

（5）心態與工做狀態：

程序員，總會有被坑的時候，或者不順心的時候，儘可能嘗試控制一下本身的心態。

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

這點是我本身但願作到的。對於責任心而言，或者是說一個優秀的程序員。不少時候並非完成產品提的需求就行了。多爲它着想，代碼可維護性和擴展性高不高。一些功能點也能夠提出本身的想法，不要老是被動的接受產品的需求，業務功能拓展性好的話，能夠減小產品改動需求。

3、學習方向與職業發展
（1）先廣後深仍是先深後廣：

對於博主而言，其實接觸的技術點還算比較多的，可是瞭解的都不深刻，我的性格而言，比較偏向於實用驅動，若是在實際使用場景有用到再去深刻學習，這樣邊學邊用才能比較集中注意力。像一些同事，他們喜歡把同樣東西研究得很深。

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

技術人員必然是技術優先，可是等你到了必定工做年限，其實業務經驗也是很是重要了。以前領導找我年度工做談話就有說過他們招高級工程師的時候對業務經驗也很是看重，是否有本身獨特的看法。相信道理你們都懂，可是平時有沒有這樣的意識，有沒有去作又是另一方面了。平時也能夠多學習業務方面的知識。

（3）相同的工做年限爲何當過項目經理的人更吃香：

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

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

要想集中注意力學習技術，須要安靜的環境，須要耐得住寂寞，所以你須要沒有人打擾的環境，好比在一個集體居住環境，幾個朋友一塊兒住，通常多數回想着去哪玩，朋友在玩遊戲，估計也是對你的一種誘惑吧。能夠早點到辦公室學習或下班學習一段時間再回去。或者選擇本身一我的住。

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

學習最能集中注意力的狀況是有着比較強的好奇心和求知慾。因此通常一些技術分享或者老員工討論的問題，可能不少概念知識你都不懂，這時候你就能夠去學習瞭解這些知識。或者你工做中遇到的問題，儘可能刨根問底的去弄清楚是什麼緣由致使的，不要一些老司機幫忙解決了就一了了之。或者是其餘同事遇到的問題，你均可以去了解一下。

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

剛畢業不久的猿友，通常都是會比較心浮氣躁的，對技術求知慾很強，特別是一些高大上的技術，什麼大數據、雲計算、架構等等，有些偏向於技術研究，有些偏向於業務。大部分程序員可能都會選擇偏向於技術研究的，因而乎對偏向業務的不怎麼感冒，所以以爲每天作這些東西沒什麼意思。這時候，靜下來分析一下，你到底適合哪一種方向。你可否靜下心來對技術研究很深刻，可否耐得住寂寞。

4、關於生活
（1）良好與糟糕的生活狀態的區別：

須要警戒一下本身是否進入了一種糟糕的生活狀態，工做上不溫不火，彷佛如今的技術已經足夠用了，徹底沒有目標沒有計劃，沒法集中注意力學習，日子就這樣一每天過去。