一個JAVA開發一年的總結

前言

到今天爲止，正好是工做一年了。
一年裏有過折磨痛苦，有過成就感，一年後很欣慰能看到本身是有所收穫的。
記錄以下，若有不當，還望指點。

技術

1. 看到別人寫出的bug，本身也很大可能會犯一樣的錯誤。

2. 從bug中學習，每個bug都會對本身有警示的做用，或許你的定時任務有問題，那麼徹底能夠想一想，若是上線了出問題怎麼辦，是否有補償機制，若是要補償如何處理。並找到根源，而後思考這個根源會影響到哪些功能。

3. 絕對不要放過一個細微的問題，以前在使用dubbo的時候發現實體類中若是有Date類型的屬性爲空會致使整個類爲null，同事們採起的作法是用別的類型替代，可是仔細鑽研一番，看了源碼以後發現這是dubbo2.5.3使用hessian序列化時候的一個自帶的bug，而且定位到了源碼中的某一行。若是不能發現並很好的避免，若是之後出問題了會很是棘手。能夠這麼說，項目中的問題，沒有小問題，任何一個問題均可能毀了一切。

4. 程序員要作的事情應該比產品提供的需求更多，包括後臺的管理，一些意外狀況的處理，甚至以前說到的定時任務的補償，均可以造成管理模塊進行開發。

5. 問題的最小場景的還原，當面對一個問題的時候，應該可以迅速的縮小問題的範圍，而後定位到問題結症所在，再予以解決，這是一個經驗的問題，仍是須要直覺和積累，而直覺來源於經驗。

6. 開發的過程當中要考慮愈來愈多的事情，性能，穩定，異常，安全，複用性，兼容性等等，作到了這些，代碼將會慢慢變成一件藝術品。

7. 項目的安全性，包括常見的SQL注入，XSS，CSRF，DDOS，cookie劫持等等的比較容易防護可是卻能形成很大危害的漏洞，應該設計時候就予以考慮，而不是開發完了再去補。

8. 功能的總體性，若是有一個較大的系統須要開發，那麼最好能先讓開發人員瞭解總體，最最好的狀況固然是整個需求一塊兒給出，這樣方便開發人員從總體上設計，若是一個龐大的體系今天一個需求明天一個需求，並且這些需求彼此關聯，後期的開發將會舉步維艱。

9. 架構的遵循，傳統的J2EE層次，如今使用到的包括Controller，Facade，Service，Dao層級。前端則是HTML和JS的配合，模板框架配合渲染HTML。那麼當使用的時候Controller應該重點負責對應起URL，進行權限的校驗，session的檢查等等並調用具體的facade層次，facade更多的是業務上的邏輯，好比轉帳那麼service應該有兩個接口，一個加錢一個減錢，facade去調用這兩個接口，而不是service直接一個接口完成了加錢減錢，facade進行了垂直的調用，而且若是要求密碼的話，我更傾向於密碼校驗在facade（那麼對應的service也要有校驗接口），而在serivce 就沒必要校驗密碼，畢竟service提供了加錢減錢的服務，而facade纔是真正的業務。在我看來這樣的設計才能讓service的複用性更高，各層級層次清晰分明。對團隊的配合相當重要。

10. 細節上注重，好比mybatis中$和#的區別，總體上關注，好比hibernate和mybatis的優缺點，redis和其餘緩存的對比等等。

11. 註釋很是重要，尤爲接口的註釋，應該說明這個接口的功能，傳入參數的類型及含義，返回值的類型及含義，若是是數字類型那麼-101234各表明了什麼。對於別人的代碼的修改也應寫好註釋，修改的起始位置，結束位置，修改人，修改時間，爲何修改等等。不然之後別人問你爲何改可能本身都記不住。

12. 日誌的記錄，在重要的業務流程或者容易出現異常的地方加入較多的日誌，日常的代碼也要加入日誌便於上線以後出了問題查找問題緣由所在。

13. 不是特別忙碌的狀況下能夠多接觸新的技術或者語言，一門新的語言可能讓你大開眼界原來還有這樣的語法，接觸的越多，思路會越廣，也會越聰明。程序員不能中止學習。

習慣

1. 任何一我的都有值得學習的地方，或許他性格沉穩，或許他樂於鑽研，或許他感興趣於新興技術。

2. 保持清醒的頭腦，忙碌也要適當，快速的反應和清晰的思路纔是最佳的狀態，而不是渾渾噩噩的癱在電腦前作着一些搬磚的工做。

3. 對於已經成型的功能點，若是進行了改進或者安全性的增強，應該在改進的同時整理優化點或者修改點，提交測試的時候一併通知測試人員，這樣能讓力量用在刀刃上，測試測的準，也省時間。

