一、技術(shù)積累

（1）代碼規(guī)范

1.1.1、通常的模塊分布：一般如果你要實現(xiàn)一個web應用，你從后臺將數(shù)據(jù)展示到前端頁面，在一個比較大的公司，你少不了跟其他項目有交集（你調(diào)用他的接口，他依賴你的接口），這樣下來，整個公司有很多個模塊，怎么做到很好的聯(lián)系�；氐絼倓偟哪K分布，你的一個web應用，應當需要分成三個模塊：core模塊、service模塊、web模塊。web模塊就是展示到頁面，后臺代碼而言主要就controller層了，其他邏輯基本都放在core了，service模塊就是一些接口類和參數(shù)dto等等，接口的實現(xiàn)類在core模塊。這樣下來，web模塊只需要依賴service模塊，同樣的其他系統(tǒng)依賴你的接口也僅僅是依賴service模塊，然后利用遠程調(diào)用方式消費你的接口服務。

1.1.2、代碼層級結(jié)構(gòu)：針對后臺服務項目，一般分為對外接口層、service層、Dao層。Dao層就是與數(shù)據(jù)庫交接的接口層，service層主要調(diào)用Dao或者外部系統(tǒng)的接口，復雜的邏輯基本都放在service層；一些方法需要提供給其他模塊調(diào)用的時候，就封裝在對外接口層，只有對外接口層是暴露。這里說的只是層級結(jié)構(gòu)，還有與層級結(jié)構(gòu)無關(guān)的，也是需要歸類的，比如對外部系統(tǒng)接口方法封裝的我們放在一個目錄下面，一些常量和工具類等我們放在common目錄下面。當然還有其他考慮，盡量讓整個模塊有層次感，代碼才不會太亂，更好的維護。

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

1.1.4、對于一些需要異步處理的，不要直接new一個thread，應當使用線程池。使用線程池的時候應當對線程數(shù)量大小合理設(shè)置，一般最大不超過50個，當然還需要考慮你的IO和CPU，怎么分析網(wǎng)上搜搜吧。

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

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

1.1.7、對象比較的時候常量放前面，養(yǎng)成好習慣，減少空指針的出現(xiàn)。

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

1.1.9、下面到數(shù)據(jù)庫了，我覺得還是在這里說了好點，一般查詢比較慢，很有可能是沒有建索引或者索引沒用到，多去檢查一下。

1.1.10、兩個大表的關(guān)聯(lián)查詢，可以使用二次訪問數(shù)據(jù)庫替代，先查出A表的數(shù)據(jù)，利用關(guān)聯(lián)字段再查B表的。不要一味想著一條sql搞定最好。

1.1.11、堅決避免，查全表數(shù)據(jù)或者數(shù)量大的數(shù)據(jù)，返回list加載到內(nèi)存中，一不小心查了100w數(shù)據(jù)，又查得比較頻繁，內(nèi)存的爆了。有這種風險的改成分頁查詢。

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

1.1.13、多考慮避免事務里面有長連接或者長事務，如果大量這種情況出現(xiàn)占用數(shù)據(jù)連接，會影響性能。一些無必要的邏輯可以放到事務外執(zhí)行。

1.1.14、對字段的加減乘除處理放到sql，嚴格避免先get處理，然后運算在set到數(shù)據(jù)庫里面，并發(fā)情況非常容易導致失真。

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

（2）SQL規(guī)范與性能優(yōu)化

1.2.1、先提前聲明，博主工作用到是MySQL，可能有些場景只針對MySQL。說到SQL優(yōu)化，一些概念必須要理解，不然死記硬背一兩天就忘記了。特別是執(zhí)行計劃的概念。

1.2.2、什么是執(zhí)行計劃：a.決定如何訪問表數(shù)據(jù)，是否通過索引，是否排序等。b.多表關(guān)聯(lián)是先訪問哪個表。c.多表關(guān)聯(lián)時，使用哪種連接方式，不過現(xiàn)在MySQL只有嵌套連接（嵌套循環(huán)，顧名思義就是將一個表為出發(fā)點，將該表全部記錄逐條去遍歷另外一張表的記錄）。

