前端架构八大设计准则

1. 适度设计（第一准则）

无论是前端还是后台，这一条是通用的。

架构设计应以满足一定周期内的需求为目标。周期一般考虑一年即可，需求包括功能性与非功能性（优化，扩展等）。在这两方面都满足，并考虑一定的前瞻性的前提下（前瞻性：业务以及技术发展的方向）。

能少一个组件就少一个组件
这可能是大家所忽略的：每增加一个组件，包括研发、测试、运维、硬件资源占用的总体成本就可能会上升数万元。

能不用微服务就不用微服务
微服务是有一些优点，最近也很火。但缺点也很明显：响应时间增加、综合成本上升、管理复杂度高。对于中小型系统、不需要频繁发布的系统，采用微服务架构就像是用高射炮打蚊子。
 

 2. 避免问题扩大化

举个例子，当我们用A插件的时候，发现它存在一些问题，然后我们又引入了B插件来解决这个A插件存在的问题，依此类推。正确的做法是直接把A插件换掉，避免引发新的问题。

3. 本质思考

脑海中印象很深的一件事是，有一次我们做了一个文件上传的功能，刚开始有用户反馈上传速度太慢了有时候还上传失败，大家一致认为是用户的网络有问题，直到后面又有客户反馈这个问题。我立马就意识到，这肯定不是网络的问题，而是单文件过大，IIS的限制导致问题的发生。 后续的方案是采取了分片上传、修改IIS限制，解决了棘手这个问题。

4. 技术选型 

经常看到这样的情况，在做技术选型决策时，明知某种技术是最优的，但还是选择当前团队掌握的技术。这种决策可以理解，但对产品长远发展不利，极有可能在与竞品的PK中落于下风（性能以及用户体验上）。

技术行业最经典的一句话：没有解决不了的技术问题，只有解决不了问题的人。始终坚信项目是可以推动团队技术发展的。

5. 重视成本

很多架构师可能有这样一种思维：把架构设计得简单了，会显得自己很平庸。弄一个高大上的架构出来，方显本事，在领导面前述职时也有善可陈。

可是，如果太超前去搞这种复杂的架构，会白白增加成本。

架构师的每一个决定都会影响到成本。包括研发成本、第三方软硬件采购成本和上线后的运营成本。不同的方案，在成本分布和最终的总体成本上会不尽相同。需要我们综合权衡，才能决策出成本最优的方案。

成本关系着企业利润，最终也会影响到个人奖金。这种因果关系的体现周期虽然较长，也不是很透明直接，但道理不会错。身为架构师，每做一个决策前，先问问自己，这个方案会花费多少成本。

 6. 慎重审视“拿来”的东西

技术这块，一直都有“借鉴”的习惯，说的不好听一点，就是抄袭。前端这块更是严重，诞生了许多的“CV”工程师。

有的人做架构设计，完全是拿来主义，不从自己系统的实际情况出发；而另一种人，则完全自己发挥，不去调查类似系统的设计方案。

7. 重视流程 

现在早已过了FTP上传文件的时代, 那么现在重要的是思考怎么用工具和流程构建一个高效且避免出错的工作流。

工作流变得越来越复杂, 那些用于它们的工具也同样如此.。这些工具在提高生产力、加快效率和保持代码一致性上带来了惊人的效果。

大家有过中大型公司工作经验的同学都知道，每一个人的岗位职责都是非常明确的，遵循既定的流程。有人会抱怨流程太过繁琐（PS：我刚进大厂的时候也是这样，哈哈）。不过直到出了一件事情：一个实习生的误操作，导致项目直接崩盘了，离上线只剩几个小时。我原本以为上线计划估计得延后了，没想到领导很淡定，切另外一条线就可以了。

开发的工作流程需要规范化，这样才能提升工作效率、降低错误成本。

比如开发环境的准备，至少要有三个环境：开发环境，测试环境，生产环境。还可以加一个备用环境，各个板块是互相关联而又不在一起的，出错了也不用慌，有其它版本。
 

 8. 性能测试

网站性能基线与行业平均水准和通用的最佳实践相比较是必不可少的。

推荐HTTPArchive(http://httparchive.org/)，它测试并记录了几十万个网站的性能数据。

数据分析：

 i.  页面大小：2061KB  

ii.  总请求数：99

iii.  可缓存资源所占比例

如果想让自己的网站比大部分网站都快，可以考虑设定一个目标：一个1648KB的网站，包括79个请求，其中44个请求可以缓存，这将使你的网站领先平均水平20%。
 

结语

如果对大家有帮助，欢迎点赞、评论和转发，感谢大家的支持。更多福利下方领取哦！