勤於積累，理清程式架構，探尋程式內部結構

我們能夠看懂程式碼，說明我們已經掌握了程式語言的基本語句和程式的基本結構，但對於程式的內在結構卻缺乏理解。或許我們能夠編寫一些簡單的子程式，但是如何把各個子程式連成一個有機的整體我們則無法完成。說到這裡我總感覺編寫程式與我們寫作文有很多相似之處，我們有些朋友在看別人的文章時能夠看懂，甚至能夠評判所寫文章的優劣，即便如此，一但讓我們拿起筆去寫文章時，我們也會有無所適從的感覺，感覺無話可寫的局面。這種情況的的出現我認為是下面原因造成的，一是我們沒有寫作的素材；二是我們沒有寫作的技巧，對文章的架構缺乏設定的技巧；三是我們的詞彙量貧乏等等，所有這一切都表現出了我們無法寫出優質的文章來。

其次是我們沒有架構這些子程式之間關係的能力，主要是我們無法把這些子程式有機地組合，形成我們所控制的程式。比如我們要用按鍵控制一個步進電機正轉和反轉，我相信很多朋友都能寫出來。但是要讓我們用按鍵控制步進電機具體的轉動圈數，並把轉動的圈數通過數碼管顯示出來，對於初學者就感覺有些難度了，這時很多初學者無法完成了。

本人985計算機碩士研究生畢業，從事開發工作近十年，對管理沒有興趣，任職資深開發崗位，年過35歲正式失業。剛學習程式設計時也經歷過題主所說的能看懂程式碼，自己寫不出來的階段。

完全正常，不用懷疑自己的智商或者思維能力。

1、看懂別人的程式碼跟自己寫，完全不是一個概念。舉個例子，大家都能看懂語文課本上的課文，有多少人能寫出來那樣水平的文章？程式是設計者和開發者思想的表現形式而已，可以用各種程式語言書寫，最終效果沒什麼本質區別，解決的都是一樣的問題。

也就是說，編寫程式碼的過程，就是把解決問題的思路或者實現功能的設計翻譯成程式語言語句的過程。這句話有兩個要點：思路，語言。對於初學者，面臨的問題通常都是練習性的，沒有太多的複雜性，這種練習類程式需要的其實就是對程式語言的屬性而已。

程式設計其實跟講故事一樣一樣的，只不過講故事用的是中文，程式設計用的是程式語言而已。要想隨心所欲地把想法實現成程式碼，首要的必要條件就是熟悉你的語言，要做到看到別人的思路就可以用程式語言翻譯成程式的程度。

熟悉程式語言這一步做到了，下一步更加關鍵，思路，或者說解決方案。

2、只是把程式語言的幾十個關鍵字背的滾瓜爛熟，而沒有解決實際問題的經驗和思路，同樣寫不出可用的程式。

還是以講故事作為例子。把新華字典倒背如流，腦子裡沒有故事情節，是不是也講不出故事？程式設計也是同樣道理，熟悉程式語言是第一步，也僅僅是第一步。決定性的還是解決問題的思路和解決方案。

而解決問題的思路從哪裡來？對問題建模。也就是將實際的問題通過控制變數、剔除干擾項等手段，轉化為相對理想化的理論問題，也就是可以程式設計解決的理論問題模型。這種理論模型通常就那麼幾種大的型別，各自都有比較成熟的解決方案和框架。大學裡舉行的數學建模大賽，也基本上就是做這個事情。這種抽象理論問題模型的能力可以在實際的專案中逐步練習掌握，當然也可以通過下面說的捷徑較快獲得。也就是學習資料結構和演算法。

3、資料結構和演算法，本質上就是祖祖輩輩的程式設計師們總結積累下來的典型問題的理論模型和通用解決方案。或者更確切迪說，是組成典型問題的理論模型和解決方案的各種元件。靈活應用這些元件，你就可以迅速拼裝出具體問題的理論模型和解決方案，有了這個基礎，程式設計實現就順理成章了。

