今天算是正式離職了，算起來還有幾個月在此家公司呆了快三年。中間的得得失失我覺得很有必要總結一下，應該算是一個對我個人來說比較有價值的總結吧。下面開始從頭屢一下。

一些閒話：

當初來公司的時候是用JavaEE開發後臺的職位，同時來的還有一個技術小夥伴，兩個人一起開發了公司的一款至今看起來比較牛逼產品的後臺；這個產品雖然在後來沒有發揮了應有的作用，但是為公司另外一個產品的設計理念和思路在就是在此產品的基礎上進行了拓展。這個專案的後臺用的Mongodb+spring，算是用Mongodb正式開發的一個專案吧。後來專案開發結束後，在專案負責人的安排下轉了android，看了一個星期的android知識後正式上崗上線。

其實在我看來，從JavaEE轉android還是挺容易的，當然在初期也犯了各種低階錯誤；有的需求是自己網上邊搜資料邊開發的，特別是一個動畫效果，當初對我來說可是一點思路都沒有，然後就下載網上同類上線的apk進行反編譯看看別人怎麼實現，最後也模仿出來了，也即是幀動畫的效果，當初我都不知道有幀動畫，自己用了其他方式都沒達到要求。其實我覺得程式設計師的工作是最有滿足感的工作，自己在親手解決一個自我感覺很困難的問題的時候，那種心中滿滿的自信，感覺很美妙的。

當然在離職之前又接收了公司的一個後臺專案的開發，算是重新把後臺拾了起來；並且打算就算辭職了以後後臺也需要繼續學習和實際開發了；技術總是學無止境的！！！

秀一下滿足感：

由於某些原因，基本上都是獨立在開發apk,事實上從來公司到離職基本上都是自己在獨立開發apk，目前為止自己獨立完成的上線專案（算上剛開始上線後來由於各種原因放棄下線的）有5個，這估計在外行人看來很牛逼，居然一個人能開發一款軟體，但是呢個人覺得缺點大於優點，太閉門造車的感覺，雖然自己開發專案自己決定使用什麼技術，也自學過RxJava,butterKnife，okhttp等技術並運用到自己的專案中去，但是總感覺閉門造車的缺點太多了；當然在開發之餘也經常閱讀自己的程式碼然後能重構的重構之，能優化的優化之。對我來說最大的收穫就是養成了任務或者某一功能完成後閱讀和重構自己程式碼的習慣，這估計是看了《重構改善程式碼既有設計》這本書的影響吧，來來回回翻看了好幾遍，每次看都有不同的感受和收穫，在我們專案組codereview的時候我也不止一次向同事推薦過這本書，確實值得讀讀。參與團隊開發的apk就三四個，獲取看到這兒會給人一種外包的感覺，然而並不是。

在工作閒暇時間也經常在android相關網站下載大量別人的高仿原始碼觀看，就是想看看別人怎麼組織程式碼，怎麼實現某個相同的功能，來吸收別人的經驗希望彌補自己閉門造車帶來的不足，收穫確實很大！就算是至今也時長下載一些別人的原始碼來瞅瞅，如果某一個知識點不是很明白的話就研究原始碼或者網上查閱資料弄懂為止。

上面說到程式碼的重構，我覺得我在公司最大的收穫或者成就（自我感覺，可能對也可能錯，就算自我感覺良好吧）是把我最初來公司時候android專案應用了好幾年的介面給徹底重構了一下。原來的介面封裝起來怎麼說呢，客觀的說程式碼組織有點亂，太多的不必要的Impl類，太多的冗餘程式碼和方法，經常用起來感覺擴充套件起來麻煩也Jude不方便，於是我自己花了半天時間研究一下這些impl類之間的關係然後算是利用了Builder模式吧，把幾十個impl類全部刪除了，提煉之後弄了一個ParamBuilder類來組織構建不同請求的物件並添加了上一頁和下一頁的功能，結合okhttp重構完成之後應用到自己獨立開發的一款專案中去，簡單明瞭使用起來很簡單。後來一個同事問我要這個重構過後API的原始碼，也就是順便給他了，他有沒有用到開發中去就不得而知了，當然現在想想自己修改的API還有改進的空間。

