在这里我谈谈我对前端人员和后台人员协作的一点感想。希望大家能够指点迷津，也希望大家分享一下你们的协作方式。

我进入公司有一段时间了，参加了一个Web项目。在项目中，我主要从事前端的编码工作。从事前端开发期间，我遇到了一些问题，也有一些自己的感想。

前端开发人员的团队合作主要体现在调用后台开发人员编写的业务逻辑层方法。在此次开发中，后台人员会首先为业务逻辑对象编写一些常用的方法，如基本的增删改查，前端人员会去寻找这些方法进行调用。如果前端人员需要一些新方法，主要是通过两种途径来实现：1.口头告知后台人员：“我需要某某新方法”，然后后台人员去编写方法，编写完后，后台人员告诉前端人员该方法的位置，让前端人员去调用。2.前端人员首先在业务逻辑层添加新方法的签名，然后告知后台人员去编写该方法。

在开发中有可能会遇到一些问题：

1. 如果后台类库只由一个人负责，查找方法还容易点。如果后台类库由多人负责，而且每个人编码不遵循编码规范，造成类名编写规则不同，方法签名编写规则不同，一个业务逻辑层的类中既存在实例方法又存在静态方法，同一个业务逻辑对象的方法可能出现在多个业务逻辑层的类中，给前端开发人员查找方法带来困难。
2. 一个业务逻辑类中既存在对外的公有方法，又存在内部使用的私有方法，一个类中存在过多的方法，给前端人员查找方法带来困难。
3. 前端人员在业务逻辑层类库中搜索需要的方法，可能由于名称的类似或其他原因，误用方法。
4. 前端人员如果需要添加新方法，需要在类库中查找是否已经存在该方法，如果不能确定，需要前端开发人员问询后台编码人员。如果前段人员需要的大部分新方法都需要问询后台人员，会降低开发速度（有可能查询耗时，有可能后台人员出差无法问询）。
5. 如果后台人员编写完新方法后，没有及时告知前端开发人员，会延误前端的开发进度。
6. 如果前端人员在业务逻辑层的文件中直接添加方法有可能由于前端人员和后台人员同时编辑同一个文件而造成冲突，冲突后再去整合是一件比较费时间的事。
7. 如果前端人员在业务逻辑层的类中添加方法签名后，忘记告知后台人员，后台人员可能无法知道类中存在需要实现的新方法。

对此，我个人有一个考虑不健全的解决方案：在开发过程中，前端先行，由前端人员编写契约，后台人员进行实现。

实现方式：添加业务逻辑接口和业务逻辑类工厂。

简单流程：前端人员负责将需要的方法添加在业务逻辑接口中，并在工厂中添加创建实例的方法；后台人员将相应的业务逻辑类继承相应的接口，并在工厂中指定创建实例的业务逻辑类。

这样做的优点：

1. 由于接口由前端人员编写，且接口中只存在对外的公共方法，因此前端人员查询方法方便。

2. 前端人员不会误用自己定义的方法。

3. 如果要添加新方法，前端人员只需在接口中直接添加即可。编译器会告知后台人员业务逻辑类没有完全实现接口中的方法。

4. 前端人员不需要被告知新方法的位置，直接调用接口方法即可，解耦前端人员和后台人员的关系。

5. 前端人员和后台人员不会因同时操作业务逻辑类而造成文件冲突。

这样做的缺点：

1. 前端人员如果在接口中添加了新方法，在后台人员在业务逻辑类中添加实现接口中该方法的方法前，项目编译将不能通过。对于此种情况，我也想出了一个解决方法：项目中可以使用多个解决方案：一个总的解决方案（包含全部项目）、一个前端的解决方案（包含Utility、Model、IBLL、表现层等前端需要用到的项目）、一个后台的解决方案（包含Utility、Model、DAL、BLL、BLLFactory等后台需要用到的项目）、一个测试解决方案（包含Utility、Model、BLL、Test等测试需要用到的项目）。这样，前端在IBLL层添加新方法，就不会导致前端使用的解决方案编译不能通过。

2. 增加编码量

其实在开发中遇到的问题都可以通过团队成员的沟通得以解决，我是想通过一些机制尽量减少一些不必要的沟通，因为沟通是以花费时间为代价的。以上只是我站在前端开发的角度，做的一些思考。这些思考都是以提高前端开发效率为前提的，尽量分开前台与后台的关联，有些地方没有考虑其他团队成员角色的工作，有些地方肯定还存在问题。这只是对此次开发中，作为前端开发人员，遇到的一些问题而提出的一些解决方法的设想。

作者: NineTyNine_LP 发表于 2010-12-31 09:27 原文链接