JS+CSS+HTML 前端开发(四)

分工固然是件好事，但是有时候分得细了，关键技术的掌控者总是容易自高自大，自以为是，确立自己的特权地位，从而压制他人。
但是当分工达到一定的程度时，关键便不是关键了，似乎就成为了人人平等的世界。

当html，css，js都在一个文件的时候，我的关注点总在js上，或者是稍微关注一下css，但是对于html的重要总是提不起兴趣来，当我对其进行了完全分离后，渐渐发现html似乎才是首先要关注的框架，如果这个世界没有框架，无论如何你也不会创造出五颜六色的世界，更遑论生生不息了。

随着js，css以及html的分离，关注的顺序似乎彻底变化了，总是在html搭建完成后，渲染css，最后才通过js进行动态显示。当然一些简单的动态效果，则通过css啦，毕竟css的一些动态变化更加流畅，没有那些层次感和断裂感。 

随着项目的进展，以及某些需求的变动，发现在某些时候框架真的很重要，不仅是为了方便，更是为了规范，如果把jquery也称为一个js框架，那么使用它，绝不仅仅是为了精简代码，因为，你最终总要解释为js，不可能直接去向浏览器要效果，jquery可以认为是一个框架的集合，一个工具，一个让我们能借此打造丰富多彩的世界的工具。框架真的很有用，当然，自己写的更好，比较别人的东西用着总有点不是很顺手。

由于鄙人在线项目上的造诣还是太差了，所以没有选择任何css框架，基本采用了手写html结构，然后在chrome下一点点调试并书写css。chrome在这方面给了很不错的工具，个人感觉和ff的firebug一样强大，在我的慢得如乌龟般的电脑上能运行得很流畅，相比ff来说，可能更适合我的电脑吧（没有任何歧视ff的意思）。

说了很多都是一直在进行代码上的种类分离，简单些说，就是把不同类型的不同作用的代码写到不同的后缀名文件中。也许这是一个好的开始。因为我感觉工作的时候不像以前那么手忙脚乱了。尤其在出现bug的时候，能够不慌不忙的在各个文件中寻找问题，没有人能不犯错的，所以我能做的就是把改正错误的时间缩短，也许就能够节省出时间来预防错误。毕竟这是一个前进的过程。

html的书写从dw转为sublime是曾经郁闷过，但是还好，毕竟挺过来了。现在基本所有的结构都是自己搭建，相比于以往的冗余，也许自己写的更能够掌控吧。css的调整需要一定的耐心，首先是不同浏览器内核对css的支持有限，而css中像素的调整有时候需要你一个一个的去计算和测试，有时候也许只是一个属性的问题，以往写css总喜欢一上来就是详细绘制，弄好一块再弄一块，虽然有些时候，看着一个一个模块渲染出来，很有阶段性的成就感，但是也很容易产生问题，我们永远不知道同一个页面上，某个属性会对你的整体布局产生什么深刻的影响。

局限于眼前也许不太适合css的书写，就我而言，着眼于整体似乎更加符合css的书写风格吧。

经过多次尝试，现在基本采用了先计算并调整html中元素的长度和宽度或者像素数量，然后进行精细的颜色绘制，先总体后局部，感觉不错。

对于js函数的书写，早期写了大量的js，基本没有什么模块化的函数，也基本没有什么能重复使用的函数，因为开始的时候只是知道苦干，很多现在看来应该模块化的东东，都没有进行封装，很多时候都是参数的改变，居然写了很多没有传递参数的函数。

开始写的js基本都是从开头到结尾，一气呵成，当然也意味着以后别想轻松修改，也没有什么函数的概念，后来天天听导师说PDCA，不禁想，是否在程序上也PDCA呢，同时在coursera的学习课程中，学到了一些编程的思路，写代码也许不是最主要的，首先应该分解问题，进行WBS分解，然后实例化描述，然后进行抽象，最后书写代码。有了点理论上的上升，所以写的函数，基本就是用来体现WBS的，而对于模块化的概念尚未了解。

有些时候做的多了，也就找出了规律，写的函数多了，也发现很多都是代码的复用，因为个人比较懒惰，所以遇到相同的功能，总是去找以前的代码，粘贴过来，当copy的多了，发现有些函数都只是修改一下某个变量啊，等等。所以开始不断进行抽象，也就是把一些适合用变量来传递的东西进行参数传递……

这时候才感觉真是量变创造质变。