殫精竭力

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以上的大洋。以便明年能在北京安個家

2017殫精竭力，2018宏圖大業