代码审核和代码重构

代码审核和代码重构，有其特别意义代码审核代码审核是通过阅读别人的代码，来寻找错误，提出改进意见等的过程和实践。使得代码更清晰，设计更合理，综合性能更好是条很漫长的路。另外一双眼睛，另外一种审视问题的角度会极大的促进方案更清楚，更优异。代码审核还会帮助程序员相互传授有用的技术，方法，风格等。只要一个项目的开发者多于一个人，那么立即开始相互审核代码。理想情况下，每一行代码都要被两个人看过，作者和审核人。对代码审核的实践有很多东西值得探讨：何时审核，如何整体审核，由谁来审核。在很多全职的程序员共同参与的大工程中，每一段代码都应在提交的时候送评（如果有更好的工具支持，则应在提交之前）。审核人要清楚与之相关的代码，并要理解其作用（还有，更重要的，可能会发生的错误）。在此过程中，审核要快速的完成（一到两天内），作者在评论完成之前，不要试图改动这段代码，以避免把事情搞乱。参与人数少的小项目则不必如此。要是代码不多的话，进展的速度会很快，要是每一次提交都审核的话耽误不起。但是，代码审核对代码和写代码的人都很有益处（因为，不说别的，这使得至少两个人都理解这段代码。）用什么样的风格做项目，只要适合就好，但一定要养成审核代码和让人审核代码的好习惯。如果你是审核人：及时如若有人请你审核一段代码，要么马上开始，要么痛快的告诉人家不行（并转交给更有资历的审核人）。千万不要让人家等。尊重代码审核的目的是确保代码的质量，不是为了显示出谁比谁高明。作为审核人，你的确有很大的权力，但是不能乱用。详尽若是有些东西你搞不清楚，要么是代码写的就不够清楚，要么是注释不够，也可能二者兼有。请作者澄清（不单单是对你私下里的解释，要写进代码里）。要是什么不对劲，这很可能，或者是对的但看上去是错的，或是晦涩的，都要告诉作者使其修改。执行规定要是项目中有些规定或规范（代码风格，命名规范，测试等），发现不符的地方一定要让作者修改。有些时候这样做显得吹毛求疵，但是定下这些规定和规范是有缘由的，所以应该遵守。如果你是被审核代码的作者：尊重审核人是你的朋友，给你有价值的建议。如果你有些不同见解，那么这绝对是建设性谈话的好议题。要是审核人对你的代码有误解，那么极有可能是你没有把代码写清楚。不要以为批评是针对你本人代码审核是要改进代码，不是要刺伤（或者是提升）你的自尊心。审核之所以一定要关注你做错的地方，是因为那就是要改进的地方。对不良代码的批评都是建设性的（很可能包括积极的建议从某方面深入思考），要是并非如此，也许找审核人礼貌的谈一谈是个不错的选择。尽早尽量获得审核审核一大堆刚写的代码是非常非常讨厌的，只有一种例外，审核人发现在整个部分你都在犯傻。这个过程需要一点一点修改提交。即使你认为要多做一点儿，将工作拆分成易于审核的小块，这样会避免很多错误，以使你得到数倍的回报。十个100行的代码审核要比一个900行的来得轻松得多，拆分着做会节省很多寻找修正bug的工作量。代码重构重写一段代码保留其运行的外部特性，但在某些方面有所改进，这样的过程称之为重构。通常这是为了代码更加清晰易读，或是为了更易于扩展，也可能是为了执行的更快。这项活动不论规模大小，都可以叫做重构。重新命名变量和函数是重构，在类之间调换功用亦是重构，将一个100，000行纠缠在一起的代码分解成一个插件架构和若干相对较小独立的组件。当然，三种目的的重构遇到的问题会有很大的不同，但有一点是不变的：无论哪一种目的的重构都不改变原有代码与外部世界的交互。重构对代码，对身心都是有益处的。一定要重构。重写一段代码并不丢人。就当第一版是草稿。这会帮助你勾勒问题的轮廓，是你明白你要从方案中得到些什么。得到已经正常运转的代码是非常有用的，这样可以制定测试组件，来精确定义你到底要解决什么问题。然后，有了测试组件，你就可以修改你的初始方案做出改进。之后，修改第二稿，第三稿，直到没有可改的了。相似的，千万不要以为没有对代码的行为做出显式的修改就是浪费时间。相反，通过梳理代码，你可以使其更加易读便于理解，易于维护和扩展，便于发现和修正bug。要是需求在最后的时刻发生了变化，在这上面花点精力的就会显得太值了，事实上也往往如此。那么，怎么重构呢：重构其价值如何强调都不过分。不要将重构与实质性的修改混为一谈代码的行为在你重构前后应该是一致的，相同的。这也是检查与验证你是不是进行重构的极其有效的手段。尽可能将你的重构一个一个的提交，而将实质性的修改分开提交。测试重构的代码除了最简单重构外，值得重构的代码，也只得测试。相应地，由重构的定义可知重构应该在不改变代码行为的框架内进行。若是测试套件已经有了足够的边界条件测试，很好。要是没有，做一些，并在你开始重构之前弄好它们。这是一个很好的方法可以使你的重构不拖累其它部分。一小块一小块的来信誓旦旦地说“我要重写这个程序”，然后埋头就干，企图一下子把所有都重做一遍。说说很容易，但绝对行不通。这样绝对不会得到看上去一样的程序，你就开始想是个bug呢，还是原本特性如此呢，原来的代码到底对此事如何处理呢，等等。绝对是灾难。在重构过程中，当目标总是停滞不前，我们总是可是把事情分成一小段一小段的，以便查验。别害怕丑陋的中间产物举例来说，如果你想修改一个接口，首先为新的接口提供支持，然后将所有客户端逐个转换，然后去掉旧版本的接口。要是修改过于庞大的话，不要一蹴而就，将其拆分成几个小部分完成。可以肯定当你修改到一半时，代码看起来会很难看，有些客户端用新方法，有些用旧方式，但是程序依旧正常工作，测试也正常通过，你好检验你的修改没有引入任何不希望的破坏。重构都可以像这样来拆分。尝试拆分，尽量将工作化成可以度量的小块儿。不要卡在中间要是开始了进行重构，那就进行到底。关键是代码要变清晰，但是干了一半儿的活儿通常会是旧的混乱加上新的方案混合在一起。绝对不要让程序长时间出于这种状态。通过重构为实质性修改铺垫你是不是经常开始做X的时候发现必须要先改Y才能行，而在改Y的时候，你又发现得先改Z，最后呢你困惑了，结果是一团糟。我们都有过类似的经历，只是相对少一些而已，预先估计都需要改什么，然后先重构，测试，提交Z，接着是Y，最后是X。这样会得到更好的代码，减少错误，即使真的有东西弄乱了，你也更容易让其步入正轨。别怕删代码人们（很可能是你）花了很多的时间去写并不意味着是代码一定能很好地完成既定任务。这些代码帮助定义了任务是什么，完成此项任务会遇到怎样的困难，这些都对日后的工作很有用，因此其作者的工作很值得尊敬。即使是知道了不用这么做也是很有帮助的，有时候很值得投入全部力量去写代码做这项似乎无意义的事。另一方面，无效的，废弃的代码只会使程序变得拥挤不堪，难于阅读和理解，所以还是删掉的好。要是后来你又最终决定用了，版本控制系统会将其完好无损的还给你。不要把应删掉