我相信絕大多數的人應該都制定過目標，比如“我要減肥”，“我要學習XXX技術”，“我要看書”，“我要寫博客” …. 。

那麽請問：你曾經制定的目標完成了嗎？

我猜肯定有人是從入門到放棄，有的人甚至還有些不甘心，當時間過了之後就把之前的目標時間延後，如：2017年過了但是還是沒完成年度目標，於是把7改成了8。其實這個和制定目標的方法是有很大的關系的，接下來我就來說說如何正確的制定目標。

1.目標不要多

現在這個時代可以說信息爆炸的時代，我們能很輕松的接觸到很多信息，這樣就會導致我們今天看這個技術不錯明天看那個技術也不錯都想去學習，結果就是今天學習pyhton，明天學習前端，後天學習後臺，甚至有的人，一天學習三種技術，每一種學習半小時。這樣雖然看上去學習了很多的技術，但是學習效果卻很糟糕。過於雜亂到學習只會導致整天都很焦慮，解決辦法就是把事情分散開，每一段時間只做一件事情，這樣能讓你專註，只有專註才能讓你更高效。切記“貪多嚼不爛”。

2.目標四要素

當我們選擇一個目標之後，我們就要開始制定目標了，這個時候要註意一個好的目標需要做到“明確可執行”這一點。怎麽才算明確可執行呢？

需要有以下四點：

時間區間

行為方式

目標對象

時間長度

如：這周用4個小時寫一篇時間管理的文章。

分解：

時間區間（這周）

行為方式（寫作）

目標對象（時間管理）

時間長度（4小時）

這樣的目標就很清晰了，簡化成一個固定的句式：在什麽時候，做什麽事情，和誰，需要多久。

3.目標拆解

上面我們得到了一個很清晰的計劃，接下來再把這4個小時再細分一下具體的任務，以及每天花多少時間，還是拿上面到寫作舉例。

定文章大綱（0.5小時）；

翻閱筆記，提取概念（0.5小時）；

寫出自己的踐行經歷（1小時）；

將概念和經歷整合（1.5小時）；

對文章內容進行修改（0.5小時）；

每完成一個小的任務，都可以更新下任務表，快速的給自己反饋，這樣讓會自己有一種成就感。

4.預留時間

需要註意的是不要把計劃和當天的時間全部排滿，預留出30%的容錯時間。在《稀缺》中提到稀缺會導致管窺效應。面對稀缺，我們就更傾向於把註意力集中在最需要關註的事情上面，這麽一來，我們往往會忽視那些真正重要的事情。

據報道美國的消防員80%都是死在了去火場的路上，因為沒有系安全帶，在急轉彎的時候被甩出車外殉職的。他們在接到出警通知的時候，就會進入時間稀缺的狀態，他們要在很短的時間裏做大量準備工作，導致一些重要但平常的事情被疏忽了。

任何系統留一定的余閑都非常重要，它不是對資源的浪費，而是讓系統更加高效運轉的保證。

總結

如何正確制定目標？

明確目標

目標制定

拆解目標

預留時間

從現在開始認真審視自己的目標，循著這些內在邏輯從新規劃自己的目標，穩紮穩打地踐行。你會發現，制定一個可完成目標如此簡單！

一個優秀的程序員應該具備哪些技能和修養？

首先是“快速學習能力”。這裏不是說一定要去快速去學習各種各樣的新技術，而是說當有需要時，能夠快速的學習。很多人開始學新的技術和技能時，一開始就一頭紮進去寫樣例、寫Demo、看源碼，我認為這不是好的方法，而且比較耗費時間，收效也不明顯。

我給大家分享我的4W2H快速學習方法。我在學習新的技術的時候，都是按照這樣的步驟去了解的：

1）這個技術能解決什麽問題（why）

2）比較適合在哪些場景應用（where + when)

3）這個技術跟我已經掌握的哪個知識或技能類似，有什麽差別、有什麽特點、 有什麽優點和缺點（what）

4）了解前面的問題後，我才會開始去嘗試寫寫Demo，或者更進一步去應用（How to use）

5）覺得有興趣或者其實現很牛逼的情況下，我就去研究一下原理機制，看看源碼等 （How it implements）

其次是“良好的理解能力”。程序員需要將產品人員或者用戶用自然語言表述的需求翻譯成程序語言。自然語言有一個特點就是通俗但不嚴謹，而程序語言必須是非常嚴謹的。如果對產品人員或者用戶提出的需求沒有很好的理解，即使程序語言寫的再漂亮，技巧再高，最後做出來也是一個不符合要求的產品

