你的代码完成了吗

《你的代码完成了吗》由会员分享，可在线阅读，更多相关《你的代码完成了吗（6页珍藏版）》请在金锄头文库上搜索。

1、你的代码完成了吗？你的代码完成了吗？日前，在 InfoQ 上发布了一篇名为完成宣言的新闻，其中探讨了什么样的代码才可以 算是“完成”了的代码。文中列出了一些标准，大家可以在这里查看相关的内容。对于此，我不由地开始反思自己曾经做过的代码，自己是否真的完成了所有的代码呢？自 己的代码是否已经满足了一定的标准，真的可以提交给用户使用了呢？其实，现在回顾这 些问题有些亡羊补牢的意味，每个人在提交自己的代码之前都应该先问自己一声，这份代 码真的完成了吗？文中主要是从代码的各种特性来界定代码是否完成的标准的：1、代码的可用性和易用性、代码的可用性和易用性2、可维护性和规范性、可维护性和规范性3、可测试性和

2、健壮性、可测试性和健壮性4、从总体上对系统的影响。、从总体上对系统的影响。接下来，我想根据自己的一些经验对其再分析一下，同时反思自己。一一. 代码的可用性和易用性代码的可用性和易用性首先，对于代码（或者说程序）的可用性和易用性，这应该是最基本的要求。我们的代码 开发出来是做什么的呢？不是用来孤芳自赏的，而是要放在业务环境中由业务人员来使用 的，也可以说是来检验的。这样的话，可能就有下面的一些要求：a) 完全实现了业务上的要求，准确地完成了相关的任务。b) 在性能上表现良好，应该是节省了用户的时间，而不是浪费他们的时间。提高工作效 率，他们的感受会很好。c）没有太过复杂的操作，即使没有相关的培训

3、，业务人员一眼看上去，大概的功能也就基 本了解，并能够很快上手使用。这些问题看似比较简单，但是实现起来却需要不少细节上的工作，不信你看下面的场景：场景一：场景一：业务人员开始抱怨：你开发的东西根本就不是我要的，我一直是这么做的，为什 么要让我改变工作的方式？这可能会有两种可能，一种是我们在开发的系统中使用了比较先进的管理学理论，改变后 的工作方式更有利于业务人员高质高效地完成工作任务，对于此，我们需要和他们耐心的 沟通，并劝说他们试验一下，感受一下看看是否能够真正对他们的工作加以改善，一旦他 们习惯了，就好了。而另一种可能就是，没有达到业务上所需要的，业务上用系统根本就无法工作。这种情况 也是

4、非常可能出现的，特别是在国内的项目开发过程中，需求分析和概要设计都没有做好 ，就匆匆开始编码了。或者说，在看到实际的程序之前，业务人员根本就不知道他们想要 的是什么，直到你做出来之后，他们才告诉你那不是他们想要的东西。对于这种情况，或者说对于这种项目，都比较麻烦。但是想要改善的话，我有几点建议， 一是要加强与客户的沟通。此时 XP 编程中的一条原则“现场客户”就非常适用。如果我们 能够经常地和他们沟通，听取他们的意见，而且在开发的过程中按照“瞄准-射击-调整”的方式，能够少走不少的弯路，也比较容易得到用户的认可。（但在这个过程中就要注意与 客户之间沟通的技巧，建议阅读我翻译过的与客户调情）。其

5、次是放下程序员的架子 ，把自己放在和业务人员同样甚至是低一些的位置上，虚心向他们学习，从客户的角度去 理解业务流程，想方设法让他们的工作更简单，效率更高，而不是一味地强迫他们按照我 们的思维模式去做，毕竟最终的东西不是我们使用。在这里一定会涉及到的问题就是变更管理，这也是开发团队和客户之间经常需要“打架”的 地方。其实有些时候，如果能够相互理解，不一味地纠缠在钱的问题上，反而更容易解决 。试想一下，如果对于每个小的变更都纠缠得非常清楚地话，那么很多时候就会造成之间 关系的僵化，从而客户不愿意把相关的业务知识告诉开发团队，那对于我们来说绝对是不 可弥补的损失，而且不是能够用 Money 来衡量的

