一个人写的项目，代码数量到近两万的时候，是否得停下来优化代码结构再继续下去。

[Registering]

近来做一个人负责一款app的开发，虽然开发过程中一直在借鉴一些开源项目的架构设计（主要借鉴oschina的android客户端）。

但是难免有些细节失控，比如突然一个类一下子就到800多行，看到一个类代码量太长总是觉得代码不干净，但是该类中的子功能又比较难抽象出来。

以前在学校也是这样，平时自己写的项目，虽然功能实现了，但项目的代码数量到一定程度，虽然会尽量注意代码的架构，还是会觉得代码增多就越来越难控制架构，感觉就得停下来优化一下，甚至优化也比较费力，所以也影响了项目的扩展性。

毕业2个月，经验有限，求技术大拿们指点。

[josephshen]

http://mobile.51cto.com/comment-452712.htm
非常好的文章，你可以看看。

[josephshen]

附带英文原文
http://www.teamten.com/lawrence/writings/norris-numbers.html

[Registering]

@josephshen 赞，呵呵，突然想起了大一用C语言写的那些代码，1000就是瓶颈了啊

[learnshare]

如果没写烂的话，就坚持写完再重构

[jimrok]

主要是为了好理解，如果过两天，就看不懂了，那还是重构一下。而且就像收拾房子一样，不是每样都要收拾的，捡最需要的部分弄一下。

[freeleestyle]

重构是一定需要的，因为随着你对项目认知的逐渐加深，会有一个新的理解，也为了更好的进行后续的工作。
重构可大可小，看你的能力与精力。但是可以从小处出发，秉持最小迭代的原则来进行。

[ivanchou]

同样的瓶颈，写完自己就看不懂了。。。

[min]

考虑lz的工作年限，做烂掉推倒重新做或者转向新的项目也不失为一个办法

如果目前这货需要长期维护的，那当然是应该找时间来重构

[iam36]

只要功能满足设计，先不急于调整，根据运行状况，自然明确调整的需求以及 方向。

[cover]

刚刚开始写的话 就是不停的推到重来吧，因为你重构的时候会发现一开始认为牛逼的设计，在工程面前会如此不堪一击

[meta]

都到两万行了才想起这个事，有点太晚了。

[Registering]

@meta 其实现在还没多大问题，只是有一个类突然大了，所以现在想重构，为后续打基础

[jjx]

看了一下现在手头的python项目已经有6万行了

重构是要随时进行的

作为开发主管, 同产品经理指定计划时,每个关键点都要留出几天时间让程序员能够回顾和重构代码

[special]

重构不是问题，但是如何保证重构后的代码可以正常运行才是问题。
以后弄新项目的话，可以弄个 robolectric 对关键的模块写一些测试，那么无论怎么重构都不是问题了。

[Registering]

@jjx 能这样最好了，，可是项目急的时候，人手又不够，身不由己啊

[lygmqkl]

先实现后优化，最后才是重构，你这没写完就要重构。。。。不合适。

[zhouquanbest]

我觉得这个和记忆力有关
特别是自己写的，很有可能各几周才去再接着弄，那么再次面对2w行的代码时，你可能会忘记一些细节。
虽然说好的代码就是最好的注释，但有时候辅助记忆的注释我觉得还是可以有的，反正自己看，丑点就丑点。

重构这个东西，还是实时继续的好，不要写几万行再来重构，给自己找麻烦，还可能引入新的bug

[otakustay]

用代码行数来判断要不要重构简直扯谈……2W行代码你重构完了会变成5000行？2W行合理的代码用一用各种模式小心就是3W行了，然后是不是觉得更应该重构了？

[Registering]

@otakustay 或许你借题发挥了，，，2w行不是重构的依据，而只是代表项目功能块到一定量之后，各个模块的线性或者非线性关系递增，代码维护扩展出现了瓶颈，，，

[ChiangDi]

有本经典的书就叫重构啊，多看看，我觉得写得挺好的。