學習目前流行架構，同時也要自己去造建議的架構

在網上看到一個文章，一個Java程式員，工作一段時候後，因為公司沒有使用最新的架構，還是使用之前老套的架構，然後離職了。

該文章下的留言是，程式員隻要有活幹給錢，做什麼都無所謂。舊架構也是能夠學習到新的東西。學習新的架構，可以私底下學習，而公司的項目要平穩，不能激進的使用新架構。

其實這些都沒有錯，在一個崗位上，肯定優先使用穩定的架構，或者是讓之前舊代碼一直穩定的運作下去。但是對于一個程式員來說，特别是之後還需要投遞履歷去找工作的程式員來說，是比較不好的。厲害的人不投履歷都有工作，但是對于普普通通的程式員來說，面試被問的最多的就是這些新架構内的東西。

前幾年Java程式員被問的最多的是關于Spring内的AOP，IOC知識，而現在會被會到SpringBoot一些知識，還有微服務架構SpringBoot， Rpc架構Dubbo。平常沒有使用過，即使私底下搭建起Demo，對其内容也是不會熟悉。

誠然這些都是架構，學會使用花不了太多的時間，但是在之前學會了使用，可能在面試時，回答上會更自信一些。我之前有一個老大，非常厲害，對這些架構很熟悉，玩的賊溜，但是他覺得這些架構使用太繁瑣，不好用，然後自己造了一套輪子。他可以玩轉各個架構，但是對于新手的我們來說，潮流是需要追的，并且需要深入下去，Dubbo是Rpc架構，學習其中原理，在項目中進行擴充，使其能夠輸出調用的日志資訊。

熟練掌握了架構的使用，能夠極大的提高程式設計的速度。Dubbo中快速失敗能夠解決解決調用Provider中異常情況下調用多次。這種就避免了自己去驗證重複調用，或者使用其他解決方案。

特别要強調說明一下，架構的學習不僅僅隻限于使用，而需要更深入了解其中的原理，哪怕是了解其中的一個點，也是好的。會使用并不能代表自己掌握了，而深入原理更能體會該架構的優美。

在掌握的原理之後，需要自己去實作一個架構，使自己更熟悉該原理。比如Rpc架構，讀了Dubbo架構的部分源碼之後，可以根據Rpc原理，自己實作架構，而造成來輪子之後，自己對Rpc的認識更上一層樓。

造出來的輪子不一定要使用，原因是現有的成熟的架構，已經被很多人驗證過。而自己寫出來的輪子不成熟，而且如果自己的輪子遇到自己解決不了的BUG時，無法解決，對線上的項目來說是災難性的。

如果再次遇到團隊依舊使用舊架構，列出一二三點優點，并提給老大，并且根據該架構已經搭建好了項目的最初版本。如果沒能說服老大，那麼自己私底下多研究新架構，為自己準備下一次面試。