其實我們常說專案經驗，專案經驗這四個字在我看來可不只是簡單的是簡歷上羅列的專案的個數（也就是說專案經驗！=自己參與的專案個數）；其實在開發專案的時候，並不只是完成自己的任務就可以萬事大吉了，此時應該做的就是多讀讀自己的程式碼或者每隔一段時間讀讀自己的程式碼看是否有重構的地方或者有沒有其他更簡單的方案；或者讀讀團隊開發中其他同事的程式碼並與自己的觀點相互認證，總能學會點別的東西，不斷的提高和錘鍊自己。堅決拒絕把舊的錯誤帶到新的專案中去！堅決不做一個程式碼搬運工。其實從一個專案中可以學到的東西很多，比如你可以自己把自己設想成專案經理或者技術經理的角色，如果自己是專案經理會怎麼分配工作以及組織後續的開發工作，同時跟團隊中的專案經理或者技術經理進行對比總結，自己哪方面可以做的對，哪方便沒有考慮到；甚至如果你有心的話，開發中的文件（包括寫法，格式等）也是可以讓你學一點東西的。

我有時候在地鐵上或者閒著的時候也會思考一些不是android的問題（這有點涉嫌無證裝逼），比如自己公司專案後臺用的到資料庫表是怎麼設計的，自己在腦海中也模仿設計一些是不是可行等等；有時候在使用一些視訊播放apk觀看電影的時候突然間腦海裡面會蹦躂出來一根問題：為什麼別人的apk重新整理了很多資料還是包含海報的資料都不會OOM呢，是什麼原因？為此我也會暫時停止視訊的觀看，特地下載相關apk反編譯之看看別人怎麼實現的（當然更多的時候是反編譯失敗）。

總之，說了這麼多，意思只有一個，用心留意自己專案所開發的任務之外的東西，也是可以學到東西的，哪怕學到的東西你用不到甚至可能忘記，但總比沒有東西可以遺忘好是吧，說不定以後會用的著呢！

第二個另外覺得有意思的收穫是根據公司專案適配的方式，自己利用業餘用java AWT，dom4j技術簡單的寫了一個dp值自動轉換工具，用來做公司專案的適配非常方便，這也是第一款業餘是自己開發工具給自己使永的軟體，感覺真的很奇妙。

由於公司性質的原因，需要經常出差；第一次是跟一個北京的同事去重慶出差，這個同事在公司都尊稱他為李哥，後來也跟他一起出差去參與貴州的專案直到我離職。當通知我去出差的時候我都不知道我還有機會去出差，說實話第一次出差感覺還是很新鮮的，而且是第一次坐飛機那感覺就簡直了。後來的幾次出差做過幾次飛機後感覺就無聊了，然後出差一直都是乘坐高鐵。當到達重慶後找到第三方，整個人還沒弄明白呢，跟同事兩個人就被對方的一個領導劈頭蓋臉的跟訓什麼似的。現在想想真是莫名其妙，然後各種噴我們的軟體設計的怎麼怎麼滴，後來又跟同事在賓館總結了一下對方要求的什麼文件，呆了一個星期後就回來了。第一次出差學到了一個不大不小的經驗並運用到以後的工作中去----出差的時候或者公司內部會議的時候很有必要帶上紙和筆，要不然溝通下來還是很容易忘記或者忽略到一點重要的東西的。

發洩可以、抱怨可以，但牢記這是私底下的事兒！