4. 多多思考如何提升工做效率，這種思考有兩種，第一種，如何提升自身效率，包括代碼習慣，IDE的使用，小技巧的積累，甚至做息時間上的調整等等。第二種就是如何提升所在團隊的效率了，所處的團隊高效，活躍，那麼自身也會受益頗多。因此能夠開發小的工具供你們使用，好比當你們一塊兒去完成一些技術含量比較低的工做的時候，開發了一個小工具來減小一些無腦的工做。好比當你們天天啓動項目的時候要啓動那麼多微服務，能夠和管理者溝通是否搭建一個公用的微服務減小你們啓動的時間以及PC內存的佔用，好比當你們痛苦於登記JIRA上的bug修改記錄的時候，是否是能夠考慮開發一個小工具造福全人類呢~

5. 跟住趨勢，承受向好方向發展時候的痛苦，好比最近在從eclipse逐步過渡到使用IDEA，快捷鍵什麼的基本不同了，用着有點不習慣，可是能感受到若是熟練了效率確定會高不少（逼格也高）。

6. 不斷的出現技術上的問題是一件好事情，說明整個項目是在向前走的。隨着項目組項目業務的愈來愈複雜，架構上的問題也逐漸暴露，因此問題的存在也在推進着不斷地進行優化。

溝通

1. 若是有新的同事或者剛剛加入項目組的同事，更傾向於首先讓其瞭解整個項目的總體做用，而後講到他即將接觸到的相對獨立的模塊的功能，而後再細緻的講解業務上的流程，數據的流轉，以及一些特殊的狀況。先了解最主線的任務，而後再講解各類不正常的狀況。從大的概念上了解，而後再比較全面的瞭解一個小功能，再輻射到更大的模塊，這也是我本身學習和滲透項目的一個思路。

2. 本身作出了一件很棒的事情徹底能夠拿去和別人炫耀，好比你用了一個很好的設計模式，好比你優化了一個功能讓他快了10倍，好比你開發了一個很棒的工具。或許你的炫耀可讓別人知道你這麼作的優勢，而後向你學習，也或許別人聽了以後給你了一個更棒的建議。成就感是最好的動力，每一個人都但願被確定。

3. 清晰的說明，耐心的講解，必要的配合一些畫圖，會讓溝通事半功倍，現在的開發節奏誰都不能獨自開發一個很棒的應用，溝通和表達在團隊中絕對是很是重要的能力。

項目相關

1. 開發的時間不該捨棄設計，單元測試，模塊測試，全面的自測，以及聯調的階段，若是時間安排上忽視了這些，那麼必然要在後來的修改bug時間，或者處理緊急問題的時間上找回來，並且必定會虧損更多的時間。

2. 公司在將項目轉化爲產品的過程當中，隨着產品包含的範圍不斷的擴大，業務的不斷整合，開發人員漸漸的不能從全局的角度來審視整個產品，而現有架構的特色對於業務的理解要求仍是比較高的。因此全局上了解了業務，才能寫出高質量，複用性高，可靠性高的代碼，這對程序員來講是一個挑戰。

3. 需求邊界的劃分清晰也是很是重要的一件事情，固然了，這不是一個普通的程序員可以掌握的事情，可是若是需求邊界不清晰，需求不斷的變動或者增長，對整個項目組來講都是一件很是耗神耗力的事情。

4. 項目組人員愈來愈多的時候，各個開發人員之間技術的差別，或者由於業務上的不清晰致使的代碼質量的問題比較嚴重，畢竟項目的水平取決於最差的一塊。

周邊

1. 問題多的時候儘可能保持平穩的心情，畢竟急躁不能帶來任何正面的效果，其實這個也是須要磨練的，光是說確定沒用的，經歷了不少折磨的事情才能淡定的面對一些很蛋疼的狀況。

2. 理解同事，不管是產品仍是測試，雖然沒有感同身受可是也應該儘可能的站在別人的角度思考，本身作成什麼樣子能對你們都好，提升你們的工做效率。

3. 注意身體健康，身體是革命的本錢啊~因此基本隔一天去公司的健身房鍛鍊一次，保證一個好的體魄，旺盛的精力才能更好的生活和工做。

4. 興趣愛好也很重要，若是天天的生活就是起牀，敲代碼，睡覺，再起牀的話，真的只是活着而不是生活了，平時喜歡彈彈烏克麗麗唱唱歌，拍拍照片旅旅遊，和同窗同事開黑LOL，要懂得休息和放鬆~

最後

• 表達能力真的很是很是重要，清晰，扼要。

• 要有責任心。

• 重視細節。

• 儘可能給團隊加buff。

• 自身能力橫向的擴展，知識面的拓寬。

• 自身能力縱向的深刻，對已知技術的深刻理解。

• 你不應只是活着，要去生活。