火车上，看完whiteman的自传，百无聊赖，续写日志。
上次关于追求极致，前端开发中，对于多次使用的函数进行抽离，从而创建了专门的js文件，从而创造了包含增删改功能的js文件以及包括读取sql统计数据的函数的js文件。虽然如此，我的总体js文件的体积得到了至少30%的缩减。这只是总体而言，但是由于js文件数量的增加，相当于零碎文件增加，相应的与服务器端的连接次数也增加了，相应的增加了http服务的负担。所以，有些时候相应的效率提高了，但是性能可能是伴随着会降低，而这往往是我们无法解决的事情，两害相权取其轻吧。（也许有些大神会说，这些不是问题。但是我个人比较相信老子的损有余而补不足的名言，一方的增加必然伴随着另一方的减少。）所以相对来说，我的编程效率提高了，但是某些方面js文件的性能有些降低。所以在某些时候，衡量一下这个网速不断提高的社会，当前的网速一定程度上，平均满足了现在这个多次连接下载js文件的稍微麻烦的需求。一般来说，为了降低http的连接次数，也是为了降低服务器压力以及提高下载速度，一般要减少诸如图片，css文件以及js文件和html文件的数量，同时减少它们的体积。从而提高网络性能，提高用户体验。这也是为什么很多人进行网络传输图片的整合，即把诸多小图标整合，合并到一张图片上，从而进行一次传输，多次调用的方便。同时，js文件以及css文件的压缩也是为了减少文件中一些空白字符等造成的体积冗余。
虽然此次将js文件中调用次数较多的函数进行分离，会导致http通信的压力，但是衡量编程速度方面的提高，这点损失对我来说还是值得的。
从宏观不断向微观挺进，从整体类型的分离，到函数的分离，不断细化，仍然未到极致。
借助于GIT的强大功能，发现很多时候模块之间的差异是一些特定，甚至相同的差异，通俗来说，就是某些时候只是一些变量的更改。所以，这些js文件，或者说js函数，是不是还可以继续抽离，继续细化。
如果将变量从函数中进行抽离，也就是说，面对类似甚至相同的业务流程，需要考虑的是数据流程的差异，既然业务流程相同，也就是说在相同的容器中，将盛放不同的液体而已。既然如此，那么把函数看作容器，变量看作液体，那么我在某些时候（这个项目中是大多时候）不再需要考虑容器，而只需要考虑放哪些液体而已。这就是简单的变量分离的基础。
极致仍是目标，变量分离，需要考虑考虑。