如何提升技術的開源

⑴ 工作一到五年的Java程序員遇到瓶頸應該如何提升

工作了5年的Java程序員，該如何提升,做了3~5年Java開發，你已經積累了不少項目經驗，擴寬了技術廣度，也許已發力成為團隊管理者。到了這個階段，大家卻常有這種感受：感覺自己卡在瓶頸進步緩慢，技術水平很難像早期一樣實現大幅突破？
其實大家往往忽略了這一點——提升自己的架構認知（工作5年左右程序員必須重視架構認知的提升，這會很大程度上推動你今後的成長）。架構的本質在於面對業務場景給出優雅的解決方案，使得業務能夠快速迭代和持續交付，從而達到降本增效的目標。提升架構認知高度，就像達克效應所描述的一樣，要敢於從愚昧之巔跳到絕望之谷，通過爬升開悟之坡，從而達到架構認知的巔峰時刻。到達巔峰時刻也就掌握了架構背後設計的哲學，面對具體業務場景在架構層面你便能夠輕松應對，以無招勝有招。
提升架構認知，要緊抓3個關鍵點：業務洞察力、技術視野、原創力（執行力）。
1.業務洞察力是技術戰略層面的問題，在當下能夠做出合理的判斷，清楚公司做什麼事情收益最大；

2. 技術視野即技術選型能力，是技術戰術層面的問題，在清楚做什麼事情後，需要進一步解決怎麼做的問題，也就是能夠給出合理的技術選型方案：是完全基於開源的方案，還是基於開源二次開發的方案，還是完全自研的方案；
3. 原創力（執行力）是技術落地執行層面的問題，一旦技術設計方案確定後，需要能夠快速Rush完成。
這3點層層遞進，最重要的是先把技術戰略問題思考清楚，然後再進一步解決技術戰術問題，最後是快速落地執行的問題。
工作5年左右的程序員，在原創力（執行力）層面比較有競爭力，往往欠缺技術視野以及業務洞察力。後面2點更加重要，這2點解決的是架構設計哲學問題，是架構師能夠持續擁有競爭力和影響力的立身之道。

舉個場景的例子來詳細說明：一提到分布式鎖問題，大多數人想到的方案是基於Redis的Master-Slave模式來實現。這個實現方案行不行？分布式鎖本質是一個CP需求，基於Redis的實現是一個AP需求，乍一看基於Redis的實現是無法滿足的。脫離業務場景來談架構都是耍流氓。
從技術戰略的需求層面來看，如果分布式鎖在極端情況下獲取鎖的不一致，社交業務場景能夠接受，那麼基於Redis的實現是完全可行的。如果業務是交易場景，分布式鎖在極端情況下獲取鎖的不一致性無法接受，那麼基於Redis的實現方案是不可行的。在鎖強一致性的場景下，需要採取基於CP模型的etcd等方案來實現。

⑵ 開源如何提升編程技能

開源是很多程序員都會面臨的問題，很多人會相信接觸的開源源技術越多對自己的編程技術提升越快，寫出來的代碼也更好。開源可提高編程技能之間有什麼相關性或因果關系嗎？

閱讀代碼能讓你變得更優秀

我在編程生涯的早期就明白我閱讀的代碼越多，我的代碼就能變得更好。我知道，當我不得不維護其他人的代碼時，簡單和干凈的代碼幾乎總是比花哨或復雜的代碼好——即使有注釋。然而另一方面，當我花足夠的時間去理解復雜代碼的時候，我常常能夠學到新的技巧。不論怎麼樣，都能讓我有所提高。

這使得我在那些沒有代碼審查的地方一再爭取。而當沒有足夠的時間來正式執行「代碼審查」的時候，我會自己瀏覽存儲庫和閱讀代碼。當然，那時我還被受限於來自於小團隊的公司資源。

超越語法

在你不得不全力對付任意編程語言的語法時，也就是學習如何充分利用該語言最瑣碎的時刻。一門語言的語法往往是非常靜態的，並且如果你出錯了，你的編譯器會向你控訴。更深層次的課程涉及到什麼語言最適合解決什麼樣的問題（「合適的工具做合適的工作」），以及如何用那種語言編寫代碼以便於使它高效和可維護。

學習新語言有許多方法：課程，教程，導師，書籍以及等等。我通常會結合這些選項來學習一門新的語言。我注意到，當涉及到非語法元素的時候，這些方法常常非常相似。

閱讀來自於其他人的實際部署代碼會讓你收獲更多。不僅僅是常規的結構化學習，你還需要學習模式和實踐方法。語言中所謂「正確」的做事方式並不總是效果最佳的方式。你會經歷邊緣情況，一次性事務以及意想不到的集成。你也會找到這些問題的解決方案，有好有壞，但如果你認真思考的話，那麼這正是出來「推薦做法」的地方。今天的模式就是明天的反面模式。

