鵝廠內部，有一個關于“編程水平提升”的帖子，題主是這樣寫的：

我是非計算機專業出身，近一年來，發現開發相關的工作越來越多。雖然能勉強應付，但是特別害怕別人看我的代碼，覺得自己的代碼寫得很糟糕。我試圖去請教前輩，怎么才能提高編碼水平，前輩說多寫。但是我感覺多寫就一直在重復那個勉強應付的if else過程，體力搬磚，并沒有什么進步。前輩說：量變才能達到質變。請問大家有好的經驗可以借鑒么？多寫真的會量變到質變么？這個量變的過程大概需要多久？

關于這個問題，我們來聽聽鵝廠程序員們的經驗：
01 有效努力是量變引起質變的前提@Jianfei.說下個人的理解，量變到質變的前提是：做出的是有效的努力。那么什么是有效努力呢？

• 無效的努力：一年的經驗努力用了十年
• 有效的努力：遇到問題問5個以上why、深度思考、不停學習、不斷突破舒適區的邊界

只有做出了有效的努力，才能積累知識的深度和廣度，當廣度和深度達到一定程度的時候，就會發生所謂的質變，質變是什么樣的狀態呢？

• 學習新知識會很快，很多東西一看就知道技術的本質是什么樣子
• 遇到問題可以一眼看到問題的本質

那具體怎么做出有效的努力呢？給幾個小建議：

• 遇到需求不要著急寫代碼：一定要想明白為什么要寫這個代碼，這個代碼到底要解決什么問題，這個需求的實現方案有幾種?最佳方案是哪個? 怎么能優雅的來實現？腦子里能徹底想明白了這些問題，寫代碼只不過是分分鐘的事情。
• 遇到問題不要慌：解決問題的關鍵是先找到到底是誰的問題，“根因”是什么，如果不能很清晰的答上來，那就說明并沒有掌握，這時候就去查資料、學習。直到吃透為止。
• 從點開始擴展成面：當你負責的是大系統里很小的一個點時，一定要先從各種渠道去學習和理解這個系統整體，去深入理解你的上下游的架構和原理，不斷擴展，進而理解整體架構

總結起來，以下三點：

• 保持好奇心：對不懂的東西保持好奇心，并且有決心去理解和攻克
• 持之以恒：技術本身是比較枯燥的，但是解決問題的時候成就感是很好的，一直保持下去

一切都是思維：一定要學會深度思考，不要只顧埋頭干活兒，所有的問題，如果你有清晰的思路都不是問題

