大家使用脚本或者样式来开发web项目的时候，难免会遇到一些排查“错误原因”的问题，当然，如果要是你的项目不是特别的庞大，可能难度还不大，顶多折腾你1到2个小时，也差不多能把问题解决了，但是，如果在一个稍微庞杂的系统中进行修改、完善一部分脚本和样式的时候，你的噩梦即将来临，下面简单描述一下，自己在这段时间内，进行这部分工作后的一些感想，希望大家能够少走弯路，直奔主题：
（1） 首先，要明确你要完成的功能或样式，啥叫明确？就是你必须在自己心中有了模型的情况下，能够将这部分功能很完美地实现，要达到这个目标，可不是一件容易的事情，你必须将需求完全理解，如果是你的程序经理负责需求的话，那么多沟通，多协商这部分功能的实际需要，并根据实现难度、时间进度等进行方案调整，最终确定一份可执行的需求方案，千万别小看这一步，虽然麻烦，但是，可以免去后来的诸多烦恼。
（2）然后，就可以开工了，先不要盲目地在原有工程中进行修改，至于原因，请往后看。新建一个工程，添加一个新的测试页面，然后，将你待实现的脚本或者样式逐一实现，%￥@#%@……%一顿编码后，要实现的功能或者样式已经基本成型，当然，如果脚本比较多的话，还是要多测测，尽量减少一部分bug的隐患；至于样式，可暂时直接写到页面上，随后再进行整理即可。
（3）这里先交代一下，之所以建议在新的工程中编写实现代码，原因就是为了排除原有系统中的一些隐形影响，类似全局样式控制，全局脚本调整等等，而且你需要修改的页面可能本来就有一些隐患，你的修改可能造成很多的连锁反应等等，当然，如果你觉得上述问题都不是问题，也可以直接在原有页面上进行修改。
（4）将实现的功能或样式代码添加到待修改的页面中，先不要忙着将脚本“对象化”或者将css进行文件另存，首先要保证的是页面能够正常地工作，并不是你将能工作的代码植入就能高枕无忧的，上面说的问题，必须一一校对，首先根据实际页面的数据进行功能测试，（当然，如果代码无法正常工作这部分，还要自己处理，估计会不会少加了一个“{”？），单元测试请做好，因为实际数据和我们测试的数据可能有所不同，虽然格式统一，但是内容会所有差异，这也会造成不少问题，当然，并不是每次都那样。……￥%……￥……一顿整合后，代码可以工作啦！
（5）终于完成了，我要check in代码咯，停！千万不要忙着更新代码，虽然你的代码已经能够正常工作，但是，是否和当初需求讨论的一致呢？有的时候很难讲，所以，在更新代码前，请再次和需求进行碰头，来确认这个功能是否符合要求，一般情况下，可能还要略微做下调整，问题都不会大，但是，如果你的第一步没有做好的话，你应该明白，现在自己的处境啦。
（6）终于可以更新了吧？当然，还有一些小工作需要处理一下，首先，将修改的脚本进行格式调整，当然，如果你喜欢对象化，完全可以将它的结构调整一下，当然，关键注释一定要注意添加；至于样式，如果仅此一个页面使用的话，存不存css文件，看个人要求了，如果在多个页面都有用到，建议另存为css文件，因为那样css的优势才能体现哦，最后的最后，如果有兴趣，把这部分代码先保存到自己的代码资源库中吧，以备以后之用。
（7）你可以更新代码了
以上是自己的一些感想，希望对大家能有所帮助~