高效率开发

开发的问题

就目前的经验而言，做一个软件开发，主要的问题是：没有将开发的各个部分划分清楚。这样的问题，在单个人开发时候，造成的问题就是，需要花大量的时候去做一些无用功。在多人开发的时候，就是需要不断地去沟通。

比如，一个取出登录用户的信息的功能。一般的做法是，先做登录功能，做完登录功能之后，在登录的基础上，根据登录用户的ID去查询用户的信息。如果取出用户的信息有问题，要不断的调试的话，则要不断地重复登录，取用户信息 这一过程。事实上，取用户信息，在做这个功能的时候，不一定非得登录，只要知道用户的ID，就可以取用户的信息了。

这样的做法，会让登录与取用户信息完全绑定在一起，一旦出现问题，也不知道是登录出了问题还是取用户信息出了问题。这就是典型的没有把登录与取数据划分开的问题。

对于团队开发而言，比如，张三做了一个页面，需要李四提供数据。而李四提供的数据又要包括页面的样式。张三就要不断地与李四沟通页面的样式如何传错了，要怎么传正确的模式等。这样的情况，会导致张三与李四的职责不清晰。他们会将大量的时候浪费在沟通由于没有划分清楚的部分。

高效突破口

如何让开发做到高效？就如造一辆汽车一样，要把汽车的各个零件定好，然后分别去生产各个零件，并保证零件的可靠性。再将零件组成一个大的部件，如，将外胎、内胎、垫带与轮圈用螺丝组装在一起。做成一个轮胎……将大的部件组合直到最终组成一辆汽车。

这样做，使得整个造车过程可以得到有效的质量保证。并且，如果某一个零件有问题，可以很容易换为其它零件，而不会因为一个部分影响整个汽车的制造。

从这个例子得到启发，也就是解决高效问题的突破口——开发的过程应该是：最小级别的单元测试，次级别的集成测试，更大级别的集成测试，整个系统的集成测试。并且，要定义好每一个层面由次级别的哪些零件构成，每一个独立的模块都有专人保证其质量。

为什么会高效

导致低效率的主要原因是：**不可预测的错误原因，导致排错需要很长时间**。再进一步去看，导致错误不可预测的原因是：没有将整体独立成各个部分，一旦出错，都要从整体开始入手来找错误。对于越大的整体，就越需要更多的时间去排错。

对于个人开发，因为所有的不可靠代码都由个人来完成，个人尚知道有可能是哪里出现问题。对于团队开发而言，当一个团队A使用其他团队B所提供的功能时，团队B不能保证功能的可靠性，那么团队A将花大量时间去了解团队B所提供的功能是否正确，甚至要花时间去测试团队B所提供的功能。结果，团队A本需要做的事情都没有做好，时间白白浪费在对团队B的功能进行测试上去了。恰好团队A开发的功能也没有质量保证的时候，那么，一旦整体功能有问题，就要去考虑是两个团队中的哪个团队做什么模块出现问题。这样，花费了大量时间去处理整体。

如果是每个模块都有质量保证，那么要找到问题是非常容易的，从而这方面的时间得到节省。往往一个项目的真正写满足功能的代码所占用的时间是非常少的，大多数时间都用在调试功能是否正确。一个正确的出发点，将会节约调试的时间。

开发一个企业项目

在做一个项目时，会有以下的考虑，项目的业务模块，用户模块。以销售系统为例，一个销售员登录到系统，录入他的销售信息，这就属于项目的业务模块；一个销售员只可以录入自己的销售信息而无权录入其他人的销售信息，这就是项目的用户模块。绝大多数项目都可以分为两个模块：

1. 业务模块 处理业务逻辑
2. 用户模块 处理用户的认证，用户的权限控制

那么在开发项目的时候，完全可以将业务模块与用户模块分离。即，做每一个操作的时候，不需要登录才能操作，更不需要权限才能操作。而只是保证一个操作是完全可以成功的。比如销售系统中，销售员录入销售信息，就是将销售信息放入数据库这么简单的事情。没有掺杂着，是否登录，是否有权限的判断。

public class SellService {  ...  public void sellProduct(Product product, int number) {    user = getUser();    user.sell(product, number);  }  ...}

同时开发的用户模块，负责处理用户是否登录（如，通过session），并提供用户权限判断的功能。在这些功能开发完成并保证其质量可靠的时候，将权限加到需要的地方（集成）如：

public class SellService {  ...  public void sellProduct(Product product, int number) {    user = getUser();    checkPrivilege(user, CAN_SELL);  // 这是新加的    user.sell(product, number);  }  ...}

在业务与用户都保证自己不出错的情况下，这个 SellService.sellProduct 出错的可能性就很小了，而一旦出错，也可以马上知道，大概率的是集成出错。那怕是小概率的两个子模块出错，也可以思路很清晰地去跟踪这两个子模块。

这样的做法，就决定了 Service 存在的意义。Service 是一个将各个子模块集成的产物。

总结

俗话说，大事化小，小事化了。将一个大的问题分解成一个个小而容易解决，也容易对其质量负责的部分。那么大事也就了了。常说的一团乱麻，一团浆糊，就是形象地道明了，当事情没有被分解的时候，人会无法清晰地认识到事情，从而让人在一个整体中无所适从。这就是本章要说明的问题。