你可能對有些事情，例如「總是注釋」，「逗號放到最後」，「縮進x個空格」有著自己的想法，當然你是對的。我對提到的這些及編碼的其他方面也有著自己的感受。

有時候當我閱讀其他人的代碼時，如果看到他們做錯了，我會生氣。但是隨著我代碼閱讀量的增加，我開始懂得，總會有一些情形常見於別人的代碼，但我在我自己的代碼中卻未曾遇到過的，並且我的方法沒有必要那樣執拗。我不僅改變了我的一些觀點，而且懂得更加靈活。

開源無處不在

隨著開源運動的發展，可供閱讀和學習的代碼數量也大幅度增長。例如Gitlab，GitHub和到BitBucket這些網站就允許我們獲取全功能的應用程序，不僅可以閱讀代碼，還可以擺弄。很少有我想要學習的東西是不能在開源代碼中獲取的。

我以前學習新的編程語言，會把重點放在諸如目錄結構和命名約定這些簡單的事情上。但是，現在，我會找一些不同的開源項目，然後可以開始拼湊常用的方法。我很少強調以前那些類型的東西了。

可用的代碼是如此之多，但質量卻良莠不齊。當我們想要學習的時候，常常搞不清楚哪個好哪個不好。那就保持閱讀代碼吧，慢慢地你會學會如何區分。閱讀「壞」的代碼可以幫助你理解為什麼它是「壞」的。關鍵是不要害怕嘗試任何你覺得看上去正確的東西，並且當你走錯路的時候能夠承認錯誤，並改正問題，然後繼續前行。

壞的代碼就壞的，是這樣的嗎？

有人會說「壞的代碼比好的代碼要更多更明顯」。sub-reddit致力於壞的代碼。

在這些年裡，我寫了很多好的代碼和壞的代碼。當我看到我以前寫的代碼時，我的第一想法就是我怎麼會寫這樣的垃圾代碼。這實際上意味著我還在學習中。如果我看到我以前的代碼，覺得它看上去非常偉大，那麼說明我並沒有提高。

那麼，我們怎麼才能從壞的代碼中學到東西呢？

你閱讀的壞代碼越多，那麼你就越擅長發現壞的代碼

當你在學習和搜索例子的時候，你會發現和使用大量不能工作的代碼。請記住，僅僅因為它不適合你的情況，並不能說明它就是壞的代碼。學習如何讓它工作能夠使得你變得更優秀。

你怎麼知道它是壞的代碼？

人們喜歡批評。閱讀評論，如果你看到很多「WTF（什麼玩意）」，那麼可能你看到的正是壞的代碼，試著指出為什麼不好的原因。不要只留下「這代碼真爛」這樣的評論。不要裝得你好像懂得壞代碼的所有需求，要知道，總有一個它之所以被這樣寫的正當理由。如果你知道它為什麼是壞代碼的原因，那麼不妨留下一個有建設性的評論。或者??

讓它變成好的代碼

放一個能讓代碼變得更好的pull請求。修正語法，使用更好的方法，添加註釋或修改縮進：這些都是改進代碼的偉大方式。加一個為什麼你推薦改變代碼的解釋。

昆明北大青鳥java培訓專家認認為，當我幫助別人學習的時候能學到更多。如果我認為我理解了一個新的主題，那麼我會找個人來試著向他解釋，這能讓我更深刻地理解和記住它，並且讓我快速發現我是否寫了壞的代碼。

回報

記住開放源代碼在你參與進去的時候效果最佳。代碼更改在大多數項目中都是受歡迎的，但是有很多出力的方法。

測試開源代碼和文件錯誤報告；幫助完成文檔集；寫教程和如何做的例子；參加對話——或者僅僅只是幫助傳播。每一件事都能帶來改變，並且越多的人參與進來越好！

⑶ 作為一名程序員，該如何提升自己的核心競爭力和不可替代性

作為一名程序員，該如何提升自己的核心競爭力和不可替代性？要想時刻保持競爭力，我覺得又具備幾個方面的能力:不斷的學習與深入這個行業，不能停留在解決問題的表面，要能有了解問題的本質上。舉個例子吧，如果你是一個java的程序員，要想學會springboot ，不能僅僅局限與會用這個框架，要了解的深入，比從程序的啟動到依賴注入，到所有模塊的載入，異常處理，註解形式及控制，最好都能很熟悉。這樣在遇到問題時，就會很有方向，而不是像新手一樣問google,只是貼些報錯，就算你要google你也會貼的更准確的報錯。