最近因为工作的缘故从底层又转向前端，在IE6的兼容改造过程中有了不少体会，在此记录一下：
- 在动手修改前一定先弄清楚问题所在。在修改过程中发现不少代码仅能算是“补丁”而不是“产品级”的代码。之所以这么说是因为我看到太多“头疼医头、脚疼医脚”的代码，比如看到在IE6下左边少了2px，则好不思考的就给CSS样式中增加一个margin-left:2px了事。对于这种代码我只能说这不是真正“职业化”程序员写出的。当我遇到类似的情况，我会先想想到底是哪里出问题了？为什么在其它浏览器下是正常的而在IE6下却是有问题的？顺便找几个关键字（上边例子的关键字可能是"margin bug ie6"）去Google一下。最终你可能会发现其实刚才的问题是一个典型的IE6 CSS Bug并且前人已经有很好的解决办法了。既然这样，你何苦自己去“头疼医头、脚疼医脚”呢？因此，找到你遇到问题的最根本原因才是最关键的，“头疼医头、脚疼医脚”只能增加潜在的问题（结果你会发现在其它浏览器中也许样式又不对了，或者你通过大量的hacks去做兼容）
- 不要不加思索的使用hack。我觉得如果能通过样式组合达到的效果就不要使用Hack，Hack是下下策。
- 修改完之后一定要多测试。这里指的测试是指加上不同的数据，特别是“临界点”样的数据进行测试会更容易发现问题。比如你写一个列表页，那你可能就要试试如果你的标题超长，人名超长，摘要超长或者没有摘要，你编写的页面是否能够继续胜任？例如前几天我在测试的过程中默认数据下是没有问题的，但是一旦有了翻页数据展现就出现问题了。因此一定多测试，各种情况的测试，很多时候我会在不断的测试中提高自己，因为我写代码的时候会有更多的考虑（避免出现测试中出现的问题）。相反，我最反感的是不假思索的说“我又做完一个页面”。有些人看起来速度很快，但是从整个产品开发过程来看这种多了之后会有两个明显的后果：其一，Bug数居高不下，同时reopen数量也非常高。原因不用我多说这也可以知道，就是因为永远不用心去测试你的代码，人家说有问题你就改，改了这个还有那个，然后再提，再改，然后就是无尽的反复下去（这种人一般在改旧Bug的时候也会引入不少新的Bug，这样的结果最终就导致产品发布期限被不断推迟）；其二，严重影响团队工作气氛。当你发现旁边的人完成的速度比你快（虽然他的代码质量很差Bug很多），但是由于（看上去）似乎完成的工作量多一些（当然，周报里也可以写得很好看）最终得到领导的表扬同时你可能会因为进度慢而被批评，这样以往下去谁会认真的去写代码？大家拼拼速度就行了，一个有技术含量的工作被逐渐变为熟练工。