1.2.3、SQL執(zhí)行順序：a.檢查語法是否正確。b.檢查表是否存在、權(quán)限是否滿足等。c.根據(jù)統(tǒng)計信息(如data length,rows,index length、索引唯一度)，生成較優(yōu)的執(zhí)行計劃。d.根據(jù)執(zhí)行計劃，進行數(shù)據(jù)檢索、過濾、合并、排序等操作。訪問數(shù)據(jù)時，內(nèi)存中如存在表數(shù)據(jù)，則直接進行操作；否則，從磁帶讀取表數(shù)據(jù)，放入內(nèi)存，再進行操作；如內(nèi)存不足，則內(nèi)存中較冷數(shù)據(jù)涮出內(nèi)存，再從內(nèi)存中讀取數(shù)據(jù)。

1.2.4、索引：查詢的時候如果使用上了索引，可以提高效率，因為建立了索引后，可以理解為數(shù)據(jù)字典的結(jié)構(gòu)存儲，因此根據(jù)條件查詢的時候更加高效。下面看一下MySQL常用的索引類型的概念。

a．普通索引：在創(chuàng)建普通索引時，不附加任何限制條件。這類索引可以創(chuàng)建在任何數(shù)據(jù)類型中，其值是否唯一和非空由字段本身的完整性約束條件決定。建立索引以后，查詢時可以通過索引進行查詢。例如，在student表的stu_id字段上建立一個普通索引。查詢記錄時，就可以根據(jù)該索引進行查詢。

b．唯一性索引:使用UNIQUE參數(shù)可以設(shè)置索引為唯一性索引。在創(chuàng)建唯一性索引時，限制該索引的值必須是唯一的。例如，在student表的stu_name字段中創(chuàng)建唯一性索引，那么stu_name字段的值就必需是唯一的。通過唯一性索引，可以更快速地確定某條記錄。主鍵就是一種特殊唯一性索引。

c．單列索引:在表中的單個字段上創(chuàng)建索引。單列索引只根據(jù)該字段進行索引。單列索引可以是普通索引，也可以是唯一性索引，還可以是全文索引。只要保證該索引只對應一個字段 即可。

d．多列索引：多列索引是在表的多個字段上創(chuàng)建一個索引。該索引指向創(chuàng)建時對應的多個字段，可以通過這幾個字段進行查詢。但是，只有查詢條件中使用了這些字段中第一個字段時，索引才會被使用。例如，在表中的id、name和sex字段上建立一個多列索引，那么，只有查詢條件使用了id字段時該索引才會被使用。

e . 全文索引：使用FULLTEXT參數(shù)可以設(shè)置索引為全文索引。全文索引只能創(chuàng)建在CHAR、VARCHAR或TEXT類型的字段上。查詢數(shù)據(jù)量較大的字符串類型的字段時，使用全文索引可以提高查詢速度。例如，student表的information字段是TEXT類型，該字段包含了很多的文字信息。在information字段上建立全文索引后，可以提高查詢information字段的速度。MySQL數(shù)據(jù)庫從3.23.23版開始支持全文索引，但只有MyISAM存儲引擎支持全文檢索。在默認情況下，全文索引的搜索執(zhí)行方式不區(qū)分大小寫。但索引的列使用二進制排序后，可以執(zhí)行區(qū)分大小寫的全文索引。

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

1.2.5、一般一張表索引不要超過5個，而且避免重復索引，而且也不是建了索引，根據(jù)索引字段條件查詢，索引就會起作用。

1.2.6、一般哪些場景會導致索引失效：a.使用like關(guān)鍵字匹配字符串第一個為”%”的場景。b.條件中包含or、in、not in、<>關(guān)鍵字，默認不走索引的。c.訪問表上的數(shù)據(jù)行超出表總記錄數(shù)30%，變成全表掃描。d.查詢條件使用函數(shù)在索引列上，或者對索引列進行運算。e.多列索引中，第一個索引列使用范圍查詢，只能用到部份或無法使用索引。f.多列索引中，第一個查詢條件不是最左索引列，上面多列索引概念中也有提到�？隙ㄟ�有更多的場景，但是博主現(xiàn)在能想到的場景就這些了。