6、。场景二：场景二：你这东西也太慢了，本来我做这件事儿需要 1 个小时，用了你的系统之后需要 2 个小时，我不得不加班！这个没说的，必须要调整了。很多人都收到学校中的一种思想的蛊惑；先把功能实现了再 说，性能那个东西可以用硬件来弥补，以后再调整也没事儿。其实，对性能的考虑不仅仅 是从开发程序之前就应该开始，而且是应该在整个系统开始之前就开始考虑，包括数据库 服务器、应用服务器的设计，数据库中的数据的存储方式、空间的分配等等，都应该在系 统开始之前就做了充分的工作，否则等墙快要倒了的时候，再去补，为时晚矣！性能应该优化到什么程度呢？我觉得最基本的原则就是，比客户要求的标准稍稍好那么一 点儿就可以了

7、，这样他们会觉得你对他们的反馈很重视，并且已经超出了他们的预期，一 定会满意的。场景三：场景三：你这程序界面上的东西太多了，我根本不知道怎么做。而且操作也太麻烦了，要 很多步才能完成一项工作。在没有完整的信息化系统之前，业务上很多的工作都是使用 Excel 之类的东西完成的，那 是非常方便的工具。但是使用了开发的软件之后，就必须改变原有的工作习惯，比方说回 车和 Tab 的使用，比方说增加新纪录的方式等等；此时就应该尽可能少地把操作的控制暴 露给用户，而应该尽可能多地由系统在后台完成工作。如果看到满屏幕都是各种各样奇怪 的控件，用户肯定会晕倒的。所以说，想要开发出来的程序对于用户来说真的可用、

8、易用，要做大量的工作。并且，随 着时间的推移，后期肯定还需要大量的调整工作。二二. 可维护性和规范性可维护性和规范性对于代码来说，这两个属性其实是紧密相连的。什么样的代码最好维护呢？当然是规范的 代码了。再差的规范也要比没有规范强得多。之前做对日项目的时候，日本人对于“规范”这个东西（他们称之为开发规约）要求的极为 严格。一方面会制定严格的规范来供大家遵守，其中不仅仅会包括对命名、代码格式的规 定，甚至还包括了每个控件之间的距离，代码的注释的格式，代码中的注释要达到什么样 的比例，每种代码结构（循环、选择等等）要怎么写，什么时候应该加空行等等，一般他 们的代码规范都至少会有 10 页左右的内容

9、。另一方面，他们还制定了比较完备的流程来 保证规范的执行，代码开发完毕，首先是要进行代码 Review，然后是进行单体测试。这 两个过程并非是在某些国内项目中，就是走个过场，在对日的项目中甚至还制定了标准，每千行代码中必须 Review 出多少个问题，必须要测试出多少个 Bug，都是有数量限制的 ，如果达不到标准，除非有充分的理由，否则这个过程是无法通过的。经过了这么多严格的过程之后，对日项目想要达到的目的就是“所有代码看起来像是一个人 写的”。尽管这有些理想化，毕竟每个人处理问题的思路还是会有些不同，但仅就代码来说 ，的确看起来干干净净，就像是同一个人编写的一样。自然在维护的时候，看起来至少

10、不 会有太严重的问题。相反，在某些国内项目中，对于代码规范的重视程度明显不够，很多代码中连最基本的缩 进和命名问题都没有解决好，更别提每个方法的长度，类和接口的设计等问题了。有时， 不得不对那样的代码进行修改的时候，我都会先把规范整理一遍，然后再开始修改。但是 ，就像破窗子理论一样，有时心情不爽的时候，根本就不会做修改，甚至还会加入更多的 不符合规范的东西。（那种情况是极少的了，哈哈。而且我不会署名啊，偷偷地闪！）由此看来，新编写的代码是否遵从了代码规范会给以后的维护和修改工作带来很大的影响 。可维护性体现在什么地方呢？我觉得就在于对现有的程序进行修改的时候，能否快速定位 到问题所在，而且在读

11、代码的时候，很容易就能理解代码所要完成的工作，那样才能够更 快速有效地对代码进行修改。在此必然会涉及到注释的问题，关于这个东西的讨论已经有很多了，我的观点是，如果能 够用较好的命名和清晰的代码说明的问题，就可以不写注释了。相反，如果仅仅看代码无 法理解的东西，尤其是业务上的知识，或者是业务流程上的一些特殊的要求，就非常有必 要写上注释，否则以后维护的人就不明白其所以然了。而对于对日项目中规定代码中的注 释率要有多少，就有些过分了。对于自身来说，想要编写规范和可维护的代码，其实也不是很难的事儿，主要在于态度。 记得当初我给公司的新人培训的时候，曾经说过：“我们应该编写什么样的代码呢？我觉得 有一

