2017殫精竭力，2018宏圖大業

殫精竭力

2017年，作得越多以爲本身不會得越多，有種殫精竭力的感受。這一年在技術上的思考和實踐的比較多，也大膽的嘗試作了跨角色跨職能的架構。也有點什麼都想作的衝動，因此反而有些事情沒作好、沒作精。

初悟編程

這一年並無花多少時間在寫代碼上面，卻是CodeReview的代碼很多，有種跳出「不識廬山真面目，只緣身在此山中」，反而更注重代碼的質量、可閱讀性、可維護性。以前一直寫Java，今年也寫了兩個月Vue，後面又寫了段時間React Native ，有跨語言的對比後，對編程有種駕輕就熟的感受。

規範

命名即思想，每每是想明白需求後命名會很天然，反過來看着不舒服的命名至少說明可能存在不少問題：

• 職責不清楚
• 職責不單一
• 需求理解不正確
• 思想或者算法不夠簡潔直接

規範是實際上是用來解決問題的手段，而不是約束。

• 增長可維護性。不須要額外再作翻譯。幾我的寫出來的代碼是同樣的。雖說沒有永遠是對的，可是總有相對正確的寫法。
• 減小寫代碼的成本。不用一直在思考重複的內容。
• 避免一些低級的debug。
• 提高性能。

有規範的前提下，能夠經過自動化的方式來解決重複的勞動。

• IDE 的代碼片斷插件
• 標準的Demo的場景
• 代碼生成器

JAVA開發規範

推薦

• 《阿里巴巴Java開發手冊》
• 《重構》

樹狀編程

不少小夥伴是線性的編程方式，寫一個方法，要把全部的細節放在裏面。這種方式的弊端

• 關注點過高。必須知道全部的關注點才能完成這個方法。
• 回來不斷的切換思惟
• 若是改動一個地方，須要從頭索引定位
• 不方便協做

若是把編程方式換成樹狀。寫一個方法，考慮同一個層次的需求點，而後在進一步細化需求點。這裏比較難的是怎麼判斷是同一個層次的抽象。

推薦

• 《代碼整潔之道》

防護式編程

不少小夥伴是線性的編程方式，在正常的邏輯裏會有各類特殊狀況判斷。這種弊端：

• 在一開始寫程序的時候很容易只考慮正常，而後後面隨着發現問題，不斷的添加各類if處理或者代碼，破壞原來的結構。而後就有代碼壞味道。
• 正常的邏輯和異常、特殊的邏輯耦合在一塊，思考關注點高。

防護式編程：把全部異常、特殊的狀況都處理完，代碼最後只考慮正常的邏輯。並且要永遠認爲程序是不安全的，不要人爲的假設是正常的。

推薦

• 《代碼大全》

用天然的語言寫代碼

一直髮現一個很奇怪的問題：不少人會把一個天然的需求，經過本身的加工，而後加上本身理解的算法，最後會很複雜的代碼把本身弄暈了。

在寫複雜算法代碼和複雜sql的時候特別明顯。

其實需求明確後，用天然的語言轉爲僞代碼，最後的僞代碼，只是根據不一樣的語言特性，純翻譯一下。

進階Java

之前只停留在會使用Java語法的階段。後來發如今高性能、高併發或者架構設計上的時候，只是瞭解語法是力不從心的。

java虛擬機

• 內存。跟蹤內存泄露，調優應用。
• 類加載。解決類衝突。
• 字節碼。不入侵業務的添加監控。遠程調試。

多線程

• 鎖。
• 線程。
• 異步。

力薦

• 《深刻理解Java虛擬機》

深刻面向對象

面向對象是一種抽象簡化問題思想方式。同時它經過經典的特性：封裝、繼承、多態來解決在面向對象抽象簡化過程當中常見的問題。

漫淡面向對象——POJO對象

漫淡面向對象——算法|設計模式

漫淡面向對象——抽象問題域分析

提高面向對象的方式，多想！多想！多想！快捷提高的方法

• 領域驅動設計
• UML
• 設計模式

力薦

• 《Thinking in UML》
• 《UML基礎、應用和案例》
• 《領域驅動設計》
• 《Head First設計模式》
• 《大話設計模式》

使用面向切面

是一種減小重複代碼，減小關注度，下降複雜度的不入侵業務的思想方式。可讓業務更簡單、更專一，可以下降複雜度。好比下面的應用場景：

• 權限判斷
• 數據聚合
• 數據格式
• 自定義標籤引擎
• 事務
• 日誌
• 統計
• 監控
• 數據收集等
• 緩存

這裏指的並非springMVC或者應用級別。指的是整個系統的各個環節或者解決問題的思考方式。好比：有的緩存，可能會放在代理的節點再加一中間層。監控可能會放到容器級別經過代理去實現。