對初學者，資料結構和演算法可能需要較多的時間和毅力才能掌握，但是這部分內容剛好就是軟體和軟體行業的靈魂和精髓，也是程式設計師的內功所在。花大量時間和精力是完全值得的。當然，也不能急於求成，學習這部分內容需要的時間起碼是以年為單位的。邊做邊學吧。

看得懂並不代表學會了程式設計，只有能夠隨心所欲地使用程式語言表達自己的思路想法，才算是學會了程式設計。沒有思路想法怎麼辦？學習常用演算法，在專案中活學活用。堅持，耐心，最重要。

何為看懂？看程式碼的粒度不同，看懂的水平也不一樣。細粒度，所有的程式碼基本就是三種套路：順序、分支(if else)、迴圈。這個基本大家只要懂語法都看得懂但是上升到更高的粒度，這個函式實現了什麼功能？這個原始檔作用是什麼？這些原始檔作用是什麼？相信很多新手頭大。就如同盲人摸象，其實還是不懂，或者不太懂。知其然，要知其所以然。所有的底碼，都有目標。圍繞著目標，才有了架構、設計，有了設計，才有底層程式碼。建議看程式碼從頂往下看，程式碼如同一個小世界，先去看山川河流，再去看森林裡的某顆小草。不要一眼就扎到細節裡面去，即使這是一顆很重要的小草。當從整體層面瞭解後，再去追究自給關心的細節，會讓人醍醐灌頂。如何寫出程式碼？自己要明確一個目標，大到是一箇中間件，小到是一個函式功能。這些可能是業務需求、可能是技術改造，總之要有目標。只要有了目標，靠著順序、分支、迴圈三板斧，都能寫出邏輯正確的程式碼來。加上資料結構和演算法，就能寫出優秀的程式碼。當然，後者需要你的功力足夠深。

寫了6年程式碼的我，6年前也是個程式碼小白，本科時候的二級也是擦邊球才過。然而，為什麼可以逐漸成長為部門的骨幹員工，應該跟以下原因密不可分吧。

無論使用的是面向物件的程式語言還是面向過程的程式語言，只有積累了足夠的程式語言基礎理論知識，才能進一步熟練應用。舉個例子，小時候學英語單詞，看著知道什麼意思，但是默寫的時候卻總也寫不對，歸其原因只是基礎知識掌握的不夠牢固，不能為其自己所用而已。

從開始學程式設計到最後的專案實施，在我看來只是讓執行的程式碼實現預期功能而已，通俗點說就是“你想讓它幹啥、它就得幹啥”；及時是異常處理，也需要在自己的掌控範圍內。不在預期掌控範圍內的程式碼，基本上就算是出Bug了。所以，這就需要程式設計者具備一定的邏輯思維能力，並且能夠讓複雜的事件簡單化。千萬不要以為只有寫出別人看不懂的“高、大、上”的複雜程式碼才算是大神，畢竟越簡潔易懂的程式碼越高效、越不容易出邏輯問題是有一定道理的。

專案方案理解

如果您已經具備“程式設計基礎積累”和“邏輯思維培養”，那麼恭喜您，離自主程式設計不遠了。如果這時候還是沒辦法親自動手實施，那麼很大的原因可能是對專案方案理解不夠透徹，換言之就是不知道接下來自己要做什麼。這類情況的解決方式無外乎是繼續研讀專案方案或者多請教專案方案相關編寫人員。

最後總結下，程式設計呢，並不是一個一蹴而就的事情，需要大量的時間去積累、沉澱，是把曾經我們在書本上的學到、看到的知識變成自己能夠與機器進行交流的過程。同樣的，程式設計也不會一次性成功，基本沒有程式設計師能夠一次性完成一段功能性程式碼而不存在任何問題，都是需要去進一步除錯才能讓其變得更加完美，而除錯的過程也是一種對程式設計知識的迭代理解學習、對專案系統深入思考體會的過程。

所以，還沒辦法自己寫出程式碼的你，要不要從“Hello World”開始嘗試，慢慢在此基礎上增加自己想實現的功能開始呢？積累到一定程度，相信在程式設計的世界裡，你技能遲早可以遊刃有餘。

