2019已到，我給java程序員的惟一一條建議！

作了幾年Java開發，或許你已經積累了很多項目經驗，擴寬了技術廣度，也許已發力成爲團隊管理者。到了這個階段，你們卻常有這種感覺：感受本身卡在瓶頸進步緩慢，技術水平很難像早期同樣實現大幅突破？其實你們每每忽略了這一點——提高本身的架構認知（工做5年左右的Java程序員必須重視架構認知的提高，這會很大程度上推進你從此的成長）。架構的本質在於面對業務場景給出優雅的解決方案，使得業務可以快速迭代和持續交付，從而達到降本增效的目標。提高架構認知高度，就像達克效應所描述的同樣，要勇於從愚昧之巔跳到絕望之谷，經過爬升開悟之坡，從而達到架構認知的巔峯時刻。到達巔峯時刻也就掌握了架構背後設計的哲學，面對具體業務場景在架構層面你便可以輕鬆應對，以無招勝有招。

   提高架構認知，要緊抓3個關鍵點：業務洞察力、技術視野、原創力（執行力）。
         1.業務洞察力是技術戰略層面的問題，在當下可以作出合理的判斷，清楚公司作什麼事情收益最大；
         2. 技術視野即技術選型能力，是技術戰術層面的問題，在清楚作什麼事情後，須要進一步解決怎麼作的問題，也就是可以給出合理的技術選型方案：是徹底基於開源的方案，仍是基於開源二次開發的方案，仍是徹底自研的方案；
         3.  原創力（執行力）是技術落地執行層面的問題，一旦技術設計方案肯定後，須要可以快速Rush完成。這3點層層遞進，最重要的是先把技術戰略問題思考清楚，而後再進一步解決技術戰術問題，最後是快速落地執行的問題。工做5年左右的程序員，在原創力（執行力）層面比較有競爭力，每每欠缺技術視野以及業務洞察力。後面2點更加劇要，這2點解決的是架構設計哲學問題，是架構師可以持續擁有競爭力和影響力的立身之道。舉個場景的例子來詳細說明：一提到分佈式鎖問題，大多數人想到的方案是基於Redis的Master-Slave模式來實現。這個實現方案行不行？分佈式鎖本質是一個CP需求，基於Redis的實現是一個AP需求，乍一看基於Redis的實現是沒法知足的。脫離業務場景來談架構都是耍流氓。從技術戰略的需求層面來看，若是分佈式鎖在極端狀況下獲取鎖的不一致，社交業務場景可以接受，那麼基於Redis的實現是徹底可行的。若是業務是交易場景，分佈式鎖在極端狀況下獲取鎖的不一致性沒法接受，那麼基於Redis的實現方案是不可行的。在鎖強一致性的場景下，須要採起基於CP模型的etcd等方案來實現。 「於一微塵中，悉見諸世界」，一切事物的本質是相通、相同的。 學習架構也是如此，掌握了架構設計背後的哲學，那麼一切工程問題也就迎刃而解了。提高架構認知不是一蹴而就的，它離不開刻意學習和思考。
         我說的這些不知道你是否也認同呢？