这几周，看了各种各样的代码，经过一堆代码review，也有了一些基本上的码农感觉。打算记录下来，这样以后忘记了还能回来看看。本来上个星期就想写这篇文章的，结果星期天晚上被叫回去修bug了……

 

　　下面分css和js来记录。

 

　　在传统意义上，css的书写，只要能够将效果表现出来，同时前面的selector不要太长就好。这样在项目比较小的时候，修改起来就十分方便。但是，当整个项目开始极度膨胀以后，css就会变得极其庞大。1000+行的css轻轻松松就能写到。

 

　　在review过程中，可以发现，大部分的css都是无法重用的。一个button样式，基本都只能是在当前页用用，而无法用于整个网站button的基类。所以，在这里，就有一个概念，就是页面中的元素style，是通过一堆class拼凑出来的，每个class都是有自己的样式，比如：

 

　　博客园编辑文章下面的发布按钮，它的样式是这样的：

 

　　这就是我们平时书写css的习惯，一溜样式写下来，效果有了，就可以回家洗洗睡了。但是，这些样式，就基本只能用在下面三个按钮上，其余的button就无法使用这些style了。

 

　　当然，我们可以把里面的css抽离出来，让它大部分代码可以在整个站点使用。如下：

 

　　这样做以后，代码总行数好像变多了，但是它的可重用性大大提升。对于smallFont，whiteFont，leftFloat，darkBlueBackground等，这些类在使用中就可以不拘束在这个button中了，对于所有的字体，我都可以使用smallFont，whiteFont。这样，原来的input.Button就会由一些列类组装来显示按钮效果，如下：

 

　　当然，对于规模较小，样式简单的网站，这样做是没有意义的。在那些已经有了自己的显示规范，样式复杂，规模较大的网站，这样做在后期的时候，只要在html里进行class组装，再定制一下当前页简短的css，就可以快速的完成一个页面的开发了。

 

　　js方面，是被骂了无数遍以后才醒悟的。以前总喜欢写看起来高大上的代码，而且据说效率还很高，比那些传统的代码还看又好用多了。但是，这样的代码，完全是写给机器看的。在多人团队中，代码不仅仅是要写给机器看，更重要的是写给人看。在这方面，甚至可以牺牲一小部分的性能，来做出易读的代码。（注意是一小部分！比如多写几句var之类的）

 

　　这里要说一个关于传参数的东西。一般在js中，我们写函数时，参数的使用主要有两大派，如下：

 

　　参数一溜排开的方式，有一个优点，那就是很清楚的让别人知道，你需要的input是什么，要你的程序跑起来需要给你什么。这样在后来人接手的时候方便理解。不过一长串参数吊在函数后面，实在是有碍观赏。而且如果想多加一个参数，还要在后面再加一个名字。总感觉不是很优雅。

 

　　参数堆在options里面的方式，让人感觉很赏心悦目。这样的写法感觉很简介大方。但是如果是在这样的情况下：

 

　　function a（options）{balabala;b（options）;};

 

　　function b（options）{balabala;};

 

　　这样的话，想要知道options里面要有什么，就必须找到b里面为止。这还是简单的情况，如果有个5,6层的调用呢，简直要让人抓狂。

 

　　有人说可以用注释，在第一次写代码的时候，我们会去乖乖注释。但是，后来人修改你的代码的时候，哪有空改注释，这样反倒形成一个坑了。

 

　　现在我的做法一般是这样：

 

　　在函数开始的时候，清楚的写明我要的是什么，在出去的时候，写明传出去的是哪些值。options只在input设置中用，后面的函数体中就不再调用了。这样，函数虽然长了，但是在团队开发中，更有利于别人理解你的代码。而在你的具体processing中，别人可以当做一个黑盒，只在input中添加语句，processing后面添加几句，就可以完成修改了。这样更加节省开发成本。

 

　　我们经常担心传进来的objec或者function是undefined。这样很容易在后期报错。不过有一招，让你不用担心这个：

 

　　这样，即使没有options，没有options.noFunc，在后面的调用中，调用options.balabala和执行testFunc都不会出错。当然，在testFunc中，后面的默认函数的返回值的类型，最好和原来的noFunc返回类型一致，这样可以更好的增强程序稳定性。

 

　　好像不小心在博客园的博客上喷了博客园的css，希望不会被干掉……