如果你能夠看懂程式碼，但就是自己寫不出來，那麼我如果沒有猜錯的話，你應該是一個新手，其實這些問題不但是你遇過，我前段時間有一個剛學完計算機語言的朋友也是出現過這類問題，我給了他一些建議，你可以參考一下：

如果你已經到了能夠看懂程式碼的時候，那就證明你已經基本懂得你所學習的那一類計算機語言的基本操作了，這個時候你再去看別人的專案或是再去看基礎教程已經沒有什麼意義了，我建議你第一步是去看一遍別人小型的專案，如何自己做一個一模一樣的專案出來。

這樣做的目的是為了讓你踏出動手的第一步，而為什麼要模仿呢？那就是因為如果你不模仿，那麼你作為一個新手剛開始做一個新專案的時候出現了bug或是到了不懂的地方，你就會發現沒有可以讓你參考的參照物，你就會進入一種迷茫的狀態，所以第一步你需要參照別人做兩個一模一樣的專案，做完後你就可以進入下一步了。

當你學會模範別人的專案後，你就要開始做一個自己的專案了，這個專案不要做這麼大，儘量做一些小型並且輕量一點的，因為這時候的你還是新手，如果做太難的東西你自己會做不出來，並且打擊你的自信心。

如果你沒有思路做什麼專案，我推薦你多逛逛貼吧或是多看看抖音之類的小視訊，在這裡面你應該可以找到靈感，儘量做一些人們經常用得上的，做出來後發在抖音或是貼吧這些交流性強的地方讓別人使用，如果有人反饋問題那就最好，因為你能夠看到自己的不足。

當你學會如何運用自己的知識進行自己做專案並且修改問題的時候，那麼你就可以上去一些接單網站上面接單了。

很多人感覺自己可以做出一個專案後，一上到接單平臺就會挑選那些中型或是大型的專案接，但是在這裡我個人是不建議的，因為你之前做的專案都是按照自己想的思路去做，因此你不一定可以百分百完成客戶的需求，所以我建議你先選擇一些小專案來做，直到認為自己可以勝任大半需求時再去選擇那些大型一點的專案。

總結：寫程式碼這一行，會看是沒有用的，關鍵還是動手，如果你不會動手那麼跟紙上談兵沒什麼區別，多動手才能讓你在工作的時候發現自己的不足並且及時改正。

我自己有過一年的程式設計學習經驗。我不知道這樣的經驗對你有沒有幫助。

我覺得你能問出這樣的問題來，應該也是剛剛入門。這個時候我覺得你看的程式碼其實都是相對比較簡單的一些。其實到後來的時候你會發現的，就是有些人寧願自己寫，也不願意去看別人寫的。因為自己寫之前已經有明確的邏輯思路和方向，但是看別人寫的，要首先了解別人的想法是什麼，然後再去嘗試著去讀。這其實是挺費時的。

就像我上面說的那樣，不管是讀程式碼也好，寫程式碼也好很重要的一個點就是邏輯思路。如果你要寫程式碼的話，那你就要有清楚的邏輯思路。知道我最終的目標是什麼，然後再把其中的幾個目標拆解，一步一步做下來。這樣就能有幫助你完成程式碼的實現。

如果是像上述所說的，在寫程式碼的整體邏輯結構上有問題。你可以嘗試著畫邏輯框圖。這個有兩個好處，第一就是有助於你去梳理你此次程式碼的實現過程。另一個好處就是在於，你下一次再去看自己的程式碼的時候也一目瞭然。坦白講自己不同時期的想法也是不一樣的，有可能一段時間之後，你再去看自己的程式碼都看不明白。這也是為什麼老師都鼓勵寫程式的時候寫邏輯框圖，讓這段程式碼的可讀性變得更高。

