浅谈项目测试阶段及Bug修复阶段所遇到得问题
进行了将近半年的项目进入了最终测试及bug修正阶段，在最近修改bug及代码审查的过程中，总结了一点心得体会。写下此文，做下总结。
1、 缺少有效地代码审查
代码审查（Code Review），是一个很有必要的流程。当开发人员自己写好代码后，首先需要审查一下自己刚刚写完的代码，包括代码的逻辑、业务的流程、设计的思路、代码的风格、必要的注释等等，这样一套流程下来，不仅可以很有效的发现程序中的bug，找出问题，改进代码，重构代码，而且可以加深对业务流程、功能模块的了解。
整个项目组也必须有有效的代码审查机制，可以拿出专门的时间、专门的人进行代码的审查工作。有效地代码审查不但可以为项目后期的集中测试以及bug修改，节约大量的时间、精力，而且可以避免已离职人员的功能模块及代码无人敢接手的情况。
然而我们现在进行的项目由于时间紧、压力大，因此并没有进行有效地代码审查工作，这给后期代码维护带来了巨大的成本，系统中到处充斥着垃圾代码，逻辑混乱甚至错误，让人崩溃的代码风格，五花八门、描述不清、混乱的注释。由于这些因素，往往一个bug的修改，70%的时间是在阅读整个功能模块的代码，然后才敢下手去修改确认的bug。
总之，代码审查是必要的，问题越早被发现那么损失就会越小，修复bug花费的时间就会越少，维护成本自然就会降低。
2、 大量引入的控件
在开发时为了实现某一项功能而引入开源控件是不可避免的事情，由于各种各样的原因，开发人员往往局限于功能的实现，而不对控件做进一步的了解，待产生问题时，往往不能快速准确的定位问题产生的原因，有效地解决问题。特别是随着项目的推进，大量开源控件的引入，不但导致项目js库以及css库的膨胀，而且对控件间可能产生的冲突都不甚了解。
以后会将在项目中用到得控件写成文章，给自己留一笔财富，也希望大家讨论学习。
3、 缺少对整个系统全局的把握
开发人员在修正bug的时候，缺少对整个系统全局的把握，仅局限在自己的功能模块，而忽略对关联功能、边界模块所产生的影响，测试提出的bug是解决了，但却产生了一连串的关联bug。在项目中遇到了不少由于对模块业务把握不准、调用关系不明晰，或者是修改别人的bug时遇到了“潜规则”而导致的这类问题。
4、 开发人员不能仅限于功能的实现，更要在实现时考虑到技术基本面的层面
项目中开发人员包括自己，有时往往会局限于功能的实现，而忽略技术基本面的知识。往往一个问题的产生会让人百思不得其解，但静下心来从基本的技术层面上理解，就会找到问题的所在，找到了为什么会产生问题，解决问题就明朗的很多。例如，项目中使用了iframe，然而iframe会阻塞主页面的onload事件，这导致了严重的bug，大家却不知如何下手，但在了解到iframe的这个特性后，采用了合适的方法，问题迎刃而解。以后会写博文专门谈到这个问题。
5、 整个web框架的缺陷。
项目UI展现部分沿用了公司一直使用的框架，这个框架是用原生的js + div + css自己搭建的。虽然是一直使用，但是却并不成熟、不完善，而且存在很多的问题。
第一， 没有成熟的js基础类库及工具库。
在项目的开始并没有使用jQuery等成熟的类库，而是在项目的中期才引入了jQuery。
第二， 没有统一的样式风格
项目不同的模块由不同的开发人员实现，但由于框架的局限以及在项目的开始并没有统一的样式、风格的规范，因此做出来不同模块五花八门。例如一个简单的“编辑”按钮，有的功能模块叫“修改”，而另一个模块叫“编辑”。
第三， 系统中各种莫名其妙的脚本错误
由于UI框架在搭建的时候具有较高的耦合性，不可避免的会影响系统的扩展性。在扩展的时候甚至修改的时候，稍不留神就会产生莫名其妙的脚本错误。
总之，界面UI是一个web系统的脸面，界面往往可以决定项目的成败，而UI框架的选择及搭建可以直接决定脸面的成败。因此，成熟、稳定、完善、可扩展的框架是非常重要的。
6、 版本号、注释以及文档的重要性
部分开发人员貌似很忙，忙到连写一个完整的注释的时间都没有，更别提写功能模块的文档。其实在项目中，并没有要求开发人员对自己的功能模块写出详尽的文档，但详细的注释、规范的代码这个不用要求，我想每个开发人员都会写吧，然而就是有一部分人却不注重，让后来维护代码，修复bug的人有一种强烈的擦屁股的感觉。
我想说的是你写的不仅仅是一段代码，而且更是自己的职业形象。要对自己写的代码，做过的东西负责。
上面所写的也算是对近期工作的一个总结，以及自己的一点心得体会，写出来也希望大家多多讨论自己在项目中遇到的问题，望大家指教。