推薦

• 《spirng in action》裏對於AOP的描述
• 《JavaEE互聯網輕量級框架整合開發》裏面對於AOP的描述

造成架構原則

其實架構自己就是一種思惟方式和能力。是對技術規劃，選擇，以最優的資源真實解決問題，同時又能在擴展和後續的一種平衡之術

推薦

• 《軟件構架設計——程序員向架構師轉型必備》
• 《軟件架構師12項修煉》

定位問題

明確要架構的邊界和要解決的問題，是架構的第一步也是很重要的一步。

能夠從下面4個維護去思考，找到問題。

• 重複。能夠經過封裝和自動化或者工具化來解決。
• 關注高。經過封裝和分層，流程和規範約定來解決。
• 複雜高。經過封裝工具和分層和規範約定來解決。
• 耦合高。經過分層、分步驟和規範約定來解決。

規劃

根據解決問題會有多少收益比。節約時間/花費時間：來明確作事的優先級。不要根據技術的好壞和牛逼與否。解決問題纔是關鍵。

合理的拆分，會讓後期落地更可控。

• 水平拆分。分層
• 垂直拆分。分步驟

迭代的思惟。一步到位和每次驗證明踐步伐太大，都容易形成夭折。

• 先有再完美。
• 傷其十指，不如斷其一指。

畢竟是商業，生產環境，因此要求穩。

• 小範圍試驗。通常來講找用戶容忍度高的，商業價值影響相對小的去試驗。
• 作好回退的方案或者備用方案。

設計

設計是爲了把風險降到最低，對一些風險高的地方提早準備和集中解決，以避免後面落地的時候返工、甚至推翻重作。不是全部的內容都須要設計，這樣就是過分設計。

開源

優先使用第三方，儘可能不要重複造輪子。直接使用開源的第三方，須要考慮下面的問題。

• 生態（社區）
• 先進性
• 成功案例
• 活躍性
• 擴展性
• 易用性
• 合理性
• 優缺點

自研

若是找不到適合的輪子。能夠經過下面的方式去思考，分析，分解設計要作的事。

• 分而治之
  • 分層
  • 分步驟
  • 職責清晰
• 抽象、建模
• 設計模式
• 思想
  • 面向對象
  • 面向切面
  • 面向插件
  • 面向服務

實施

• 質量
  • 代碼質量
  • 軟件質量
  • 需求質量
• 研發
  • 核心代碼
  • 算法
  • 關鍵節點的實現（複雜度高的）
• 指導
  • 有現成的解決方案

驗證

• 演示是最好的辦法。一來能show一下成果，二來羣衆的眼睛是雪亮的，發現問題的角度更不一樣。

優化

在解決完問題後。還須要從易用性、擴展性去考慮。

• 文檔化
  • 文檔
  • Demo
• 易用性
  • 暴露出去須要使用者知道的參數越少越好。
  • 經常使用的一些場景對應的參數越天然趙好。不要讓用戶思考太多。
• 擴展性
  • 在不須要知道太多細節的狀況下，更方便的擴展

落地跨職能架構

今年一共落地前端Web（Vue），後臺（SpringMVC+mybatis），混合（React Native）以及優化應用架構。每種架構對應的領域技術和須要的能力有所不一樣。可是架構原則幾乎是同樣的。具體的後面再補充

• 前端Web架構（Vue和React，其實抽象上是一致的，細節不太同樣）。
• 混合架構（React Native)。和前端的架構絕大數雷同，只是額外須要考慮和原生交互和移動端原生等問題。
• 後臺架構（Java和Nodejs，涉及到的領域也是同樣的，細節和語法、工具、周邊不太同樣）
• 應用架構。經過項目管理，版本管理，自動化持續集成等方式把一個產品以更快、最優方式轉成互聯網能夠提供服務的服務。
• 服務化架構。今年主要對分層職責定義，服務邊界定義更明確了，數據聚合和設計，只是經過jar包的方式解決，下一步能夠實踐使用服務化和微服務相關的技術落地。

優化效率

多一個技能，能節省後面不少的時間，時間質量會愈來愈高。後面會專門花點時間作些這方面的專題。

辦公

• typora(markdown)
• everything(找文件)
• xmind（幫助思考、固化和解決問題的神器）
• licecap（製做gif圖的神器）
• excel (在一些轉數據的場景，幫了大忙，有的寫sql或者程序要幾個小時甚至幾天的，用excel幾乎幾分鐘內就完成)
• ...

客戶端

• redis-desktop-manager
• navicat
• SecureCRT
• ...

IDEA

• Intellj idea
• webstorm
• Vim配置
• notepad++
• ...

開發輔助

• jd-gui
• fiddler
• chorme控制檯
• beyond compare
• ...

