我们不应该“为了拆方法，而把方法硬性拆分。而应该是因为业务需要而对方法拆分!”。而且函数调用我们知道，本身也是耗费性能和内存的。如果你这个方法体内的有些部分，其他方法也要调用，那么这时候你可以把这部分代码做成一个方法。如果你的方法里有很多调用其他类里的方法，不也看着很麻烦吗?还不如写到一个方法里呢!这样还比较直观些。

4> 找回以前删除的代码。

我:如果某个功能产品要求撤下来，但是过了很长一段时间，产品又要求再上这个功能。那么我原来的代码是删除呢?还是只做注释呢!

老大:删除掉!

我：那我怎么恢复呢?要把原来代码做备份吗?

老大：你可以使用版本管理软件做恢复。如svn。

例子演示:

(1)最初代码

svn提交代码:

(2)产品要求下线代码

svn提交代码:

(3)隔了一段时间，产品又要求重新上线该模块。

svn操作:先查询日志，然后针对日志进行合并

总结

上面的问题，我估计你也遇到过，所以大家共勉下吧!

题外话:曾经我在离开一家工作一年的公司的时候!项目经理就跟我说你如果频繁跳槽，会对你的将来的发展是不利的，但是没有告诉我怎么不利?现在我有点明白了，因为我到过的公司很多技术过硬的人，都是在这个公司带过3年以上的人。我发现如果你在一家公司待很长时间，对你的技术提升是很有帮助的。

1》 不停的重构代码，提升你的代码质量。

我们开始进入公司的时候，一般都是公司急需赶个项目人手缺乏。等项目完成，一般都是1年左右。如果你在公司待足够长的时间，这个项目多多少少会跟你扯上边的，这时候，你会不停的翻看自己的代码，你也会不断的调整代码， 不断的重构你的代码——跟写文章一眼，你不停的看自己写过的文章，你会不停的做修改，越修改你的文章会越让你喜欢。

2》业务熟悉，能够更快更好的写出代码!——我个人比较喜欢“行云流水”似的感觉。

你如果在一个公司待了很长一段时间，那么你对这个领域是非常熟悉的。新需求上来，你会很快的知道怎么做代码架构，比如上面提到的，你就知道方法中，哪些代码部分可以抽出来，独立做成一个方法;你也会知道，将来什么地方会频繁修改的。——写代码，如行云流水般!