想請問一下，因為剛進這個行業幾個月
所以一開始，就是看前輩之前寫的專案
並維護一個小程式，一直有一個問題困擾著我
小程式還好，幾千行的code，慢慢的就消化完了
其餘的時間就在閱讀前輩之前寫的一個專案
但是這個專案對我來說非常龐大，有上萬行之多
因為這是他之前寫的，所以已經沒再用了，拿來給我閱讀
畢竟新的專案是從這個演化過來的，多多少少有幫助
因為頭一次遇到這麼多行的程式碼，所以我都從程式開始的地方
一行一行的看，想請問我這樣閱讀code是正確的嗎?
因為感覺真的很沒效率，有時候因為太多了，看到後面
中間如果有其他事(譬如:被叫去寫一個小程式，或改改我維護程式的Bug)
，回來之後之前看得又有點忘記了，有要重新費一番功夫去理解
所以想請問新人要怎麼閱讀前輩的程式碼呢?

先看大略看一次架構，再看功能，再看功能如何實踐，由小入大會很吃力這是我個人看程式碼的方式

先知道這個系統在做什麼，每個環節都是跟業務流程相扣

先看架構理清甚麼大概會放在那, 再按Input-Process-Output的脈絡看數據在怎樣傳遞. 一般就這樣的感覺.

先用看看這東西到底幹麻用的 從功能往下猜

一個功能一個功能看~先了解該功能用途~再看code~

還可以新舊code比對，可以更深刻領會程式為什麼這樣設計

看他之前的架構寫得怎麼樣囉~寫得好的話~應該可以從大方向開始往下分~慢慢由大而小地看~寫不好就...

先看做什麼事>功能面>流程面>最後才看CODE就算不看CODE也沒差，反正你知道後可以寫的比他好

寫得好的code你應該看得懂 也可以從看code知道程式跑起來大概會怎樣看舊的..到不如看新的..

Btw, 已經沒在用的程式碼還拿給你就是想你學coding的風格啊, 否則直接拿設計文件來看不是更有效率?別說不用看code那樣的話了.

依樣畫葫蘆，實作小改程式幾次，不用多久就會了

拆解別人的作品是種感覺，拆久了再大的很快都可以拆解掉如果程式裡沒有足夠的註解，我會建議你先從加註解開始然後找到程式的Output點往回推，因為通常Output的定義都會比Input來的明確很多，從Input從下找我的經驗是不行分析出第一串流程後，就開始動手改變流程變數觀察變化最後把程式還原回原狀，包含已加的新註解都拿掉依照原程式的風格，修改需求，免得challenge到原作者天知道那個前輩是誰，說不定正是你的主管