日前，在InfoQ上发布了一篇名为《完成宣言》的新闻，其中探讨了什么样的代码才可以算是“完成”了的代码。文中列出了一些标准，大家可以在这里查看相关的内容。
对于此，我不由地开始反思自己曾经做过的代码，自己是否真的完成了所有的代码呢？自己的代码是否已经满足了一定的标准，真的可以提交给用户使用了呢？其实，现在回顾这些问题有些亡羊补牢的意味，每个人在提交自己的代码之前都应该先问自己一声，这份代码真的完成了吗？
文中主要是从代码的各种特性来界定代码是否完成的标准的：
1、代码的可用性和易用性
2、可维护性和规范性
3、可测试性和健壮性
4、从总体上对系统的影响。
接下来，我想根据自己的一些经验对其再分析一下，同时反思自己。
一. 代码的可用性和易用性
首先，对于代码（或者说程序）的可用性 和易用性，这应该是最基本的要求。我们的代码开发出来是做什么的呢？不是用来孤芳自赏的，而是要放在业务环境中由业务人员来使用的，也可以说是来检验的。这样的话，可能就有下面的一些要求：
a) 完全实现了业务上的要求，准确地完成了相关的任务。
b) 在性能上表现良好，应该是节省了用户的时间，而不是浪费他们的时间。提高工作效率，他们的感受会很好。
c）没有太过复杂的操作，即使没有相关的培训，业务人员一眼看上去，大概的功能也就基本了解，并能够很快上手使用。
这些问题看似比较简单，但是实现起来却需要不少细节上的工作，不信你看下面的场景：
场景一：业务人员开始抱怨：你开发的东西根本就不是我要的，我一直是这么做的，为什么要让我改变工作的方式？
这可能会有两种可能，一种是我们在开发的系统中使用了比较先进的管理学理论，改变后的工作方式更有利于业务人员高质高效地完成工作任务，对于此，我们需要和他们耐心的沟通，并劝说他们试验一下，感受一下看看是否能够真正对他们的工作加以改善，一旦他们习惯了，就好了。
而另一种可能就是，没有达到业务上所需要的，业务上用系统根本就无法工作。这种情况也是非常可能出现的，特别是在国内的项目开发过程中，需求分析和概要设计都没有做好，就匆匆开始编码了。或者说，在看到实际的程序之前，业务人员根本就不知道他们想要的是什么，直到你做出来之后，他们才告诉你那不是他们想要的东西。
对于这种情况，或者说对于这种项目，都比较麻烦。但是想要改善的话，我有几点建议，一是要加强与客户的沟通。此时XP编程中的一条原则“现场客户”就非常适用。如果我们能够经常地和他们沟通，听取他们的意见，而且在开发的过程中按照“瞄准-射击-调整”的方式，能够少走不少的弯路，也比较容易得到用户的认可。（但在这个过程中就要注意与客户之间沟通的技巧，建议阅读我翻译过的《与客户调情》）。其次是放下程序员的架子，把自己放在和业务人员同样甚至是低一些的位置上，虚心向他们学习，从客户的角度去理解业务流程，想方设法让他们的工作更简单，效率更高，而不是一味地强迫他们按照我们的思维模式去做，毕竟最终的东西不是我们使用。
在这里一定会涉及到的问题就是变更管理，这也是开发团队和客户之间经常需要“打架”的地方。其实有些时候，如果能够相互理解，不一味地纠缠在钱的问题上，反而更容易解决。试想一下，如果对于每个小的变更都纠缠得非常清楚地话，那么很多时候就会造成之间关系的僵化，从而客户不愿意把相关的业务知识告诉开发团队，那对于我们来说绝对是不可弥补的损失，而且不是能够用Money来衡量的。
场景二：你这东西也太慢了，本来我做这件事儿需要1个小时，用了你的系统之后需要2个小时，我不得不加班！
这个没说的，必须要调整了。很多人都收到学校中的一种思想的蛊惑；先把功能实现了再说，性能那个东西可以用硬件来弥补，以后再调整也没事儿。其实，对性能的考虑不仅仅是从开发程序之前就应该开始，而且是应该在整个系统开始之前就开始考虑，包括数据库服务器、应用服务器的设计，数据库中的数据的存储方式、空间的分配等等，都应该在系统开始之前就做了充分的工作，否则等墙快要倒了的时候，再去补，为时晚矣！
性能应该优化到什么程度呢？我觉得最基本的原则就是，比客户要求的标准稍稍好那么一点儿就可以了，这样他们会觉得你对他们的反馈很重视，并且已经超出了他们的预期，一定会满意的。
场景三：你这程序界面上的东西太多了，我根本不知道怎么做。而且操作也太麻烦了，要很多步才能完成一项工作。
在没有完整的信息化系统之前，业务上很多的工作都是使用Excel之类的东西完成的，那是非常方便的工具。但是使用了开发的软件之后，就必须改变原有的工作习惯，比方说回车和Tab的使用，比方说增加新纪录的方式等等；此时就应该尽可能少地把操作的控制暴露给用户，而应该尽可能多地由系统在后台完成工作。如果看到满屏幕都是各种各样奇怪的控件，用户肯定会晕倒的。
所以说，想要开发出来的程序对于用户来说真的可用、易用，要做大量的工作。并且，随着时间的推移，后期肯定还需要大量的调整工作。
待续……