記得有一個關於“美女”的笑話：人聽到“美女”後的反應是想到“天使面孔魔鬼身材童顏巨乳”，而豬聽到“美女”後的反應是“烏克蘭大白豬”，貓聽到“美女”後的反應是“有著金色光滑皮毛的波斯貓”。如果程序員給了貓一個“天使面孔魔鬼身材童顏巨乳”的美女，貓一定會覺得很難看。

第三是“持續不斷的學習”。軟件開發領域設計的知識和技能太多了。從廣度上來說，有操作系統、數據庫、編程語言、網絡、設計等，編程語言又有幾十種；從深度上來說，操作系統、數據庫、編程語言等都是可以不斷深入去學習的。無論你是從事對技能廣度要求更高的業務開發，還是從事對技能深度要求更高開發專項系統，都需要不斷的學習，這樣才能不斷的提升自己的能力。

第四是“樂於分享”。如果單純從個人完成工作的能力來看，可能確實也有很多程序員不愛分享但確實很厲害。但我認為真正優秀的程序員一定是除了自己優秀外，還能讓其他人也變得優秀，或者能夠貢獻優秀的開源項目以降低別人的重復工作。分享的途徑有很多種，可以給公司人員做培訓，可以寫博客，可以貢獻開源項目等。

我不會以碼農自卑，但一定以常年碼農為恥！

大家討論的地方，如果你總期望有高手總無償指點你，除非他是你親戚！！討論者，起碼是水平相當的才有討論的說法，如果水平真差距太遠了，連基本操作都需要別人給解答，誰還跟你討論呢。

---浮躁的人容易問：我到底該學什麽；----別問，學就對了；

---浮躁的人容易問：有錢途嗎；----建議你去搶銀行算了；

---浮躁的人容易說：我要中文版！我英文不行！----不行？學呀！

---浮躁的人分兩種：只觀望而不學的人；只學而不堅持的人；

---浮躁的人永遠不是（也成不了）一個高手。

java開發人員可以看過來。

對於參加工作1年到2年的同學。這部分時間段的同學，已經對Java有了一個更加深入的了解。

對於參加工作2年到3年的同學有的同學在這個時候覺得自己已經很牛逼了，於是忍不住開始慢慢松懈。

參加工作3年到4年的同學這個階段的同學，提升已經是很難了，而且這個階段的學習往往會比較多樣化。

參加工作4年到5年的同學經過前面一年的歷練，相信你在自己所鉆研的領域已經有了自己一定的見解，這個時候，技術上你應該已經遇到瓶頸了。

可以一起學習：454377428 java架構\多線程\高性能 一起交流學習吧、 幫你提升自己，圖片瓶頸，跟上時代的腳步。

為大家分享自己總結的架構師學習路線圖，大家可以拿來做一個參考：

一、分布式架構體系

分布式怎麽來的。傳統的電信、銀行業，當業務量大了之後，普通服務器CPU/IO/網絡到了100%，請求太慢怎麽辦？最直接的做法，升級硬件，反正也不缺錢，IBM小型機，大型機，采購了堆硬件。

但是互聯網不能這麽幹，互聯網沒有那麽財大氣粗，還有很多初創，能不能賺錢還不知道。所以就有了軟件方面的解決方案：分布式系統，簡單說，就是一臺服務器不行，我用兩臺、10臺、100臺...這就要軟件系統需要支持。

那麽多臺機器，我如何讓他們協同工作，這就需要一個調度中心（或註冊中心）；肯定涉及到機器間通信，那麽需要一個高效的RPC框架；一個請求過來了，如何分發，需要一個請求分發系統（負載均衡）；然後還要考慮每個角色都不能成為性能瓶頸；還有要能方便的進行橫向擴展，還有考慮單節點故障。

需要分布式系統，並發量肯定不低，

那麽有了上面的還是不夠的，還需要考慮cache、mq、job、db等方面的問題。cache，現在第三方緩存也比較成熟，redis/memcache等；mq，rabbitmq,kafka等等也不錯；job，現在第三方任務框架有elasticjob和tbschedule，或者你用quartz也支持分布式環境下的任務，不過quartz就沒有運維工具了。DB，數據庫最好在項目前期就考慮好業務拆分，系統拆分後DB對應的垂直拆分，後期可做讀寫分離，一主多從，甚至多主多從，業界也有了相應的解決方案。

