前言
到今天為止，正好是工作一年了。
一年裡有過折磨痛苦，有過成就感，一年後很欣慰能看到自己是有所收穫的。
記錄如下，如有不當，還望指點。
技術
-
看到別人寫出的bug，自己也很大可能會犯同樣的錯誤。
-
從bug中學習，每一個bug都會對自己有警示的作用，或許你的定時任務有問題，那麼完全可以想想，如果上線了出問題怎麼辦，是否有補償機制，如果要補償如何處理。並找到根源，然後思考這個根源會影響到哪些功能。
-
絕對不要放過一個細微的問題，之前在使用dubbo的時候發現實體類中如果有Date型別的屬性為空會導致整個類為null，同事們採取的做法是用別的型別替代，但是仔細鑽研一番，看了原始碼之後發現這是dubbo2.5.3使用hessian序列化時候的一個自帶的bug，並且定位到了原始碼中的某一行。如果不能發現並很好的避免，如果以後出問題了會非常棘手。可以這麼說，專案中的問題，沒有小問題，任何一個問題都可能毀了一切。
-
程式設計師要做的事情應該比產品提供的需求更多，包括後臺的管理，一些意外情況的處理，甚至之前說到的定時任務的補償，都可以形成管理模組進行開發。
-
問題的最小場景的還原，當面對一個問題的時候，應該能夠迅速的縮小問題的範圍，然後定位到問題結症所在，再予以解決，這是一個經驗的問題，還是需要直覺和積累，而直覺來源於經驗。
-
開發的過程中要考慮越來越多的事情，效能，穩定，異常，安全，複用性，相容性等等，做到了這些，程式碼將會慢慢變成一件藝術品。
-
專案的安全性，包括常見的SQL隱碼攻擊，XSS，CSRF，DDOS，cookie劫持等等的比較容易防禦但是卻能造成很大危害的漏洞，應該設計時候就予以考慮，而不是開發完了再去補。
-
功能的整體性，如果有一個較大的系統需要開發，那麼最好能先讓開發人員瞭解整體，最最好的情況當然是整個需求一起給出，這樣方便開發人員從整體上設計，如果一個龐大的體系今天一個需求明天一個需求，而且這些需求彼此關聯，後期的開發將會舉步維艱。
-
架構的遵循，傳統的J2EE層次，現在使用到的包括Controller，Facade，Service，Dao層級。前端則是HTML和JS的配合，模板框架配合渲染HTML。那麼當使用的時候Controller應該重點負責對應起URL，進行許可權的校驗，session的檢查等等並呼叫具體的facade層次，facade更多的是業務上的邏輯，比如轉賬那麼service應該有兩個介面，一個加錢一個減錢，facade去呼叫這兩個介面，而不是service直接一個介面完成了加錢減錢，facade進行了垂直的呼叫，並且如果要求密碼的話，我更傾向於密碼校驗在facade（那麼對應的service也要有校驗介面），而在serivce 就不必校驗密碼，畢竟service提供了加錢減錢的服務，而facade才是真正的業務。在我看來這樣的設計才能讓service的複用性更高，各層級層次清晰分明。對團隊的配合至關重要。
-
細節上注重，比如mybatis中$和#的區別，整體上關注，比如hibernate和mybatis的優缺點，redis和其他快取的對比等等。
-
註釋非常重要，尤其介面的註釋，應該說明這個介面的功能，傳入引數的型別及含義，返回值的型別及含義，如果是數字型別那麼-101234各代表了什麼。對於別人的程式碼的修改也應寫好註釋，修改的起始位置，結束位置，修改人，修改時間，為什麼修改等等。否則以後別人問你為什麼改可能自己都記不住。
-
日誌的記錄，在重要的業務流程或者容易出現異常的地方加入較多的日誌，平常的程式碼也要加入日誌便於上線之後出了問題查詢問題原因所在。
-
不是特別忙碌的情況下可以多接觸新的技術或者語言，一門新的語言可能讓你大開眼界原來還有這樣的語法，接觸的越多，思路會越廣，也會越聰明。程式設計師不能停止學習。
習慣
-
任何一個人都有值得學習的地方，或許他性格沉穩，或許他樂於鑽研，或許他感興趣於新興技術。
-
保持清醒的頭腦，忙碌也要適當，快速的反應和清晰的思路才是最佳的狀態，而不是渾渾噩噩的癱在電腦前做著一些搬磚的工作。
-
對於已經成型的功能點，如果進行了改進或者安全性的加強，應該在改進的同時整理優化點或者修改點，提交測試的時候一併通知測試人員，這樣能讓力量用在刀刃上，測試測的準，也省時間。
-
多多思考如何提高工作效率，這種思考有兩種，第一種，如何提高自身效率，包括程式碼習慣，IDE的使用，小技巧的積累，甚至作息時間上的調整等等。第二種就是如何提高所在團隊的效率了，所處的團隊高效，活躍，那麼自身也會受益頗多。所以可以開發小的工具供大家使用，比如當大家一起去完成一些技術含量比較低的工作的時候，開發了一個小工具來減少一些無腦的工作。比如當大家每天啟動專案的時候要啟動那麼多微服務，可以和管理者溝通是否搭建一個公用的微服務減少大家啟動的時間以及PC記憶體的佔用，比如當大家痛苦於登記JIRA上的bug修改記錄的時候，是不是可以考慮開發一個小工具造福全人類呢~
-
跟住趨勢，承受向好方向發展時候的痛苦，比如最近在從eclipse逐步過渡到使用IDEA，快捷鍵什麼的基本不一樣了，用著有點不習慣，但是能感覺到如果熟練了效率肯定會高很多（逼格也高）。
-
不斷的出現技術上的問題是一件好事情，說明整個專案是在向前走的。隨著專案組專案業務的越來越複雜，架構上的問題也逐漸暴露，所以問題的存在也在推動著不斷地進行優化。
溝通
-
如果有新的同事或者剛剛加入專案組的同事，更傾向於首先讓其瞭解整個專案的整體作用，然後講到他即將接觸到的相對獨立的模組的功能，然後再細緻的講解業務上的流程，資料的流轉，以及一些特殊的情況。先了解最主線的任務，然後再講解各種不正常的情況。從大的概念上了解，然後再比較全面的瞭解一個小功能，再輻射到更大的模組，這也是我自己學習和滲透專案的一個思路。
-
自己做出了一件很棒的事情完全可以拿去和別人炫耀，比如你用了一個很好的設計模式，比如你優化了一個功能讓他快了10倍，比如你開發了一個很棒的工具。或許你的炫耀可以讓別人知道你這麼做的優點，然後向你學習，也或許別人聽了之後給你了一個更棒的建議。成就感是最好的動力，每個人都希望被肯定。
-
清晰的說明，耐心的講解，必要的配合一些畫圖，會讓溝通事半功倍，如今的開發節奏誰都不能獨自開發一個很棒的應用，溝通和表達在團隊中絕對是非常重要的能力。
專案相關
-
開發的時間不應捨棄設計，單元測試，模組測試，全面的自測，以及聯調的階段，如果時間安排上忽視了這些，那麼必然要在後來的修改bug時間，或者處理緊急問題的時間上找回來，而且一定會虧損更多的時間。
-
公司在將專案轉化為產品的過程中，隨著產品包含的範圍不斷的擴大，業務的不斷整合，開發人員漸漸的不能從全域性的角度來審視整個產品，而現有架構的特點對於業務的理解要求還是比較高的。所以全域性上了解了業務，才能寫出高質量，複用性高，可靠性高的程式碼，這對程式設計師來說是一個挑戰。
-
需求邊界的劃分清晰也是非常重要的一件事情，當然了，這不是一個普通的程式設計師能夠掌握的事情，但是如果需求邊界不清晰，需求不斷的變更或者增加，對整個專案組來說都是一件非常耗神耗力的事情。
-
專案組人員越來越多的時候，各個開發人員之間技術的差異，或者因為業務上的不清晰導致的程式碼質量的問題比較嚴重，畢竟專案的水平取決於最差的一塊。
周邊
-
問題多的時候儘量保持平穩的心情，畢竟急躁不能帶來任何正面的效果，其實這個也是需要磨練的，光是說肯定沒用的，經歷了很多折磨的事情才能淡定的面對一些很蛋疼的情況。
-
理解同事，無論是產品還是測試，雖然沒有感同身受但是也應該儘量的站在別人的角度思考，自己做成什麼樣子能對大家都好，提高大家的工作效率。
-
注意身體健康，身體是革命的本錢啊~所以基本隔一天去公司的健身房鍛鍊一次，保證一個好的體魄，旺盛的精力才能更好的生活和工作。
-
興趣愛好也很重要，如果每天的生活就是起床，敲程式碼，睡覺，再起床的話，真的只是活著而不是生活了，平時喜歡彈彈烏克麗麗唱唱歌，拍拍照片旅旅遊，和同學同事開黑LOL，要懂得休息和放鬆~
最後
-
表達能力真的非常非常重要，清晰，扼要。
-
要有責任心。
-
重視細節。
-
儘量給團隊加buff。
-
自身能力橫向的擴充套件，知識面的拓寬。
-
自身能力縱向的深入，對已知技術的深入理解。
-
你不該只是活著，要去生活。