另一方面原因是不在於邏輯上的問題。而是在於函式使用上的一些問題。比如函式上的傳遞，方法和類的使用之類的。這些基本上就屬於熟能生巧的。就是你自己剛開始寫的時候，自己想不起來那些名字，想不起來函式傳遞的順序。這個問題在你寫的多了之後就自然解決了。而且如果你選擇一個好用的Ide的話，很多他是會有提示的。這種提示其實是生產當中非常有必要。對於剛入門的小白，一定會有這樣的一個觀念，就是我要把這些全部都背下來。但是實際情況真的就是被那些基礎的就好了，學的越多你就知道很多東西你根本就背不下來，資料量太龐大了。基本就是不管黑貓白貓，能抓到老鼠就是好貓。因此如果是這樣的問題的話，其實不必要太多糾結。多寫一寫，多練一練自然就會了。

先了解這個先，然後在怎麼學！

4.操作軟體，遊戲，工具-3.程式設計軟體-系統操作-2.晶片指令集演算法-1.01二進位制與硬體設計邏輯。

01二進位制是代表硬體設計佈局，設計成晶片指令演算法語法結構，形成作業系統，在作業系統內部製作程式設計軟體，在用程式設計軟體編寫不同軟體與遊戲！

目前我們所學校的程式設計軟體是在第三方面系統，操作軟體為第四系統，第二方面系統為編輯作業系統，第一方面系統是用半導體元件來佈局不同的模組電路圖，從電路圖中採用正玄波控制每個單元開關形成邏輯判斷思維，然後設計出計算器用於計算邏輯顯示，在用半導體佈局成語言表達為方程，那麼才算是計算機。通過這些語言法以及指令控制記憶體進行記憶體內部操作，執行記憶體就是一臺顯示器由於看不見所以要轉入訊號到顯示器，由於不同的顯示器邏輯不同所以要用晶片來轉換原始碼，才可以實現，記憶體內部通過CPU PIN腳傳送到顯示器，有的是為了更高質量顯示器顯示彩色更加逼真，就需要到顯示卡進行通過模擬進行放大電壓傳送到顯示器！

所以學習程式設計過程任意一個程式設計軟體就可以，但有的程式設計軟體製作出來的不能再安卓或IOS 內部執行，需要新的程式設計器，那麼怎麼辦？因為每個程式設計軟體都是指定一個系統，所以需要翻譯機虛擬機器執行，就可以實現任意一門程式設計語法進行程式設計。

無論是VB 還彙編，還是C ，還是JAVA 等等程式設計器，他們的邏輯思維都是一樣的，語言也是基本相同，只有編譯成第二方面指令集不同，第一方面編譯系統這是硬體設計問題，所以屬於作業系統指令集不是硬體晶片指令集，因為安卓是第二方面系統，第一方面系統只有制定晶片時候才會有，語言開發商供應指令碼，只有合作關係開發硬體商才給指令，但有法律規定不能洩露，一但洩露將斷供，硬體商為了保護自己的智慧財產權，在每個晶片內部設定序列號，只有出廠指定買家才解鎖，一但停供，你去買新的都用不了。

所以學習程式設計之前必須瞭解一下

那麼瞭解計算機了，那麼就要了解指令集，我簡單說下，指令集代表所有字母與符號，那麼就那麼多控制摁扭，這種程式設計我們永遠不會用到！一般這些只有晶片設計師才知道！

那麼利用以上邏輯摁扭，組拼成元件，元件就不用你寫了，別人已經寫好，然後你把它用起來，比如元件VOA 是什麼東西？這些你都要去翻譯過來，你不懂這個你會看程式碼有用嗎？

一看程式碼這不是我們學的代數嗎？對沒有錯是用代數來表示，但你不知道控制什麼？這就尷尬了，你得知道控制一個圖片移動，什麼時候移動停止呢？肯定要用時間控制，那麼設定好代數座標，假如如果那麼是if 假如什麼呢？

假如a +b 距離，那麼就要宣告一個標記符，不然計算機不知道a +b 是什麼鬼，畢竟是第三方面系統操作，每個程式設計內部語法不同但計算代數，所以語言不用記，你就記代數就可以！其餘不要想，越想越糊塗，用多了語言自然記得！

​