總結一下，首先要了解分布式原理，然後對應著每個功能區找業界內成熟的產品來實時。互聯網行業，基本都有開源的產品供你選擇。

下圖是我總結的分布式的技術攻克點：

二、微服務架構

微服務（Microservice）這個概念是2012年出現的，作為加快Web和移動應用程序開發進程的一種方法，2014年開始受到各方的關註，而2015年，可以說是微服務的元年；

越來越多的論壇、社區、blog以及互聯網行業巨頭開始對微服務進行討論、實踐，可以說這樣更近一步推動了微服務的發展和創新。

微服務架構（Microservice Architecture）是一種架構概念，旨在通過將功能分解到各個離散的服務中以實現對解決方案的解耦。你可以將其看作是在架構層次而非獲取服務的

類上應用很多SOLID原則。微服務架構是個很有趣的概念，它的主要作用是將功能分解到離散的各個服務當中，從而降低系統的耦合性，並提供更加靈活的服務支持。

概念：把一個大型的單個應用程序和服務拆分為數個甚至數十個的支持微服務，它可擴展單個組件而不是整個的應用程序堆棧，從而滿足服務等級協議。

定義：圍繞業務領域組件來創建應用，這些應用可獨立地進行開發、管理和叠代。在分散的組件中使用雲架構和平臺式部署、管理和服務功能，使產品交付變得更加簡單。

本質：用一些功能比較明確、業務比較精練的服務去解決更大、更實際的問題。

這些知識點都是我從業多年總結出來的的經驗，都是當前最主流的技術。想學習這些技術的朋友可以加群：619881427。群裏會分享這些技術知識點供大家學習免費下載

下圖是我總結的微服務的技術要點：

三、閱讀源碼、分析源碼

程序員每天都和代碼打交道。經過數年的基礎教育和職業培訓，大部分程序員都會「寫」代碼，或者至少會抄代碼和改代碼。但是，會讀代碼的並不在多數，會讀代碼又真正讀懂一些大項目的源碼的，少之又少。這種怪狀，真要追究起來，怪不得程序員這個群體本身 —— 它是兩個原因造成的。

我們所有的教育和培訓都在強調怎麽寫代碼，並沒有教大家如何讀代碼

大多數工作場景都是一個蘿蔔一個坑，我們只需要了解一個系統的局部便能開展工作，讀不相幹的代碼，似乎沒用

我常常把寫代碼和寫作進行類比 —— 二者有很多相通之處;但從培養寫代碼和寫作的過程來看，二者又有很多不同。我們的寫作能力，是建立在大量基礎閱讀的基礎上的，是除了學習語法和文法知識外，從小學開始，經年累月，通過閱讀各種不同層次的名家的作品，再加上各種各樣的寫作訓練，累積出來的;而我們的寫代碼的能力，在了解和掌握了語法/文法之後(學習和抄寫 example 代碼也算語法/文法學習的一部分)，跳過了大量閱讀名家作品的過程，直接 biu 地一下就自動養成了：學會基礎的語法和試驗了若幹 example 後，我們就火箭般躥到了自己寫代碼打怪贊經驗的階段。這樣略過大量閱讀代碼的階段有三個害處：

寫代碼的基礎是不牢靠的，打怪升級的過程也是最慢的。道理很簡單 —— 前輩們踩過的坑，總結的經驗教訓，你都不得不親自用最慢的法子一點點試著踩一遍。

很容易養成 stackoverflow driven 的寫代碼習慣 —— 遇到不知如何寫的代碼，從網上找現成的答案，找個高票的復制粘貼改吧改吧，湊活著完成功能再說。寫代碼的過程中遇到問題，開啟調試模式，要麽設置無數斷點一步步跟蹤，要麽到處打印信息試圖為滿是窟窿的代碼打上補丁，導致整個寫代碼的過程是一部調代碼的血淚史。(見我的文章：你要避免的軟件開發模式)

你周圍最強的那個工程師的開發水平的上限就是你的上限。

下圖是作為程序員最需要了解的源碼體系：

四、工具的使用

工欲善其事必先利其器，工具對Java程序員的重要性不言而喻現在有很多庫、實用工具和程序任Java開發人員選擇。下圖列出的工具都是程序員必不可少的工具

五、性能優化

性能優化，簡而言之，就是在不影響系統運行正確性的前提下，使之運行地更快，完成特定功能所需的時間更短。性能問題永遠是永恒的主題之一，而優化則更需要技巧。

程序員如何利用好自己的時間學習更多的知識？