@Howard.這事我覺得吧，量變到質變是有的，但單純重復簡單代碼是不可能質變的。我自己水平也就一般般，班門弄斧說兩句，希望能拋磚引玉。其實計算機專業的大學課程就已經指出大概的學習方向了：1. 一般大一學C語言，大概掌握面向過程的程序設計思路。大多數非科班工科專業的計算機課程基本都停留在這階段，無論用多少年MATLAB也不會改觀（我用了8年matlab，我現在天天黑）。大多數腳本語言也都是這樣，按照順序把思路寫下來，讓計算機一步一步執行。2. 理解OOP（面向對象編程）是水平提升的一大飛躍。掌握繼承、多態、封裝之后是一個aha moment，原來代碼還能這么寫，真牛X！現在大多數的大型系統基本都是基于OOP思想設計的，OOP是你掌握編程和控制系統復雜度的一個利器。3. 學會算法與數據結構，也是代碼提升的一大步。當你像洋蔥一樣撥開數據結構的層層外殼時，你對編程的理解就進入了一個新的階段。什么時候用鏈表、什么時候用順序表、什么時候用圖、什么時候用樹。什么是B數、B+樹、紅黑樹？為什么數據庫要用B+樹，為什么有些場景要用紅黑樹。4. 學會操作系統原理，也是代碼提升的一大步。當程序設計到一定階段，想要繼續提升和優化，你就必須要深挖程序所在的平臺 - 操作系統了。明白操作系統底層的運作機理，你才會明白，如何調度程序能夠讓代碼更高效，如何并行、如何多進程，如何多線程。5. 當然再往下深挖編譯器和計算機組成原理（壓榨CPU性能、壓榨GPU性能等），依然有很大的代碼提升空間，但對大多數人用處不大了。一般都是交給專業人員來深入優化。02 量變引起質變，需要找準標準+刻意練習@Zale.個人深知自己能力及知識都存在很大局限性，僅嘗試分享同為非計算專業畢業生當前認知中的理解，如有不同見解歡迎溝通和補充。【結論】1、量變不一定會引起質變，而1萬小時+刻意練習能極大程度上促進質變的形成
PS：為方便梳理，下面主要將量變等價于1萬小時，質變等價為領域專家，質變的嘗試界定詳見基礎知識的PS2。
2、無論如何，不要因為現在忙而放下學習和成長，視野和能力的提升會幫助你更好、更高效的解決問題。【基礎知識】一、量變與質變一萬小時定律起源于《異類》，指“人們眼中的天才之所以卓越非凡，并非天資超人一等，而是付出了持續不斷的努力”，并提出1萬小時是任何人從平凡變成世界級大師的必要條件（注意，只是必要條件）。《刻意練習》對一萬小時定律進行了補充，即1萬小時+刻意練習能幫你更大概率的達到專家水平（注意，會極大程度上促進你成為專家的概率）新增的刻意練習主要是指通過不斷重復，將學習區的內容拉取舒適區，主要涉及以下內容：0、找準標準：有合理發展的領域或行業、能引導你的導師。主要作用是明確標準，從而引領你刻意練習的方向。1、大量重復的訓練：從不會到會，秘訣就是重復。在熟悉之后就跨越舒適區，不斷再將學習區中高難度的事件重復并嘗試將其納入舒適區。2、持續獲得有效的反饋：反思、總結、改進3、精神高度集中：獨立思考和獨立練習（可引申至深度工作）總結一下核心就是：直面問題，明確標準，獨立思考，持續行動，不斷走出舒適區。
PS1：遇到恐慌區的事情怎么辦？計算機領域中有兩個重要概念分解和等價，遇到恐慌區的事務，將其分解為多個學習區和舒適區內容的總和，保證整體等價，即A（做不了）= B（可以做）+ C（可以做）+ D（可以做） + ... + Z（可以做）。PS2：如何界定質變/專家？這里的界定可能比較模糊，每個人心中的標準可能不太一致。但你既然提出了這個問題，更大概率是跟高水平框架設計、優雅的實現及公司/業界的專家相掛鉤。
如果是指這些，他們在領域專業程度和貢獻上都會有比較高的積累，也許我們短期很難達到。可以嘗試換個角度思考，一方面，我們可以通過學習逐步成為領域內的組內專家、部門專家、公司專家、業界專家；另一方面，我們可以將看問題的視角從外部轉向內部，減少外界身份或標簽的界定，更多地關注自身的每一次成長，關注每一次實現是否能有更好的解決方案，關注技術所產生的價值和成就感。這樣會讓我們更快樂、更快速的成長，更大概率的觸發專家的質變。二、稀缺與體系化稀缺在《稀缺：我們是如何陷入貧窮和忙碌的》中定義為：“擁有”少于“需要”的感覺：

書中結論一：稀缺容易觸發管窺書中結論二：稀缺會進一步延續并加劇稀缺

優化方案：跳出當前"管窺"場景和視野，站在更長遠的角度去思考問題。管窺：專注于某一件事物就意味著我們會忽略其他事物，也叫“隧道視野”。就像視野被局限在一個管子中，那些存在于“管子”視野之外的事務就被抑制了。

為什么忽然會提到稀缺？是希望能對提問中“開發工作邏輯簡單、很多東西不懂”這里有所幫助。在完成需求的情況下，你可以跳出你原本的開發內容，去自由的了解更多你想知道的東西。可以感受到你希望自己能夠快速成長的心情，那可以站在讓自己快速成長的角度，更體系化、更全面的去了解技術、項目甚至領域，這對你的未來工作和發展也會很有幫助。比如去了解文章中描述的配置、存放目錄甚至是項目技術選型、框架設計等等內容，當然這需要你主動花費時間。【回到編程領域】一、找準標準：從整體到局部

