做个商城吧在（一）前端架构概要
liuyuhang原创，未经允许进制转载
1、为什么要设计前端架构？
忘了谁和我说的了，前端没啥架构！无非是选择用vue还是用angular，用不用node之类。
但是在我眼里好像并非这样。框架和架构不是一码事！
对于如何配置，如何分类，什么功能前端做，什么功能后端做，都应该说的清清楚楚！
一个人写还好，爱咋写咋写，爱咋改咋改。
多个人写一个文件，结果必然是页面混乱，会产生各种同步校验，增加沟通成本，增加bug。
综上，一个前端设计，应该能够避免上述问题的！
2、如果这是我的团队做的，将是如何分配角色的？
从岗位设置上来说，前端的团队比较复杂的，
会分为产品，美工，UI，H5工程师，JS工程师，css工程师，node工程师，前端架构师，等等！
可能我一时拍脑袋就能想得起这么几个吧！专业性的还有专业性的工程师，那是各领域的了！
但是那是岗位招聘，不是具体的代码分工啊，分工是不同的，每个人写的内容是不同的。
生活就是一场战争，在战争中，必定根据轻重武器不同，根据人员能力不同，根据地形场景不同，
进行梯度配置，近中远分清楚，谁攻坚，谁侧翼，谁抄后，谁打洞，这样才能各司其职。
不是招聘了一个岗位的人员他就必定能做那个岗位的工作，也不是几个同岗位的成员工作能力是相同的。
做软件的，难以衡量的就是付出成果，一天下来进度不进反退的例子应该有很多（好在我没遇到，都是传说）。
正因为如此，同一个岗位的不同程序员的知识储备，阅历，代码量，代码种类都是不同的！
有些人css优秀，有些人js优秀，有些人gis优秀，有些人3d优秀。
除了个别领域的深入人才，还有一些就是兢兢业业的人，同样不可忽视：
比如大量代码迁移细心不出错的人，比如重复性工作能保持细心和代码规范的人等等。
所以，要因人而异。而这其中，不管是什么岗位的人（虽然身兼多岗的人会更多一些）都是有自己的作用的。
我在这里，只将角色分为三种：
①设计师：统筹与远詹，沟通能力强，能知道将来的诸多可能分支的人。
这种角色为将来做打算，不一定必须参与编码，但是对设计中会加入诸多限制，如：
数据格式的设置，时间格式的设置，封装的功能表现形式，扩展性应该如何。
这种人虽然不一定参与编码，但是一定会懂代码，属于架构师和产品经理之间的角色了！
②架构师：封装架构师，规则制定者与推广员。
这种角色为整个项目打好基础，制定一套规则。然而规则无好坏，使用什么框架都可以。
他制定的规则，一定是满足一定的需求的，健壮性，扩展性，移植性，研发便利，接纳程度，低复杂度等。
这种人一定是参与编码的，对技术有执着的追求，同时又有开放的心态，善于沟通与倾听！
③程序员：普通开发者，代码的生产者与搬运工，测试员。
这种角色是项目的实际推进者，是最广大的组成部分，同时又是矛盾的集合体。
有些人认为自己很有能耐又不踏踏实实写代码，又不提出建设性建议，只抱怨收入低，又不高效。
有些人认为自己踏踏实实的推进项目，不受赏识，岗位太底层。
实际上大多数人都是这样，都是从底层代码量看着，有个靠谱的人带着，一点点成长起来的。
对于这种角色，是需要潜心维护的，是要钱，是要权，是要知识，是要重视，全看管理者来激发效率了。
对于项目经理，产品经理，架构师，技术负责人这四个角色，很多时候是可以互换的，不仅需要一定的管理才能，
远詹能力，又能够踏踏实实的推进项目，维护项目成员关系，才是最重要的！
3、前端架构设计有什么约束？
说了这么多关于角色分配的问题，就必须说前端架构设计，前端的架构设计和实际项目的角色分配是分不开的。
如果人员比较多（8人以上），那么就肯定需要一个项目经理专职管理，一个架构师或技术负责人在技术上服人。
但是不管人多还是人少，工作内容还是分开的好，防止侵入式代码污染是必要的！
3.1.工作内容的分割，主要是两种方式，缺一不可！
①纵向分割：
纵向分割，指的是将项目中的技术难度，进行纵向分割。从难度高到难度低。
实施上：必然有人做全局设计，有人做封装，有人做复制粘贴。
管理上：必然有人做反馈，必然有人做统筹，必然有人做分配。
②横向分割：
横向分割，指的是将项目中的实际实施内容，根据业务需要，根据文件分割规则，每个人负责不同的部分。
公共部分：耦合度较高，谁都会用到，由架构师或技术负责人进行统一编写。如配置，公共工具等。
分离业务：耦合度较低，一个人写一个模块或一个页面，或一类文件，由程序员根据架构师要求进行撰写，
其中会调用架构师制作的各种工具，使用架构师的统一配置，遵循架构师设计的规则等。
3.2.那么实际工作中如何进行约束设计呢？
个人认为，前端架构的约束设计主要有几种问题需要解答。都解答了，那么约束就确定了！
①项目预算允许几个人以多高的薪水来做？
不同的薪水程度决定了程序员使用技能的深度，比如js和jsp程序员入门都会，
但是node和es6可能很多程序员还没听说过，angular1还用不明白可能就不理解angular2中的各种功能了。
②项目成员的技术栈的公共部分是什么？
公共的技术是必须应用的技术，比如都会jquery，非要禁止，那就是架构师或者技术负责人脑袋有泡！
③项目的访问量有多少？
项目的访问量，可以根据最大的访问人数，页面深度，每天业务进行数来计算，然后将访问量从每天24小时，
缩小到每天2小时，或者更少，算出每秒访问量来。以此推算是使用静态资源的RESTful设计，还是动态设计。
④有没有时间和人员去踏坑？
假设手头有成熟的ssm为基础的架构设计基底，是否要使用springboot，取决于时间、人员和项目具体内容了。
⑤是否是分布式，高效集群，离线大数据业务？
不是说前端架构么，这怎么越说越偏后端了？
请求方式是如何的，是否需要sse推送，是否需要websocket连接，是否会调用外部API（地图，语音识别）等？
这些问题考虑上去，必定对前端的设计有一定的要求，有关联的了！
⑥项目成员是一人多面手，还是每人只负责一小部分技术？
这个问题当然和人员和项目复杂度和预算都有关，看起来人手足够，但是做起来撂挑子的项目也不少。
实际上产生问题的原因并不复杂，就是没有做好功课。什么功课？必然是对项目本身的了解程度了！
什么样的需求，决定什么样的供给，过多过少的配置都不对的。人员技术越好，沟通问题也许越复杂。
如果学过项目管理，应该知道降低沟通复杂度，是管理项目的较好方式。
降低沟通复杂度的实际方法，就是将项目中的任务进行分级和分类了，上面说到的横向分割和纵向分割了。
⑦技术积累都有什么？
技术积累，可以是公司的技术积累，可以是个人的技术积累，不能说什么都在网上找。有些解决方案网上有，
有些即使有，也不适合当前的状况。
技术积累可以是底层的，可以是架构的，可以是表面的，可以是功能性的，可以是业务的，可以是复杂度解耦的。
⑧是否有确定核心需求。
项目立项的时候，应该会有核心需求，比如实现xxx功能，达到做xxx就能出现或者完成yyy的这种需求描述。
这种需求，就是核心需求，如果立项的时候并没有说明白，那么应该停下来讨论一下，核心需求是什么。
在核心需求之外的，一律可以视作为扩展需求或镀金，将需求分为三个档，逐层实现才对。
⑨安全性。
真的是相当技术的东西，安全性十分重要，各种网络攻击，各种校验，即有硬件上的，又有软件设计上的。
然而我能说的真心不多，因为我就没有那么多的经验。
作为互联网产品，安全性更加重要一些。作为内部的管理系统，安全性弱一些，但是校验依然十分重要。
⑩有多少功能表现形式是重复的？
比如表单提交，可以用form，可以用ajax。
比如checkbox，比如ridio，比如上传，比如缩略图。
比如页面跳转模式，比如悬浮框，比如提示，比如警告，比如打印。
还有一些css的，比如移动条，比如进度条遮罩。
除去整体外观设计之外，这些元素的设计和封装应该统一，经常用么，所以需要统一设计，统一封装，统一使用。
3.3.其他规则？
还有规则？有的，就我知道的，大概列举下比较重要可能引起争执的规则。
①命名模式：太老生长谈了，不就是驼峰或者下划线么。别忘了还有css命名标准呢？还有xml命名标准？还有常量。。。
先定下，别人的命名标准是可以改的，怎么方便怎么来，就是要统一。
②跳转模式：页面是如何跳转的，什么情况下用转发？什么情况下用重定向？
③ajax模式：ajax是否需要封装，是否和token有关，是否需要errorFunction，是否需要同步，是否需要只发送不接收
④js对html和css的操作规则：什么情况下使用js对html和css进行侵入式操作，什么情况下是例外的，什么情况下是禁止的?
如果岗位分的比较细，一个功能到底给css工程师，还是给js工程师，还是给h5工程师？
千万不要增加沟通成本，约束可以提前定好的！
⑤配置文件：js配置文件都应该配置什么？路由？id群组？app模块？
⑥常量与全局变量文件：常量的定义是否需要统一的维护，全局变量的定义与修改是否需要统一的维护？
⑦特效文件：这里的特效文件，即有css，又有js。比如鼠标指针划过的特效，动画特效，点击监听，键盘监听等。
如果这些特效，能够与业务分离开来，不属于业务的一部分，或者直接就是一整块业务，应当单独分离出来。
4、可能都有什么样的功能点？
前端功能点，主要从两个方面来考虑。
①架构功能点：为了整个项目在人员和代码的分配合理性和基础功能覆盖面而做的功能。
②业务功能点：为了整个项目根据业务的不同，封装出的符合一个统一主题的功能点。
4.1.架构功能点列举（应该列举不全）：
4.1.1.页面加载路由。
4.1.2.权限缓存池。
4.1.3.全局变量池。
4.1.4.ajax封装。
4.1.5.悬浮提示。
4.1.6.进度条。
4.1.7.文件上传。
4.1.8.文件缩略图。
4.1.9.轮播。
4.1.10.前端校验。
4.1.11.点击收集。
4.1.12.命名空间体系。
4.2.业务功能点列举（同样应该列举不全）：
4.2.1.用户注册。
4.2.2.商户注册。
4.2.3.用户信息完善。
4.2.4.商户信息完善。
4.2.5.用户登陆。
4.2.6.商户登陆。
4.2.7.用户设置。
4.2.8.商户设置。
4.2.9.商品上传。
4.2.10.添加购物车。
4.2.11.购物车结算。
4.2.12.订单结算。
4.2.13.订单管理。
4.2.14.商户订单管理。
4.2.15.商户统计。
4.2.16.平台审核商户。
4.2.17.平台审核商品。
4.2.18.平台处置商户。
4.2.19.平台处置用户。
4.2.20.平台发布信息。
4.2.21.平台统计。
4.2.22.接入IM。
4.2.23.店铺搜索。
4.2.24.服务范围搜索。
看起来要写的内容还蛮多的呢。
慢慢更吧就！
以上！