1.2.7、不能同時使用兩個索引，一個過濾數(shù)據(jù)，一個用于排序（主鍵除外）。

1.2.8、DML語句如果使用索引，會導致lock全表；如果使用了非唯一索引，可能只是鎖住一定范圍。對此，建議更新/刪除數(shù)據(jù)盡量用上索引，如果可以最好用上主鍵或唯一索引，另外事務要及時提交。

1.2.9、最后一點，如何看執(zhí)行計劃，分析SQL的性能。這個吧，三言兩語說不清楚，直接看其他博主的博文吧

（3）關(guān)于事務的一些建議

如果沒有聽過事務這么個概念，網(wǎng)上了解學習一下，先理解一下各個事務類型的含義吧：a.日志記錄盡量放在獨立事務里面，避免后面的異常發(fā)生導致日志丟失。b.上面已經(jīng)幾次提到，盡早提交事務，避免事務過長，因此寫代碼的時候，一些可以不放到事務的邏輯可以移到外面，長事務看能否拆成兩個事務。

（4）關(guān)于數(shù)據(jù)庫連接池。

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

initialSize ： 默認值是 0, 連接池創(chuàng)建連接的初始連接數(shù)目。

minIdle : 默認是 0, 連接數(shù)中最小空閑連接數(shù)。

maxIdle : 默認是 8 ，連接池中最大空閑連接數(shù)。

maxActive : 默認值是 8, 連接池中同時可以分派的最大活躍連接數(shù)。

maxWait : 默認值是無限大，當連接池中連接已經(jīng)用完了，等待建立一個新連接的最大毫秒數(shù) ( 在拋異常之前 )。

validationQuery : 一條 sql 語句，用來驗證數(shù)據(jù)庫連接是否正常。這條語句必須是一個查詢模式，并至少返回一條數(shù)據(jù)。一般用“ select 1 ”。

minEvictableIdleTimeMilis : 默認值是 1000 * 60 * 30(30 分鐘 ) 單位也是毫秒，連接池中連接可空閑的時間。

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

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

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

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

1.7.2、關(guān)于移動端頁面重構(gòu)兼容不同屏幕大小的問題，建議doc的fontSize，實時獲取屏幕的寬度，然后除以320再乘以16，當然16可以根據(jù)自己情況去調(diào)。然后其他一些單位盡量用rem，這樣無論什么大小的屏幕都等比例縮放。感覺比@media效果好很多。

關(guān)于技術(shù)積累這一塊，之前羅列的提綱還挺多的，寫到后面感覺沒什么精力了，有些三言兩語似乎說不清楚啊。

二、工作心得

（1）溝通協(xié)作第一：

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

（2）謹慎記錄與排漏：

感覺現(xiàn)在挺經(jīng)常是開一兩個會，測試同時偶爾找你排查一下環(huán)境問題，一天下來其實寫代

碼的時間并不多。一些關(guān)鍵點，非常建議提前記錄下來，方便接回被打斷的思路，同時避免一些邏輯或功能點的遺漏。

（3）思路清晰與效率：

建議動手寫代碼之前，建議先理清思路，關(guān)鍵邏輯，需求細節(jié)，這樣后面寫代碼的時候效率比較高，而且質(zhì)量也比較好。

（4）主動與多管閑事：

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

（5）心態(tài)與工作狀態(tài)：

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

（6）可持續(xù)發(fā)展觀看待技術(shù)與業(yè)務：

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

三、學習方向與職業(yè)發(fā)展

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

對于博主而言，其實接觸的技術(shù)點還算比較多的，但是了解的都不深入，個人性格而言，比較偏向于實用驅(qū)動，如果在實際使用場景有用到再去深入學習，這樣邊學邊用才能比較集中注意力。像一些同事，他們喜歡把一樣東西研究得很深。

