1、拿到需求不要着急动手，先理清楚整体架构，拆分完成整个逻辑需要的步骤，罗列出来，按照罗列出来的逻辑去写代码。
好处：逻辑清晰，回看便于理解
2、一个需求之中的独立模块要拆分出来，尽量不要有重复的代码，封装封装再封装。
后端举例说明：例如一个插入金额的功能肯定有很多地方会到，就封装起来一个基础的插入金额方法，后续有插入金额就调用这一个方法，如果金额对应的表需要修改的时候，也只需要修改这一个方法。
前端举例说明：控件的复用和封装，同样的页面只需用一份代码
示例图：
好处：好对小需求进行单独方法针对修改，不影响其他大模块
3、js代码闭包使用时，传入和穿出的参数，尽量使用对象，便于扩展。
例如：方法X判断是否有x1 目前只在A方法用到，传出时只传 cb(null,true)
后来有需求，方法X还要判断是否有x2, 在B方法用到，而A方法没有，这时候需传出两个参数，就有可能对A方法造成影响，要修改A方法，很有可能遗漏或忘记。
如果原先传出的是cb(null,{x1:true}),这时候修改后cb(null,{x1:true,x2:true}),不影响到A方法的时候。
好处：不会对原方法造成影响，便于扩展
4、测试。 拆分后的代码，可以以每个拆分的小模块为测试单元测试，完成后再进行整个模块的枚举测试，看似繁琐，但会大大降低出问题的概率。
好处：减少bug
5、git上传代码。 记得先拉再提交！先pull再push,先pull再push！！
更新后的东西、外网用到的时候记得一定要上传git，不然别人不知情的情况下很容易替换了旧代码，造成影响
好处：节省很多处理冲突的时间，保证代码的最新和完整性
5、上线新代码时的注意项。 在上线代码之前，注意保留文字步骤，例如本次更新设计的代码文件、config文件、图片文件、数据库语句都罗列出来，更新的顺序也提前写好，完成之后按该步骤严格执行。这样更新的时候不会因为手忙脚乱造成错误。
示例：
好处：保证稳定上线过渡，不至于出错。
6、事情处理方法。 处理事情的时候尽量使用单线程，处理的事情，就尽量完成好，再去处理下一件。 如果实在有突然事情插入，就考虑能否快速完成当前事情，如果可以就完成后再去处理突发事件，不行的话也要记录下当前事情还差的步骤，再去处理突发事件，否则很容易遗漏。
例如：在测试修改了代码，突然有人喊你去做别的事，忘记了这部分代码改了，打包造成了错误。 或者事情只是草草完成，就去处理别的事，回头不测试直接使用。 跟玩数独游戏是一个道理，每一个推论都是建立在前面100%正确的前提下，如果前面出错，只能从来。
好处：一件一件事做完整，才能保证稳定。
7、提早做准备。 可以每天抽出一块时间安排出今天要做的事项，这样每天至少都在计划当中，虽然总会被突发事件打乱，但大多数情况下仍是可控的。
以上方法待更新...
很多时候不是我没有技能能力，而是方法不对、态度不端正。 但技能、方法、态度综合起来的才是我的专业能力。知行合一，只有真正做到了，才是真正知道了；知道了并不等于做得到。专业能力+沟通+同等价值观才是一个合格的人才。
