有关协同开发实际工作的问题

项目大了，出现的沟通中的无限效率底下。前一段在开发了个群组的后台管理系统，就是管理群组，管理里面发布的内容。但是任务分工的时候是按层划分的，之前没有这样开发过，笔者自己做的，就是像对方去描述我需要的接口，就很纠结，涉及到数组呀，键值的就很头疼，最开始开发的时候又没有数据，本来要是自己去封装m层就好了。大不了我的一些业务逻辑可以放到m层去做。d层就只放sql了。但是当合作的时候，合作的先把m写好了。对方感觉你要这样的数据就提过这样的数据就好了。但是痛苦的我要去符合接口的数据格式，我去痛苦的组合数组，以完成那接口需要的参数，代码开放完肯定存在不少的问题，问题出现的时候你没有可以肯定的代码。就只有一点点的跟踪，改别人写的代码。有时候参数先后的顺序可能错了，因为不一样的习惯。或者有代码的或者的逻辑的错误。调试起来就更加纠结。这个情况后来自己仔细想了想，把远程接口和本地接口分开是一个好方法，个人就自己写自己的本地接口，反正比较快，远程的放到一个文件，可以单独一个人开发，也方便有伪代码测试。在都不是特别的大牛，还是分模块开发，不要分层开发

    还有一个不得不提的问题，破开发机环境不会报错。怎么调试环境都不成，然后很多警告错误看不到。要是致命错误，页面白板 。然后写代码的时候只有靠经验去判断某个地方可能出警告。但是数据正常的时候是没有的，也不是很多开发者都会注意到的问题，然后移到测试机就是一堆的警告。

   还有环境真tm的复杂，后台前台不是相同的服务器，后台的机器就存储前台推送过来的ID，然后后来更加简单的条件去查出来这些ID，然后根据ID去用远程接口去取数据。前台推送用的是mcq，我们后台机器要启动队列，去写库。这样就造成以换环境就很多的脏数据，测试人员不明白。就去纠结某个ＩＤ的记录更改不了。那是因为通过ＩＤ到前台取得数据，但是更改的状态在后台是更新的，然后库中没有那条记录，造成更改失效。说到远程接口，很多时候也不是很可靠。就造成我们去痛苦的跟踪。还有很对ｄｅａｌ文件，ｃｒｏｎｔ，想测试一个东西好了没，得跑到好几台机器去看，排除。继续纠结当中， 　 

　　有好长时间没有来这了，去想想前段做的东西。