接手一个有50万行源代码的ERP程序？

[marklr]

没有原开发者的指点，只有之前留下的一些开发者写的注释，不算很完善，这种情况下，有可能接手做二次开发吗？

[dabingsou]

按照功能去研究,先关注需要修改的部分,慢慢来

[wm0508]

从main函数开始，一步一步来

[全栈极简]

单步调试，弄清楚流程。

[gxingmin]

我要接手一个900万行的c/s程序呢，现在代码很乱，文档也乱，晕

[threenewbee]

修改下版权信息，还是有可能的。 至于维护——没有团队支持的源代码，一文不值，因为维护的成本甚至比从头搞更高。当然业务逻辑本身是有价值的。但是这不关源代码什么事。

[autoid1]

先全面跑一次看看.问题多的就果断弃之..

[woaiwano]

在VS打开代码，按F5，然后按F11，看看整体跑跑有木有问题，

[以专业开发人员为伍]

引用 楼主 marklr 的回复:

没有原开发者的指点，只有之前留下的一些开发者写的注释，不算很完善，这种情况下，有可能接手做二次开发吗？

不可能。 （50万行代码）如果不是一大堆垃圾、相类似的代码反复抄袭的，那么就是一个超级复杂的产品了。这种东西需要有3、4个熟练开发人员，带着10个不熟练的开发人员，而且不能搞“山头主意”。 有些幼稚的项目组经常搞“谁的代码谁个人负责”这种让编程断子绝孙后继无人的“管理办法”。根本上来说，是因为管理人员只从行政上进行管理，于是总以为这样就能够方便的压服开发人员了。 如果出现这种后继无人的现象，那么就是软件“活该倒霉”。你接受这种产品时，要么就是混点工资，要么早就该跳槽了。 除非这个公司打算重新开发产品！

[以专业开发人员为伍]

那些“为了三层而三层”的代码往往比正规而合理的分层的代码多10倍的代码。 有些所谓的“架构师”根本不懂从用户出发进行敏捷地开发和重构，而是把所有精力放在什么“增删改查”之类的最低级的代码，这样非常容易留下一大堆代码，而干不了什么事情。 不过无论如何，一个软件公司的主要产品应该围绕着“同一套”服务端系统来展开。一个软件公司应该以市场为导向，那样开发出来的产品才有一定的档次，知道为了应付不同用户的需求而进行架构设计和不断重构其架构细节。 有些公司，只有4、5个员工，却号称有50个大型“产品”。这种公司任何人都应该非常谨慎不要陷进去。因为随便不用脑子都能想到，这个公司的老板是什么样的“产品研发管理”思路了！程序员只可能卑鄙地去临时“熟悉”一堆垃圾，然后在上面胡乱增加一大堆应景之作，然后迅速扔掉它。程序猿的层次根本不可能提高！

[以专业开发人员为伍]

引用 4 楼 gxingmin 的回复:

我要接手一个900万行的c/s程序呢，现在代码很乱，文档也乱，晕

除非是几万人维护的军工产品，否则如果想让文档能够符合“900万行代码”的需求，那是天方夜谭。 真正的敏捷开发不是基于文档的，而是基于自动化测试的。文档是废弃的，过了3个月自然就是垃圾，因此从来不要求文档一直与代码同步维护。但是要求所有开发人员都要自己写可执行的测试用例，并且频繁交流（甚至每天进行两次以上“姐对编程”），所有人经常变换负责的编程方面（比如说擅长sql的人也必须去领取好几个UI开发工单）。 因此要解决问题，主要在于人，而不是文档！