1万5千行的C代码，要多久能看懂？
代码量：1万5千多行；编程语言：C语言；只知道产品大概功能和原理图，没有相关说明文档，注释很少，无操作系统。像这样的条件，大家觉得，
1. 能在上面正确修改功能要多久时间？
2. 完全看懂要多久时间？ 看代码风格，好的架构和注释，后来者可以很快上手，否则满满都是泪。 1.5万行，代码量还不算多，我的代码基本都在5000行以上，加上注释，基本都上万。 问写这个程序的人吧 就像是一本书，可能是中文的，一个月看完，可能是英文的，半年看完，也可能是爱斯基摩文的，一辈子都看不完：） 原作者已找不到，只能靠自己了 努力吧，这个只能靠自己了 一周应该没什么问题吧？ 架构一般，子函数动则6，7百行，不像UCOS那样清晰明了
大家给个参考时间，多久保险点？ 以前网上有个视频一个星期学会单片机。靠{:lol:} 没有其他事情，一般一周够了。 1万5千行只是主框架还是包括外围设备的驱动程序？对外围器件了解的话应该很快，不然就只能看个大概了 包括外围设备驱动程序，但不包含C库函数 你的是c的还好，我的还汇编耶，完全没注释，完全是折磨+痛苦，还真想自己重新开发。 用Source Insight你懂的{:lol:} ExtremeFly 发表于 2014-8-12 11:12
用Source Insight你懂的
这个软件我也在用 lzchuo 发表于 2014-8-12 10:57
架构一般，子函数动则6，7百行，不像UCOS那样清晰明了
大家给个参考时间，多久保险点？ ...
子函数动则6，7百行？
只能说你苦逼了，我一直觉得能TM将一个函数写到100+行的都是牛(2)人(B)。 这个真不好说，写的乱乱的，你一个月也搞不懂，子函数什么的都模块化很强的，一个星期就够了
结合硬件，先搞懂硬件如何实现，再看代码，会轻松多了，光看代码，很累。还搞不清楚 还不如重新做代码了，核心的算法部分找出来抄抄就行 这个还真帮不了你，除非给代码大家看看 两个月，参考 现在也是满满一头的汗珠 能不能看你懂一是看行数的，有两个关键，一对这个程序的产品功能有多少理解，如果有多少理解，再结合程序的话，1.5万行不算什么。另外，程序的架构，如果子程序的独立性很强的，那么分块去摸索，要弄懂也不算很难。如果有注释 就更好了 没有写程序的上讲一下结构，还是很有点麻烦的 如果与硬件无关，一个月可搞定 与UCOSII相比，UCOSII，5千多行，有书籍讲解代码，大家觉得完全看懂要用多久时间？
项目1.5万行，
劣势：
1.代码多些，
2.架构没UCOSII那么清晰明了，
3.子函数模块化没UCOSII那么精简
4.没相关资料说明文档，注释少
优势：
1.数据结构也没UCOSII那么复杂，链表没有，结构体也不太多，
2.算法也没有UCOSII那么高深
如果非要给自己定个时间，觉得多久合适？
J8688 发表于 2014-8-12 11:23
能不能看你懂一是看行数的，有两个关键，一对这个程序的产品功能有多少理解，如果有多少理解，再结合程序的 ...
有道理，先从产品功能入手 zuu0 发表于 2014-8-12 11:19
这个真不好说，写的乱乱的，你一个月也搞不懂，子函数什么的都模块化很强的，一个星期就够了
结合硬件，先 ...
有道理，先把外围设备搞清楚 techbaby 发表于 2014-8-12 11:17
子函数动则6，7百行？
只能说你苦逼了，我一直觉得能TM将一个函数写到100+行的都是牛(2)人(B)。 ...
是啊，我自己写都是一个函数一个小功能尽量小，一般不超过100行， Robin_King 发表于 2014-8-12 10:56
一周应该没什么问题吧？
莫非你就是传说中的高手？？？ 用SI跟代码，考察你能力的时候来了 这个就不好说了，主要看架构和注释怎样了 先clean一下，再rebuild一下，下载，看功能是否完整正常。正常后再考虑下一步
没必要看懂，你只需要用ultraedit根据需求找到相关代码段，看一点点就够了。
如果需求变动太大，再深入点阅读，不行就重写 重写不太可能，毕竟一个产品的东西，测试一大堆东西就来了，你想重写，人家测试部也不给你测，写完你的东西毫无价值，最好还是顺着原代码缕缕吧，垃圾也忍吧 mhw 发表于 2014-8-12 11:45
先clean一下，再rebuild一下，下载，看功能是否完整正常。正常后再考虑下一步
没必要看懂，你只需要用ultr ...
有道理，先把要修改的地方看明白，然后再慢慢深入研究 rootxie 发表于 2014-8-12 11:50
重写不太可能，毕竟一个产品的东西，测试一大堆东西就来了，你想重写，人家测试部也不给你测，写完你的东西 ...
是啊，哪敢重写啊，只能先熟悉一下，在基础上修改，等到完全掌握了，再优化了 J8688 发表于 2014-8-12 11:23
能不能看你懂一是看行数的，有两个关键，一对这个程序的产品功能有多少理解，如果有多少理解，再结合程序的 ...
确实如此
从代码摸索产品的行为，是程序设计的逆向过程，非常的麻烦
对产品理解后，是设计的过程，你还可以比较你和原作者的想法谁更好
建议搞懂产品再搞代码吧 是的，方法往往比努力更重要 只喜欢看代码水平比自己好的人的代码，赏心悦目 找原版硬件，直接上机断点运行，妥妥的。板子运行的过程就是原作者思考的过程。 建议你直接自己重新写，来实现产品功能 jacky_yhy 发表于 2014-8-12 12:13
找原版硬件，直接上机断点运行，妥妥的。板子运行的过程就是原作者思考的过程。 ...
有道理，多谢 产品没有完全弄清楚的话看懂代码有时很难，甚至是不可能的。 只问一个问题：为什么原作者找不到了？
只有一个建议：如果换着我，天塌下来也特木的不会去改别人的程序！ 写程序的人跳了，能找到估计也不会理吧，也没见过
项目交给你了，难道你要说：本人从来不改别人的程序？或者说本人搞不定，找别人吧？ 任务还是要接，只是说能有一个比较合理的时间评估，大概多长时间可以搞定，有什么好的方法可以借鉴 {:titter:}操作下产品实物，功能，，，翻翻硬件pcb，，，，然后，，，重写代码 如果只是改功能，大概看看，加了断点立马可以上手，如果看懂，你那个超过五百行代码的函数估计就够折腾的了。以前改过一个几百行代码，几十个goto的函数，一直到最后重新写都没有完全看懂，期间好几个月。 一周吧，6 7百行的子程序，没多少子程序么，确定下基本功能，画个框架出来，再说了你又了解产品基本功能，还不是小意思，改更快，有个两三天就可以改了，完全不需要全看懂 一个.c 1W5千行吗？呵呵 我觉得还是自己从头开始吧 lzchuo 发表于 2014-8-12 16:46
写程序的人跳了，能找到估计也不会理吧，也没见过
项目交给你了，难道你要说：本人从来不改别人的程序？或 ...
如果公司强加给我，可以改，但先声明，本人不对产生的后果负责！ 你需要一个神器“Source Insight” 光知道代码间的关联是不够的，关键是要理中间的逻辑。
一个月读通，读的时候随时根据理解增加注释（刚开始的几天发现，从一坑掉入另一个坑，越掉越深，不知什么时候是个头。），半个月复述逻辑（有点眉目了，越来越开朗。），这时候就可以开始进行小修改了（记得及时备份）。
还有就是看到不合自己味口的对齐方式等等代码格式，会增加其间的不适应，电工都有强迫症，修改会花不少时间，可以先用自己味口的方式格式化一下。
如果能余半个月那就最好了，基本要两个月。
其实楼主问这个事，就是心里在打鼓。
改并不需要多少时间，关键是能理清思路 看来楼主是没维护过旧产品的经历啊 我看过一个.c文件20000多行，5000行以下是废掉的根本没用到 有注释，有结构文档，不用太费时间。 lzchuo 发表于 2014-8-12 11:33
与UCOSII相比，UCOSII，5千多行，有书籍讲解代码，大家觉得完全看懂要用多久时间？
项目1.5万行，
劣势：
不能与UCOS相比的。UCOS里头的算法非常巧妙，若没有书籍讲解其思想意图，是很累人的。 三天了解大概,一周可以消化,前提相当有空 本帖最后由 xintao 于 2014-8-13 08:48 编辑
我觉得要先看是基于什么样的硬件的吧，
然后自己先分析一下，实现这样的功能，如果让自己写代码，需要怎样来写，
然后再去看代码，如果思路对了，很快就能上手改代码了，没必要每一行代码都去看。 楼上有几位说得很对，先读产品设计文档，再看代码，按照功能索引读源码。 放上部分代码来看看，我改过别人的代码，加起来不到3百行吧，改来改去，硬件部分，单片机程序，FPGA逻辑 统统改了，{:titter:}，前前后后加起来尼玛有一个多月。这都是要交了的项目，干了一年了，奖金估计都领到了 代码行数不是问题,关键是这要明白这个产品代码的架构与产品的功能控制等,代码什么也不是,只是个最终实现的工具而已,不要拿代码大小来说事,没有意思.再说了,不同的产品代码没有可比,不同人写的也可能天壤之别啊. 时间长短不是别人决定的,还是看你自己的领悟吧 iwqt1983 发表于 2014-8-25 14:34
代码行数不是问题,关键是这要明白这个产品代码的架构与产品的功能控制等,代码什么也不是,只是个最终实现的 ...
代码行数多少可以间接说明产品功能的多少和复杂程度，2千行和2万行代码的产品的复杂程度绝对不是一个概念。
代码行数多了，变量，标志，指针，结构体，函数多了，数据结构也相对要复杂得多。理解起来当然也就难一些，所以要有方法才会顺利一些。
“明白产品代码的架构与产品的功能控制”不都得看代码吗？我觉得用代码量的大小来描述这个问题，还算比较贴切的；
听听大家读别人代码的一些经验和方法，我觉得很有必要，也很感谢大家的分享。 1个礼拜足够了吧！关键是用心，拒绝浮躁！ 代码多少有用吗?有的程序用几行与几千出来的效果可能是几行代码的更好. 都说了没有可比性的. 不同产品的代码大小没有可比性, 不同人的代码没有可比性. 上面说的很明白的. 为什么要用大小来比较呢. 不同的产品功能各不相同，不同人写出的代码千差万别，这点我是相当认同的；
不同的产品，不同写代码的人，它们的相同点恰恰是代码，而代码量的多少可以反应出产品的复杂度或者说规模；不用代码量描述用什么描述更合适呢？把功能都列出来不就变成具体项目了吗？
我们要做的是，找出类似问题的一般规律，和解决类似问题的普遍方法。这样的问题很多人都会遇到，对后来者也有益。 学习找到程序的整体框架，认真研究1-2个核心功能，然后有需要修改的地方就上就是了
改程序比较麻烦，因为要读懂旧的，再把新的加入，而且要该分的分，该合的合，要不只会越改越烂
我们项目组开发搞了几年的一个项目已经有80多w行代码了，但是新人依然可以1周入职进行开发新功能、修改已有、排除bug的工作，除了对新人能力有一定要求外，项目的原则和架构把握好，还是可以很快上手的 qwerttt 发表于 2014-8-12 20:48
一个.c 1W5千行吗？呵呵
看到这个，我来说说，特么，我刚来我公司的时候，就是一个.c，然后接近一万行 这么长的代码！慢慢看吧！ 说实话，个人感觉代码量只是个噱头，如果作者习惯比较好，写之前考虑到了易读性，再加上如果功能不是很复杂的话，还是不难看懂的，这个就是体力活了。。。要不然的话，楼主就等着抓狂吧、、、、、、 有问的时间，都看完了。{:lol:} 十个工作日 techbaby 发表于 2014-8-12 11:17
子函数动则6，7百行？
只能说你苦逼了，我一直觉得能TM将一个函数写到100+行的都是牛(2)人(B)。 ...
看下linux的 nand_base.c
满满的都是泪 techbaby 发表于 2014-8-12 11:17
子函数动则6，7百行？
只能说你苦逼了，我一直觉得能TM将一个函数写到100+行的都是牛(2)人(B)。 ...
看下linux的nand_base.c
满满的都是泪 rockyyangyang 发表于 2014-8-26 13:08
看到这个，我来说说，特么，我刚来我公司的时候，就是一个.c，然后接近一万行 ...
吓尿了。。。。。。。。 架构清晰，取名通俗的花很快就能看懂的，要是连什么变量或者函数式干什么的都看不懂的话，那就有点费力了 架构清晰，取名通俗的花很快就能看懂的，要是连什么变量或者函数式干什么的都看不懂的话，那就有点费力了 维护别人的旧代码就得从功能入手，根本不必每一个函数顺序看过去。从main函数开始，分析它的架构，层次；能清楚了大概，再根据你的修改需求细化探究，1.5万行的项目不算很大！ 发片段来瞧瞧 两周看不懂就不用看了 看运气了啊兄弟 慢慢来。。。。。 修改功能看一周吧，完全看懂就得看代码复杂度了 Robin_King 发表于 2014-8-12 10:56
一周应该没什么问题吧？
莫非你就是传说中的高手？？？
绝对高手啊{:lol:} 两年可以
页:
[1]