如何评价软件好不好，有哪些评判的指标

下面是20070621写的一篇文章，题目为《如何评价软件好不好，有哪些评判的指标.doc》，我认为这是我个人在软件知识方面的一次总结。


软件好坏标准


本文描述了我对软件好坏标准的看法，仅仅是我个人的想法，不一定正确。


1. 概述
我认为软件的评判指标有下面这些：
功能
Simply and Clear
有文档对应
模块化
可阅读
容易修改
可重用
模块接口最简化
硬件模块分开
按照逻辑来编写程序
速度
有版本控制策略
重构
下面逐个来仅限描述。


2. 功能
完成功能，是一切标准的前提。


3. Simply and Clear
实际上，软件有一个通用的标准，即：Simply and Clear。只不过这个标准过于抽象，每个人对这一条也有不同的看法，所以，有了下面这些具体的条目。但这条标准告诉我们，如果一个软件“复杂而且晦涩”，就不是一个好的软件了。


4. 有文档对应
写软件为什么要写文档？有的书也说：代码即文档，即不写文档，用代码去描述所有的信息，实际上很难做到。我认为：软件的本质是人（程序员）告诉机器(CPU)做什么。所以，如果程序员不知道该怎么去做这件事情，那么计算机一定不知道；程序员只知道大概，计算机也会做的别别扭扭的，不可靠、不稳定。因此，在编码前，应该清晰的描述我们期望计算机做什么、怎么做。不仅整个软件应该这样做，对于子模块，也要这样做。
代码只能告诉我们，一个模块是如何做一件事情的，他不能告诉我们为什么要这样做，有没有其他选择，大的流程是怎样的等等，或者不能直接的告诉我们这些信息。因此，只有代码、没有文档，信息是不完全的。
回想以前的做法，拿到任务就编码，然后在计算机前不断尝试、修正，这会浪费很多时间，而且做下来，也不知道怎么做正确的，个人能力也没有提高，程序中还有很多没有考虑到的情况，软件也不会稳定。正确做法：明确思路在先。转变是困难的，但程序员应该积极向这个方向转变。
写文档的效率问题。写文档也是要花时间的，如果文档写一遍、代码再写一遍同样的信息，这会浪费时间，文档的职责应该是描述大的框架、思路、流程，能够约束住你写的代码内容，具体的实现交给代码去做。
编写软件有两个大的难点：思路、编码。如果做到有文档对应，就能够消灭“思路”难点。编码也会出错的，我们无法消灭编码的错误，但应尽量减少，这需要其他的方法来解决。
这里“对应”的意思是说：需求、框架、大的模块划分、子模块划分要有文档。子模块的设计及bug修正要有文档对应。所以，主要软件开发活动，都要有文档对应。


5. 模块化[1][2]
将一个软件划分为大的模块，模块提供清晰、简单的接口，这样才能多人合作。一个糨糊式的软件，是无法多人合作开发的。而且，也无法调试。
我们以往比较注意大的模块的划分，实际上，这个原则可以递归下去，大模块可以拆分成小模块，直到拆分成你能够轻易的设计、编码。
划分模块，尽量用名词代替动词来划分，例如：霍尔传感器、eeprom等，甚至一些不是实体的东西，也可以划分为模块：例如park变化、电流环、int1中断。用名词代替动词来划分模块的好处在于，一个动作模块很难在其他系统中复用，而一个名词模块比较容易重用。另外，一个动作可能涉及到多个名词物体，编码、调试起来牵涉的物体多，编码、调试的困难就大。如果是名词模块，只涉及到一个物体，调试起来就容易，思考起来也容易。


6. 可阅读
代码要维护、修改，别人就要阅读你写的代码。因此，保持代码尽量便于阅读，是一个非常重要的原则。对于自己也很重要，你会阅读自己半年前的代码，如果还要搜肠刮肚的想一番，说明代码可阅读性就差。
便于阅读，不仅指格式、注释，也指代码的逻辑。用最清晰的逻辑来编码，具体表现有：一个变量只有一个含义，一个函数只做一件事情，函数尽量短小，函数尽量少的传递参数，用有意义的名称代替立即数，变量名少用只有自己知道的缩写。其他体现，建议看看[3]、[4]。


