可理解性（Understandability）——一个扩展视角

   可理解性与可测试性，可维护性，可扩展性，可重用性等属性一起组成了软件开发的内部质量属性。

 

   所有这些质量属性中，我认为最重要的的就是可理解性。

 

   首先我们来看看人是如何行动的。比如我要买一个手机，我会去网上找我喜欢的牌子，了解功能，价格，售后服务等信息。了解了情况之后，我们可能去手机卖场，淘宝等地方去实施购买行为。我在这里想表达的意思是，人们在做出行动之前，都会获取用于指导行动的信息，然后再进行行动。

 

   下面，我简要描述一个典型的软件开发过程：

 

   首先，销售联系客户，了解客户的需求后，和客户达成初步合作意向。销售带领公司售前技术支持去客户那里对解决方案进行演讲，以获得客户的认可。假设经过招标，最终拿下项目。这时，我们的需求分析人员开始需求分析，包括对客户高层，中层以及终端用户的访谈，收集报表等基础数据资料。需求分析人员写就《需求分析报告》，可能的话，和美工一起，把界面原型做出来。然后，开始去客户处演示。经过几轮的交流，需求基本得到认可。

 

    需求分析人员和设计人员交流，设计人员给出系统架构设计，数据库设计以及详细设计等等。然后经过设计和开发人员的交流，开发人员根据详细设计进行编码。如果前期设计人员只给出了架构设计和数据库设计，开发人员可能承担详细设计的任务。开发人员开始编码。开发人员交付测试。测试人员进行集成测试，测试人员进行确认。部署人员进行部署发布。

 

    可以看的出来，每个人都是其中的一个沟通单元，每个人获得信息，然后输出处理结果。每个人都是流程中的一部分，信息获取的多少，正确与否，都会影响我们的行为，进而影响你的输出。如果一个地方出错了，就会不断放大，而使整个系统处于颠簸和不稳定的状态。拿设计人员做一个例子：

 

    1）接受 需求分析人员传递的信息，通过召开需求宣讲会或是需求规格说明书 。

    2）设计人员理解 接收到的信息。

    3）设计人员根据理解的信息进行设计 。

    4）设计人员编写设计说明书 。

 

   设计的质量取决于需求人员传递的信息，设计人员本身对需求提供信息的理解，设计人员以往的经验这三方面。

 

   这里面最容易出问题的是三个地方：

 

   a. 设计人员接受的信息，也就是需求分析人员提供的信息可能是不完整的。

   b. 设计人员本身的理解也可能产生误差，取决于经验和对领域的了解程度。

   c.  需求规格说明书本身可能是不易理解的，也就是说工作单元产生的制品不具备可理解性。

 

    所有这些都可能造成工作的浪费，造成返工。这在软件开发中已经非常常见了。

 

    如果把这种沟通抽象出来，是三个方面：

 

   1）人和人之间的可理解性。

 

     我们每天的开会，日常交流，任务分配，培训，Presentation都是在人和人的交流。如果每个人都是一个可理解性强的人，就是说有足够的理解别人的能力（倾听，实现准备），有足够的正确表达自己想法的能力（需要不断训练）。信息就不会在我们之间堵塞（部分传递），变质（错误传递）。应该注意到信息是一个控制变量，遗漏信息和误传信息会影响到接收信息人的行为。

 

     我认为一个沟通流畅的团队就是一个优秀的团队。

 

   2）人和文档之间的可理解性。

 

     每天我们都在看文档，它是承载信息的方式。与人相比，它不会说话，不会回应。你唯一做的就是对它强加于你自己的理解。如果文档组织的好，结构清晰，就好像它会说话一样，那我就比较容易了解它的意图。仿佛它就是一个向导。反过来，可能会阻碍我的理解，更坏的结果是把我引向错误的道路。

 

     信息只有被用心组织才能有更好的可理解性。

   3）人和代码之间的可理解性。

 

    开发人员每天和代码为伴，很多人会修改以前别人的代码。好的代码会说话，坏的代码一句话不说，而且面目狰狞，五官发育不全。代码的可理解性是靠开发人员来控制的，是造一个天使还是一个怪物，全看我们的态度是怎么样的。

 

    写可理解性强的代码是一门艺术。

 

    总结下来，我想说的是，作为团队中的一员，你首先尽可能使你自己成为一个可理解性强的人，能够用心倾听，接受信息。也能够仔细思考你自己的表达方式，不要做闷葫芦，也不要用随意的表达方式表达你自己的想法。而是要考虑一下，接收你信息具体是什么样的人，如果我是他，我会怎么想。要针对不同的人呢，自己思考你的表达方式。要有意识的获取反馈，随时调整你自己的表达方式。写文档要考虑看文档的人，写代码要考虑看代码的人。

 

     两句总结：

 

    Do everything by intent。

 

    痛，则不通；通，则不痛。