编写可维护的代码
软件的BUG修复需要花费大量的精力。尤其当代码已经发布之后，随着时间的增长，维护的成本愈发的高。当你一发现BUG的时候，就立即去修复，这时候你的代码还是热乎的，你也不需要回忆，因为就是刚刚写好的。但是当你做了其他任务，几乎完全忘记了这份代码，这时候就需要：
重新学习和理解问题
理解代码是如何解决问题的
另外一个问题是，在大项目或者大公司里面，经常是解决BUG的人不是产生BUG的人，而且也不是发现BUG的人。所以减少理解代码的时间就是最重要 的问题，无论这个代码是你自己以前写的还是团队中的其他成员写的，因为我们都想去搞搞新的有意思的东西，而不是去维护那些个陈旧的代码。
还有一个开发中的普遍问题就是，往往读代码的时间比写代码的时间还要多。有时候你钻研一个问题，可以花整整一个下午的时间来考虑代码的编写。这个代码当时是可以工作的，但是随着开发的进行，其他东西发生了很大的变化，这时候也就需要你自己来重新审查修改编写代码。比如：
还有BUG没有解决
添加了新的功能
程序需要在新的环境中运行（比如一个新上市的浏览器）
代码有问题
代码需要重写因为修改了架构甚至要使用另一个语言
因为这些原因，也许你当时一个下午写好的代码，后面需要花费几周的时间来阅读。所以编写可维护的代码对于软件的成功至关重要。
可维护的代码包括：
可读性
连续性
预见性
看起来是一个人写的
有文档
最少化全局变量
河南新华
1.利用浏览器的304缓存，但是304叫协商缓存，还是需要与服务器通信一次2.强制使用浏览器使用本地缓存（cache-control/expires），但是问题来了，不让浏览器发资源请求，资源怎么更新。
3.使用版本号，类似于a.css?v=1.0，b.css?v=1.0，做了更改的时候都变成a.css?v=2.0，b.css?v=2.0，有时候a.css改变了，b.css没有改变，不是多此一举吗？
4.使用数据摘要算法，类似于a.css?v=0abc23，b.css?v=65ao1j，如果a.css做了更改的话，a.css=v=1asd2j，b.css还是b.css?v=65ao1j。
5.很多企业，现在都静态文件cdn部署了，类似于http://static.cdn.com/css/a.css?v=0abc23，与页面分开部署了，
a.如果先部署页面，再部署资源：在二者部署的时间间隔内，如果有用户访问页面，就会在新的页面结构中加载旧的资源，并且把这个旧版本的资源当做新版本缓存起来，其结果就是：用户访问到了一个样式错乱的页面，除非手动刷新，否则在资源缓存过期之前，页面会一直执行错误。
b.如果先部署资源，再部署页面：
在部署时间间隔之内，有旧版本资源本地缓存的用户访问网站，由于请求的页面是旧版本的，资源引用没有改变，浏览器将直接使用本地缓存，这种情况下页面展现正常；但没有本地缓存或者缓存过期的用户访问网站，就会出现旧版本页面加载新版本资源的情况，导致页面执行错误，但当页面完成部署，这部分用户再次访问页面又会恢复正常了。
解决方法：改变命名方式，改成a_0abc23.css，上线的时候先部署静态资源，再部署页面。
