● 对于开发同学的要求：

　　1、环境稳定性问题：

　　- 严格遵守日常环境，预发环境的重启时间约定，避免测试环境不稳定造成的测试时间浪费。

　　2、代码变化需要同步项目组同学：

　　- 任何对于代码的优化，改动，无论多小，必须通知测试和PD同学，走流程，避免混乱。

　　- 更加不可以私自发布上线。

　　3、提高单元测试和自测力度：

　　- 鼓励开发同学内部进行单元测试的分享。

　　- 前后端联调的部分需要做充分自测后再提给测试同学测试，后期测试主导做好监督机制，相关smoke test没通过，不接受测试。

　　4、发布权限和能力：

　　- 每个开发同学都要有线上发布的能力，但是发布权限需要PM的严格控制。

　　5、开发内部互相code review：

　　- 严谨的对待自己的每次改动，无论多么小，大部分开发同学都曾经顺手做过一件小事，结果证明只要细心点，都不会错。

　　- 开发内部互相review代码，加强这个部分，同时提高开发代码质量。

　　- 这个部分测试同学也需要通过代码review来协助提高。

　　6、不要改动初期约定好的接口定义：

　　- 在开发中后期，除非不得已，不能改动接口定义，否则会造成测试同学接口测试的浪费和返工。

　　7、开发分工更加均匀：

　　- 核心模块不能仅有一个开发负责

　　- 测试也有这个问题，后期可以考虑把每次迭代的工作内容更加细化，并且分给不同的同学负责。同时可以做好备份机制。

　　8、和合作方保持及时沟通：

　　- 电话，旺旺，Email， 避免消息没有及时通知合作方，而导致的环境不稳定，造成时间浪费。

　　● 对于项目的建议：

　　1、代码使用SVN管理。

　　2、推拽版增加用户可编辑的模块，后续可以推出模块市场，增加推拽办的丰富性。

　　3、编码办提供模块代码，降低开发成本。

　　● 技术支持建议和考虑：

　　1、自动化掉ISV的反馈机制，接入kelude平台，减少技术支持的人肉投入，云木已经开始推动。

　　2、开始ISV公共组件的建设和使用。

　　3、帮助ISV提高站点的功能和性能：

　　a）前段页面的性能检查，可以尝试使用开源的测试工具：dynatrace，yslow.

　　b）死链接的自动检查等。

　　4、考虑如何保证升级兼容：避免每次升级的时候，ISV不得不悲催的改动自己的代码以适应升级。