7. 容易修改
有以下几个具体表现：
改一个常量，只用改一个地方。
修改某一个功能，只用更改一个文件。
某个变量的变化，只在一个点就可以监视和控制。
例如：在产品x中的errorCode，我们期望能够过滤掉一两个故障，因为errorCode的赋值在整个代码中，而且有多处，因此，实现这个功能，必须要搜索、修改整个代码，这是不容易修改的具体表现。在产品y中，改进成用一个函数sysGuardReportError( errorCode )来报告错误，如果要屏蔽某些错误，在这个函数中做一些事情即可。
再例如：串口通讯在每个产品上都有的，能否做到串口模块只有几个地方（模块、函数）修改，就能适应不同的cpu，甚至是不同的协议呢？
软件的一个特性在于容易变化，硬件的特征在于相对稳定。软件容易修改的根本原因在于需求是变化的（相对于硬件来说），积极拥抱变化，软件保持根据客户提出的需求而快速变更的能力，是程序员无法回避的问题。如果能够做到，你的代码也会容易调试。


8. 可重用
对于程序员来说，写出可重用的模块，是个人知识财富的积累。对于公司来说，可以节省很多编码、测试的时间，软件可靠性也要高。
要可重用，就要划分尽量小的模块，只有“砖头”可以重用，“大厦”是没有办法重用的。当然，如果能将“砖头”写成“楼梯”、“房间”，也是可以重用，这个层次更高一些，[2]有这方面的描述。


9. 模块接口最简化
例如：提供了设置IO高低的函数SetIO(b)，就不用提供IO翻转的函数。当然，这也不是绝对的，如果翻转用的很多，你提供也可，弊端就是增大了接口的维护工作量。


10. 硬件模块分开
硬件用单独的模块来描述，这是[1]中描述的原则。
例如：将所有中断独立在出来。原来int1为hall中断，现在更改上停针中断，只用更改中断服务函数即可，不用更改int1的配置。采用这种方式，使产品y 2806代码在中断部分只有很少的变化。


11. 按照逻辑来编写程序
[3]中对这个题目有完整的描述。


12. 速度
以前的cpu能力非常有限，因此，很多情况下，要保证速度优先的原则。如果项目cpu足够快，可以将其他原则优先，特别是“可阅读”。
另外一个思路是，cpu速度的消耗是按照2/8原则的，即20%的代码消耗了80%的cpu计算能力，如果你的代码非常清晰，你就很容易找到这20%的代码，从而改写他。例如：更改算法，用宏定义代替函数调用、改成汇编等。Minid明显电流环是那20%，如果要优化，首要关注电流环。因此，即使cpu计算能力有限，也应该将代码尽量模块化和可阅读，除非是极端的有限。


13. 有版本控制策略[5]
在用SV N将近一年的时间里，让我感觉软件版本变化有强大的依靠，我不用担心版本信息丢失，因此，我敢于大量修改代码。同时，也方便了在不同的人之间传递软件。
如果团队不习惯SVN，可以用其他版本策略来代替，用纯手工的方式也可以，但必须有一个明确的策略。SVN相对来说，应该是很简便的方法了。


14. 重构[4]
重构不是软件好坏的标准，而是让软件向好的方向持续前进的手段。其根本含义是：当你发现软件有不好的倾向，更改他。至于的更改标准，就是“可阅读”。


15. 总结
上面这些标准，相互之间是制约的，要寻求一个平衡。另外，如何量化也是一个难题。但文档对应、模块化是最主要的标准。


参考文献
[1] A Software Modularity Strategy for Digital Control Systems.pdf, www.ti.com
[2]嵌入式系统构件, Jean J.Labrosse, 机械工业出版社
[3]代码大全
[4]重构
[5]程序员修炼三步曲-版本控制之道-使用SVN