（2）業(yè)務經(jīng)驗也應當注重：

技術(shù)人員必然是技術(shù)優(yōu)先，但是等你到了一定工作年限，其實業(yè)務經(jīng)驗也是非常重要了。之前領(lǐng)導找我年度工作談話就有說過他們招高級工程師的時候?qū)I(yè)務經(jīng)驗也非常看重，是否有自己獨特的見解。相信道理大家都懂，但是平時有沒有這樣的意識，有沒有去做又是另外一方面了。平時也可以多學習業(yè)務方面的知識。

（3）相同的工作年限為什么當過項目經(jīng)理的人更吃香：

因為他們對業(yè)務理解更加深入，代碼質(zhì)量問題落在他頭上，項目的人員協(xié)調(diào)與時間安排規(guī)劃，責任越大，思考的問題就越多，遇到的問題處理經(jīng)驗就越豐富。把控能力也比較強。

（4）怎樣能進入學習狀態(tài)，并且堅持：

要想集中注意力學習技術(shù)，需要安靜的環(huán)境，需要耐得住寂寞，因此你需要沒有人打擾的環(huán)境，比如在一個集體居住環(huán)境，幾個朋友一起住，一般多數(shù)回想著去哪玩，朋友在玩游戲，估計也是對你的一種誘惑吧�？梢栽琰c到辦公室學習或下班學習一段時間再回去�；蛘哌x擇自己一個人住。

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

學習最能集中注意力的情況是有著比較強的好奇心和求知欲。所以一般一些技術(shù)分享或者老員工討論的問題，可能很多概念知識你都不懂，這時候你就可以去學習了解這些知識�；蛘吣愎ぷ髦杏龅降膯栴}，盡量刨根問底的去弄清楚是什么原因?qū)е碌模灰恍├纤緳C幫忙解決了就一了了之�；蛘呤瞧渌掠龅降膯栴}，你都可以去了解一下。

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

剛畢業(yè)不久的猿友，一般都是會比較心浮氣躁的，對技術(shù)求知欲很強，特別是一些高大上的技術(shù)，什么大數(shù)據(jù)、云計算、架構(gòu)等等，有些偏向于技術(shù)研究，有些偏向于業(yè)務。大部分程序員可能都會選擇偏向于技術(shù)研究的，于是乎對偏向業(yè)務的不怎么感冒，因此覺得天天做這些東西沒什么意思。這時候，靜下來分析一下，你到底適合哪種方向。你能否靜下心來對技術(shù)研究很深入，能否耐得住寂寞。

四、關(guān)于生活

（1）良好與糟糕的生活狀態(tài)的區(qū)別：

需要警惕一下自己是否進入了一種糟糕的生活狀態(tài)，工作上不溫不火，似乎現(xiàn)在的技術(shù)已經(jīng)足夠用了，完全沒有目標沒有計劃，無法集中注意力學習，日子就這樣一天天過去。

（2）設(shè)定17年自己的一些期望吧！

2016年總結(jié)-JAVA程序員 - 小寶鴿 - 博客頻道 - CSDN.NET

作者：小寶鴿

     Ps：IT行業(yè)發(fā)展速度越來越快，每年都會新增很多人才需求。從下面面這個圖中的數(shù)據(jù)可以看出，IT行業(yè)目前已經(jīng)占據(jù)了百分之35的市場，可以說非常的廣泛，需求非常的大，每年的IT人才需求可以達到2000萬人數(shù)，這個數(shù)字，聽到了是不是很驚訝，這么一個巨大的群體，所以，這是一個非常有朝氣的行業(yè)。

    但是機遇和挑戰(zhàn)都是并存的，看完以上長篇的干貨分享，不知道同讀的你有沒有產(chǎn)生什么樣的思考呢？歡迎和思妹來互動：在你長達幾十年的學習生涯中，你所遇的人有什么讓你嘆為觀止的好習慣嗎？

    可以留言和我們分享哦！