较好的代码维护实践

在别人实现的基础上进行开发，基本是一种常态。特别是对原来的代码陌生的情况下，有没有什么好的实践方法呢？

基本原则:类似重构一样，尽量减少对原有流程和结构的修改，最好能兼容原有结构。上来就按自己的相法来修改代是比较容易的，这样做很大程度是因为理解原有的代码需要较长的时间且有一定的难度，但这样会增加系统的复杂度，也会引入许多不必要的风险。除非得到项目负责人的同意，否则相当然的直接动手重写，绝非是什么好事！

那么如何做呢？要花大量的时间从头阅读代码吗？你以为文档写得那么好吗？

嗯，阅读代码和文档是免不了得，但需要有明确的目标和有序的安排。有效地控制各个阶段所关注的内容是成功的关键。过早的被许多的细节困扰会严重打击自信，有可能会变得越来越艰难！

首先应当解决掉两个问题:

  1. 原来程序的行为是什么? (试着像个用户一样跑一下，对照一下规格书,去理解它对做什么?)

  2.现在新的需求是什么?  (看看需求说明，找人了解一下！)

并不需要直接进入代码和相关技术文档的阅读。特别在分析第二个问题时，应当列出一个清单，包含要变更的功能。

到这里，按照那个清单，从中间找出你认为比较简单或影响面小的功能，以它为目标展开对现有代码的分析。因为强烈的目标，这让你会更有效地关注相关的代码。而不是，一边看，发现一个分支，就去转过去，就像走迷宫一样。当然虽然是焦点明确，但也免不了困在迷宫中。那么走出迷宫最好的方式是什么呢？在走过路上做个标记吧！Easy, 那就一边看代码，一边画个草图或流程图。你可以使用深度搜索或宽度搜索的方式，把你的道路打扫干净。但只是面前的这条路！

这个过程最为关键，你要开始去了解原来作者的意图，适应代码的写法。如果发现有类似的变量和函数，不要重新写，想想有没有可能重用它。这样也会促使你用原作者的逻辑来思考。

当然也有工具可以辅助一下，比如Doxygen或者SourceInsight,Kscope之类的。无论如何，运用当前的IDE环境才是最关键的。

到这，如果你在没有失去信心的情况下搞定了，那么恭喜你。如果开始有点着急了，那就果断地回头看一下你定的列表，你现在的选择真得是最简单的吗？

如果这个程序对你而言是一门的新语言，也没关系。一开始写错几个函数命名或多一个符号，少一个符号的没有关系，这就是一个成长的过程。只要方法对，方向对，好的结果并不会太远。

这样来回几次之后，有些可能会重工，记得要同步修改你的图，那是最关键的东西！

最后，这是一个迭代的过程，不要一开始就尝试着掌握一切!  你不是上帝，你只是来给上帝修修房子的。