李振亞love
代碼能力遇到瓶頸的話，你要和其它人比較一下，你的水平處在整個行業的哪個階段，如果是初級階段的話，說明你的能力還有很大提升，那麼就要多看其他人的優質代碼，多看源碼，或者通過一些書籍學習怎麼寫出好的代碼，對於優質代碼要詢問別人為什麼這麼寫，有什麼好處或優點，這樣才能才能突破自己的瓶頸。
如果你的水平已經到達中級的水準，說明你的代碼寫的比較優質了，你可以學習下設計模式，要知道每個設計模式使用的場景是什麼，每個設計模式使用的時候有什麼優點和缺點，為什麼要使用這種設計模式，你在寫代碼的時候有沒有用過這種設計模式，要理解到設計思想的精髓，你可以用學到的思想把自己項目中的代碼重構下，證明自己確實學到了，學會了。
如果你已經到了高級開發的階段了，代碼層面可能確實到極限了，你可以學習下架構的設計，你的項目用到了什麼框架，這種框架的優勢在哪裡，有沒有可替代性，有沒有成本更低的框架選擇，擴展性怎麼樣，是否高可用等等，要學習的東西有很多，只要用心學習總能學習到心的東西，提升自己的價值，提高在公司的地位。
JAVA異世界
作為一名IT行業的從業者，同時也是一名教育工作者，我來回答一下這個問題。
首先，對於程序員來說，代碼編寫能力必然會經歷多次的上升瓶頸期，每一個瓶頸期都需要有不同的解決方案。
對於初級程序員來說，要想突破自身的代碼編寫能力從而成長為主力程序員，需要從三個方面入手，其一是注重開發知識的全面性；其二是注重各種開發模式的掌握；其三是注重開發工具的運用。對於大部分初級程序員來說，成長為主力程序員往往只是時間的問題，通常能夠勇於承擔新任務的程序員會獲得更快的發展速度。
對於主力程序員來說，如果想進一步提升自己的編碼能力，則需要選擇一個自己的主攻方向，有了主攻方向才能不斷深入相應的技術體系。在技術方向的選擇上既應該考慮到崗位任務的需求，同時也要考慮到未來的發展趨勢。從目前IT行業的技術發展趨勢來看，大數據、雲計算、人工智能、區塊鏈等技術方向都是不錯的選擇，而且這些方向下面也有很多細分的方向，可以根據自身的實際情況進行選擇。
在突破代碼編寫瓶頸的過程中，應該多與技術專家進行交流，交流的過程也是學習的過程，而如果有條件讀研，通過讀研來突破代碼能力也是一個不錯的選擇。代碼編寫問題說到底就是數學問題，所以要想能夠不斷提升自身的代碼編寫能力，一定要注重數學知識的學習。
最後，自身所處的開發團隊對於程序員能否不斷突破編碼瓶頸也有比較直接的影響，所以程序員應該注重開發團隊的選擇。
我從事互聯網行業多年，目前也在帶計算機專業的研究生，主要的研究方向集中在大數據和人工智能領域，我會陸續寫一些關於互聯網技術方面的文章，感興趣的朋友可以關注我，相信一定會有所收穫。
如果有互聯網、大數據、人工智能等方面的問題，或者是考研方面的問題，都可以在評論區留言，或者私信我！
IT人劉俊明
心態上放輕鬆，瓶頸期很正常不過，其次就是堅持，過了這個瓶頸期就是進步。方法論上，我個人覺得有兩條路。一是自我主動提升，被動反饋，二是找高手請教，主動反饋。
所有的能力提升，方法都是相通的。任何技術在學會之前都感覺很難，學會之後感覺很簡單，難者不會，會者不難。在不會之前，尤其是瓶頸期，會讓很多人放棄。
觀摩別人
以我學游泳為例，蛙泳很簡單很快，一兩個月可以入門。但學自由泳時，遇到了各種瓶頸，陸陸續近一年才遊得有點樣子，終於學會呼吸。中間過程是在泳池裡各種喝水，卡在呼吸上。最終是通過觀看各種視頻，琢磨才慢慢會呼吸。
代碼能力也一樣，觀摩別人的代碼，尤其是自己領域高手的代碼，以java為例，看看openjdk的源碼，比如hashmap的設計，從數組到鏈表到紅黑樹。要去琢磨為什麼這樣設計。java的源碼，可以認為是經過千錘百煉的。
點評: 學習並思考專家的源碼，千錘百煉的代碼，值得向書法一樣反覆臨摹。
專家反饋
現在想來，可能當時請個專業教練指導下，可能游泳不會學得這麼辛苦。教練可能一眼就能發現你的問題在哪裡。
編程也一樣。把你的代碼，讓專家review下，高水平專家的反饋，再加上自己的練習，能讓你的代碼水準快速上一個階梯。能讓你少走很多彎路。
點評: 有點像深度學習，從預訓練的模型學習很快就能收斂，而從頭學可能要很久很久。預訓練的模型，就是專家的反饋。
授之以魚，不如授之以漁。希望能早日突破瓶頸，超越自我。
平凡科技
代碼能力總的來看錶現在兩個方面：代碼的設計和代碼的性能；
1.代碼的設計
小的方面講你需要遵循設計原則，以及各種設計模式；大的方面講整個系統需要合理的架構；
六大設計原則：單一原則，里氏替換原則，依賴倒置原則，接口隔離，迪米特原則，開閉原則；
設計模式：包括23種設計模式包括：單例，工廠，組合模式等等；
架構：架構要講的東西太多了，我個人覺得最重要的是根據自己的項目選擇合適的架構，沒有一種架構適用所有項目；所以這個就需要你瞭解各種組件的優缺點，比如是用rpc還是mq，用本地緩存還是分佈式緩存，用什麼數據庫，mq也有很多種該選擇哪個等等，所有的這些都需要有豐富的使用經驗，進行擇優選擇；
2.代碼的性能
小的方面講你需要了解數據結構，每種結構的使用場景；另外其實我們往往使用的是一些封裝好的數據結構，所以你需要去看源碼，瞭解其實現機制，這樣才能寫出高性能的代碼；
大的方面講如果提高整個系統的性能，比如同步轉異步，緩存機制，數據庫優化等等
最後說一點就是多去看優秀項目的源碼，會潛移默化的提升你的能力
ksfzhaohui
這還是要根據具體情況具體分析。
我們來一個個剖析問題。
第一個問題。“寫出來代碼質量不高，經常寫bug”。
先問自己一個問題：這種bug一般是源於什麼？
- 打字問題。例如莫名其妙就是會把逗號打成中文的；
- 邏輯問題。主邏輯就有問題，在算法上出錯；
- 細心問題。處理不好邊界情況，永遠都在特殊輸入上卡殼，導致多次返工。
如果是1，我想一個值得考慮的建議是：打字儘可能慢。寫代碼出現符號打錯的情況絕對是缺少訓練的表現，在多做算法題（例如LeetCode等）之餘，儘可能讓自己慢下來，就可以避免很多錯誤。
如果是2，說明自己的邏輯無法與計算機邏輯緊密貼合，有出現跳躍甚至紊亂的情況，那麼我推薦你在LeetCode上刷題練習。要使邏輯貼合倒是不需要追求什麼複雜的算法，但是一定要把“模擬法”徹底搞透。即使是再複雜的邏輯，只要它可以純靠模擬來做，你都應該能夠輕鬆應對。
對於這一點，
- 我推薦的一種學習方式是：寫代碼時，學會先寫偽代碼。偽代碼如何寫？可以參考我後面第三個問題講“註釋一團糟”時舉的例子。偽代碼和註釋有時候其實是一個東西。
- 我推薦的一種訓練方式是：使用LeetCode上中等難度的題目來刷。中等題目的難度不追求一些奇巧，但是算法邏輯又不會像簡單難度的題目那樣過分簡潔明瞭。LeetCode中等難度題庫
如果是3，說明對於邊界輸入缺乏經驗。例如0的輸入，過大過小（過多過少）的輸入等等。針對不同的問題，會有不同的邊界情況。如果是這方面有問題，我建議你可以在任何的Online Judge上閱讀它們的題解，閱讀題乾和題解中的邊界情況解析，培養自己的“邊界思考”。邊界是最能有相通之處的，廣泛閱讀之後，以後在遇到任何具體問題，你都可以條件反射問自己：“輸入特殊的…會是什麼情況？”這種自我追問源自你曾經多次在不同題目的題解中見過的邊界處理。
第二個問題。“發現有新的需求，原來的架構接口通通要重寫”。
有新的需求，為什麼架構接口需要重寫？
說明原先的設計不好。
對於這一點，我推薦你學習“設計模式”。並不是要求我們要在實際代碼開發中一定要用什麼模式，這未免太侷限和拘泥了。我們的目的是藉助模式的學習，以培養自己的設計思想。
推薦你可以購買一本書《Head First設計模式》，會從具體的業務場景切入展開設計模式，讀起來並不枯燥，講的也很清楚。
第三個問題。“註釋一團糟”。
註釋不能過於細緻，更不能過於寬泛。
我們先來講講寫註釋的目的，從目的出發，來看我們如何寫註釋。
一般人認為的寫註釋的目的：在未來給其他程序員看，或者未來給已經缺失代碼記憶的自己看，能夠迅速理解上手代碼。
我們來更具體剖析一下這個目的，我想應該是這樣的：
寫註釋的目的：在現在付出一定代價寫註釋，在未來節省更多的代價來上手代碼。
如果現在不寫註釋，未來看代碼無疑是非常辛苦的。如果寫太多，現在承受的代價又太大。正是這種權衡能力的缺失，導致你寫註釋非常痛苦、收效又不好。
那麼如何把握寫註釋的量呢？
我們真正寫代碼的時候，自己的邏輯都是從概括到具體的過程。
舉一個具體的例子。
我們有這樣一個業務需求：
- 用戶有積分制度，收藏話題可以得1分。
- 用戶每個月收藏話題獲得的積分不能超過50分。
- 用戶當月內重複收藏同一話題只能得1分。
- 用戶收藏新話題獲得積分時，系統需要對用戶發出積分變更的通知。
那麼我們寫代碼時，我們的思考過程是如何進行的？
當用戶要對話題進行收藏時，我們考慮到有如下幾個大步驟：
- 檢查用戶的當月積分是否已經達到上限
- 檢查用戶當月內是否已經收藏過這個話題
- 如果上面兩個都ok，就準備進行加分，把積分刷新到數據庫裡
- 向用戶發送積分變更通知
- 內存或磁盤裡記錄一下：該用戶當月內收藏了這個話題
- 內存或磁盤裡記錄一下：該用戶當月已經獲得的積分
每個步驟可能都會涉及到其他一些方法的調用，或者幾行代碼。
你的邏輯應該是先想到這六點，然後分別進行展開。
所以你的註釋，你的偽代碼，其實就是這六行字。
我這裡也寫了六個步驟對應的方法，但並不是說它們一定要封裝到方法裡。
在這些代碼中，可能部分你是會調用到其他方法的，可能部分你就直接寫在上面了，這都是可取的，根據具體的代碼複雜度來看即可。
但是你的註釋，應該就是這樣的六行。你的偽代碼，也應該是這樣的六行代碼。不用再細了，但是也不應該再寬泛了。
總結一句話：你寫的註釋，應該是你的整體代碼從無到有的第一步邏輯。
除非你感覺有確切需要（不寫就感覺以後真的會看不懂，而且你覺得未來真的有必要看懂這個細節），否則所有的註釋都應該遵循這樣的粒度規範。這並不過粗，也無需再細。
柴十八自媒體
提高代碼能力無怪乎多看，多聽，多寫。多看大神的開源項目源碼，看看大神是怎麼寫代碼的。多聽周圍同事的建議和思路，集思廣益。多寫代碼並不是瞎寫，要寫完後不斷優化，從不同角度寫，並測試效率。寫的再好看，效率低等於個零。比如用遞歸實現，了了幾行，但效率極低，不如用棧，雖然代碼量上去了，但效率高啊。
程序猿有話說
做任何一件事都會有瓶頸期，所謂的瓶頸期有兩個方面，一是評你個人的經驗和知識水平達到了一個水準，在一段時間內無法得到提高，這種情況你還要不斷學習創新，等積累到一定程度，即所謂的量變到質變的轉換。另一方面就是你的能力和天賦已經到最大，不是你不努力，而是先天基因已經決定。
聰聰軟件
找到行業圈子裡面牛的人學習
