四、提示信息

　　关于提示，我们这里主要说两点：

　　其一、很多程序员喜欢复制粘贴自己前面写的提示信息的代码（因为提示信息一般是封装好的一个方法），特别是类似的功能提示。 这样一来，经常造成一些不合理的提示出现。比如你在在删除失败的时候，复制了一份删除成功的提示，那么巧了，如果你删除的时候，传的参数处理存在Bug，可能你每次点删除按扭的时候，系统都提示你删除成功，其实这时是不成功的。有时候你写代码可能就是把脑代给写昏了，说不定你反复点来点去，一直认为是程序有数据处理的Bug，而实际上仅仅是一个提示错误而已。白白浪费你太多时间。

　　其二、建议Web程序多留些旁注，简单明了地告诉用户当前位置的操作方法。不加旁注，不是一种Bug， 但是它可以有效地规避由于用户操作不合理而给公司或者你个人带来极大的维护成本。如果你在写程序的时候，在每一个用户的关键操作点，都有旁注，相信你平时的麻烦事应该很少。喜欢加旁注的人，曾经一定有类似的伤心史。所以他长教训了：“我让你还不断地问！我哪有那么多精力解答你！”

　　五、性能类

　　谈到性能类，建议不同的项目区别对待，小项目有小项目的做法，大项目有大项目的做法，不同的项目在不同的阶段，针对性能设计也要区别对待，不建议一视同仁。如果是个小项目，日访问量不足百十来个IP，你也去做什么静态化处理，启用海量数据处理方案，搞复杂的服务器组织结构，那真是：“自作孽，不可活”呀。我曾经经手过一个Web站，本来访问量每天几百个不得了，有时候不足几十个，结果想了一大堆方案，预想着网站马上会有一堆流量。结果，流量没上来，项目搞了半年还说不合理，承受不了大的访问量，天天又纠结一些几乎不会出现既便是出现了也不会对站点造成什么影响的Bug。最后商机慢慢也没了，烧了几百万，换了几张空页面。股东吓的纷纷撤股。真可谓，有钱没地方使。

　　另外补充一点，给项目负责人看：项目的不同时期要把握好项目的进度，对测试人员也要有不同的要求，不要为了一味的排除所谓的Bug，而把项目做死了。再补充一点，给开发人员看，闲的时候，多找些程序优化的知识看看，多总结一些常见的Bug解决方法。在实际的项目开发过程中，自己知道的Bug处理方法尽量全部用上，至少在个人知识层面上不要出现Bug，这不仅是一种工作的态度，最重要的是对整个项目负责。经验多了，Bug会越来越少，重点就可以集中在逻辑功能的处理上，才可以使你的代码质量越来越高。

　　最后一条，老生常谈：我们做程序，要把用户当傻瓜，虽然不中听，但是确实是一条人间正道！