我也經歷過這麼一段過程，能看懂別人寫的程式碼，自己就是寫不出來。挺過那段艱難的歷程後，發現無外乎下面幾種情況。

一般來說，只要有一定基礎，看懂一行程式碼是非常容易的，看懂一個方法可能需要花點時間，看懂整個專案需要花更多的時間。甚至可以說，只要能把專案執行起來，通過斷點除錯能看懂絕大多數你所熟悉的程式語言寫的程式碼。

但是程式碼不是零散的，從工程的角度看，它是一個完整的整體。為了能高效而簡潔地編寫程式碼，同時兼顧可維護性、可擴充套件性，往往會引入各種框架、類庫，這些可能是陌生的。甚至有很多程式設計技巧，在初次看到別人這麼用時，覺得能看懂，但的確是沒想到還可以這樣寫。

要突破這個階段，確實需要大量的練習，看別人的程式碼，模仿其程式碼風格。書讀百遍其義自見，慢慢的，就有感覺了。

古詩有云：

熟讀唐詩三百首,不會作詩也會吟。

看懂了，記住了，領悟了，掌握別人寫程式碼的技巧，總結其中的規律，把別人的程式碼放一邊，用自己的方式寫出來，這才是真正的看懂了。

新接觸一個業務領域時，也會經歷這個過程。對背後的業務邏輯不理解，可以看懂程式碼在幹什麼事情，但是拿起鍵盤，不知道自己寫的程式碼該處於整個業務流程中的哪一環。

對業務不熟悉，也可以隨著自己對行業的理解，慢慢化解。當然，要是在學習和工作中能遇到一個熱心同事，一個好領導，這些都不是事。

看完一本書，不見得能寫出一本書。寫程式碼也是創造的過程，請不要煩惱。

這是剛開始學程式設計時會碰到的情況。

我的答案相信對你會有幫助！

如果你思考過之後連思路都沒有，可以去參考別人的程式碼，最重要的是，要學思路，而不是看程式碼具體本身。

再說一點，看程式碼的時候，不要逐字逐句的"翻譯"，而應該從整體到區域性。先從整體瞭解這個程式碼是幹什麼的，入口是哪裡，從入口那裡用到了那些方法？這些方法是為了解決什麼問題的?

先帶著這些疑問去讀，思路應該就清晰了。

虛擬碼相對於思路來說，必須結構清晰，程式碼簡單，可讀性好。

其實程式語言就是一些語法規則，最主要的還是思路問題。如果遇到不會的、印象模糊的，請立即向別人請教或查教程。然後記下這個語法規則。

這步主要是為了增加熟練度，總結和反思，看看能不能有其它思路，做到舉一反三。

經過這四步之後，你絕對可以寫出來了！

根據你描述的這種自己能看懂別人的程式碼卻自己寫不出來的情況判定你應該是剛開始接觸到程式設計這一領域。

我覺得這是每個初學者必定會經歷的一個過程。就像我們平時看那些小說名著等等一樣，我們同樣能夠看懂，但是讓我們去寫的話並不是太過現實。

對於這種情況一定不要慌亂，不要覺得自己不是做程式設計的那塊料。

結合本人自己的經驗，在學習程式設計之初，一定不能只是去看那個程式碼。

最開始可以選擇對照著例程去編寫程式碼，就算出來是一模一樣的也行，也就是抄程式碼（這點不難吧）。但是在寫的時候要去理解每一條語句的用意。

然後儘量的不去看例程，看自己能否獨立寫出一些簡單的程式碼（一些最基本的程式還是需要能夠獨立完成）

當你可以寫出一些簡單程式的時候說明已經差不多入門了

這個時候的我們可以去找一些小的專案進行一些簡單開發，去閱讀別人的程式碼，充實自己的知識。

在招聘當中有時候會提出一個程式碼量的概念，其實這個概念恰恰說明了，不能光看，得動手的問題。寫的越多，錯的越多，學到的也就越多。

多思考，多東西，養成良好的習慣！

不要慌亂，不要著急！

一步步來，順其自然的就會了！