1. 程式人生 > >希望每一位2017殫精竭力的“Java程序猿”在2018宏圖大業

希望每一位2017殫精竭力的“Java程序猿”在2018宏圖大業

uml基礎 xmind 高端 細節 excel 資源 分析 head 保持

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年沈下心來,優先攻技術。
另外越來越覺得資源很重要,解決問題的途徑並不僅限於自己,能解決問題就是本事,所以想擴大圈子,也想做些自己的事,雖然我也沒太想明白要做什麽,但是總歸還是要開始做些。
有的時候感覺自己的激情越來越少,一回頭發現原來是因為生活
實戰微服務
搭建環境,熟悉相關的技術棧。
用於生產環境。整理出遇到的問題。
整理系列的知識體系並且固化。
技術分享圖片
實戰大數據
搭建環境,熟悉相關的技術棧。不涉及到具體的大數據的分析算法。
用於生產環境。整理出遇到的問題。
明確大數據,大概能解決什麽問題場景。
整理系列的知識體系並且固化。

推薦
一個挺不錯的Java架構交流學習群:688583154裏面會分享一些資深架構師錄制的視頻錄像:有Spring,MyBatis,Netty源碼分析,高並發、高性能、分布式、微服務架構的原理,JVM性能優化這些成為架構師必備的知識體系。還能領取免費的學習資源,目前受益良多:
技術分享圖片

完善應用架構
希望真實的落地到具體的應用和生產環境中,並且完善細節。現在比較尷尬,一說都知道,有的也在用,但是沒有做到極致。
技術解決方案
消息隊列
全文索引
日誌系統
企業解決方案
工作流
權限(數據級別)
經典應用系統
企業後臺系統。(系統功能,功能,CMS,工作流,以及一套完善的後臺框架)
代碼生成器
擴大圈子
越做到後面,越發現如果想自己做事業,就越需要資源。
好友
校友
同事
特定群體(同鄉、同行等)
營銷自我
一來對自己的知識和成長有一個持續性的積累,減少因為時間的折損。二來增加自己的影響力和資源。三來促進自己知識成體系,擺脫野生程序員的窘境。
博客(網站)
github(知識管理和更新)
平時的積累和總結,系統出視頻。
出國旅遊
世界這麽大,想出去走走。需要更明確的預算和計劃
健康身體
減肥。也是今年的一個遺憾,都減下來了,又因為一些事情反彈上去了。主要還是要保持一個良好的心情和合理的飲食和生活習慣。
看病。拒絕安慰自己,有不舒服的都去看看,並且支持把小毛病看怎麽處理下。比如原來的牙疼哈。
鍛煉身體。一周去二到三次健身房,二周到戶外做的有氧運行。
賺錢
今年的目標是能存50W以上的大洋。以便明年能在北京安個家

希望每一位2017殫精竭力的“Java程序猿”在2018宏圖大業