{技术}{讨论}您是如何阅读大型代码的？
谢铸聪
jinq...@163.com
谢铸聪 写道:
> 从大学时代的看小型的面向过程的代码，到现在工作时看的大型的面向对象的代
> 码，感觉很难看懂，效率也很低，不知道各位高手是如何阅读大型代码的，有没有
> 什么技巧，或者遵循什么样的原则？
> 个人喜欢看东西从底层看起，也就是每看到一个类的引用，就会去翻一下这个类是
> 干嘛的，但是真正开发时，引擎是封装起来的，有很多底层的类都是看不到的，这
> 样就总是感觉看代码老是看不懂，因为很多东西都是看不到的，不知道大家如何解
> 决这个问题。
> 问题浅陋之处，还请多多包涵，首次发帖，不胜惶恐。
Alan Gao
这个过程需要经验的积累。。刚开始会比较难，后来会越顺手。
--
Alan Gao
SOFTWARE ENGINEER
-----
Java User, Ubuntu Lover, Open Source Supporter
public class LunchBox @ http://cgaolei.javaeye.com
supern lee
Michael
如果你是设计者你应该怎么去设计？比如要你来设计3D游戏引擎？站在设计者的角度，用设计者的思维去多考虑问题。
sagasw
另外，我个人的建议是感兴趣那个部分去读哪个部分，然后做适当的外延。
代码阅读能力跟看书学习一样，熟能生巧。
对于一些开源项目，可以参考他们的设计文档或者前人做的研究。
现在出了不少读linux、python、apache代码的书，可以作个参考。
机械唯物主义
Weiming Yin
过程中最好是能够把代码运行起来，并且自己打印出来一些信息，这样很容易理清脉络。
然后结合一些工具，（我个人使用 emacs etags）这样能够快速的定位代码。
在一些地方，囫囵吞枣的过去，只要知道这部分（大致）是干什么的就可以，甚至是猜也好。
在一些地方，比如面向对象中的多态的地方，或者一些按照条件dispatch的地方，就需要研读，然后延伸到对应的数据结构，等等，这样容易明白设计的一些思路。
2009/7/24 sagasw <sag...@gmail.com>:
--
Weiming Yin
Tiny fool
--
--------------
Gmail: tiny...@gmail.com
Gtalk: tiny...@gmail.com
Phone: 13520711089
Twitter:http://twitter.com/tinyfool
银杏泰克科技有限公司-专业的站内搜索引擎提供商
http://www.ginkgotek.com/
Tinyfool的开发日记
http://www.tinydust.net/prog/diary/diary.htm
TV的Google观察
http://www.tinydust.net/tinygoogle/
@@
Tiny fool
Kenny Yuan
太大的代码（以GB为单位的）是不可能掌握的，修改的版本变得多起来之后，文档也多半失去了意义，在此时，规范和结构就显得无比重要（这个话题很大，在这里就不多说了）
我知道某公司的某一个产品，它的CC一共有0.42TB，在这种情况下，许多熟悉的问题都变得开始陌生起来。
我这方面比较差，很难掌握太大的代码，还需要学习。我本来有计划移植wesnoth到iPhone的，就是wesnoth的代码看着实在太累，暂时搁浅。
--
Kenny Yuan
C++, UI, LISP, MMA, Psychology and Automobile.
BLOG: CS巴别塔(Computer Science Babel)
URL1: http://csbabel.wordpress.com/
URL2: http://blog.csdn.net/yuankaining/
qiaojie
赞一个！说实话不容易，有些人习惯于靠想像说出一些貌似有道理的经验的东西，结果只能误导别人
太大的代码（以GB为单位的）是不可能掌握的，修改的版本变得多起来之后，文档也多半失去了意义，在此时，规范和结构就显得无比重要（这个话题很大，在这里就不多说了）
我知道某公司的某一个产品，它的CC一共有0.42TB，在这种情况下，许多熟悉的问题都变得开始陌生起来。
机械唯物主义
或者包含了一些中间代码，object文件？
On Jul 24, 2:23 pm, qiaojie <qiao...@gmail.com> wrote:
> 2009/7/24 Kenny Yuan <yuankain...@gmail.com>
>
> > 赞一个！说实话不容易，有些人习惯于靠想像说出一些貌似有道理的经验的东西，结果只能误导别人
>
> > 太大的代码（以GB为单位的）是不可能掌握的，修改的版本变得多起来之后，文档也多半失去了意义，在此时，规范和结构就显得无比重要（这个话题很大，在这里就不多说了）
>
> > 我知道某公司的某一个产品，它的CC一共有0.42TB，在这种情况下，许多熟悉的问题都变得开始陌生起来。
>
> 老兄吹牛打打草稿吧。042TB相当于130亿行代码，以平均每人年产5w行代码计算，130亿行代码要26w人年，就算10000人的超大规模软件开发团队最快也要写26年才能完成。windows上所有的软件的代码行加起来估计也没有130亿行。
>
>
>
> > 2009/7/24 Tiny fool <tinyf...@gmail.com>
XiongJia Le
Capt John
翁翊成
qiaojie
Tiny fool
Mikster.Z
--
EX - EMBEDDED SYSTEM DEVELOPER
SOFTWARE ENGINEER
Name : Mikster
Corp: NokiaSiemensNetwork
Kenny Yuan
在CC的view里统计结果就是0.42T，有i18n的文件，也有编译工具，还有第三方工具，等等
其中，主要的源代码部分（仅仅CPP和H文件，以及一些相关的SCRIPT和MAKEFILE），也有几十GB
其它地方的源代码不好按文件夹隔离，所以没有去数（在根目录进行find|xargs在这里基本上属于不可能完成之任务，要论天为单位来跑的）
超出个人想像力的东西很难一下子接受的，要经历过才能明白
Kenny Yuan
Linker
2009/7/24 谢铸聪 <zhuco...@gmail.com>:
> 从大学时代的看小型的面向过程的代码，到现在工作时看的大型的面向对象的代码，感觉很难看懂，效率也很低，不知道各位高手是如何阅读大型代码的，有没有什么技巧，或者遵循什么样的原则？
> 个人喜欢看东西从底层看起，也就是每看到一个类的引用，就会去翻一下这个类是干嘛的，但是真正开发时，引擎是封装起来的，有很多底层的类都是看不到的，这样就总是感觉看代码老是看不懂，因为很多东西都是看不到的，不知道大家如何解决这个问题。
> 问题浅陋之处，还请多多包涵，首次发帖，不胜惶恐。
--
Regards,
Linker Lin
linker...@gmail.com
刘金雨
从入口开始，看其初始化过程，可以基本上把握其内部的各类数据结构以及其之间的关系。
初始化过程之后，如果是面向过程的代码，就找其主体逻辑；如果是事件驱动的，就找其事件分发部分的代码。
最怕的是看面向接口编程的带有动态特性的代码，一大堆的接口和ioc，有的时候不用调试方式跑起来看内存根本就不知道具体实例对应的是哪个类。
整个过程由于入口到真正核心部分代码的分支可能会有很多，所以这是一个不断地探路、回溯的过程。推荐用一段大块、整段的时间去看代码，这样不至于下回看
的时候就忘记了。
Linker
Fei Yan
有些印度人喜欢把一些垃圾的代码放在ｖｏｂ里边，可能那一坨东西从来不会被某个实际的ｖｉｅｗ包进去。
我曾经见过某人把几个tgz的包放在里边，然后makefile直接跳过了。
貌似ＣＣ的确浪费空间啊，我们公司的两台ｖｏｂ服务器经常爆掉的。
IBM搞出来这么臃肿的东西也不容易啊！
Kenny Yuan
不过我们这里倒是不会出这种事，ENGR只能在PB上做，MAIN和INT类的BRANCH都是由RELEASE的人做的，所有的更改都要先APPROVE才能进INT，多余的东西没机会进去的。某一个VIEW中想要用什么CONF SPEC也是要按规矩来的，和RELEASE的对不上号就会被REJECT。
其实这么大的源码听起来不可能，但稍稍研究之后就会感觉一点也不奇怪，因为几百K甚至几MB的CPP文件多得数不胜数，文件总量也相当地大，我在某个不算太深的目录下，递归地列了一下文件名，结果重定向的文本文件有将近40MB
ning
jrckkyy
qiaojie
Thomas Iverson
> 我本来有计划移植wesnoth到iPhone的，就是wesnoth的代码看着实在太累，暂时搁浅。
wesnoth是好游戏阿...
--
http://ghosTunix.org
Keep It Simple Stupid
谢铸聪
不是看不懂，是很难看懂，其实这世上应该没有什么是绝对不行的，只有难和容易之分。经过大家的讨论后，我发现思路清晰了，也知道应该如何看
了，今天看了一天总算是能够体会了，也能够试着去改了。
在这里总结下我从大家学到的地方，大家说得很有道理，我也就不再做进一步的总结了，就以大家的名义来分点，呵呵。：
1.jinq0123,supern lee——规范写代码，通过名称来了解类、变量、方法的含义。
2.Alan GAO——通过画UML图，了解软件结构。
3.云端孤鹜——通过类提供的接口，判断其是否重要，进而深入了解。
4.Michael——站在模块功能设计的角度上来了解，具体类里面先看私有变量，然后看接口。
5.sagasw——有本书叫code reading.找感兴趣的部分去读，然后外延，熟能生巧。读别人的设计文档或者看那些读代码的书。
6.机械唯物主义——逐个击破。
7.Weiming Yin——(看法和我类似)根据软件的运行逻辑，从main开始看，不断延伸，通过打印信息跟踪观察，利用优秀编辑工具能够快速阅读代码。有些地方自己思考后发现没有难度，可以粗略过，如果有些地方设计到多态或者分支，则需要研读，并延伸到它的数据结构。
8.Tiny fool——勇敢的移植代码学习者。
9.Kenny Yuan——规范和结构显得无比重要，大工程是无法掌握的。
10.Linker——看不懂代码的地方最好走人。（我相信你这么说是认为我们公司缺乏代码规范，不适合发展，其实也不是，就算公司再规范，也不是说就可以轻易看懂代码的。还是要感谢你的关心，不过我会继续坚持下去的。）
相信一个人站在的高度，保持的视觉，都是源于此人所读写过的代码量的，呵呵，所以讲得实在的和讲得意味深长的，都是非常有价值的。
谢铸聪
huan yi
--
Huan Yi @ HUST
http://security.byhh.net
Huazhong University of Science and Technology(HUST)
Kenny Yuan
不要太执着于你的那个估算，我从一开始就说了，0.42T中不都是源码，只是统计了CC的VIEW中所有文件的大小，这个操作就统计了10多个小时（CC服务器太慢）
关于这个问题我就说这么些，再有疑问我也不负责回答了，反正你也不会相信的，每次打消你1个疑问你就会再瞎猜10个出来（甚至包括“是代码而不是数据？”这样天真的问题），还是那句话，等你碰到了这样的大坨之后，就能体会了
想起来一个可以类比的例子：做单用户系统的人很难理解高并发编程中的种种注意事项……
qiaojie
Kenny Yuan
己所不欲，勿施于人
Shuo Chen
嗯，如果接口的实现还是通过配置文件来指定的，就更头疼了。解耦也是双刃剑，提高了可测试性，降低了可理解性。
qiaojie
Tiny fool
嗯，如果接口的实现还是通过配置文件来指定的，就更头疼了。解耦也是双刃剑，提高了可测试性，降低了可理解性。
张慧聪
你既然放卫星，我当然可以进行质疑。你要想证明自己没有吹牛，就拿出数据和事实来证明，用一句“没见过就很难理解”算什么东西？你若是不愿意证明，那我也只能认为你在吹牛装B了。
另外，请把无关引文删除，谢谢
Kenny Yuan
原先一般碰上这种人一般都是不理的，这次是想尽可能地在不违反policy的情况下多说明一下情况（公司严令禁止的），结果碰上了一个小屁孩儿，手里拿着一个马列主义手电筒，只会照别人，从来不照自己——道理都被他一个人占尽了，怎么说都是他自己“常有理”——碰上这种事，我不免口气也有些不好，因为大家发言时都客客气气的，但冒出来这么一个搅屎棍，难免会比较厌恶。如果在平时碰到这种人的话，我早就left hook - right uppercut给丫揍趴下了（碰上不讲理的，我会比他更不讲理）……靠，幸亏这个社会现在还不是这种小屁孩儿支撑着的
牢骚发得有点多，就此打住，这个话题不回了。
qiaojie
On 7/25/09, Kenny Yuan <yuank...@gmail.com> wrote:
> 我倒是一直没想吵。我最烦在网上吵架了，一点技术含量也没有，10年前就不在网上吵架了，呵呵
>
> 原先一般碰上这种人一般都是不理的，这次是想尽可能地在不违反policy的情况下多说明一下情况（公司严令禁止的），结果碰上了一个小屁孩儿，手里拿着一个马列主义手电筒，只会照别人，从来不照自己——道理都被他一个人占尽了，怎么说都是他自己“常有理”——碰上这种事，我不免口气也有些不好，因为大家发言时都客客气气的，但冒出来这么一个搅屎棍，难免会比较厌恶。如果在平时碰到这种人的话，我早就left
> hook - right uppercut给丫揍趴下了（碰上不讲理的，我会比他更不讲理）……靠，幸亏这个社会现在还不是这种小屁孩儿支撑着的
>
> 牢骚发得有点多，就此打住，这个话题不回了。
>
> 2009/7/25 Tiny fool <tiny...@gmail.com>
>
>> 好了，大家都别吵了
>> > 最怕的是看面向接口编程的带有动态特性的代码，一大堆的接口和ioc，有的时候不用调试方式跑起来看内存根本就不知道具体实例对应的是哪个类。
>>
>> 嗯，如果接口的实现还是通过配置文件来指定的，就更头疼了。解耦也是双刃剑，提高了可测试性，降低了可理解性。
>>
>> 多点上面这样的讨论和思考不好么？
>>
>>
>> 2009/7/25 qiaojie <qia...@gmail.com>
>>
>>> 你既然放卫星，我当然可以进行质疑。你要想证明自己没有吹牛，就拿出数据和事实来证明，用一句“没见过就很难理解”算什么东西？你若是不
肖海彤
你的帖子态度过于主观, 而且带有攻击性.
On Jul 25, 4:52 pm, qiaojie <qiao...@gmail.com> wrote:
> 你既然放卫星，我当然可以进行质疑。你要想证明自己没有吹牛，就拿出数据和事实来证明，用一句"没见过就很难理解"算什么东西？你若是不
> 愿意证明，那我也只能认为你在吹牛装B了。
qiaojie
>太大的代码（以GB为单位的）是不可能掌握的，修改的版本变得多起来之后，文档也多半失去了意义，在此时，规范和结构就显得无比重要（这个话题很大，在这里就不多说了）
>我知道某公司的某一个产品，它的CC一共有0.42TB，在这种情况下，许多熟悉的问题都变得开始陌生起来。
Tiny fool
Samuel Ji
这里我可以给你解释一下。第一个帖子里kenny说“CC一共有0.42TB” ，这里我理解错误，把CC当成是C代码的缩写，根据简单的数据推算，显然不可能存在0.42TB代码量的单个软件产品，所以我说他在吹牛，这里其实是有些误会。之后我了解了0.42TB是ClearCase的VIEW中所有文件的大小，我对大型项目的开发也很有兴趣，只是想多了解一下具体的细节，比如代码量，投入人力和时间，以及如何进行管理和任务的分配等等，所以就追问了下去，态度虽然不是什么虚心请教，但也没有故
谢铸聪
Linker
--
Sent from my mobile device
Regards,
Linker Lin
linker...@gmail.com
Zoom.Quiet
--
http://zoomquiet.org 人生苦短,Pythonic!-)
一个人如果力求完善自己,就会看到:为此也必须同时完善他人. 一个人如果不关心别人的完善,自己便不可能完善!
Zoom.Quiet
> 那些大文件的确是代码，而且还是核心代码，另外，归我负责的那一大坨中，也有好几个将近1MB的CPP文件，别问我为什么那么大，我见到它们的时候就已经是这样了
>
>
> 想起来一个可以类比的例子：做单用户系统的人很难理解高并发编程中的种种注意事项……
>
> 2009/7/24 qiaojie <qia...@gmail.com>
>>
>> 你确定那些几兆的CPP都是代码而不是数据？是手工写的而不是工具自动生成的？你最好再仔细 统计一下代码行数
在一个没有 code review 没有版本控制 没有配置管理 等等，没有一切软件工程所建议的控制机制的团队中，人工代码的增长速度，甚至于可以高过数据的！
因为，所有人都在不断的无视即有代码，自个儿重新写相似的功能模块，
甚至这模块的前一版本就是自个儿写的！
--
http://zoomquiet.org 人生苦短,Pythonic!-)
流程是对先前蠢行的内在反应! ~ Clay Shirky
James liu
看架构我不会uml，但是会了解其先后关系图，，c++，一般细看.h。。。cpp通常是扫，除非有其他需求（比如copy段code自己用）
--
regards
j.L ( I live in Shanghai, China)
showgood
1. 如果没有任何文档，画一些类图，这样可以看出类之间的关系，比如包含关系，继承关系，依赖关系
2. 弄清楚一下关键类的创建关系，比如谁创建谁，什么时候创建
3. sequence diagram对弄清楚某个业务逻辑很有帮助
4. 多线程程序的话，看看软件运行时有些什么线程，线程之间的关系和各自的作用
On Jul 24, 1:19 pm, Tiny fool <tinyf...@gmail.com> wrote:
> 操作我觉得问题不大，应该能解决，但是从头做，我觉得太累，移植貌似也太累，犹豫中...
>
> 2009/7/24 @@ <ask...@gmail.com>
>
>
>
> > wesnoth 能完全靠触摸屏搞定吗？玩的时候用很多键啊
>
> > 不过非常期待这样一款游戏能到移动平台上
>
> > 2009/7/24 Tiny fool <tinyf...@gmail.com>
>
> > 我这方面比较差，很难掌握太大的代码，还需要学习。
> >> 我本来有计划移植wesnoth到iPhone的，就是wesnoth的代码看着实在太累，暂时搁浅。
>
> >> 2009/7/24 Weiming Yin <yinweim...@gmail.com>
>
> >> 我个人系统从main作为入口，开始不断的延伸。
> >>> 过程中最好是能够把代码运行起来，并且自己打印出来一些信息，这样很容易理清脉络。
> >>> 然后结合一些工具，（我个人使用 emacs etags）这样能够快速的定位代码。
>
> >>> 在一些地方，囫囵吞枣的过去，只要知道这部分（大致）是干什么的就可以，甚至是猜也好。
>
> >>> 在一些地方，比如面向对象中的多态的地方，或者一些按照条件dispatch的地方，就需要研读，然后延伸到对应的数据结构，等等，这样容易明白设计的一些思路。
>
> >>> 2009/7/24 sagasw <sag...@gmail.com>:
> >>> > 有本书叫做code reading。
>
> >>> > 另外，我个人的建议是感兴趣那个部分去读哪个部分，然后做适当的外延。
> >>> > 代码阅读能力跟看书学习一样，熟能生巧。
>
> >>> > 对于一些开源项目，可以参考他们的设计文档或者前人做的研究。
> >>> > 现在出了不少读linux、python、apache代码的书，可以作个参考。
>
> >>> > 2009/7/24 Michael <zhonglia...@gmail.com>
>
> >>> >> 我说说我个人的方法吧，大家轻拍！
> >>> >> 1，先考虑一个模块
> >>> >> a，打开class view，根据class name
> >>> 来判断这个类的功能。在心里对每一个类功能，已经类之间的相互关系有一个底。
> >>> >> 想想如果你是这模块的设计者，你应该怎么去设计？一般来说，有经验的程序员代码都会按照MVC模式去设计代码，
> >>> >> 并且每一个类的功能都会非常简洁。
> >>> >> b，读class，先看私有变量，一个class中哪些数据，这是一个class的核心，大部分操作都是相对数据来操作的。
> >>> >> 然后看接口。
>
> >>> >> 2，模块之间耦合
> >>> >> 如果你是设计者你应该怎么去设计？比如要你来设计3D游戏引擎？站在设计者的角度，用设计者的思维去多考虑问题。
> >>> >> 2009/7/24 jinq0...@163.com <jinq0...@163.com>
>
> >>> >>> 靠猜。如果猜不出来或猜错,那是代码的错。
>
> >>> >>> 谢铸聪 写道:
> >>> >>> > 从大学时代的看小型的面向过程的代码，到现在工作时看的大型的面向对象的代
> >>> >>> > 码，感觉很难看懂，效率也很低，不知道各位高手是如何阅读大型代码的，有没有
> >>> >>> > 什么技巧，或者遵循什么样的原则？
> >>> >>> > 个人喜欢看东西从底层看起，也就是每看到一个类的引用，就会去翻一下这个类是
> >>> >>> > 干嘛的，但是真正开发时，引擎是封装起来的，有很多底层的类都是看不到的，这
> >>> >>> > 样就总是感觉看代码老是看不懂，因为很多东西都是看不到的，不知道大家如何解
> >>> >>> > 决这个问题。
> >>> >>> > 问题浅陋之处，还请多多包涵，首次发帖，不胜惶恐。
>
> >>> --
> >>> Weiming Yin
>
> >> --
> >> --------------
> >> Gmail: tinyf...@gmail.com
> >> Gtalk: tinyf...@gmail.com
> >> Phone: 13520711089
> >> Twitter:http://twitter.com/tinyfool
>
> >> 银杏泰克科技有限公司-专业的站内搜索引擎提供商
> >>http://www.ginkgotek.com/
>
> >> Tinyfool的开发日记
> >>http://www.tinydust.net/prog/diary/diary.htm
>
> >> TV的Google观察
> >>http://www.tinydust.net/tinygoogle/
>
> --
> --------------
> Gmail: tinyf...@gmail.com
> Gtalk: tinyf...@gmail.com
Zhang Jiejing
有了切入点以后， 利用看代码工具， 我使用 cscope＋emacs 来找到各个类之间的引用关系，有时候看不懂这个类的意思， 可以看看其他用这
个类的地方是怎么用的。
不过这都是微观层面的看代码， 有时候你需要一些指导性文档，比如代码树是怎么布置的，那些模块大概使用来干什么的。
On 7月24日, 上午9时40分, 谢铸聪 <zhucong...@gmail.com> wrote:
> 从大学时代的看小型的面向过程的代码，到现在工作时看的大型的面向对象的代码，感觉很难看懂，效率也很低，不知道各位高手是如何阅读大型代码的，有没有什么技巧，或者遵循什么样的原则？
> 个人喜欢看东西从底层看起，也就是每看到一个类的引用，就会去翻一下这个类是干嘛的，但是真正开发时，引擎是封装起来的，有很多底层的类都是看不到的，这样就总是感觉看代码老是看不懂，因为很多东西都是看不到的，不知道大家如何解决这个问题。
你说这个看不到源代码就可能要看这个引擎的文档，还有一些其他地方的用法。
> 问题浅陋之处，还请多多包涵，首次发帖，不胜惶恐。
这仅仅是我的个人经验。
tommy xiao
我也喜欢读代码，我的经验也是从一个同事那里得到的灵感，也一直在用。
1.代码场景是Java,直接找test。从test入手，学习一些“所谓”的技巧。然后有了感觉以后再一块一块module处理。
2.C++这一块，就没有可操作的经验了，希望有更多的经验分享。
我想模仿对方，作一些功能上的demo，拿其它的代码直接来构造这些demo应该可以学习到一些。
3.多使用GG作search，看看别人是怎么分析代码的。
从大学时代的看小型的面向过程的代码，到现在工作时看的大型的面向对象的代码，感觉很难看懂，效率也很低，不知道各位高手是如何阅读大型代码的，有没有什么技巧，或者遵循什么样的原则？个人喜欢看东西从底层看起，也就是每看到一个类的引用，就会去翻一下这个类是干嘛的，但是真正开发时，引擎是封装起来的，有很多底层的类都是看不到的，这样就总是感觉看代码老是看不懂，因为很多东西都是看不到的，不知道大家如何解决这个问题。
问题浅陋之处，还请多多包涵，首次发帖，不胜惶恐。
--
tommy xiao
谢铸聪
sagasw
比如我看书，会看作者出版社，看看目录，然后选择是精读还是泛读，
是躺着或如厕读，还是坐着加笔记本的读。
读代码也是如此。好的代码是由有声誉的作者、软件组织产生的。有的代码值得精读，有的只适合泛泛掠过。
翁翊成
读代码就跟读书一样，你读书习惯是什么样，读代码也是一样。
比如我看书，会看作者出版社，看看目录，然后选择是精读还是泛读，
是躺着或如厕读，还是坐着加笔记本的读。
读代码也是如此。好的代码是由有声誉的作者、软件组织产生的。有的代码值得精读，有的只适合泛泛掠过。
翁翊成
在那堆充满着类似
if ()
{
if()
{
if()
{
....
的逻辑处理，
n多的无用变量，
对程序运行状态对象的随意改变，
导致n多的bug，程序的功能可以说基本上没实现。
痛苦啊痛苦。
jinhu wang
张学成
所以说同样是代码, 有些事关键性的, 有些是可以忽略的,那么这种思路不知是否可行:
在读代码之前,先搞清楚它的设计者是要达到一个怎样的目的, 然后去研究一下相关的资料, 这类问题都需要考虑哪些可能出现的情况, 再搜索一下作者有没有这方面的文档, 记录了他开发过程中的思考, 最后自己能大概理出一个框架, 如果我写一个这样的软件的话,会有哪几个模块, 大概实现哪些功能, 基本胸有成竹之后, 恐怕无需关注太多代码的细节, 整个工程都提纲挈领了.
不过真要是几千万行的代码, 您一个人去读, 就算读懂了又能怎样呢....
从大学时代的看小型的面向过程的代码，到现在工作时看的大型的面向对象的代码，感觉很难看懂，效率也很低，不知道各位高手是如何阅读大型代码的，有没有什么技巧，或者遵循什么样的原则？个人喜欢看东西从底层看起，也就是每看到一个类的引用，就会去翻一下这个类是干嘛的，但是真正开发时，引擎是封装起来的，有很多底层的类都是看不到的，这样就总是感觉看代码老是看不懂，因为很多东西都是看不到的，不知道大家如何解决这个问题。问题浅陋之处，还请多多包涵，首次发帖，不胜惶恐。
--
zhang xuecheng
http://veryzhang.cn
Tiny fool
张学成
我之前也有过好多次移植的经历, 都是类似于从ffmpeg中移植一个demux或者decoder到另一个编译器的环境下, 或者从wince平台移植一个库到nucleus的平台, 但是成功的次数不多, 也是大部分都不了了之了.
后来我自己在公司的芯片上做了一个debugger, 需要用到很多elf和dwarf相关的东西, 我找到的唯一的资源就是binutils里面的objdump了, 但是移植肯定是不可能的, 因为我只需要解析, 不需要bfd那些复杂的东西, 整个系统的文件IO乃至内存分配都是完全不一样的.
所以我采取的办法是从一个函数开始, 逐个把我需要的函数, 结构体, 宏定义等等全都拷到一个文件里, 稍加修改后编译通过, 然后就在这个基础上调, 功能基本ok之后再回过头来把代码整理一下, 分成几个文件, 以后再用起来也很方便了.
所以我觉得你移植成功的那个项目应该是有代表性的, 就是先整个挪过来再小范围的修改是往往行不通的, 而从模块或者函数级别开始重新构建, 虽然累了点, 但是往往能够成功.
就像很多书里面都会讲的, 在你优化一段之前, 必须保证能有一个能工作的正确版本, 移植可能也是这样, 自下而上的去做, 至少每个步骤都是经过梳理之后可以用的了, 自上而下的话可能自始至终都没有那个部分能称得上可用:)
Tiny fool
淋雨的感觉
，我这里只是总结下自己的看法。
Bill Wung
dikatour
. 不会动的代码是没有价值的，因此将程序运行起来进行调试跟踪绝对是最有效的办法
. 大项目分模块从简单功能入手，逐步扩展，有些时候可能就从一个button按下去开始，怎么方便怎么来
. 搞清楚基本业务，基本业务都没搞明白就上手看代码会死人的，譬如hack linux kernel, 连os基本概念都没搞清楚就去hack岂不
是自讨苦吃，代码时描述业务的
. 画流程图或序列图或其他图，做笔记，根据具体业务猜测代码的逻辑，根据猜测做实验，再跑程序
. 平时积累常用惯用法，譬如设计模式，网络模型，惯用法就那么几种；如果代码是一个人写的，可以留心作者的编码习惯
. 注意读作者的注释，有些开源代码开头有很长很长的注释，读读绝对有好处
. 一段代码（函数或类），不光看是如何实现的，更要看是如何被使用的
. 搜索创建线程的函数（譬如_begithreadex之类），看看模块的线程模型，大项目很多都是多线程，了解线程模型，对理解代码很有帮助
. 关键代码一定耐心细看，譬如模块是一个dll,那么dll的导出函数肯定相当的关键
. 工具辅助，譬如grep , source insight, vc, vim, beyond compare, svn等等, 最近使用了
understand C++这个工具，发现相当的好用，会生成一段代码的流程图，一个类的所有情况，一个变量的get,set，use的状况，一个函
数的调用图，被调用图，蝴蝶图等等
. 无论如何，程序员才是主人，多思考，不要被代码细节带着走，有机会的话多问原作者，多和别人交流等等
sagasw
余波
我半年前刚好读过一次"代码"，而且是使用反编译的方式读的，然后又把它翻译成了可以编译修改的源码。
这是一套用于web系统的基础框架，一共有三十几个DLL，翻译过来的代码量应该在十万行以上，前前后后用了两个多月（很多不眠之夜）。
我是使用著名的.NET Reflector把它攻下的。
在谈怎么读之前，我先说说我能够攻下这套框架的几个决定因素：
1、对这套东西能够干什么，基本上要很清楚。我们先不管其功能是怎么做到的，但我们必须了解如何使用其功能。功能清楚了，才能够顺藤摸瓜，把代码背后的
想法摸清楚。
2、基本功要扎实。挑战大型代码，难点不在代码多，而是代码背后的思想我们是否清楚，我们阅读代码，其实是上和代码构建者进行一次思想交流。穿梭在迷宫
当中，你至少要知道门是门，窗是窗，具体一点就是：像什么多线程啊，委托啊，签名这些砖砖瓦瓦要有系统的了解。
3、耐心。有时候读代码读到恶心，反胃，但还是要坚持，要有平和的心态。既然是大型代码，就不是一天两天的事情，是持久战。
以上三点，是我体会最深刻的，缺一不可。
接下来的就是一些技巧性的东西：
1、使用源码管理器管理源码变更，其中包含注释，每读必一些东西，就随手写下注释，然后使用源码管理工具提交变更，我使用的是SVN。
2、先从框架的启动和初始化开始，从配置项摸进去，看相关配置参数是如何起作用的。
3、要有阅读计划，比如，最近两三天，要把什么阅读完。整体上有一个列表，不一定要多么严格，但一定要有。
4、劳逸结合，身体是革命本钱。
5、如果你已经有了家人，一定要争取家人（室友）的支持和理解，否则你每天挑灯夜战的结果就是导致彼此关系的紧张。你想啊，你成天搞到那么晚，对别人刺
激大了。
On 7月24日, 上午9时40分, 谢铸聪 <zhucong...@gmail.com> wrote:
> 从大学时代的看小型的面向过程的代码，到现在工作时看的大型的面向对象的代码，感觉很难看懂，效率也很低，不知道各位高手是如何阅读大型代码的，有没有什么技巧-，或者遵循什么样的原则？
> 个人喜欢看东西从底层看起，也就是每看到一个类的引用，就会去翻一下这个类是干嘛的，但是真正开发时，引擎是封装起来的，有很多底层的类都是看不到的，这样就总-是感觉看代码老是看不懂，因为很多东西都是看不到的，不知道大家如何解决这个问题。
> 问题浅陋之处，还请多多包涵，首次发帖，不胜惶恐。
sunskyor sunskyor
oliver yang
2009/8/11 sunskyor sunskyor <suns...@gmail.com>:
--
Cheers,
Oliver Yang
Blog: http://blog.csdn.net/yayong
--------------------------------------------------------------------
An OpenSolaris Developer
rockeet
qiaojie
Jeffrey Zhao
qiaojie
Jeffrey Zhao
qiaojie
Reflector应该是自动更新的，我做了个试验如下：
原始代码：
class Program
{
static void Main(string[] args)
{
Func<int, int, int> max = (int a, int b) => a > b ? a : b;
int i = max(4, 5);
}
}
反编译后的代码：
internal class Program { // Methods private static void Main(string[] args) { Func<int, int, int> max = delegate (int a, int b) { return (a > b) ? ((void) a) : ((void) b); }; int i = max(4, 5); } }
qiaojie
Joe
sunskyor sunskyor
Hank
2. 用SI一类的工具边搜索边看；
3. 用调试工具，单步跟踪。
Tin
如果是好的面向对象代码，可以考虑看看命名，从命名推测设计意图。UML我觉得不是什么很好的办法，逆向工程产生的UML我觉得很难体现设计意图。
面向对象代码还可以看看包设计，也可以推测出大的逻辑划分。
对于这些都不是的代码，我觉得不要考虑从main自己推测，因为人脑推测运行过程耗时也容易出错，不如debug运行代码然后跟踪一下看看运行流程。
On 7月24日, 上午9时40分, 谢铸聪 <zhucong...@gmail.com> wrote:
> 从大学时代的看小型的面向过程的代码，到现在工作时看的大型的面向对象的代码，感觉很难看懂，效率也很低，不知道各位高手是如何阅读大型代码的，有没有什么技巧 ，或者遵循什么样的原则？
> 个人喜欢看东西从底层看起，也就是每看到一个类的引用，就会去翻一下这个类是干嘛的，但是真正开发时，引擎是封装起来的，有很多底层的类都是看不到的，这样就总 是感觉看代码老是看不懂，因为很多东西都是看不到的，不知道大家如何解决这个问题。
> 问题浅陋之处，还请多多包涵，首次发帖，不胜惶恐。
Bill Wung
Thronds
比较麻烦的是，项目运行需要实验室的硬件环境，但资源紧张，只能自己干看代码。
已经用SI来帮助阅读，但还是很痛苦（嘴上还是说读代码是种乐趣）。
现在用到的一招就是跟以前负责这个模块的人搞好关系，请他给我讲了一些。
一段代码反复读，肯定是没有问题的。但时间有限，效率问题还没解决。。。。。
On 8月13日, 下午10时56分, Hank <hankhu2...@gmail.com> wrote:
> 1. 找配套的设计文档看；
> 2. 用SI一类的工具边搜索边看；
> 3. 用调试工具，单步跟踪。
>
> On Jul 24, 9:40 am, 谢铸聪 <zhucong...@gmail.com> wrote:
>
>
>
> > 从大学时代的看小型的面向过程的代码，到现在工作时看的大型的面向对象的代码，感觉很难看懂，效率也很低，不知道各位高手是如何阅读大型代码的，有没有什么技巧--，或者遵循什么样的原则？
> > 个人喜欢看东西从底层看起，也就是每看到一个类的引用，就会去翻一下这个类是干嘛的，但是真正开发时，引擎是封装起来的，有很多底层的类都是看不到的，这样就总--是感觉看代码老是看不懂，因为很多东西都是看不到的，不知道大家如何解决这个问题。
> > 问题浅陋之处，还请多多包涵，首次发帖，不胜惶恐。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
jingmi
见，最后就是拼个 IO 的速度。
其实关键是，这么大的项目，也没必要每个都看，核心也就几万十几万行，全搞明白也没什么意义。
On Jul 24, 3:47 pm, Kenny Yuan <yuankain...@gmail.com> wrote:
> 呵呵，不光打了草稿，还统计了CC盘中的文件属性，只不过截图不方便放
>
> 在CC的view里统计结果就是0.42T，有i18n的文件，也有编译工具，还有第三方工具，等等
>
> 其中，主要的源代码部分（仅仅CPP和H文件，以及一些相关的SCRIPT和MAKEFILE），也有几十GB
>
> 其它地方的源代码不好按文件夹隔离，所以没有去数（在根目录进行find|xargs在这里基本上属于不可能完成之任务，要论天为单位来跑的）
>
> 超出个人想像力的东西很难一下子接受的，要经历过才能明白
>
> 2009/7/24 qiaojie <qiao...@gmail.com>
>
>
>
>
>
>
>
> > 2009/7/24 Kenny Yuan <yuankain...@gmail.com>
>
> >> 赞一个！说实话不容易，有些人习惯于靠想像说出一些貌似有道理的经验的东西，结果只能误导别人
>
> >> 太大的代码（以GB为单位的）是不可能掌握的，修改的版本变得多起来之后，文档也多半失去了意义，在此时，规范和结构就显得无比重要（这个话题很大，在这里就不 多说了）
>
> >> 我知道某公司的某一个产品，它的CC一共有0.42TB，在这种情况下，许多熟悉的问题都变得开始陌生起来。
>
> > 老兄吹牛打打草稿吧。042TB相当于130亿行代码，以平均每人年产5w行代码计算，130亿行代码要26w人年，就算10000人的超大规模软件开发团队最 快也要写26年才能完成。windows上所有的软件的代码行加起来估计也没有130亿行。
>
> >> 2009/7/24 Tiny fool <tinyf...@gmail.com>
>
> >>> 我这方面比较差，很难掌握太大的代码，还需要学习。
> >>> 我本来有计划移植wesnoth到iPhone的，就是wesnoth的代码看着实在太累，暂时搁浅。
>
> >> --
> >> Kenny Yuan
> >> C++, UI, LISP, MMA, Psychology and Automobile.
> >> BLOG: CS巴别塔(Computer Science Babel)
> >> URL1:http://csbabel.wordpress.com/
> >> URL2:http://blog.csdn.net/yuankaining/
>
> --
> Kenny Yuan
> C++, UI, LISP, MMA, Psychology and Automobile.
> BLOG: CS巴别塔(Computer Science Babel)
> URL1:http://csbabel.wordpress.com/
> URL2:http://blog.csdn.net/yuankaining/