12、个原则，那就是别人在以后修改、维护你写的代码的时候，不会一边改，一边骂人， 他*，这是谁写的鬼代码，让我有打人的冲动。”呵呵，玩笑而已，但还是能说明一些问 题的吧。三、可测试性和健壮性三、可测试性和健壮性首先向说说可测试性，而这其中先要交代的就是测试的方法。大家都知道，在一个系统的开发过程中，有很多测试环节，而这些测试环节与设计与开发 环节又都是相互对应的，大概是这样：单体测试单体测试-详细设计详细设计结合测试结合测试-概要设计概要设计业务测试业务测试-需求分析需求分析但是，在不同的开发环境中，所采用的测试方法也都是不一样的。通常我们都会使用人工的测试方法人工的测试方法，尤其是对于界面上的一些

13、元素针对特定操作的反应， 只有真正能够得出想要的结果，那样才能够算是做好了这个功能。但即使是人工的测试，详细的程度也会有所不同：在对日项目中，因为会有人针对详细设 计编写详细的单体测试设计书，然后会有测试人员按照这份文档，对界面上的每个功能都 做详细的检查，看所提供的功能是否复合设计书上的要求。而对于整合测试，同样会有类 似的文档以及更高一级的测试人员来完成相应的工作。并且，日本使用计算机的程度普遍比较高，到了用户那里，同样会测试出一些问题。经过详细的三个步骤，加上厚厚的文档 ，最终交付使用的产品一般质量会比较高。而对于国内的项目，很多时间抽不出那么多人来做那么多的流程，所以一般测试都比较简

14、略，而很多开发人员对于应该怎样测试自己的程序也不甚了解，只测试最理想的情况，很 多的边界情况和特殊情况都考虑的不够。再加上整合测试做的不够，一般交给用户测试的 时候，会有比较多的问题。在这里，有人可能会说，我们做国内项目的并不是不想测试，也不是不会测试，而是时间 紧、任务重，要么要质量、要么要进度，二者权衡取其重，所以我们就用质量来换速度。 客户明天就要了，我今天才做好，哪有时间测试啊。但是，我还是觉得那样做，其实是在饮鸩止渴，项目之所会砸掉，很多都是因为用质量换 进度造成的。上面有些扯远了，其实我在这里想要说的可测试性针对的是另一种测试方法，也就是利用利用 xUnit 工具进行的自动化单元测

15、试工具进行的自动化单元测试。关于此最经典的东西可能就是那本测试驱动开发了，每次拜读的时候都会受益匪浅。然而，在很多情况下，想要达到那样的目标都比较困难，因为那需要编写很多测试代码， 而那些代码对于程序本身，或者更清楚一些，针对用户是毫无意义的，只是用来保证我们 确实实现了所需要的功能。而且，开发人员编写程序代码的时间都比较紧张，怎么会有时 间再去编写一份测试代码呢？我也是一样，似乎到现在真正编写过的自动化测试代码也不超过 20 个，只有在觉得时间 比较充裕，而且感觉到测试的步骤很多，必须需要自动化测试来帮忙的时候才会那样做。其实，测试代码与其说是给自己编写的，不如说是给别人编写的，给整个项目组

16、编写的测试代码与其说是给自己编写的，不如说是给别人编写的，给整个项目组编写的。我们经常会遇到这种情况，修改一个程序，改好了之后，自己测试了没问题，但是发布了 之后，发现其实有一种情况没有考虑到，或者说原有的程序中有一些特殊的处理我们不知 道，结果就会导致在某些情况下程序崩溃。如果有自动化测试代码，特别是自动化的整合测试代码，就可以在某种程度上改善这种情 况，每次在修改之后，只修改相关的测试代码，而不变原有的，那样执行一下，闪闪发光 的小绿条和小红条就会告诉我们的修改是否合理了。因此说，如果说自己的代码在可测试性方面完成的话，那就必须有相对应、比较完善的自 动化单体测试代码，并且测试的代码覆盖率达到了一定的程序，比方说 80%以上。接下来，我想说的是什么样的程序是健壮的什么样的程序是健壮的，看我的程序的抗击打性如何，哈哈。曾经在做对日项目的时候，有这么一种说法（大家一定觉得奇怪我怎么总是提对日开发， 希望大家不要对一件事物全盘肯定和否定，其实对日、对国内、对欧美三种开发模式都各 有各的优点，也各有各的缺点），那就是叫做“猴子测试猴子测试”！猴子怎么会测试呢？当