最近发现自己的代码产出率下降多了，在编码期间会不断的去推敲代码是否合适，是否做到了该有的优化、语意化、代码分离、提高代码复用、增强代码的可读性。该让HTML做的事情，就尽量让HTML去做；能用HTML、CSS去帮助JS一起实现的功能，就尽量依赖于HTML、CSS，来减少JS的代码量，同时也不失代码的分离，各司其职，互相独立，这或许是一个极端，让三者（HTML、CSS、JS）互相帮助，互相辅助（减少JS动态生成HTML的代码；较少多个样式设置的次数；减少HTML中包含CSS、JS代码；尽量少去删除和增加DOM树的节点；是用innerHTML来代替内容，还是简单的使用显示隐藏，或者replaceChild代替原来的节点。。。），而又不能互相在代码上互相嵌入，依赖过大，保持必要的分离，从而达到一个平衡的状态，那么在性能、代码量等等上就是一个很好的权衡。 有句话说的好：“当你感觉一个功能的代码已经无法再增加和删除代码了，那么就行了”。但是这种感觉以及代码的质量的如何，那就是个人的功底和经验是否丰富了。自我感觉良好有时候也是一种自我封闭，应该保持学习和改变的心态。 但是这样做的后果很明显，项目开发时间拉长了一些（除非在相同的开发时间里，加班加点完成），所以在代码质量、开发时间上是不能成正比的，需要一个权衡。而这个权衡很大的一部分在于上头对于代码质量是否有一定程度的要求，而在开发时间上能够尽量的放宽，当然开发者本身的功底对于实现该需求在质量和时间上是否能够达到一个平衡，也是其中的一点。关键还是看上头是否重视该需求吧。 对于一些小需求来说，可能要求是尽快的产出，上头对此的重视程度不高，只要实现了功能，对于是否影响用户体验没有过大的要求，那么这样也去反复推敲代码的质量，是否有必要呢？更多的是从习惯以及对自己以后的发展负责去考虑这个问题了，养成一定的良好的开发习惯，这或许对自己本身来说是非常重要的。
2010-7-30 Update: 对于”Transfer-Encoding:chunked”HTTP响应头，虽然说它可以使得服务器可以以小块数据包的形式连续的发送HTML内容回来，或许有些人会认为：为什么不让他应用于Js，CSS呢，这样使得JS，CSS可以边加载边解析。理论上是可以的，但是实际是会崩溃的，在JS，CSS的响应头中应用它的时候，会造成JS，CSS加载失败，很悲剧的事情…… 2010-6-2 Update: 今天捣鼓了下设置HTTP文档的响应头Transfer-Encoding:chunked。对于Transfer-Encoding的作用，在《高性能网站建设指南》中所说的就是“块编码”，它是HTTP/1.1引入的，使用它HTML文档可以被分成多个数据块立即返回，而不需要浏览器知道数据的大小和确定响应的结束时间，这就允许浏览器在下载数据包后马上进行解析，使得页面的加载速度更快。而HTTP/1.0是通过Content-Length头来发送的，而且还是将HTML一整块的发送，所以浏览器在响应结束之前，不会开始渲染页面和下载资源。 可是经过一上午的折腾，给页面加上了这个HTTP头之后，出错了，Chrome下返回错误“ERR_INVALID_CHUNKED_ENCODING”。郁闷了很久，之后在HTTPWatch官方博客上看到关于这个的文章《Content Length & Transfer Encoding》，在文章的Example中提到了一句话提醒了我：“if you are accessing this page through a proxy it … 了解更多