• 当然了，这些可能是我自己的理解，并不是最优的，所以没必要在自己的项目开发过程中按照这些方式做。你可以根据你项目的实际情况或者更利于你的当前团队既有的模式具体分析来决定怎么做，但是我们的目的————形成良好的代码结构，便于后期维护，以及团队协作。不要以为代码随便写没关系，后期维护起来你就知道“后果”了。

• 首先说一下我最开始写html代码的时候怎么构建dom的，那时候的想法就是总的页面用一个div来包住，从而实现所有的初始化样式或者说重置样式都在div上设置了，以为可以这样省下很多重复的css代码，其实并不是这回事，如果这样写的话，那么你的代码将会很将会很僵化，非常不灵活，所以后期我发现不能这样写dom结构，为什么呢！我们来设想这样一种场景：板块1和板块2是页面中两块不同的内容，板块1左右边距有个10px的外边距，而板块2没有边距，而是贴边的。如果用一个div来把这两块内容包住，然后在div上设置padding:0px 10px来实现左右的外边距，对于板块1来说，确实不用写margin来实现外边距了，可是对于板块2呢！这是我们只能通过margin等于负值来实现贴边展现效果，好像貌似这样实现了确实能达到效果，但是我们这里只是举了一个简单例子，如果是更复杂的生产环境中呢！不到不得已尽量不要使用负margin，因为页面负值之后你将很难管理你的页面样式。此外，我还发现一个问题，如果采用这样的dom结构，页面将会变得很难维护，比如你将来在这个div之内又加一些子板块内容，如果此时需要设置一些冲突的样式的话，那么就会在父div上或新div上设置一些冗余样式来兼容，这样你将变得头都大了！当然采用这样的布局方式还有其他很多问题，后面将一一说明！

• 那我是怎么布局的呢？我们还是从得到一张设计图开始吧，假设设计图如下：

我们分析一下页面结构，设计图顶部出现的是一个固定在顶部的搜索栏，中间是我们理解为产品内容区域，而底部是一个固定的网站导航栏，那么从现在开始，你的脑海应该呈现这样的一副按“块”分的设计图结构，然后分块完成之！如下图：

好了，现在每个块的内容或者样式都可以分开写了，这样就不会担心彼此互相影响了，那么怎么解决刚才那种布局中会出现的css代码冗余呢，比如这里如果三个块都有一个左右10px的margin，我只需要把这部分提炼出来单独用一个css类来表示，比如:

这样在每个板块用一下这个类就不会写重复的样式了！而板块之间都不影响了，并不影响将来扩展或删减，也不至于项目越来越到，你却摸不着头脑了！

• 虽然按“块”的结构构建你的dom结构，只是很微不足道的优化，但是我确认为它带来了以下优点：

我们可以发现完全没有注释，我们要找到bug的地方不费点力气，我想是很难找到的，所以良好的注释在团队合作中真的很重要。

• 当然我第一次喜欢上注释也并非是为了团队合作，因为之前前端我一个人在做，所以谈合作有些牵强，也不是没合作，但大部分时间自己在维护自己写的代码。所以我第一次迷恋上写注释是因为自己强迫症，总觉得那样写出来具有良好的代码结构，到了后面，发现确实注释能给工作带来很多便利之处。至少发现bug到修复bug完成不会像之前时间花费的多了，而且很容易找到出现问题的地方。

• 下面我说一下，在工作开发过程中我怎样采用注释的。需要提前说明一下的是，在团队开发过程中，注释是很好的便于团队合作，所以未必我下面说的注释就是最好的，你当前使用的注释结构也不一定是差的，总的看团队合作模式，大家已经有了稳定的约定俗成的注释模式，那么就保持这种风格就好！

• 因为本身html是标记性语言，有开始标签和结束标签，那么我也采用类似的注释结构，将每个块开始处和结束处都加上一个标记，以表明这部分代码表现是页面那部分内容。如下：

我觉得写注释跟前面按“块”的方式构建你的dom相得益彰，有异曲同工之妙，都能很好的表述你的代码结构，好的注释解释更能很好的说明这部分html实现的内容！

• 对于css代码注释，我的理解就是你需要说明你的样式用于那部分内容，或者实现什么组件样式。所以采用两种方式来实现对css代码进行注释。如下：

当然了，现在提供了sass和less等css预编译语言，它们的注释我也是采用类似注释结构。这种注释结构能很清楚css代码用于那部分内容和实现了什么样式。

• 我觉得js注释还是需要讲究的，因为曾经写过一种类型的样式，但是后面觉得不适合，看一下我最开始的写的js注释代码：

我发现上面的js注释方式能够很快帮你定位到出现问题的代码，并且很好的管理的代码结构，所以我一直在用！