在写代码，文档方面，程序员最喜欢且最常做的是不写文档，不写代码注释，最不愿意看到就是：别人不写文档，别人不写代码注释，这几乎是所有程序员的一个状态吧。遇到无文档，无注释，无人可问的代码，对于一个程序员来说是比较崩溃的，对么？想必有部分程序员朋友可能会遇到这样尴尬的场景，不过比起这样的情况，还有一种情况也是够难受的，下面让我们来看看这名安卓工程师遇到的情况吧！
据这名安卓工程师所说，他刚入职了一家公司，然后被分配了一个项目，需要接手维护其他人的代码，当他看到具体代码的时候，就有压力了，一下子感觉这个事情很棘手，很有挑战性，因为他发现其中一个Activity
里写了7000行代码，他就硬着头皮去看，看的头都疼了，关于他这样的描述，想必有部分网友也有过类似酸爽的经历吧，针对这样的情况，让我们一起看看其他网友们是怎么看待的吧！
网友一：500行以上都是有问题的
上世是朵花：如果排除一些历史原因，新设计代码一个方法500行的确是有问题的。
腾讯员工：QQ代码了解一下
网友回复腾讯员工：QQ是因为功能比较复杂吧，而且要兼容到Android2.3还是2.2。你这个历史原因没办法，但其他的应用，一般真没那么多东西处理，还是因为不懂拆分，说真的，哪怕换成Fragment，他们照样也是一股脑堆代码。这种事情，见多了就麻木了。
上世是朵花：没错，设计的的初衷都是为了能够方便维护，但是也不排除有的项目有各种各样的历史原因，比如人员更替后，新人没有勇气重构代码，只能在往以前的代码上继续累积，也可能造成代码臃肿的一个原因。
网友三：楼主看来是写小项目的，没做过大项目。7000行很正常，Android源码一个类都有超过两万行的，业务多的超过7000行正常。主要是你想不想担风险去重构。
楼主回复网友三：源码是见过，但是写业务逻辑还真没见过
上世是朵花：有一些源码这样正常，不过业务逻辑代码这么多行，抱怨两句也是正常的
京东员工：历史问题，等以后别人接你盘的时候，也会这样骂你
上世是朵花：通过这个案例，就能感觉到代码管理的重要性了。
网友五：上一个人也是这么说的 谁写的5000行，然后默默填到7000行
上世是朵花：这话挺有意思，呵呵，这名网友的意思是这7000行代码是以前每届程序员累积的结果。
小米科技员工：谷歌鼓励将逻辑写入acticity，但是7000行就过分了
上世是朵花：没错，一个acticity7000行的确是大的出奇，估计这里面肯定有一些历史原因，比如是多个人累积的结果。
网友七：你是没见识过上万行的存储过程，方法调方法
上世是朵花：上万行存储过程，厉害了，这个确实没有见过，没有两下子真不好维护啊，这也太海量了。
网友八：记得第一次写js一个复杂页面三个方法我写了7500行
上世是朵花：每个方法也2000多行，那这种做法肯定是不科学了，方法的可拆分性一定很大了。
对于新做的项目，新开发的产品，我想不会有哪个程序员会一个方法写7000行不是么？设计代码的初衷都是奔着高效，易维护的原则去进行的，我想这名安卓工程师遇到的情况肯定是有历史原因的因素在里面，这样的现象也算是正常，在相当一部分公司都会存在这种“大长方法”的业务代码，当然，这不一定是程序员们故意写成这样的，每个这种现象的背后都可能有一个故事，比如我能想到的就是，这是一段核心代码，但是维护这代码的人在不断的更替，新来的人要继续维护，没有人有勇气重构这段代码，只能在这段代码上进行累积，如果增加新功能，继续往上加，在短期内看，往上累积要比重构轻松的多，因此大部分人就选择这种轻松的方式，也许这个方法最初不到500行，经过几届人员接替就逐渐2000行，3000行，5000行的增加，直到这名安卓工程师网友看到的时候已经达到了7000行了，除非他有勇气重构这段代码，否则以后这个代码会继续8000行，9000行，1万行，一直到最后一个程序员表示无法忍受，开始准备下决心去重构这段代码为止。
以上所有图片均来之互联网
大家好，我是“上世是朵花”。如果你有什么好的看法或者观点可以在评论区展现你的才华，互动交流，如果想进一步了解我，那就关注我吧！