後來也著手開發了一些軟體，總體來說波瀾不大。從15年5月份開始基本上一直著手忙活著貴州的專案，感覺跟他們打交道得做好受氣的準備，好多時候都感覺很扯淡，他們讓我們配置修改一點東西跟催命鬼使得，“哎呀呀，你們這個功能得趕緊弄啊”；當我有些資源需要他們配合的時候真特麼跟蝸牛還慢，有的技術人員他們這邊的專案協調人都指使不動，想想也是醉了。每次下班過後我都跟李哥抱怨來發洩心中的怨氣和怒氣！有時候發郵件的時候也會帶點情緒在郵件裡面，抄送給李哥的時候李哥對這種情況特別跟我做了指導，總體上是說就是對面溝通或者處理問題的是儘量控制自己的情緒吧之類的。後來跟李哥學會了怎麼處理這種事情（算是比較靈活了吧或者小油條一枚），起碼學會了面對這種情況郵件該怎麼發吧。事實上李哥是個經驗比較牛叉的同事，從他身上確實學會了不少東西；由於我們兩個住在一個標間，說實話他比我的工作多的太多了，白天在貴州忙貴州的專案，晚上回來我看電影或者畫畫的時候他還得忙公司其他的專案到很晚，偶爾也會聽到他對第三方的抱怨和吐槽，但是該做的工作還是仔細認真的完成，這點確實是值得學習的優點！想想我白天還在抱怨這怎麼怎麼滴，那怎麼怎麼滴，還真是汗顏。當然不能說後面我都沒抱怨過，也會各種吐槽，只是吐槽仍然是私下裡吐槽，從來沒有帶入到工作中去罷了。慢慢學會了心平氣和的跟對方溝通了。

要學會說不！

在跟第三方對接的時候，真不能什麼都滿足他們的要求，該拒絕的時候就拒絕，當然拒絕的時候不是無謂的拒絕，要有理有據，這樣才有說服力。剛開始貴州專案要上線的時候對方毫無道理的或者是感覺想懶省事的原因居然要求我把開發好的apk查分成3個獨立的apk然後配置三個入口來啟動不同的頁面；當時我就怒了，先不說拆分起來很麻煩，不用拆分也可以實現他的要求。直接拒絕之！然後按照我提供的啟動方式在他們的後臺配置好入口一切OK；這是我第一次明確的拒絕別人的要求，所以記得很清晰；當初要是不假思索的答應他們差分成3個，上線後後來又增加的許許多多的需求，其結果簡直不敢想象的！

後來也拒絕過其他專案的一些毫無道理的要求，都是有理有據的拒絕，對方也對拒絕的理由表示接受。拒絕也是需要方法滴！

最後別忘了擠點時間給自己充電

《java8實戰》這本書也感覺不錯，對java8的學習很有幫助，目前還在閱讀學習中，這本書是出差的時候週末沒事去書店逛蕩，然後看了一部分頓時感覺很有買的必要就果斷入手了。

《在小吃店遇到凱恩斯》《王二的經濟學故事》《微觀經濟學》等經濟類書籍也可以讀讀，開闊眼界或者用來裝逼用也是好的！

自己的失

還有正如什麼所說，自己團隊開中的經驗相對而言有點少了（雖然也參與了公司幾個專案的團隊開發），算是比較缺少團隊開發中的溝通交流的經驗吧！前面雖然對重構做了很多的講解，其實在自己開發的幾個專案中，現在只有最後一個專案的程式碼組織還像點樣子，還算比較滿意吧。其他的專案雖然也做到了部分提煉和重構，但是整體上程式碼看起來還是很混亂，因為前期的考慮不是充分，現在要全面的提煉或者重構的話會也會花費不少時間和工作量，當然我不會再對他們進行重構了（雖然腦海裡也有些感覺不錯的組織方式）從某方面來說設計模式這種東西理解了思想靈活運用之更重要，就用這些組織混亂的程式碼作為失敗產品，以此為鑑吧！

還有一個自我感覺很失敗的地方：就是從頭到尾沒有主動跟領導提過加薪的要求（口笨，不知道如何開口，鄙視下自己）。

總結就到此吧，感覺寫的亂七八糟的毫無章法