網站

• github：管理知識和資源
• 百度網盤：管理資源和軟件
• 爲知：管理網文
• doit：時間管理
• worktile|teambition：項目管理
• 博客園：知識固化和自我營銷。
• ....

瞭解大數據

• 是一種分佈式計算的解決方案和生態圈。
• 和傳統的數據庫的建模和理解是雷同的。
• 瞭解了能解決的問題，以及企業對大數據的訴求有哪些。

團隊招聘

明確要招過來的人職責是什麼，具體工做和定位是什麼。而後就是怎麼驗證他們是否符合這些能力。

開放式問題

封閉的答案每每，不能體現一我的的能力並且容易是背出來的。

• 瞭解知道的知識面和關注度
• 思惟是否清晰
• 是否真實解決過問題。

好比：如今服務一個頁面訪問是404，其餘都是正常的，怎麼公定位問題。

有價值的問題

很容易知道關注度還有就是層次。

好比去年最有價值的事，去年作過最難的事。若是面試小夥伴上來講最難的是寫統計sql，或者畫ui，或者寫購物車的交互難等，其實很容易看出來他實際的定位以及處於的階段。

往下深挖三級

往下繼續問三級或者連環問三個以上的問題。不用關心答案是否正確，不用去驗證它。特別是在跨職業面試的時候很是好用。也能知道面試者的知識體系和掌握水平。若是最後他的問題經過三級，他的話比較接近天然語言和細節，那就說明掌握得還不錯。通常來講，要麼有明確的細節，要麼有明確的衡量標準。

好比：你怎麼預估一個項目？（求職者會說一堆，而後說一個風險係數）繼續問，風險係數你怎麼確認的，有什麼衡量標準？（求職者又說了一堆，而後說考慮團隊的穩定性的戰鬥力）繼續問，怎麼明確團隊的戰鬥力？

相對多彩的生活

越努力越精彩。滑雪、高爾夫、泡溫泉、張北草原、攀巖、承德避暑、鍵盤控、文具控........有點遺憾的是陪伴家人的時間仍是比較少。主要也是由於一些事限制本身，沒有明確的目標，時間黑洞比較多，因此只能用加班的方式來完成了。

宏圖大業

2017年事後，有種什麼感受呢——尷尬！感受高不成，低不就，後面反思了一下，仍是由於沒有很紮實的邁入高端的職業生涯裏，因此計劃2018年沉下心來，優先攻技術。

另外愈來愈以爲資源很重要，解決問題的途徑並不只限於本身，能解決問題就是本事，因此想擴大圈子，也想作些本身的事，雖然我也沒太想明白要作什麼，可是總歸仍是要開始作些。

有的時候感受本身的激情愈來愈少，一回頭髮現原來是由於生活

實戰微服務

• 搭建環境，熟悉相關的技術棧。
• 用於生產環境。整理出遇到的問題。
• 整理系列的知識體系而且固化。

實戰大數據

• 搭建環境，熟悉相關的技術棧。不涉及到具體的大數據的分析算法。
• 用於生產環境。整理出遇到的問題。
• 明確大數據，大概能解決什麼問題場景。
• 整理系列的知識體系而且固化。

完善應用架構

但願真實的落地到具體的應用和生產環境中，而且完善細節。如今比較尷尬，一說都知道，有的也在用，可是沒有作到極致。

技術解決方案

• 消息隊列
• 全文索引
• 日誌系統

企業解決方案

• 工做流
• 權限（數據級別）

經典應用系統

• 企業後臺系統。（系統功能，功能，CMS，工做流，以及一套完善的後臺框架）
• 代碼生成器

擴大圈子

越作到後面，愈加現若是想本身作事業，就越須要資源。

• 好友
• 校友
• 同事
• 特定羣體(同鄉、同行等)

營銷自我

一來對本身的知識和成長有一個持續性的積累，減小由於時間的折損。二來增長本身的影響力和資源。三來促進本身知識成體系，擺脫野生程序員的窘境。

• 博客（網站）
• github（知識管理和更新）
• 平時的積累和總結，系統出視頻。

出國旅遊

世界這麼大，想出去走走。須要更明確的預算和計劃

再照婚紗

主題：花海。圓原來的承諾。生活短暫，青春易逝。

健康身體

• 減肥。也是今年的一個遺憾，都減下來了，又由於一些事情反彈上去了。主要仍是要保持一個良好的心情和合理的飲食和生活習慣。
• 看病。拒絕安慰本身，有不舒服的都去看看，而且支持把小毛病看怎麼處理下。好比原來的牙疼哈。
• 鍛鍊身體。一週去二到三次健身房，二週到戶外作的有氧運行。

賺錢

今年的目標是能存50W以上的大洋。以便明年能在北京安個家