想请问一下，因为刚进这个行业几个月
所以一开始，就是看前辈之前写的专案
并维护一个小程式，一直有一个问题困扰着我
小程式还好，几千行的code，慢慢的就消化完了
其余的时间就在阅读前辈之前写的一个专案
但是这个专案对我来说非常庞大，有上万行之多
因为这是他之前写的，所以已经没再用了，拿来给我阅读
毕竟新的专案是从这个演化过来的，多多少少有帮助
因为头一次遇到这么多行的程式码，所以我都从程式开始的地方
一行一行的看，想请问我这样阅读code是正确的吗?
因为感觉真的很没效率，有时候因为太多了，看到后面
中间如果有其他事(譬如:被叫去写一个小程式，或改改我维护程式的Bug)
，回来之后之前看得又有点忘记了，有要重新费一番功夫去理解
所以想请问新人要怎么阅读前辈的程式码呢?

先看大略看一次架构，再看功能，再看功能如何实践，由小入大会很吃力这是我个人看程式码的方式

先知道这个系统在做什么，每个环节都是跟业务流程相扣

先看架构理清什么大概会放在那, 再按Input-Process-Output的脉络看数据在怎样传递. 一般就这样的感觉.

先用看看这东西到底干麻用的 从功能往下猜

一个功能一个功能看~先了解该功能用途~再看code~

还可以新旧code比对，可以更深刻领会程式为什么这样设计

看他之前的架构写得怎么样囉~写得好的话~应该可以从大方向开始往下分~慢慢由大而小地看~写不好就...

先看做什么事>功能面>流程面>最后才看CODE就算不看CODE也没差，反正你知道后可以写的比他好

写得好的code你应该看得懂 也可以从看code知道程式跑起来大概会怎样看旧的..到不如看新的..

Btw, 已经没在用的程式码还拿给你就是想你学coding的风格啊, 否则直接拿设计文件来看不是更有效率?别说不用看code那样的话了.

依样画葫芦，实作小改程式几次，不用多久就会了

拆解别人的作品是种感觉，拆久了再大的很快都可以拆解掉如果程式里没有足够的注解，我会建议你先从加注解开始然后找到程式的Output点往回推，因为通常Output的定义都会比Input来的明确很多，从Input从下找我的经验是不行分析出第一串流程后，就开始动手改变流程变量观察变化最后把程式还原回原状，包含已加的新注解都拿掉依照原程式的风格，修改需求，免得challenge到原作者天知道那个前辈是谁，说不定正是你的主管