了解學科發展：計算機行業已經發展幾十年，各個領域都有自身的體系架構，可以參考學習。
PS：能讓我們更清楚的了解到自己所在的領域歷史發展，當前處于什么階段，當前需要什么，以后會要往哪個方向發展，我們需要做什么準備。

站在巨人的肩膀上：領域經典書籍、領域前沿技術、領域成熟開源項目的代碼都有非常大的參考學習價值的。
PS：能幫助我們完善領域知識體系、框架設計、代碼風格等很多內容。

基礎知識：語言、數據結構、算法、設計模式、操作系統、計算機組成原理
PS：能讓我們在遇到問題的時候，了解有哪些方法可用，如何更便捷、更高效，更普適實現。

個人實際編程：技術是由場景和需求推動的，在自己所處的領域、場景和需求中嘗試做到最好。
PS：能讓我們將上述學習到的所有內容進行實際的落地和嘗試。

二、刻意練習：從局部到整體

優化原有代碼：自己寫的代碼能否嘗試優化，抽象，封裝，甚至開源協同推廣給其他人。

業務需求：新的業務需求是否有用更優的方案實現，是否可以花更多時間去仔細研究。

開源協同：參與到內外部開源協同中，接觸更多的優秀代碼，接觸更多的業務場景和需求，詳情可見技術圖譜。

不斷成長：不斷穩固基礎，不斷在上述3項中成長，不斷吸取領域前沿知識并反思落地，相關成長還可以分享到技術論壇。

03 編程水平的提升是解決問題能力的提升@Liquan.樓主提問的真實內涵是為了提高自己的編程水平，那大多數人都會建議多寫一寫代碼，量變才會有質變。這里就要看看“量”變的量到底是代碼量的積累還是其他，這里結合自身的一些經驗談談：編程水平的提升，不僅僅是代碼量的提升，歸根結底是解決問題的綜合能力的提升。分享一下我大學的編程故事：大學的時候參與過一些軟件開發項目（C語言、網絡協議實現），當時是一行代碼10塊錢（大括號也算一行），也就是說，像一般的學生來做，寫個1-2千行代碼，其實創造的收入也會有幾萬塊，現在想想依然還是會興奮的搓搓小手，當然前提是代碼質量和功能均能夠通過評審；當時因為是和傳統軟件廠商合作，所以項目都是嚴格的遵守項目流程的，采用的流程是V模型，大概會經歷這幾個階段：在這個流程下，前期的需求分析，概要設計和詳細設計大概會占到2個多月，后期的單元測試，集成測試等也會占到2個多月，實際代碼開發的時間一般不到1個月，所以真正編碼的時間可能僅占整個項目的不到20%左右的時間。項目前期的需求分析、拆解以及概要設計一般是項目經理（公司的資深經理）帶著幾個項目骨干完成，詳細的流程圖、設計圖和文檔等，作為菜鳥一般就繼續結合相關業務知識完成詳細設計和編碼，以及后面的功能驗收等；所以說編程能力僅僅是編碼實現嗎？至少從這個流程中看，對業務知識的理解、詳細的設計等系統性的思考會比編碼占據多的多的時間。所以編程水平絕不僅僅只是把代碼寫好了，它是一個系統工程，歸根結底還是高質量、高效地解決實際業務問題。編程水平的提升過程，在我看來應該是這樣一個過程：1、能夠把簡單的業務需求轉變成代碼邏輯，并能夠高效的完成；
2、針對小型的項目能夠將業務的實際問題拆解成詳細的需求，能夠完成整體方案的設計和選型；
3、再往上就是能夠完成較大項目的設計，能夠設計多種方案，并且明白所有方案的優缺點以及當前業界方案的優缺點來選擇最優，能夠根據實際問題突破關鍵性難點，取得原創性的成果，最終達到系統的最優。所以對于我們來說一般做到第1.2 層面也許就夠了，可以：1、多寫代碼，多總結思考，參考編程規范，寫出高質量的代碼2、將一些常用模塊抽象成庫，盡量的復用已有模塊；3、熟悉常見的一些設計模式，并基于此解決項目中實際的問題；4、了解業界同行在相同項目上的方案，并知道優缺點。