这要从很久的事情开始说起，前端最初的发展就像一团浑浊的云团，什么都往一块写，然后东拼西凑，最后竟然能运行。其实每个人前端人都会对页面的混杂感到头疼，谁不想好好优化一下呢？但是奈何那会没有成型的工具，更没有现在高质量的组件库，从此解放了我们的代码编写，真正做到了开箱即用，它不香吗？
从最初发展到现在，代码无非就是进行了高度的解耦，让每一个部分都负责自己的内容，把结构、样式与行为分离，使得代码的职能非常清晰，看什么都舒服。所以后来很多前端都要求把自家的网站进行重构，毕竟谁也不想接手上一代遗留下来的产品，自己重新写一套都比他们的要舒服。
为什么说前端的代码难以维护呢？其实主要是出于以下的三点：
浏览器层面
浏览器是我们前端人经常打交道的工具，其实是浏览器孕育了前端这个大家庭，也是我们生存的根本。假如用户不需要看东西，不需要进行交互，或者我们就不需要存在了。不知道大家是否了解过全息投影？等到那项技术普及的时候，我们又是做着什么样的工作呢？
虽然现在浏览器的兼容性越来越好，主流的浏览器一般都会兼容很多css属性，最起码常用的、多人使用的你是一定要支持的，像flex布局这种神仙属性。当我们习惯于使用某一个浏览器（如谷歌）之后，再尝试使用360浏览器，你会发现自己根部看不下去。就像你习惯于使用谷歌搜索，但是要你使用百度一样的道理。
所以前端浏览器之间的兼容是我们必须要跨过的一道坎，即使现在的兼容性越来越好，但是用户群体也有很多使用IE或者360浏览器的，我们也不能忽略他们的使用。可是有一句话说，兼容IE就是浪费生命，自己细品一下。
技术层面
由于每一家的公司使用的技术都不太一样，事实上很多公司都会有自己内部的框架，我们要使用他们内部的框架与现有的技术框架结合在一起，那也是一件很头疼的事情。即使你是一位刚跳槽进来的员工，也是要学习他们内部的技术框架你才可以进行项目的开发。
很多公司创立阶段的时候可能vue、react等神仙框架还没出来，就是jQuery的天下，我们的项目底层也不是一朝一夕就能改变的，所以很多公司即使知道了新技术的出现，也不会去使用，也是处于探索阶段。假设公司需要使用一种新技术进行代码的重构，也可能因为员工对新技术的理解还不够深刻，写出的代码也会存在一定的设计漏洞。所以理解不深，就很容易写出难以维护的代码，给我们的团队造成阅读困难，最终也会变成一个难以维护的项目。
团队合作
团队合作才是真正的难题，不像我们自己编写的项目，想怎么写都行，不怕有看不懂的时候。当我们提交代码的时候也是不用经过其他成员的同意，直接push到master分支。这些都是我们个人开发的时候做法，到了公司层面或者项目的层面，那你就直接收拾东西吧。
大型的项目一般开发人员是比较多的，每一个人都会负责不同的模块和不同的功能，每一个人都会有自己独立的分支，代码合并到主分支的时候还得经过审核，这是一个完善、系统的开发流程。所以项目越复杂，团队合作的要求就会越高。一般我们都会有一种代码开发规则，大家都应该相互遵守，不然我们就会污染正常的代码，导致项目难以维护。所谓团队合作的最大困难不是技术，是人。
小结：
除了我们要项目的代码进行解耦，把结构、样式与行为进行分离之外，我们还应该重视简洁、可复用以及结构化的特点。当你能够做到这些的时候，你的项目就会显得专业，代码的可维护性以及可扩展性就会越高，开发人员添加新的功能或者模块就会显得比较轻松。
语义化
HTML5出来之后，添加了很多新的标签和属性，而语义化这个概念就出现在前端人的眼中。之前我们编写结构代码的时候一般会选择使用div与类名/ID名的方式来命名一个模块，所谓DIV+CSS开发模式就是这样由来。那么这种方式可否可行呢？当然是可行的，而且别人用的很舒服，就是cv操作多了点。
当然缺点是有的，比如最主要的就是结构不清晰，无论是编写导航还是模块、亦或是底部，全程div。这样结构就不清晰了，如果没有加以类名或者ID名，根本不知道你写的代码是属于哪一个模块。而且还有一点就是对搜索引擎不友好，不能准确识别你的网站结构和信息。
那么如何看你的代码是否语义化呢？很简单，把所有的样式都去掉，看你的页面结构是否显示正常，一般语义化的标签都会有默认的样式。如果显示还可以，结构有序就是语义化比较好了，反之你就重新写一下吧。
模块化
模块化其实就是跟在语义化之后的，如果你的语义化做的比较好，那么相应的模块化就比较好了。我认为模块化的重点应该关注你的标签选择是否合理，比如文字就使用p/span标签，标题应该使用H1-6标签等。不能所有的文字都是用div这个万能的标签元素，能用p的就不要去用div，因为p本身是针对文字的，有一定的基础样式。
小结：
不过现在我们似乎不会关注这些东西了，因为有了高颜值组件库的出现，需要什么直接cv过来使用。但是我们注意的是，并不是说这样你就逃避学习的理由，因为无论是多高大上的组件都是由最基本的样式和结构组成的，学会背后的造轮子思想才是最重要的。当组件不能满足业务上的需求的时候，就需要你进行css代码的编写了。
盒子模型
一般面试或多或少都会问一下你关于css盒子模型的理解，如果没有准备的小伙伴可能会把内容搞混了。这里再重复一遍：
-
IE：元素的宽度由width+border+padding组成
-
标准：元素的宽度就是width，本身包括了padding+border
样式组织
关于我们页面的样式如何编写，也是我们要考虑的一个问题，我们关于样式的编写没有对错只有好坏。页面写出来，能够满足自己的期望那就是对的样式，是否合理又是另一方面的事情了。
所以这里可以参考一下样式的结构组织：reset.css+common.css+view.css
首先第一个是基本的样式标准，专注于底层的样式。这里的reset是指我们把浏览器默认的基本样式都重置一下，尽量满足所有的浏览器样式看起来是一致的。还记得我们之前说过通配符*吗？那是一个及其暴力的样式重置，但也是很危险的一个操作符。危险是因为需要遍历页面所有的元素节点，给他加上样式。这里我们就推荐使用网上的reset.css即可，都有很多供你选择，假如你懒得找且项目支持npm安装，直接npm i reset-css即可，简单快速方便。
common.css是指一些组件相关的样式，比如我们们如果在vue里面写代码的话就知道一个vue文件可以由三部分组成，其中一个部分就是可以让你编写属于组件的样式代码，这里我们重用组件的时候就会显得非常方便。关于view.css其实就是一个更高层次的编写，属于一个页面的样式文件。
选择器使用
选择器可对某一个节点进行样式编写，有同学可能会说，我能把我的节点样式应用成功就好，还需要关心它怎么使用吗？其实要的，我们先从css选择器的匹配方案说起，选择器是从右向左进行匹配的，.class ul li a p这样的选择器，会先从全局匹配p标签然后再匹配a标签，依次类推。
所以第一个问题就是我们一定要避免选择器的嵌套过深，因为很耗费性能。假如可以使用ID匹配到唯一的元素就不用使用其他的选择器了。也正是因为选择器的这种匹配规则，使得元素更高效的匹配，也是经过长期的验证得来的结论。最后我们应该更加注意样式的继承，避免多次编写重复样式，所谓少用组合，多用继承原则。
近年来出现的css预处理器可以有效地提高样式的编写，使用一种面向对象的写法，更大程度对样式代码进行复用，有stylus、scss、less等，读者可以自行去官网了解。
编码风格
样式风格：关于css的编码风格也是因人而异，一般来说我们应该使用多行的写法，因为这样可读性就更高。假如样式代码写在一行，难免造成阅读困难的情况。后期我们进行项目发布的时候可以进行对代码的压缩。
id/class：id选择器一般使用在全局唯一的元素节点上面，如果确定元素节点唯一的情况下我们就可以使用，但是假如元素节点不唯一，那么就推荐使用class。
良好习惯
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数前端工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Web前端开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上前端开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：前端）
最后
文章到这里就结束了，如果觉得对你有帮助可以点个赞哦，如果有需要前端校招面试题PDF完整版的朋友可以点击这里即可免费获取，包括答案解析。
：前端）**
[外链图片转存中…(img-8myi0ZmF-1713807153862)]
最后
文章到这里就结束了，如果觉得对你有帮助可以点个赞哦，如果有需要前端校招面试题PDF完整版的朋友可以点击这里即可免费获取，包括答案解析。
[外链图片转存中…(img-46mo2n0j-1713807153862)]
1530
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
