1，自己负责的模块尽量不要让别人参与，可以求助，但不要在责任上把任务分配给别人
a) 如果模块简单还好说
b) 如果模块的业务逻辑复杂或者代码写的复杂，一部分是另外同事负责，难免产生不可避免的问题
2，不管业务逻辑复杂还是代码本身复杂一定记得加注释
c) 业务复杂就注释中写一下逻辑，因为后面维护一定会忘记逻辑。
d) 代码复杂，比如js中定义的变量与业务本身无关，只单单是为了代码立的flag之类的时间久了哪怕是自己写的也会忘记是干嘛的。
3，新增需求或者需求大改一定回报上级，不要自己决定
e) 需求可以确定是小的改动，比如页面的某个输入框的宽度等无关紧要的改动自行修改即可。
f) 新增的新功能需求除了超级微小的都得上报上级，正式邮件沟通，作为记录；或者需求的巨大改动牵扯到业务逻辑或是数据亦是如此。
g) 若是不确定，一样的处理方法，将问题捋清楚，然后和上级沟通。
4，代码的重用性要适度
方法或函数的重用性使用频繁，但切记不可紧密程度，否则某种情况下需要用flag分开处理会很麻烦，而且以后产生的影响也不能得到准确预估，会成为潜在的BUG；当然jdk级别的代码人家可以做到全球适用，我们就不相提并论了。
5，向非程序员人员了解需求时一定要前段后端一起参与
a） 完成任务本身就是需要前端展示和后端处理数据，这两人不了解，其他人接手就无从下手了。
b） 写设计文档两人要沟通好公用的东西，比如：参数名，参数格式
c） 提需求人员如果擅长写需求文档则无事，如果写的不够好，那就得开发人员将需求文档过目一边，对表达不清的地方加以更正，否则后期在需求上面产生分歧，无法追溯。